SE の雑記

サンプルアプリケーションを使って ADFS から Azure AD への認証移行ステップを確認する で解説されている AD FS を使用しているアプリケーションから Azure AD への移行を実施する際に使用できるデモを動作させる際のメモを。

久しぶりに AD FS を触ったら何も覚えていませんでした…。

AD FS 上のアプリをさらに Azure AD に移行するための新機能の提供 がどのような内容を表しているのかを検証するための下準備となります。

AD FS 上に WS-Federation 認証でサインインするサンプル アプリを登録するために必要な手順 も合わせて読んでおくとよいかなと思いました。

AD FS について思い出す

ADFS については、国井さんの ADFSトレーニングテキスト全文公開チャレンジ(1) から続く、一連のコンテンツを確認するのが良いのではないでしょうか。

AD FS のセットアップについては、Azure Active Directory Connect のインストール から実施することができますので、検証目的の環境を作成するのは AAD Connect のインストーラーに頼ってしまってもよいかと思います。

全体的な流れを確認するための資料としては古い情報にはなりますが、Microsoft Office 365 自習書 AD FS によるシングル サインオン環境構築ステップ バイ ステップ ガイド も参考になるかと。

新機能の提供が何を表しているのかを把握する

新機能で実現できるようになったもの

AD FS 上のアプリをさらに Azure AD に移行するための新機能の提供  で紹介されている機能については、AD FS で実施していた SAML トークンのカスタマイズの一部の機能を Azure AD で実施することができるようになったという認識でいます。

新機能で紹介されているカスタマイズとしては次のようなものがありますので、これらの変換を AD FS で実行している場合に、AAD のみでどのように対応できるかが焦点になるのかと。

• 部分文字列の一致を用いて、トークンに含まれるグループをフィルターする
• 追加のユーザー属性をクレームとして構成する
• 新しい変換機能で SAML トークンのクレームをカスタマイズする
  • 確認されていない任意の UPN ドメインをトークンに含めることができるようになった。
• 正規表現言語 (regex) を使用して、グループ クレームを作成および変換する

作成したエンタープライズアプリケーションのシングルサインオンの設定で「属性とクレーム」のカスタマイズが今回の新機能の主な観点となります。

属性とクレームのクレームの設定で今までは AD FS でのみ実施することができていたものを AAD 単体で実現することができるようになったものがあり、AD FS から発行していたクレームと同等の内容を AAD のみで発行することができるかが、AD FS アプリを Azure AD に移行することができるかの判断材料となるのではないでしょうか。

Azure AD Connect による AAD への同期のマッピング

AAD Connect には、Synchronization Rules Editor があり、これを使用すると AD の情報がどのように AAD に同期されているかを確認することができます。

AD の「accountName」が AAD の「onPremisesSamAccountName」として連携されていることが確認できますね。

Graph Explorer 等で情報を確認すると AAD で実際に値が格納されていることが確認できます。

SAML トークンのカスタマイズ方法 (発行変換規則のルール作成)

SAML トークンのカスタマイズがどのように使用されているかについては、次のようなドキュメントを参考にするとよいのかと思いました。

• ADFS と AWS の間の信頼を確立し、Active Directory 認証情報を使用して ODBC ドライバーで Amazon Athena に接続する
• Use attribute-based access control with AD FS to simplify IAM permissions management
• ADFS claim rules to filter group membership
• AD FS を使用して SAML シングル サインオンを設定する
• CLAIMS -BASED IDENTITY AND ACCESS CONTROL

AD FS の設定としては、該当のアプリケーションに対しての「要求発行ポリシーの編集」の「発行変換規則」のカスタマイズについて、Azure AD 側で実施できる内容が増えたことで AD FS を廃止することができる可能性が出てきたのかなと思っています。

SAML トークンのカスタマイズに使用する要求規則については、安納さんの AD FS deep dive – claim rule set がとても参考になります。

