EC2からADサーバーを自分で作成し、WorkSpacesのディレクトリとして使ってみよう！

はじめに

こんにちは、孔子の80代目子孫、孔です。自己紹介に子の字が多いですね。この度、自分でADサーバーを作ってそのディレクトリを使ってWorkSpacesを構築してみました。

WorkSpacesを構築する際にAWS managed MSADやSimpleADを使うとより簡単にWorkSpacesの構築ができますが、そうするとその裏にあるディレクトリの仕組を理解することができないかと思います。ですので、ADサーバの理解も深めつつ、WorkSpacesまで構築して見ると、WorkSpacesの環境構築だけでなく裏のディレクトリに関する知識も付けることが出来るのではないかと思います。そこで、本記事ではADサーバの概念説明や、その他多くの基礎的な知識も丁寧にご説明いたしながら進めていきます。

かなり量が多いので記事を３つに分けたいと思います。まず最初に「ADサーバを立ち上げる」ところを本記事で記述します。その次の記事では「ADサーバにドメインを登録する」→「ADサーバにユーザーを登録し、リモートPCに接続してみる」をやります。そして最後に立ち上げたADサーバを使って「WorkSpaces環境を構築する」ところをやりたいと思います。

それでは、早速ADサーバを立ち上げるところから始めてみましょう！

ADサーバを立ち上げる

それでは、早速ADサーバを作成したいと思いますが、その前にそもそもADってなに？と思う方もいらっしゃると思いますので、ご説明いたします。わかりやすいように3つに分けて、「Directoryとは」「Directoryサービスとは」「Active Directoryとは」に分けて説明したいと思います。

Directoryとは
- 情報を収納するためのものを指します。データベースや電話帳などをイメージするといいでしょう。
Directoryサービスとは
- Directoryに収納された情報を見つけやすくするためのサービスを指します。例えば、DNSサービスも該当します。IPアドレスと紐付いたドメイン名に関する情報がたくさんある中で、それをクライアントが見つけやすくしてくれるからです。
Active Directory(=AD)とは
- Microsoft社がWindows2000から提供しているDirectoryサービスとなります。Windows server 2008以降では「Active Directory Domain Service(AD DS)」と呼ばれています。

と説明されても、どのようなものなのかあまりイメージがつかないと思いますが、この記事に沿って一つ一つ進めていただくときっと最後にはこれらがどのようなものなのか、イメージが付くと思います。それでは、習うより慣れろということで、とりあえずADサーバを立ててみましょう。

まずはWindows serverを用意します。本記事では「Microsoft Windows Server 2019 Base(ami-0e91b6337c71c2fad)」のAMIを使用します。インスタンスタイプはt3.smallを使いました。次に、セキュリティグループの指定が必要です。ちなみに、私がこの度ADサーバを作ったVPCのPrivate IPの領域が172.31.0.0/16となっていますが（デフォルトVPCのPrivate IPの領域です）皆様のVPC環境に合わせてどのIPアドレス向けにセキュリティグループをInbound許可するかを設定してください。

Custom UDP Rule	UDP	445	172.31.0.0/16
Custom UDP Rule	UDP	137 - 138	172.31.0.0/16
Custom TCP Rule	TCP	139	172.31.0.0/16
Custom TCP Rule	TCP	135	172.31.0.0/16
Custom UDP Rule	UDP	389	172.31.0.0/16
DNS (UDP)	UDP	53	172.31.0.0/16
Custom TCP Rule	TCP	1024-65535	172.31.0.0/16
DNS (TCP)	TCP	53	172.31.0.0/16
LDAP	TCP	389	172.31.0.0/16
Custom UDP Rule	UDP	123	172.31.0.0/16
RDP	TCP	3389	EC2に接続するIPアドレス
SMB	TCP	445	172.31.0.0/16
Custom TCP Rule	TCP	88	172.31.0.0/16

各ポートがどのようなものなのか気になる方は、ここのリンクの最後のところをチェックして下さい。設定が終わり、インスタンスが立ち上がりましたらEC2に接続しましょう。Windows serverへリモート接続する方法はこのリンクを参考にして下さい。Macの場合には、「Microsoft Remote Desktop」というアプリケーションをインストールする必要があります。

Windows serverへリモート接続できたら、server managerに入ります。

入ったら、次のような画面が出てきます。２番の「Add roles and features」に入り、このサーバで担当する役割を設定しましょう。

このような画面が出てきますので、「Next」をクリックし、「role-base or feature-base installation」を選択して次へ進みます。

次にこのような画面が出てきます。「Active Directory Domain service(=AD DS)」と「DNS server」にチェックを入れ、次へ進みます。この画面でこのWindows serverがどのような役割をするのかを設定し、インストールします。AD DSがこれから使用するDirectory serviceとなります。AD DSはドメインをサーバ登録し、そのドメインにユーザーを追加して管理を行います。例えば、googleの場合はkong@google.comのようにユーザー名を登録して管理していますね。それと同じ方式で、kong@domain.localのような形でADサーバがユーザーを登録をします。そのドメイン(@domain.local)の名前解決をする必要があるため、DNSサーバも必要となります。

