AWS Managed Microsoft AD と Azure AD Connect v2 をつかってAzure ADへID同期(パススルー認証)する方法
しばたです。
先日Amazon AppStream 2.0でActive Directoryドメインを利用(ドメイン結合)するためにAzure AD Connect v2を使ってAWS Managed Microsoft ADとAzure AD間でID同期を行いました。
本記事ではその具体的な手順を紹介します。
参考資料
本記事の内容はお手本があり、基本的には以下のAWS Security Blogの内容を踏襲しています。
こちらは元々Office 365に対するID同期の仕方を解説していますがAzure ADでもやり方は全く同じです。
AWS Managed Microsoft ADはマネージドサービスであるため一部Azure AD Connectの通常のインストール方法で求められる権限が不足しており若干ですがAzure AD Connectのインストール方法がカスタマイズされています。
本記事と併せて見てもらえると参考になると思います。
1. 初期条件
本記事では私の検証用AWSアカウントに下図の構成を作ります。
事前に用意したVPC環境のPrivateなサブネットにAWS Managed Microsoft ADとAzure AD Connect v2をインストールするWindows Server 2019 EC2インスタンスを構築します。
加えてActive Directoryの管理用に踏み台サーバーも別途用意しておきます。
VPC、AWS Managed Microsoft ADおよび各EC2の具体的な構築手順は割愛します。
なおEC2は本日時点で最新の日本語版AMI(ami-0f68012440b1be6df Windows_Server-2019-Japanese-Full-Base-2021.12.15)を使っています。
1-1. Azure ADの初期状態
Azure AD Connectを利用するにあたりAzure AD側も一定の初期条件が求められます。
今回は新規にAzure ADテナントを用意しexample.shibata.techというカスタムドメインを設定済みです。
1-2. AWS Managed Microsoft ADの初期状態
今回は代替UPNサフィックスを試すために敢えてshibata.localという.localな非推奨なドメイン名のActive Direcotry環境を用意しています。
AWS Tools for PowerShellからこんな感じで作ってます。
# AWS Tools for PowerShell で AWS Managed Microsoft ADを作成
$params = @{
VpcSettings_VpcId = 'vpc-xxxxxxxxxx'
VpcSettings_SubnetId = ('subnet-xxxxxxxxxx', 'subnet-xxxxxxxxxx')
Edition = 'Standard'
Name = 'shibata.local'
ShortName = 'corp'
Password = 'P@ssword'
}
New-DSMicrosoftAD @params
一般的な環境であればこの様にAzure ADのカスタムドメインとActive Directoryドメイン名は異なっているはずであり、この場合は事前にActive Directory側で代替UPNサフィックスをexample.shibata.techにしてUPNサフィックスをAzure ADのものと合わせておく必要があります。
(もしくはAzure ADと同期させる項目をUPNの代わりにメールアドレスにするなどの対処を採る)
この変更によりshibata.localドメインのユーザーであってもUPNをuser@example.shibata.techの様にexample.shibata.techとすることができます。
ちなみに、あまりない事だと思いますが、完全に新規に環境を作ることができるのであればActive Directoryドメインを最初からexample.shibata.techにして構いません。
1-3. 踏み台サーバーの初期状態
Active Direcotry管理用に踏み台サーバーを用意しshibata.localドメインに参加させておきます。
Active Directory管理に必要な各種ツールも併せて導入済みです。
2. Azure AD Connectの前提条件
次にAzure AD Connectの前提条件を確認しておきます。
本記事では上記ドキュメントから本記事に関連する部分をかいつまんで説明します。
2-1. Azure AD側の前提条件
Azure ADテナントとカスタムドメインを追加設定しておく必要があります。
いちおう既定のドメイン(xxxxxx.onmicrosoft.comなやつ)でも動作自体はさせることができましたが、本番環境で採るべき構成ではないですし、このため非サポートということでしょう。
2-2. Active Directory側の前提条件
ADの機能レベルはWindows Server 2003以降である必要があり、特にパスワードライトバックを使いたい場合はドメインコントローラーのOSがWindows Server 2016以降である必要があります。
現状AWS Managed Microsoft ADの基盤となるOSはWindows Server 2012 R2であるため、残念ながらこの環境ではパスワードライトバックが使えません。[1]
2-3. PowerShell実行ポリシー
Azure AD Connectのインストール中にPowerShellスクリプトを実行するそうです。
このためインストール中はPowerShellの実行ポリシーを変えておく必要があります。
(正直これくらいならインストーラー側でやるべきなのでは？と思いますが...それは置いておきます)
PowerShellの実行ポリシーの変え方は多数ありAzure AD Connectのインストール中だけ変えることもできますが、まあ、インストールユーザーのポリシーを変えるのが一番手っ取り早いでしょう。
Azure AD ConnectをインストールするOSユーザーでPowerShellコンソールを開き、以下の様に-Scope CurrentUserを付けてSet-ExecutionPolicyを実行しておいてください。
# スコープ指定してるので管理者権限は不要
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser -Force
2-4. Azure AD ConnectのOSスペックなど
現在の最新バージョン(Azure AD Connect v2)はWindows Server 2016以降のOSにインストールする必要があります。
そしてServer CoreではなくフルインストールされたOSでなければなりません。
また、OSに要求されるスペックはActive Directoryの規模に応じて変わり以下の様に最小要件が定められています。
CPUのコア数に関する記述が無いのはデフォルトでSQL Server Express LocalDB 2019を使うからだと思われます。(SQL Server Express 2019を使う場合は CPU 4コア がライセンス上の上限ですのでご注意ください)
今回は検証用なので本当に最低限のスペック(t3.medium、70GB EBS)としています。
その他細かい条件はドキュメントをご確認ください。
2-5. 通信要件
Azure AD Connectを使う環境での通信要件は以下のドキュメントにまとめられています。
細かい点はドキュメントで確認してほしいのですが、重要な点としては以下となります。
- Azure AD Connect → Active Directoryへの通信ポートを開けておく
- AWS Managed Microsoft ADの場合はデフォルト設定でポートが空いてるので基本問題ない
- Azure AD Connect → Azure ADへのアウトバウンド通信(HTTP,HTTPS)を開けておく
- インバウンド通信は基本使わない。RDPを開けておく位で十分
- セキュリティグループのデフォルトはアウトバウンド全許可なので基本問題ない
3. Azure AD Connectのインストール
ここから実際にAzure AD Connectのインストール作業を開始します。
EC2はドメインに参加済みの状態にしておいてください。
以後の作業はすべて管理者ユーザーであるadmin@example.shibata.tech (admin@shibata.local)で行っています。
3-1. 同期用ドメインユーザーの準備
Azure AD ConnectでID同期を行う際に専用のドメインユーザーが必要になります。
このユーザーはAzure AD Connectのインストール時に自動作成することもできるのですが、自動作成のためには「Enterprise Admin」権限が必要でありAWS Managed Microsoft ADだと権限不足で作成できません。
このため別途手動で用意しておく必要があります。
今回はAWS Security Blogの例に倣いAADConnectSvcという名前のユーザーを新規作成しておきます。
以下の様にPowerShellコマンドを使うかGUIでユーザーを作成しておいてください。
# 同期用ユーザーの作成
# 踏み台サーバーなどAD管理できる環境から実施
# ※PowerShellでなく手作業で作成しても構わない
$params = @{
Name = 'AADConnectSvc';
UserPrincipalName = 'AADConnectSvc@example.shibata.tech';
Description = 'AADC Connector account'
AccountPassword = ConvertTo-SecureString 'P@ssword' -AsPlainText -Force;
PasswordNeverExpires = $true;
Enabled = $true;
}
New-ADUser @Params
なお、ユーザーの権限はデフォルトの状態で構いません。
権限は後でAzure AD Connectに付属のツールから設定します。
3-2. Azure AD Connectのダウンロードとインストール
Azure AD Connectは通常Azure ADのポータルからダウンロードできますが、以下のリンクからダウンロードしても構いません。
今回は以下のスクリプトでサクッとダウンロードしておきます。
(バージョンはVer.2.0.89でした)
# インストーラーを直接デスクトップにダウンロード
$ProgressPreference = "SilentlyContinue"
$params = @{
Uri = 'https://download.microsoft.com/download/B/0/0/B00291D0-5A83-4DE7-86F5-980BC00DE05A/AzureADConnect.msi'
OutFile = "$env:USERPROFILE\Desktop\AzureADConnect.msi"
}
Invoke-WebRequest @params
ダウンロードしたAzureADConnect.msiを実行すると直ちにインストールが開始されます。
インストール後に初期設定ウィザードが開始されますが、ウィザードを進める前にやることがあるため一旦そのまま放置します。
3-3. 同期用ドメインユーザーの権限設定
ここで先に述べたAADConnectSvcユーザーの権限設定を行います。
PowerShellコンソールからAzure AD Connectに付属のツール(AdSyncConfig.psm1)をインポートし、権限設定のための2つのコマンドt-ADSyncBasicReadPermissionとSet-ADSyncMsDsConsistencyGuidPermissionsを実行してやります。
#
# (要管理者権限) 事前に別途 RSAT-AD-Tools のインストールが必要
#
Install-WindowsFeature RSAT-AD-Tools
#
# (要ドメイン管理者権限) 専用モジュールのインポート
#
Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1"
# ドメインに対する読み取り権限を追加
$params = @{
ADConnectorAccountName = 'AADConnectSvc'
ADobjectDN = 'CN=AADConnectSvc,OU=Users,OU=corp,DC=shibata,DC=local'
ADConnectorAccountDomain = 'shibata.local'
IncludeAdminSDHolders = $false
Confirm = $false
}
Set-ADSyncBasicReadPermissions @params
# Azure ADソースアンカーに対する書き込み権限の追加
$params = @{
ADConnectorAccountName = 'AADConnectSvc'
ADobjectDN = 'CN=AADConnectSvc,OU=Users,OU=corp,DC=shibata,DC=local'
ADConnectorAccountDomain = 'shibata.local'
IncludeAdminSDHolders = $false
Confirm = $false
}
Set-ADSyncMsDsConsistencyGuidPermissions @params
コマンドがエラー無く終了すればOKです。
3-4. Azure AD Connect の初期設定
ここから放置していた初期設定ウィザードを再開します。
「ライセンス条項に同意」して「続行」します。
今回は「カスタマイズ」を選びます。
ここでカスタマイズする対象をチェックして各種設定を記載していくのですが、今回ここは何もチェックせずそのまま「インストール」をクリックします。
(環境に応じ必要があればカスタマイズしてください)
SQL Server Express Local DBなどの必須コンポーネントのインストールが開始されるのでしばらく待ちます。
必須コンポーネントのインストールが完了すると以下の画面になり、各種設定を行っていきます。
今回は「パススルー認証」を試します。
シームレスシングルサインオン[2]は今回使わないのと前提条件がめんどうなので有効にせずに進めます。
つづけてAzure ADのグローバル管理者のアカウント情報を記載します。
この情報はインストール時のみ利用されるものです。
※なお、Azure ADへのサインインを確認する際にWEBブラウザ(IEコンポーネント)が起動されるため事前にIEセキュリティ強化の構成(IE ESC)を無効にしておかないと下図の様に真っ白な画面が表示されてしまいます...
(都度サイトの許可を追加してリトライでも構いません)
問題ない状態だとこの様にサインイン画面がちゃんと表示されるので画面の指示にしたがいサインインを完了させてください。
つづけてActive Directory側の設定に移ります。
対象フォレストを決めた状態で「ディレクトリの追加」をクリックします。
するとAzure ADとの同期用ユーザーの設定ダイアログが表示されるので、「既存のADアカウントを使用」を選び先ほど作成したAADConnectSvcユーザーの情報を記入します。
問題なければ「構成済みディレクトリ」欄にドメインが表示されるので「次へ」進みます。
次にAzure ADユーザー名として使用するActive Directory属性の設定を行います。
通常であればUPN (userPrincipalName)をAzure ADユーザー名にしますので今回はそのままにしています。
(この設定で「Azure ADユーザーのUPN ⇔ オンプレドメインユーザーのUPN」の同期になります)
また、今回はshibata.localドメインに代替UPNサフィックスexample.shibata.techを追加しているため「一部のUPNサフィックスが確認済みドメインに一致してなくても続行する」の警告がでていますが、問題ないのでチェックを付けて「次へ」進みます。
次は同期対象を選択します。
今回はAWS Managed Microsoft AD環境ですので「"NET BIOS名\Users"」OUだけ同期する様にしています。
続けてActive Directoryドメイン側の識別方法を決めます。
こちらは基本的にデフォルト設定のままで問題ないのでそのまま「次へ」進みます。
フィルタリング設定はしないのでそのまま「次へ」進みます。
オプション機能もデフォルトのまま「次へ」進みます。
最終確認画面になるので構成に間違いがないことを確認し「インストール」をクリックします。
インストール完了まで待ちます。
インストールが完了すると下図の様になりますので「終了」をクリックしてウィザードを終わらせます。
以上でAzure AD Connectのインストールは完了です。
4. 動作確認
この状態でAzure AD側を確認すると下図の様にユーザーが同期されていることがわかります。
通常のドメインユーザーの他にOn-Premises Directory Synchronization Service AccountといったID同期のための専用ユーザーも増えています。
今回はテスト用に織田信長ユーザーを追加しているのですが、こんな感じでActive Directoryと同期しています。
また、Azure AD Connectの状態はこんな感じになります。
今回パススルー認証をしているのでこちらも有効となり利用されているエージェント数が表示されます。
(エージェントが2つあるのは別件で削除済みのデータがまだ残っているためです)
AWSと連携してみた
実際のユーザー使用例として以下の記事の内容を参考にAWSアカウントにログインしてみました。
具体的な設定手順は割愛しますが、Azure ADのエンタープライズアプリケーション設定後同期されたユーザーでログインするとこんな感じになります。
AWSアカウントに無事ログインできました。
余談
最後にAzure AD Connectに関する余談をいくつか。
1. Azure AD Connect v1の廃止
本記事ではAzure AD Connectの最新バージョンであるv2を利用していますが、前のバージョンであるv1は今年の8月で廃止となります。
まだアップグレードする準備ができていませんが、どれくらいの時間がありますか?
できるだけ早く Azure AD Connect V2.0 にアップグレードする必要があります。 すべての Azure AD Connect V1 バージョンは、2022 年 8 月 31 日に廃止されます。
いまからv1を新規インストールする方はいないと思いますが、間違ってインストールしない様に気をつけてください。
2. Azure AD Connect Cloud Syncについて
去年の夏ごろからAzure AD Connect Cloud Sync(Azure AD Connect クラウド同期)という名前の新しいソフトウェアがリリースされています。
こちらは従来のAzure AD Connectとは異なり内部でSQL Serverを使わない(その分の設定をAzure ADで受け持つ形になる)軽量なエージェントとなります。
雰囲気としてはAzure AD Connectの後継の様に見えなくもないのですが、サポートされる機能にばらつきがあり正直何ともいえません...
このAzure AD Connect Cloud Syncに対し従来のAzure AD ConnectをAzure AD Connect sync(Azure AD Connect 同期)と呼称する場合もあります。
AWS Managed Microsoft ADでAzure AD Connect Cloud Syncが使えるのかはまだ一切調査してませんが、機会があれば試してみたいですね。
3. 冗長構成について
Azure AD Connectは原則として冗長構成にできません。
その代わり「ステージングモード」と利用モードの違う環境を用意し障害時にフェイルオーバーさせることが可能です。
(ただし、設定のレプリケーションはできない模様)
また、パススルー認証では専用のエージェントプログラムがインストールされるのですが、こちらのエージェントについては負荷分散および冗長化を目的として複数台構成にすることが可能です。
Microsoftとしてはパススルー認証エージェントは3台以上で構成することを推奨しています。
未検証ですがこんな感じで冗長構成が採れると思います。
終わりに
以上となります。
パスワードライトバックが使えないのは痛いですがAWS Managed Microsoft AD環境でもAzure AD Connect v2を使うことができました。
本記事の内容が皆さんの役に立てば幸いです。
