私が制御しないShibbolethサービスプロバイダー/信頼パーティーにAD FS 3.0 IDプロバイダー（IDP）を接続する必要があります。 Unfortunatley、AD FSとShibbolethはクレーム/属性に同じフォーマットを使用していません。SamAccountNameを介してAD FS 3.0をShibbolethに接続します。名前ID
多くの情報がありますが、これについてのウェブと、2つのルール（Active Directoryから値を取得するルールと、Shibbolethが期待するものと一致するように変換するルール）の必要性があります。 AD FS 2.0のために書かれているか、または名前IDとして電子メールアドレスを使用しています（私は本当にこのためにSamAccountNameが必要です）。
Shibbolethが受け入れるwindows-account-nameを使用してクレームを生成するには、どのようにAD FS idPを取得できますか？
私は最終的にここに答えが見つかりました：リストをリンク
https://cccnext.jira.com/wiki/spaces/CSF/pages/147817839/Attributes+for+the+Proxy+AD+FS
カスタムSAMアカウント/窓・アカウント名を含むActive Directoryフィールドの数の組を支配します。
私はこのような外観を使用したルール：
@Rulename="Get sAMAaccountName"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
=> add(store = "Active Directory", types = ("urn:oid:1.2.840.113556.1.4.221"), query = ";sAMAccountName;{0}", param = c.Value);
@Rulename="Convert sAMAccountName/uid xml"
c:[Type == "urn:oid:1.2.840.113556.1.4.221"]
=> issue(Type = "urn:oid:0.9.2342.19200300.100.1.1", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/attributename"] = "urn:oasis:names:tc:SAML:2.0:attrname-format:uri");
これらは、PowerShellスクリプトの一部として含まれていたが、あなたは、カスタム要求ルールを追加することにより、AD FSのインタフェースを介してそれらを追加することができます。
これでもShibboleth側の変更が必要な場合があります。これまでのところ、相手側のサービス技術者は、除外された属性を見て、その属性を許可するように変更したと報告しました。しかし、これは異なるルールのセットでした。このルールセットがその変更を利用しているかどうかはわかりません。