指定が終わりましたら、次にどんどん進みます。確認画面が出ますので、最終確認をしてインストールを始めます。これでADサーバの立ち上げが終わります。

ADサーバにドメインを登録する

インストールが終わりますと、画面の右上の「Notification」（旗の形をしたアイコン）にインストールが完了したというお知らせが来ます。これからこのサーバはドメインコントローラーとなりますので、昇格させてあげましょう。「Promote this server to a domain controller」ボタンをクリックします。

これからドメインを作成し、そのドメインにどんどん端末やユーザーを追加していきます。Domain controllerは、このドメイン内に所属しているパソコンなどを管理する役割を果たします。ボタンをクリックしますと、次のような画面が出てきます。

「Add a new forest」をクリックし、ドメイン名（任意）を入力します。フォレストというのは、ドメインツリーの集まりです。例えば、サブドメインはあるドメインに属しているドメインとなり、まるで木のような形になります。これをドメインツリーとよび、このドメインツリーたちの集まりをフォレストといいます。

指定が終わりましたら次へ進み、パスワードを入力し、次へ進みます。このパスワードはドメインサーバに障害が起きた際に、DSRM専用のAdministratorユーザーでログインすることができます。サーバがドメインコントローラーに昇格すると、そのサーバのローカルAdministratorユーザーはドメインのAdministratorユーザーに変わります。つまりドメインコントローラーにはローカルユーザーとしてのAdministratorがいなくなります。よってDSRMを使って、ドメインのAdministratorでなくDSRM専用のユーザーとして入る必要があります。

次に進むと、DNS optionとして「DNS delegation（権限移譲）」をするかどうかが聞かれます。権限移譲とは、サブドメインに対してDNSサーバとしての権限を委譲することを意味します。今回は特にサブドメインは作らないのでチェックしないで、次に進みます。

次に、「Additional Options」では、NetBIOSドメイン名を指定します。NetBIOSドメイン名は、ドメインの別名です。test.localにtestというNetBIOSドメイン名を登録すると、testでtest.localに名前解決ができます。本来ユニークな名前を与えたほうがいいですが、今回はサーバが一台しかないのでtestにします。

これで設定は終わりですので、ほかはパスして次へ進んでください。最終確認が出てきます。インストールしましょう。

インストールが終わると、サーバを再起動する必要があります。再起動すると、以下のような画面となり、初期設定が行われます。所要時間は１０分程度です。

これで、ドメイン登録が完了しました。次は今作ったディレクトリにユーザーを登録し、そのユーザーを使って他の端末からリモート接続してみましょう。

ADサーバにユーザーを登録し、リモートPCに接続してみる

リモートPCに接続するために、同じVPC内にもう一台EC2（便宜上ユーザーサーバと呼ぶことにします。ADサーバとユーザーサーバで区別してください）を立てました。これからこの端末を先程作成したADサーバのドメインに参加させ、ユーザーサーバへリモート接続できる権限のあるユーザーを作成して、リモート接続してみます。

まず最初に、ADサーバからユーザーを新規作成します。まず「Active Directory Users and Computers」に入ります。

すると、このような画面が出てきます。test.localがドメインとして登録されていることがわかります。

test.localを展開し、usersディレクトリを右クリックして、新規ユーザーを作成しましょう。[users] → [New] → [user]の順でクリックしてください。

すると、下のような画面が出てきます。ここでユーザーの設定を行います。名前を入力し、logonするためのアカウント名を作ります。ユーザー名を入力し、パスワードまで指定すると確認画面が出て、ユーザーが作成されます。

このユーザーを使って別途作成したユーザーサーバからドメイン参加を行います。ドメイン参加とは、別の端末をあるドメインに参加させることを意味します。まずドメイン参加出来るようにユーザーに適切な権限を与える必要があります。先程作成したユーザーを右クリックし、「add to a group」をクリックしましょう。

すると下のような画面が画面が出てきます。ユーザーがドメイン参加するための権限を持つにはには「Domain Admins」グループに属する必要がありますので、グループ名に「Domain Admins」を入力し、右の「check names」をクリックしてからOKボタンをクリックします。これでユーザーがドメイン参加出来る権限を持つようになりました。

次にユーザーサーバに移動しましょう。ユーザーサーバに接続し、DNSのIPアドレスをドメインサーバのIPに指定します。これで、test.localというドメインの名前解決が出来るようになります。（ADサーバにDNSサーバも一緒に入っているからです）

設定が終わりましたら、ドメイン参加をしましょう。「system properties」画面に入ります。

画面の中央にある「change...」ボタンを押すと、以下のような画面が出てきます。「domain」にADサーバで登録したドメイン名を入力し、「OK」ボタンをクリックします。

するとドメインに登録できるユーザー名とパスワードを入力してくださいという画面が出てきます。先程登録したユーザーが「Domain Admins」グループに登録されたため、ユーザーサーバを端末として登録できるようになります。

