本ページは広告が含まれています。気になる広告をクリック頂けますと、サーバ運営費になります(^^
後でActiveDirectoryをインストールして大丈夫？
この記事では、構築し終わったワークグループサーバをActive Directoryのドメインコントローラにして支障はでないか？という事について書いています。
設定しているサーバ機能
- リモートデスクトップサービス
- ファイル共有
- IIS
結論
リモートデスクトップサービスを利用するのにグループポリシー設定必要
ファイル共有は問題なく権限移行される
IISは問題なく動作する
リモートデスクトップライセンスの問題
先日構築したワークグループサーバです。
リモートデスクトップ環境を駆使しし、ファイル共有・Webサーバとしても構築しました。
やっとの思いで、ワークグループサーバでもリモートデスクトップ接続がちゃんとできるようになった！と思ったのに、なんかの拍子にログイン時このような警告が出るように。
このセッションは60分後に切断されます
痛い話です。せっかく全て設定が終わってさぁ使い始めるぞと運用を始めたら「リモートデスクトップライセンスの問題」で、60分後に切断されるようになりました。
ログオフにはならないので、ログオンしなおせば続きから作業ができるのでいいのですが、大きいファイルのやり取りをしていると、60分間でダウンロードしきらず途中で切断されるような事態に陥ります。
なので、せっかく設定したワークグループサーバをADドメインコントローラ―に昇格させてやろうというお話しです。今まで設定したサーバ機能がちゃんと動くのか？がポイントです。
ローカルユーザはどうなる？
ワークグループのサーバーをドメインコントローラに昇格させると
それまで存在したローカルユーザーはそのままドメインのADユーザーになります。
共有フォルダに設定したローカルユーザーのアクセス権も、ADユーザーのアクセス権に変わっています
共有フォルダへのアクセスは大丈夫そうです。権限関係も引き継がれそうですね。
ActiveDirectoryをインストールすると
ローカルユーザは、ActiveDirectoryユーザになりました。
アクセス権も全て移行されてます。
Windows2019 Active Directoryのセットアップ
手順はこのリンク先に従えばできそう。
注記：以前はActive DirectoryのDNS名として.localを利用していましたが.localはマルチキャストDNS (mDNS）で利用されておりWindows10(ビルド1803以降）やMac端末がドメインに追加されていると不具合が発生する場合があるようです。
DNS名に .localは使っちゃだめだそうで、外部で名前引きできないドメインとして .digitalとしようかな。
インストールが完了すると、ドメインコントローラに昇格する事ができる。
新しいフォレストを追加する ルートドメイン名必要
サーバ名.サブドメイン名.ドメイン
という構成で、とりあえずここだけちゃんと決めておけば、後は次へを押していけばインストールできる。あくまで他のActiveDirectoryと連携させない前提で、新規にフォレストを作成する場合の話です。
実際にインストールを始めて迷ったのは、ドメインコントローラオプション。DNSサーバをインストールしていない状態だったので、勝手にちゃんとインストールされるのかが不安材料だった。
この設定の中でちゃんと含まれていて、インストールされた。
リモートデスクトップで、ログインする際には
ユーザ名: サブドメイン名.ドメイン\user
で入らないと入れなかった。
しかし、以下のグループポリシーの設定をしたところ、自動的に補完されるようになり、
ユーザ名: user
でそのままログインできるようになりました。
リモートデスクトップサービスは動くか？
普通はActive Directoryをインストールしてからリモートデスクトップサービスをインストールしますよね。その逆手順でちゃんと動くのか心配。
順当な手順はこれですよね。
Active DirectoryサーバにRDSを構成すること自体あまりお勧めできないという人もいます。
NIFCLOUDの情報から
メッセージを表示しないようにするにはドメイン環境を構築する必要があります。詳しくは、以下のユーザガイドをご確認ください。
「リモートデスクトップライセンスに問題があるため、このセッションは60分後に切断されます。」と表示される。
対応策
RDSサーバーをドメイン環境として構築することで、上記のメッセージを表示させないようにすることができます。
また、クライアント側は構築したドメイン環境のADに参加しなくてもリモートデスクトップ接続を行うことが可能です。ドメイン構築の手順については、以下のMicrosoft社のサイトをご確認ください。
OSイメージ：Windows Server + RDS + Office
この情報から、RDSサーバが構築された状態から、Active DirectoryをインストールしてもそのままRDSサーバは利用できそうな気がします。
ActiveDirectoryをインストールすると
RDSサービスは動いているようですが、権限で問題が。
「リモートでサインインするには、リモートデスクトップサービス経由でサインインする権限が必要です。」
権限が引き継がれていて、「Remote Desktop User」グループに所属しているにも関わらず、こんな表示が出ます。Administratorsグループを追加するわけにはいかないので、グループポリシーの管理をクリック
起動したグループポリシーの管理画面から
フォレスト → ドメイン → グループポリシーオブジェクト → Default Domain Controllerを右クリックして、編集をクリック
すると、昔ながらのグループポリシー管理エディターが起動します。
Remote Desktop Usersグループを許可します
注意 この時 Administratorsグループを追加しておいた方がいいです。特にリモートでAdministratorで設定している場合、ここでAdministratorsを追加しておかないと次回Administratorでログインできなくなります。
これを反映させます。コマンドプロンプトを管理者として実行し
gpupdate /force
を実行します。
すると、無事に以前インストールしたユーザがログインできるようになりました。
この設定後は、ユーザの前にドメイン指定しなくても入れるようになりました。
IISは動くの？
Active Directoryと、IISを同じサーバで稼働させることもセキュリティ上よくないという人もいますが、同梱自体はできそうです。
IISがインストールされているサーバにADをインストールするとどうなるか？について書いている記事はみつかりませんでした。
IISを実行しているWindows Server 2008ベースまたはそれ以降のバージョンベースのサーバーにAD DSをインストールした後、組み込みのIISアカウントを解決できない
古いMicrosoftサポートの記事に、以前のWinodwsServerバージョンの情報はあり、IISを実行していてActiveDirectoryをインストールすること自体はできても、IUSRやIIS_IUSRSなどのIISビルトインアカウントが利用できなくなってしまう事があるような記載があります。
だけど、解決方法も掲載してあり、できない事はなさそうな気がします。
You have a server that is running Windows Server 2008 or a later version.
The server is running Internet Information Services (IIS).
You install Active Directory Domain Services (AD DS) to set the server as a domain controller of a Windows 2000-based or Windows Server 2003-based domain.
The PDC Emulator operations master role (also known as flexible single master operations or FSMO) is not located on the Windows Server 2008-level or higher-level domain controller.
この内容から考えれば、IISはWindows2008上で動いていてADをWindows2000,2003ベースのドメインとして設定した場合に起こる不具合のようで、新しいサーバではもう起きない問題でもあると読めます。
つまり、IISがインストールされているサーバに後からADをインストールしても問題なさそうな気がします。
Active Directoryをインストールすると
IISは全く問題なく調整も必要なく動いてました。
ASP.NETも利用していますが、ことらも問題なく動いてホッと一安心。内部でPostgresと連携もさせているのですが、こちらも問題なく動いています。