公式のドキュメントとしては次のようなものが参考になるのではないでしょうか。

• Windows Server 2012 R2 および Windows Server 2012 AD FS のアクセス制御ポリシー
• 要求規則の構成
• 要求規則言語の役割

グループの追加を例としたカスタマイズのサンプル

ユーザーがメンバーとして追加されているグループの取得並びにフィルターについては、次の情報が参考になり、AAD でグループのフィルターを検証する際には、この情報を参考にすることで、AD FS との差を確認できるのではないでしょうか。

以下の情報で設定した場合、メンバーとして取得されるのは、「ドメイン ローカル」のスコープのグループとなるようで、「グローバル グループ」については取得されていないようでしたので、メンバーとして追加するグループの種類については、気を付けたほうが良いのかもしれませんね。

• ADFS Claim to Flatten Groups and Return full DN
• ADFS – How to be specific on a groups claim
• AD FS 2.0: Domain Local Groups in a claim

グループの情報をトークンに含め、特定のグループ名のみにフィルターしたい場合は、作成した「WebApp_SAML」の「証明書利用者信頼」の「発行変換規則」に次のような 3 つのルールを追加します。

# Rule 01
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
 => add(store = "Active Directory", types = ("http://contoso.com/UserDN"), query = ";distinguishedName;{0}", param = c.Value);

# Rule 02
c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
 && c2:[Type == "http://contoso.com/UserDN"]
 => add(store = "Active Directory", types = ("http://contoso.com/myclaims/MemberOfDN"), query = "(member:1.2.840.113556.1.4.1941:={1});distinguishedName;{0}", param = c1.Value, param = c2.Value);

# Rule 03
c:[Type == "http://contoso.com/myclaims/MemberOfDN", Value =~ "(?i)^*dnsadmins,"]
 => issue(claim = c);

グローバル グループを含める場合には、フェデレーション認証を実装する の tokenGroups を使用する必要がありそうです。(tokenGroups だとローカルグループが取得されないようですが)

AWS 向けのカスタマイズ

AWS と AD FS の連携した際の SAML トークンのカスタマイズは、Enabling Federation to AWS Using Windows Active Directory, ADFS, and SAML 2.0 から確認することができます。(国井さんが書かれている ADFSを利用してAWSにシングルサインオンする方法 も参考になります)

AWS 向けに次のような SAML トークンを追加する手順となっています。

# Role SessoinName
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
 => issue(store = "Active Directory", types = ("https://aws.amazon.com/SAML/Attributes/RoleSessionName"), query = ";mail;{0}", param = c.Value);

# Get AD Groups
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
 => add(store = "Active Directory", types = ("http://temp/variable"), query = ";tokenGroups;{0}", param = c.Value);

# Roles
c:[Type == "http://temp/variable", Value =~ "(?i)^AWS-"]
 => issue(Type = "https://aws.amazon.com/SAML/Attributes/Role", Value = RegExReplace(c.Value, "AWS-", "arn:aws:iam::123456789012:saml-provider/ADFS,arn:aws:iam::123456789012:role/ADFS-"));

上記のルールを発行変換規則に設定したものが次の情報となりますが、機能の検証を行う際にはこのようなクレームが Azure の機能のみで設定できるかがポイントとなるのではないでしょうか。

AD FS で設定していた SAML のカスタマイズが、AAD の新機能で次のように設定することができ利用になります。

AAD の機能で、次のような SAML トークンを生成することができるようになり、SAML のカスタマイズをクラウドで実現することができるようになり、AD FS を廃止することができるシナリオが増えるというのが今回の機能追加となります。

サンプルアプリを動作させる際のメモ

サンプルアプリケーションについて

アプリケーションと AD FS の連携については、サンプルアプリケーションを使って ADFS から Azure AD への認証移行ステップを確認する  で紹介されている Azure-Samples/ms-identity-dotnet-adfs-to-aad: Guide to migrate applications from AFDS to AAD (github.com) のアプリケーションを使用することで確認ができます。