以下のメッセージが出ると成功です。ドメイン参加をすると、再起動が行われます。設定に１０分程度がかかります。

ADサーバに戻り、test.localの「computers」ディレクトリを見てみると、以下のように端末が登録されていることがわかります。もし「RPCサーバを利用できません（the RPC server is unavailable)」と言われましたら、WindowsのFirewallやEC2のセキュリティグループが正しく設定されているかを確認してください。

リモート接続をしてみましょう。ADサーバから、まず先程登録したユーザーを「Remote Desktop Users」グループに追加します。

これでADサーバに先程登録したユーザーがアクセス出来るようになります。ユーザーサーバに戻り、「Remote Desktop Connection」を開きます。

すると、以下のような画面が出てきます。ADサーバのIPを入力します。「Connect」をクリックして、次に出てくる画面でユーザー名とパスワードを入力してみると無事リモート接続出来ることがわかります。権限がないと言われたら、ユーザーを「Administrators」グループに追加してください。

以上でADサーバ編は終了となります。これからこのADサーバを使ってWorkSpacesを構築してみましょう。

WorkSpaces環境を構築する

ここからは只今作成したADサーバを使ってWorkSpaces環境を構築します。その前にWorkSpacesは、１台でも立ち上げた段階で初期費用を取られます。立ち上げてすぐ削除しても、初期費用は取られ、かつ月単位で課金されますので注意してください。それでは始めてみましょう。

AWSのコンソールからWorkSpacesに移動しましょう。ダッシュボードから「Directory」に入り、「Set up Directory」をクリックします。

すると以下のような画面が出てきますので、「AD Connector」を選択し、次へ進みます。これに設定することで既存のADサーバにリダイレクトしてくれるコネクターを作成し、実際認証を行う際には既存のADサーバから認証ができるようになります。

Directoryのサイズは今回は全然大きくないのでsmallで十分です。設定し、次へ進みます。

VPCはADサーバを立ち上げたVPCを指定して、次へ進みます。

次の設定画面に移動します。任意の「Organization name」を入力し、「Directory DNS name」にADサーバのDirectoryのDNS名を入力します。「DNS IP addresses」にADサーバのIPアドレスを入力し、最後に先程登録したユーザー名とパスワードを入力します。このユーザーは、Directoryを操作する権限があるユーザーである必要がありますが、先程このユーザーにDomain Admin権限を与えたため、問題なくこれで登録ができます。

このように登録が完了しました。「Actions」から「Register」ボタンをクリックすると、このDirectoryをWorkSpacesのとして使用する事ができます。

登録が完了しましたら、ダッシュボードから「WorkSpaces」をクリックしてください。これからWorkSpacesを構築します。「Launch WorkSpaces」ボタンをクリックすると、以下のような画面になりますので、先程登録したDirectoryを選択して次へ進みます。

すると、Directoryに登録したユーザー一覧が出てきます。WorkSpacesは１ユーザーにつき一つのWorkSpacesを登録することが可能です。ユーザーを選択し、追加して次へ進みます。

構築したいOSを選択し、ボリュームを割り当てて次へ進みます。

Running modeとEncryption有無を選択する画面が出てきます。Running modeは2つあります。常にWorkSpacesを立ち上がった状態にするか、使用してないときには自動で電源を切るかの設定ができます。常時使用されるものであれば「Always on」でいいですが、今回はそうでないのでAutostopにしましょう。Autostopにすると何時間使用してなかったら切るかを設定できます。今回は一時間にしておきます。Encryptionは、特に今回はボリュームの暗号化は必要ないかと思いますので設定は不要です。次に進むと、確認画面が出ます。完了すると約２０分後構築が完了します。

構築が完了し、WorkSpacesを使える状態になりましたらWorkSpacesのクライアントを使って接続してみましょう。ここのリンクでクライアントをダウンロードすることができます。registration codeが必要ですが、こちらは構築したWorkSpacesで確認することができます。

ここに書かれているコードをクライアントに入力しましょう。

すると以下のようにユーザー名とパスワードを入力する画面が表示まれますので、先程設定したユーザーとパスワードを入れてWorkSpacesに接続します。

以下のように接続ができることがわかります。以上でWorkSpacesの構築は完了です。お疲れさまでした。

最後に

少し長かったですが、いかがでしょうか。WorkSpacesはDirectoryを使ってユーザーを管理していますが、Directoryがどのような仕組みなのかまだ理解できてない方々にこの記事が少しでも役に立てたら嬉しいです。私も初めてADサーバを立て、そのDirectoryを使ってWorkSpacesを構築してみましたが、大変勉強になったので、もし初心者の方がいらっしゃればこの知識を共有したいと思い、ブログを書くことにしました。

Directoryサービスに限らず、AWSは裏でいろいろなことを全部やってくれるのでインフラなど基盤となる知識がなくても使えてしまいます。それはとても便利で価値のあることですが、せっかくなので裏の仕組みがどのようなものなのかも理解しておくと今後応用もいろいろできるのではないかと思います。長い時間お読みいただき、どうもありがとうございました！