AD ConnectorはActive DirectoryとAWSとの間で信頼関係を確立するためのかんたんなやり方を提供するために設計されています。AD Connectorを構成すると、信頼によって以下のようなことができるようになります：
- Active Directoryの認証情報を使用したAmazon WorkSpaces、Amazon WorkDocs、Amazon WorkMailなどのAWSアプリケーションへのサインイン
- Amazon EC2 launch wizardまたはEC2 Simple System Manager（SSM） API経由でのプログラムによるActive DirectoryドメインへのWindowsインスタンスのシームレスな参加
- Active DirectoryのアイデンティティとAWS Identity and Access Management（IAM）ロールとのマッピングによるAWS Management Consoleへのフェデレーションによるサインインの提供
AD Connectorはカスタムアプリケーションから利用することはできず、上に言及した3つのユースケースでセキュアなAWSとのインテグレーションのためだけに使用されます。オンプレミスのActive Directoryに依存したカスタムアプリケーションは直接ドメインコントローラーに通信すべきです。
AD Connectorにより、すべてのユーザーアイデンティティをActive Directoryから調達および管理することによりアイデンティティ管理が効率化されます。さらにパスワードの有効期限や履歴、アカウントロックアウトポリシーなどの既存のActive Directoryのセキュリティポリシーを再利用することができます。また、ユーザーはもう別のユーザー名とパスワードの組み合わせを記憶する必要がなくなります。そしてAD Connectorは複雑なディレクトリ同期のテクノロジーやActive Directoryフェデレーションサービス（AD FS）には依存しないため、SAMLベースのフェデレーションインフラストラクチャをホストするためのコストや複雑さから解放されます。つまり、AD Connectorは既存のオンプレミスへの投資をAWSの別の側面のコントロールに利用することによりハイブリッド環境の運用に役立ちます。
このブログ記事では、AD Connectorがどのように動作するかだけでなくどのようにしてフェデレートされたコンソールアクセス、ユーザーへのロールのアサイン、Active DirectoryドメインへのEC2インスタンスのシームレスな参加を可能にするかをご紹介します。
AD Connector - 内部の仕組み
AD ConnectorはAWSアプリとオンプレミスのディレクトリを接続するため両方のアベイラビリティゾーンにあるプロキシのサービスです。AD Connectorは認証のためのActive Directoryへのサインインリクエストをフォワードしてアプリケーションがディレクトリのデータをクエリできるようにします。AD Connectorを構成するときに、サービスアカウントの認証情報を入力すると、それはAWSによってセキュアに保管されます。このアカウントはAWSによるシームレスなドメインへの参加、シングルサインオン（SSO）、およびAWSアプリケーション（WorkSpaces、WorkDocs、WorkMail）の機能を有効化するために使用されます。AD Connectorの役割はプロキシであるため、ユーザーの認証情報を保管したりキャッシュしたりすることはありません。というより、すべての認証、検索および管理のリクエストはActive Directoryによって処理されます。
AD Connectorを作成するためには、セットアップ中に一対のDNS IPアドレス入力する必要があります。これはAD Connectorがリクエストをルートするための一番近いドメインコントローラーを見つけるサービス（SRV）のDNSレコードを取得するために使用されます。AD ConnectorのプロキシインスタンスはActive Directoryドメインコントローラーののロケータプロセスと類似のアルゴリズムを使用してどのドメインコントローラーがLDAPとKerberosのリクエストを受け付けるのかを決定します。
AWSアプリケーションとAWS Management Consoleへの認証のために、AWS Directory Serviceコンソールからaccess URLを構成することができます。このaccess URLはhttps://<alias>.awsapps.comのフォーマットでパブリックにアクセス可能なサインインページを提供します。https://<alias>.awsapps.com/workdocsではWorkDocsへのサインインが、https://<alias>.awsapps.com/consoleではAWS Management Consoleへのサインインができます。以下のイメージはAWS Management Consoleへのサインインページです。
セキュリティを強化するために多要素認証（MFA）をAD Connectorで有効化することができますが、この機能を利用するためにはオンプレミスのネットワークにセットアップした既存のRADIUSインフラストラクチャが必要になります。要件と構成に関するよりくわしい情報についてはAD Connector – Multi-factor Authentication Prerequisitesを参照してください。AD ConnectorでMFAを有効にすると、access URLでホストされるサインインページでユーザーは通常のサインインの認証情報にくわえてMFAコードを要求されます。
AD ConnectorにはSmallとLargeのふたつのサイズがあります。Large AD ConnectorはSmall AD Connectorよりもパワフルなコンピュートリソースとより高いコストで稼働します。AD Connectorによってプロキシされるトラフィックの量に応じて、ニーズにもとづく適切なサイズを選ぶことになります。
AD Connectorはデプロイするリージョン内の複数のアベイラビリティゾーンをまたがって内部ホストをデプロイするため、高い可用性があります。ホストレベルの障害があった場合、Directory Serviceは障害のあったホストについて通知するとともに置き換えをします。さらにDirectory ServiceはパフォーマンスおよびセキュリティアップデートをAD Connectorに自動的に適用します。
以下のダイアグラムはAWS Management Consoleアクセスを有効にしたときの認証のフローとネットワークパスについて図にしたものです：
- ユーザーはセキュアなカスタムサインインページをひらいてActive Directoryのユーザー名とパスワードを入力します。
- 認証リクエストはSSLを通してAD Connectorに送られます。
- AD ConnectorがActive DirectoryにLDAP認証を実行します。
注：AD ConnectorはドメインのSRV DNSレコードを検索してもっとも近いドメインコントローラを見つけます。
- ユーザーが認証されたあとに、AD Connectorはユーザーの一時的なセキュリティクレデンシャルを取得するためにSTSのAssumeRoleメソッドを呼び出します。
注：ユーザーが複数のロールにマップされている場合、どのロールとしてサインインするかの選択が求められます。ユーザーセッションは1時間有効です。
AWS Management ConsoleアクセスをフェデレートするためのAD Connectorの構成をはじめる前に、prerequisites for AD Connectorを読んで理解するようにしてください。たとえば、VPNまたはDirect Connect回線がVPCとオンプレミス環境の間に存在する必要があります。ドメインはWindows Server 2003機能レベル以上で動作している必要があります。さらに、AD Connectorがオンプレミスのディレクトリと通信できるようにさまざまなポートがVPCとオンプレミス環境との間でオープンされている必要があります。
AD ConnetorでAWS Management Consoleアクセスとのフェデレーションを構成する
コンソールアクセスの有効化
ユーザーにActive Directory認証情報によるサインインを許可するためには、明示的にコンソールアクセスを有効化する必要があります。これはDirectory ServiceコンソールをひらいてDirectory IDの名前をクリックすることでおこなえます。
Directory DetailsのページがひらくとApp & ServicesタブにディレクトリからAWS Management Consoleアクセスを有効化するためのボタンが表示されます。実行するためには、App & ServicesセクションのManage Accessリンクをクリックします。
コンソールアクセスを有効化するかどうか別のダイアログボックスがひらきます。Enable Accessをクリックします。
コンソールアクセスを有効化すると、ロールを構成してActive Directoryユーザーやグループをこれらのロールと関連付けることができるようになります。
これらのステップを実行してあたらしいロールを作成します。Directory Serviceコンソールからあたらしいロールを作成すると、AD Connectorは自動的にDirectory Serviceとの信頼関係を追加します。以下のコード例はロールが作成されたあとのロールのIAM信頼ポリシーをしめしています。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "ds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:externalid": "482242153642"
}
}
}
]
}
ユーザーのロールへのアサイン
AD Connectorが構成されてロールを作成したので、次の仕事はユーザーまたはグループにこれらのIAMロールにアサインすることです。ロールのマッピングはAWS内でユーザーがどのリソースにアクセスできるかを制御します。そのためには以下のようにする必要があります：
- . Directory Service consoleをひらいてManage Accessのリンクをクリックします。
- Create New Roleをクリックします。
- Use Existing Roleをクリックします。注：すでにActive Directoryユーザーまたはグループをロールにアサインしている場合は、Directory Serviceコンソールからロールのリンクをクリックすることでメンバーシップを修正することができます。
- リストからロールを選択して、Next Stepをクリックします。
- 検索フィールドからActive Directoryユーザーまたはグループの名前を入力します。
- Next Stepをクリックします。
- Create Role Assignmentsをクリックします。
完了するとユーザーまたはグループの名前がそのオブジェクトに対応したIDが上のイメージのように表示されます。
次回ユーザーがカスタムサインインページからAWS Management Consoleにサインインすると、EC2ReadOnlyセキュリティロールにサインインされます。
Active Directoryドメインへのインスタンスのシームレスな参加
AD Connectorを使用するもうひとつの利点はWindows（EC2）インスタンスをActive Directoryドメインにシームレスに参加させることができることです。この機能については今年のはじめにAWS Blogで読んだことがあるかもしれません。つまりスクリプトや手動による操作なしでインスタンスがプロビジョンされている間にWindows Serverをドメインに参加させることができるということです。ブログのこのセクションでは自分の環境でこの機能を有効にするために必要なステップとこのサービスがどのようにして動くのかについて解説します。
ステップ1:ロールの作成
最近まではEC2インスタンスからSSM、すなわち実行中または初回起動時にWindowsインスタンスを構成するためのAWSサービスにアクセスするためのIAMポリシーを手動で作成する必要がありました。いまは、AmazonEC2RoleforSSMというマネージドポリシーがあるためにかわりにそれをつかうことができます。作成したこのロールはプロビジョン時にEC2インスタンスにアサインされ、SSMサービスへのアクセス権を許可します。
このロールを作成するためには：
- IAMコンソールをひらきます。
- ナビゲーションペーンのRoleをクリックします。
- Create Roleをクリックします。
- Role Nameフィールドのロールに名前を入力します。
- AWS Service Roleから、Amazon EC2を選択してSelectをクリックします。
- Attach Policyページで、AmazonEC2RoleforSSMを選択してNext Stepをクリックします。
- Reviewページで、Create Roleをクリックします。
作成したロールをクリックすると、EC2の信頼ポリシーが以下のコード例のように見ることができます。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
ステップ2: EC2コンソールからあたらしいWindowsインスタンスの作成
このロールがあることによって、EC2 launch wizardからWindowsインスタンスを参加させることができるようになります。どのようにして行うかについての詳細な説明は、Joining a Domain Using the Amazon EC2 Launch Wizardを参照してください。
しかしながら、APIからあたらしいインスタンスを作成する場合は、SSMの構成ドキュメントを作成して事前にそれをSSMサービスにアップロードする必要が有ります。このプロセスについてここからみてきましょう。
注：インスタンスはSSMサービスと通信するためにインターネットアクセスが必要になります。
EC2 launch wizardからあたらしいWindowsインスタンスを作成すると、ウィザードはAD Connectorに保管されている情報をもとにして自動的にSSMの構成ドキュメントを作成します。現在のところ、EC2 launch wizardでメンバーサーバーをデプロイする組織単位（OU）を指定することはできません。
ステップ3: SSMドキュメントの作成（AWS APIによるドメインへのシームレスなドメイン参加）
AWS CLIまたはAPIからあたらしいWindowsインスタンスをプロビジョンしたい、もしくはインスタンスのターゲットOUを指定したい場合は、SSMの構成ドキュメントを作成する必要があります。構成ドキュメントはインスタンスを構成するためのさまざまなパラメータがふくまれるJSONファイルです。以下のコード例はドメインに参加するための構成ドキュメントです。
{
"schemaVersion": "1.0",
"description": "Sample configuration to join an instance to a domain",
"runtimeConfig": {
"aws:domainJoin": {
"properties": {
"directoryId": "d-1234567890",
"directoryName": "test.example.com",
"directoryOU": "OU=test,DC=example,DC=com",
"dnsIpAddresses": [
"198.51.100.1",
"198.51.100.2"
]
}
}
}
}
この構成ドキュメントでは：
- directoryIdは事前に作成したAD ConnectorのIDです。
- directoryNameはドメインの名前です（たとえば、examplecompany.com）。
- directoryOUはドメインのOUです。
- dnsIpAddressesはAD Connectorを作成したときに指定したDNSサーバーのIPアドレスです。
追加の情報については、aws:domainJoinを参照してください。ファイルの作成が完了したら、JSONファイルとして保存します。 注：ファイルの名前は最小1文字から最大で64文字までの長さになります。
ステップ4: 構成ドキュメントのSSMへのアップロード
このステップではユーザーがSSMでインスタンスを構成できるパーミッションをもっている必要があります。これらの権限をふくむポリシーがない場合は、以下のJSONをつかってあたらしいポリシーを作成し、IAMユーザーまたはグループにアサインします。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ssm:*",
"Resource": "*"
}
]
}
作成したSSMのIAMポリシーに関連付けられたユーザーでサインインしたあとに、AWS CLIから以下のコマンドを実行します。
aws ssm create-document --content file://path/to/myconfigfile.json --name "My_Custom_Config_File"
注：Linux/Macシステムではパスのはじめに"/"を追加する必要があります（たとえば、file:///Users/username/temp）
このコマンドは作成した構成ドキュメントをSSMサービスにアップロードして、あたらしいWindowsインスタンスをAWS CLIまたはEC2 launch wizardから作成したときに参照できるようにします。
結論
このブログ記事ではActive DirectoryとAWS Management Consoleとのフェデレーションによりアカウント管理をシンプルにする方法についてご紹介しました。また、AD ConnectorをつかってWindowsインスタンスをシームレスにActive Directoryドメインに参加させることによりハイブリッドITを実現する方法についても解説しています。この情報を活用してActive DirectoryとAWSとの信頼関係を作成することができます。さらに、アイデンティティの複製やオンプレミスのインフラを追加で展開することなくシングルサインオンを実現するすばやくかんたんなやり方を手に入れたことになります。
わたしたちはあなたがどのようにDirectory Serviceをつかっているのかについてとても知りたいと思っており、エクスペリエンスを改善するためのフィードバックをおまちしております。以下にコメントしていただくか、Directory Service forumにコメントや質問を記入していただけます。
- Jeremy（翻訳はSA渡邉が担当しました。原文：How to Connect Your On-Premises Active Directory to AWS Using AD Connector）