公式ドキュメントとしては、アプリケーション認証を Azure Active Directory に移動する となり、サンプルアプリについては、開発者向けの AD FS から Azure AD へのアプリケーション移行プレイブック としても記載されています。

AD FS とアプリケーションの連携については、1.1 Integrate app with AD FS の内容を実施することで使用することができます。

AD FS と連携した場合は次のような情報が取得され、

AAD と連携した場合は、次のような情報が取得されますので、

この両環境の情報をいかにして AAD の機能だけで近づけることができるかがポイントとなるようですね。

設定時の注意点 #1

上記ドキュメントでAD FS 側の設定については、WS-Federation のエンドポイントの信頼された URL として「web.config」の ida:Wtrealm の URL を指定したエンドポイントを作成するということが不足しているように見えました。

私が使用している環境では、WS-Federation のエンドポイントとして「https://localhost:44347/」(web.config に最後の / を設定したのであれば、エンドポイントの URL も / を指定する) を設定していないと、アプリケーションとしては「不明なエラーが発生しました」が表示されていました。

AD FS のイベントログの AD FS には、「MSIS5004: エンドポイント ‘xxxxxxx’ で識別された証明書利用者信頼に WSFederationPassiveEndpoint アドレスが構成されていません。現在の要求を処理するには、このアドレスが必要です。」が出力されていました。(本エラーのエンドポイントとして表示されている URL が  WS-Federation のエンドポイントとして設定が必要)

Visual Studio をインストールした環境内の IIS Express で実行する場合には、手順を基にして、上記の設定を気を付ければ動作させることができました。

AD FS から取得した SAML トークンの内容を出力するアプリケーションとなっているので、AAD でどのようにトークンのカスタマイズができるかを比較するのに便利そうですね。

設定時の注意点 #2

今回は、証明書利用者信頼 (Relying Party Trust) のトークン暗号化証明書について設定はせずに検証を実施しています。

• 証明書利用者の信頼を作成する

作成した証明書利用者信頼 (WebApp_SAML) で暗号化の証明書を使用する場合は「Set-ADFSRelyingPartyTrust」の設定を意識する必要がありそうでした。

• AD FS を使用した SAML の構成
  • 自己署名証明書の失効状態確認の無効化
    • Set-ADFSRelyingPartyTrust -targetname "<ターゲット名>" -SigningCertificateRevocationCheck "none"
    • Set-ADFSRelyingPartyTrust -targetname "<ターゲット名>" -EncryptionCertificateRevocationCheck "none"
• ADFS 2.0 を使用したエンタープライズサインインの設定
  • 暗号化アサーションを送信しないようにする場合
    • set-ADFSRelyingPartyTrust –TargetName"< relyingPartyTrustDisplayName >" –EncryptClaims $False

ローカルデバッグ用の設定

検証用環境であれば、How to fix "IDX20804: Unable to retrieve document from: ‘[PII is hidden]’" error in C# の情報を覚えておくとエラー時のローカルデバッグについても対応できそうでした。(Startup.cs に「IdentityModelEventSource.ShowPII=true」を追加)

IIS に対して発行する場合の注意点

IIS に発行して検証を実行する場合には、次のドキュメントが参考になります。WebPI のサポートは 2022/7/1 で廃止 となっているようなので、現時点では発行するための準備は Web PI 経由ではなく、手動で設定をすることを検討したほうが良いかと。

• Web 配置発行の Web サーバーを構成する (Web 配置ハンドラー)
• Web Deploy v3.6

IIS に発行してアプリケーションを動作させる場合「web.config」だけでなく「Setup.Auth.cs」に記載されている「Wreply」についても修正しないと動作しませんでしたので、IIS Express 以外で動作させる場合は変更箇所を注意しておいたほうが良いかもしれませんね。