AD FS サーバーのセットアップのために知っておくべきオプションと設定項目があります。
Microsoft の Active Directory は、フェデレーテッド ID とアクセス管理は Active Directoryフェデレーションサービス（AD FS） によって有効にされ、インターネットに直接接続するアプリケーションへのシングルサインオン機能の使用を有効にするためによく使用されます。このブログは、AD FS サーバーをセットアップするためのプロセスすべてを説明するものではなく、このサービスの使用方法、設計上の考慮事項、そして適切に設定するためのポイントなどを説明するものです。
Active Directory 環境に合わせて AD FS を設定
Windows Server 2012 以前は、多くの場合、専用の AD FS サーバーを作成する必要がありました。シンプルなデプロイメントの場合、ドメインコントローラ上での共存が推奨されていない Web サービスがデフォルトで有効になるよう設定されているケースが一般的だったことが主な理由です。現在は、ユーザーが1,000人以下の場合は、ドメインコントローラに AD FS をインストールしても問題ないとされています。
実際のインストールプロセス自体は、一般的な IT 知識があれば、それほど複雑ではありません。AD FS を設定する際に複雑だと感じられるのは、Relying Party Trust（証明書利用者信頼）と要求プロバイダー設定が複雑だからです。
- Relying Party Trust (証明書利用者信頼) - これは、認証リクエストを行うアプリケーションと、そのリクエストを信頼して処理する方法です。
- Claims Provider (要求プロバイダー) - 承認リクエストを行ったアプリケーションの要求設定によって、AD FS サーバーがその要求を処理して応答する方法が決まります。認証された場合、要求情報を変換して適切なプロパティを返すオプションがあります。
従来 SAML 認証ワークフローに使用されてきた AD FS に関してはいくつかのオプションがあります。AD FS の最新バージョンは、Azure が提供する完全な多要素フローもサポートしています。
- フォーム認証
- 証明書認証
- デバイス認証
- Azure MFA
- Microsoft パスポート認証
Azure AD と AD FS
クラウド中心の組織、特に Office 365 ユーザーの場合は、AD FS のような従来のオンプレミスソリューションはそれほど必要ないかもしれませんが、AD FS はAzure AD と連携できます。Azure AD を使用する場合の設定はシンプルで、簡単に Azure AD ソリューションのスケーラビリティと管理を活用できます。
ただし、シンプルということは、管理オプションが十分でないことを意味します。認証シナリオが複雑な場合、より多くのことが AD FS サーバーでできます。 したがって、組織のニーズによっては、AD FS サーバーが依然として最適なソリューションということになるかもしれません。
AD FS 設定に関する一般的なヒント、コツ、および注意事項
AD FS 設定時におけるいくつかの一般的な問題は、ある程度の知識があれば回避でき、スムーズにインストールすることができます。
認証局
AD FS サーバーを認証して信頼できることを確認するのに使用できる SSL 証明書の作成を有効にするために、Active Directory 環境向けに設定されている認証局を持っていることが推奨されます。
SSL 証明書
AD FS のインストール時には、SSL 証明書が必要になります。そのためには、AD FS が効果的に機能するように DNS が正しく設定されていることを確認する必要があります。証明書を作成するときに、次の代替 DNS 名を追加します。
- {FQDN of AD FS Server}.domain
- domain
グループの管理されたサービスアカウント
AD FS サーバーをインストールするときは、そのサービスを実行するようにアカウントを設定する必要があります。従来のサービスアカウントは sMSA（standalone Managed Service Account、スタンドアロンの管理されたサービスアカウント）方式を使用しますが、新しい Active Directory サービスでは、gMSA（group Managed Service Account、グループの管理されたサービスアカウント）を使用するのが最適です。主な違いは、Windows オペレーティングシステムがアカウントのパスワードを管理することです。AD FS で機能するようにするためには、まず KDS ルートキーを追加する必要があります。インストールプロセスでの非ブロック警告が回避するため、PowerShell 管理プロンプトを使用して次のコードを実行し、インストールの10時間前に KDS ルートキーを生成します。
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))
KDS ルートキーを追加した後、AD FS サービスの管理に使用する gMSA アカウントを作成する必要があります。これは、以下に示すように、PowerShell を使用して行うのが最適です。ServerPrincipalNames として http://win2019server.ad.test.local が設定されていますが、これは、ドメインに参加しているクライアントと AD FS の間の Kerberos 認証を有効にするためです。
$Name = 'sa_adfs'
$Params = @{
"Name" = $Name
"DNSHostName" = 'win2019server.ad.test.local'
"PrincipalsAllowedToRetrieveManagedPassword" = 'win2019server$'
"ServicePrincipalNames" = 'http/win2019server.ad.test.local'
}
New-ADServiceAccount @Params
Install-ADServiceAccount -Identity $Name
Add-ADComputerServiceAccount -Identity 'win2019server' -ServiceAccount $Name
Install-ADServiceAccount の実行中にアクセス拒否エラーが発生した場合は、サーバーを再起動する必要があります。
IdP サインオンページの有効化
IdP Initiated サインオンページは、AD FS サーバーを設定するときに見逃されがちですが、これを必要とする可能性のあるアプリケーションもあり、トラブルシューティングにも役立ちます。PowerShell を使って簡単に有効化できます。
Set-ADFSProperties -EnableIdPInitiatedSignonPage $True
AD FS サーバーのメタデータの確認
適切なメタデータが返されていることを確認する最も簡単な方法は、AD FS サーバーの FQDN を使用するように更新された次の URL を使用することです。
https://{FQDN of AD FS Server}/adfs/fs/federationserverservice.asmx
まとめ
このブログでは、AD FS の設定に関して少しだけ説明したにすぎません。それでも、よくある見落としなど、多少のヒントが役立つことを願っています。Azure AD を使用している場合は、Azure Portal から設定できる、AD FS サーバーを必要としない認証プロセスがありますが、AD SF サーバーをセットアップすれば、より複雑な認証ワークフローやオンプレミスの Active Directory 環境に適切に対処することができます。