概要
以前、アップしたOpenAMとOffice365のSAML連携が何だか中途半端な感じになってしまったので、
ちゃんと最初から最後まできちんと仕上げようと思います。
記事でどこまで書けるかというところですが、頑張ってみようと思います。
この記事ではAWS EC2インスタンスの作成～AD/AADCサーバの準備までを記載します。
EC2インスタンスの準備
前回の記事では端折っていましたが、土台の部分から記事にしていこうと思います。
構成としては以下を予定しています。
・OpenAM13：Linux(CentOS)
・データストア：ActiveDirectory(WindowsServer2016 Standard)
・アカウント同期：Azure ActiveDirectory Connect(WindowsServer2016 Standard)
最終的なイメージとして↓のような構成を予定しています。
まずはCentOSのイメージでEC2を準備します。
検証なのでt2.microでインスタンスを作成します。
vpcサブネットも分けないですし、特にいじらないで作成します。
ストレージ設定もそのままでいきます。
タグもいじりません。
セキュリティグループは後で変更しますので、とりあえずSSHだけ許可する構成にします。
作成したインスタンスにはElasticIPも紐づけておきます。
とりあえず、OpenAMのインスタンスは準備完了です。
※すみません、本題から逸れるため、記事では割愛しますがADとAADCもインスタンスを用意します。
ちなみにADはt2.micro、AADCはt2.smallで作成しました。
そんなに大きな規模の環境ではないため、少し控えめな感じです。
ADの用意
作成したインスタンス上にADを実装します。
まずはサーバーマネージャーを起動します。
役割の追加ウィザードを起動して、「役割ベースまたは機能ベースのインストール」を実行します。
サーバープールの選択は既定で選択されているローカルサーバー(自分自身)を選択します。
「ActiveDirectoryドメインサービス」にチェックを入れます。
ADインストールに必要な機能が表示されるので「機能の追加」を選択します。
「次へ」を選択します。
↓の画面が表示されたら「次へ」を選択します。
「必要に応じて対象サーバーを自動的に再起動する」はチェックを入れずに「インストール」を実行します。
インストールが無事に完了すると↓の画面が表示されるので閉じるを選択します。
サーバーマネージャーに戻って画面上のほうに↓のようなマークが表示されるのでクリックします。
「展開後構成」と警告メッセージが表示されているので「このサーバーをドメインコントローラーに昇格する」部分をクリックします。
「新しいフォレストを追加する」を選択して、「ルートドメイン名」にフェデレーションを有効化するドメイン名を入力して、「次へ」をクリックします。
「フォレストの機能レベル」「ドメインの機能レベル」は共に「Windows Server 2016」にして、ドメインコントローラーの機能には「ドメインネームシステム(DNS)サーバー」「グローバルカタログ」にチェックを入れて、ディレクトリサービス復元モードのパスワードを入力し、「次へ」を選択します。
後ほどDNSのインストールを実施するため、「次へ」をクリックします。
NetBIOS名はとりあえずドメイン名の短縮名を入力して「次へ」をクリックします。
データベース、ログ、sysvolの保存場所は既定値のままにします。
インストール内容のサマリが表示されますが特に何も追加するものも無いので「次へ」をクリックします。
windowsNT4.0と互換性のあるアルゴリズムが有効になっていること（本番の場合は放っておかないでくださいね）、固定IPが利用されていない旨の警告（後ほど変更します）が表示されますが、前提条件をクリアできるのでそのまま「インストール」をクリックします。
インストールに成功するとサインアウトを促すポップが表示されるので「閉じる」をクリックします。
再起動が終わって起動するとWindows管理ツールがインストールされていることを確認します。
サーバーマネージャーを起動して、ダッシュボードからADDSとDNSが起動していることを確認します。
Windows管理ツールから「Active Directory ユーザーとコンピューター」を起動してみます。
ツールを起動できることを確認して、ADがインストールできたことを確認します。
これでOpenAMの認証データストアとして利用するADの実装は完了です。
※1 記事には記載しませんがEC2インスタンスに固定IPを振ることを忘れないようにしてくださいね。
※2 固定IPに変更する際はAWSから割り振られているプライベートIPアドレスを設定しますが、この時、サブネットマスクの情報やデフォルトゲートウェイの設定を誤るとRDPできなくなってしまうので要注意です。設定をミスした場合は新しいENIをアタッチすることで再接続可能になります。これはまた別の記事で紹介しますね。
AADCサーバの準備
ローカルのADアカウント情報をOffice365上のAzureADに同期させるため、AzureADConnect(AADC)と呼ばれるツールを利用します。
まずはツールをダウンロードします。
以下のサイトから入手可能です。
https://www.microsoft.com/en-us/download/details.aspx?id=47594
まぁ公式サイトにはいろいろと記載されているのですが、検証用で利用する環境を作成する程度であるならば、2ステップで作成できます。
①ツールのダウンロード
②インストール
上記のように書くと簡単に使えてしまいそうな印象ですが、ほんとに簡単です(笑)
まずはツールをダウンロードしたら、最初に用意したAWS上のEC2インスタンスに配置します。
私の場合は圧縮した状態でインストーラを配置したので、解凍した後、インストーラをダブルクリックして実行します。
そうすると1分かからないレベルで↓の画面が表示されます。
そのままの勢いでインストール！！…といきたいところですが、今回は簡単インストールなるものでもっと簡単に同期を行えるよう「簡単設定」を利用したいため、前項で作成したローカルADのドメインに参加します。
というわけでこの画面は閉じて、AADCサーバをADドメインに参加させます。
「コントロール パネル」-「システムとセキュリティ」-「システム」と開いて、「設定の変更」をクリックします。
次に「変更」をクリックします。
「所属するグループ」に参加するドメイン名を入力して「OK」をクリックします。
うまく通信ができれば↓の画面が表示されるのでドメイン参加用のユーザーアカウント情報を入力してドメイン参加します。
※私の場合はAdministratorを利用しています。
いつもの「ようこそ」画面が表示されるのでOKをクリックして、サーバを再起動します。
再起動が完了してサーバが起動してくれば、ドメインに参加した状態になっています。
一応、私と同じようにEC2インスタンスでドメイン参加させる場合の留意しておくべき点について記載しますね。
【留意事項】
__ (1)Windowsファイアウォールが有効になっている__
__ (2)DNSはローカルADサーバを参照する__
まぁ、以前に以下の記事でもお伝えしたのですが、WindowsのAMIは既定でWindowsファイアウォールが有効なので、セキュリティグループと2重で制御がかかっている状況です。
＜【仕事メモ】OpenAM(Ver13) データストアの連携とローカル認証の確認（２）＞
https://qiita.com/Blue2012/items/e0884082878386937a2d
私の場合は検証用として利用している環境なのでセキュリティグループのみで十分です。
※そうでなくとも、セキュリティグループのみで十分と考えている節はあるのですが…
ちなみにインスタンスにセキュリティグループを設定する際はIPアドレスで設定しがちですが、↓のようにセキュリティグループIDを指定して設定することも可能です。
こうやって設定するとそのセキュリティグループを有するインスタンスやサービスからしか指定の通信を受け付けない設定とすることができます。
とっても便利！！ってご存知の方にとっては当たり前ですよね…
というわけでお伝えしたかったことはドメイン参加時も通信要件は重要になってきますのでご注意をということでした。
ドメインに参加した状態でAADCを起動すると↓のように「簡単設定を使う」がクリックできるようになります。
クリックすると同期先であるOffice365グローバル管理者のアカウント情報を入力する欄が表示されるので入力します。
同じように今度は同期元となるローカルADのエンタープライズ管理者権限のアカウント情報を入力する欄が表示されるので入力します。
入力が完了して、入力内容などに問題がなければ、最終確認のページが表示されるので「インストール」をクリックします。
※「構成が完了したら、同期プロセスを開始してください。」は既定でチェックが入っていますのでチェックを入れたままインストールをクリックしてください。
少し警告っぽいメッセージが表示されていますが私の利用している環境独自の内容であり、私が問題とならないことを認識しておりますので無視します。
ウィザードを終了した後に「Synchronization Service Manager」なるツールもインストールされているので立ち上げてみるとAzureADとの同期状態を確認することができます。
「Status」の値がすべて「Success」となっていればAzureADへの同期が完了していることを表しています。
そして、Office365管理センターにログインしてダッシュボードを確認してみるとタイルが１つ増えていることを確認することができます。
同期に成功すると「AAD Connectの状態」という項目でAADCとの接続ステータスを確認することが可能となります。
ローカルADにユーザーを作成している場合はユーザーの一覧情報にローカルADユーザー情報が含まれて表示されていることを確認することができます、今回はユーザーを作成していませんので、ここまで確認できればAADCの実装は完了です。
次回予告
OpenAMのデータストアとしてADを連携する部分を掲載する予定です。
…力が余ってたら、もう少し書くかもしれないです。