Příznaky
Zvažte následující scénář:
-
Používáte ověřování deklarací identity systému Windows (přes Windows Challenge/Response [NTLM] nebo Kerberos) ve webové aplikaci Microsoft SharePoint Server 2013.
-
Rozhodnete se přepnout na deklarace důvěryhodných zprostředkovatelů pomocí zprostředkovatele založeného na protokolu SAML (Secure Application Markup Language), například AD FS (Active Directory Federation Services).
-
Kroky v migraci ověřování deklarací identity systému Windows na ověřování deklarací identity založené na základu SAML se prozkoumá na webu Microsoft Developer Network (MSDN) na stránce SharePoint serveru 2013.
-
Spustíte tento příkaz:
Convert-SPWebApplication-ID $wa-to-deklarace deklarací – TRUSTED – DEFAULT-from-Fromes-WINDOWS-TrustedProvider $tp-SourceSkipList $csv-RetainPermissions
V tomto scénáři se zobrazí následující chybová zpráva:
Ověřování deklarací založené na SAML není kompatibilní.
Příčina
K tomuto problému dochází, protože nebyl vytvořen Vydavatel důvěryhodného tokenu pomocí výchozí konfigurace. Aby příkaz Convert-SPWebApplication fungoval správně, je nutné použít výchozí konfiguraci. Příkaz Convert-SPWebApplication vyžaduje konkrétní konfiguraci pro důvěryhodného poskytovatele, aby byl kompatibilní s převodem deklarací systému Windows na SAML nebo naopak. Konkrétně musí být Vydavatel důvěryhodné identity vytvořen pomocí parametrů UseDefaultConfiguration a IdentifierClaimIs . Spuštěním následujících skriptů Windows PowerShellu můžete zkontrolovat, jestli byl Vystavitel důvěryhodného tokenu vytvořen pomocí parametru UseDefaultConfiguration .Poznámka: Tyto skripty předpokládají, že máte v aktuální farmě vytvořen pouze jeden důvěryhodný poskytovatel identity.
$tp = Get-SPTrustedIdentityTokenIssuer$tp.claimtypes
Typy deklarací, které by měl tento skript mít, jsou následující:
-
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname
-
http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid
-
http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid
-
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
-
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn
#Get the Identity claim:$tp = Get-SPTrustedIdentityTokenIssuer$tp.IdentityClaimTypeInformation
Deklarace identity musí mít jednu z těchto věcí:
-
WindowAccountName
-
EmailAddress
-
UPN
Příklad výstupu $tp. IdentityClaimTypeInformation: DisplayName: e-mailová InputClaimType: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddressMappedClaimType: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress#IsIdentityClaim: SPTrustedBackedByActiveDirectoryClaimProvider by měl být poskytovatel vlastní deklarace se stejným názvem jako Vystavitel tokenu a měl by být typu SPTrustedBackedByActiveDirectoryClaimProvider. Spuštěním této možnosti zjistíte, jestli je poskytovatel deklarací přítomen a slučitelný:
$tp = Get-SPTrustedIdentityTokenIssuer$name = $tp.name$cp = Get-SPClaimProvider $nameif($cp.typename -match "SPTrustedBackedByActiveDirectoryClaimProvider"){write-host "Claim provider is present and has TypeName of " $cp.typename " it should be valid"}else{write-host "Claim provider is not present. Trusted Identity Token Issuer" $tp.name " is not compatible with convert-spwebapplication"}Řešení
Tento problém vyřešíte tak, že odstraníte a znovu vytvoříte Vystavitel tokenu důvěryhodné identity. Postupujte takto:
-
Spusťte následující skript:
$tp = Get-SPTrustedIdentityTokenIssuer$tp | fl$tp.name$tp.IdentityClaimTypeInformation
Vytvořte kopii výstupu tohoto skriptu pro pozdější referenci. Konkrétně potřebujeme hodnotu vlastnosti Name, takže nový Vystavitel tokenu může být vytvořen pomocí stejného názvu a potřebujeme deklaraci identity, aby bylo možné vytvořit nového poskytovatele deklarací identity. Dokud bude pro vystavitele tokenu použit stejný název a jako deklarace identity se používá stejná deklarace, všichni uživatelé budou po opětovném vytvoření vydavatele tokenu udržovat jejich oprávnění v rámci webové aplikace.
-
Odeberte aktuálního důvěryhodného poskytovatele identity od zprostředkovatelů ověřování pro každou webovou aplikaci, která ji aktuálně používá.
-
Odstraňte vystavitele tokenu spuštěním následujícího příkazu:
Remove-SPTrustedIdentityTokenIssuer -Identity "TheNameOfYourTokenIssuer"
-
Znovu vytvořte vystavitele tokenu. Chcete-li získat další informace, postupujte podle kroků v tématu implementace ověřování založeného na standardu SAML na webu Microsoft TechNet 2013.Důležité Když spustíte příkaz New-SPTrustedIdentityTokenIssuer , musíte použít parametry UseDefaultConfiguration a IdentifierClaimIs . Parametr UseDefaultConfiguration je jenom přepínač. Možné hodnoty parametru IdentifierClaimIs jsou následující:
-
NÁZEV ÚČTU
-
E-mailu
-
UŽIVATELSKÉ JMÉNO PRO UŽIVATELE
Příklad skriptu:
$ap = New-SPTrustedIdentityTokenIssuer -Name $tokenIdentityProviderName -Description $TrustedIdentityTokenIssuerDescription -realm $siteRealm -ImportTrustCertificate $adfsCert-SignInUrl $signInUrl -UseDefaultConfiguration -IdentifierClaimIs EMAIL -RegisteredIssuerName $siteRealm
-
-
V centrální správě přidejte nového vystavitele důvěryhodného tokenu identity zpátky k poskytovatelům ověřování webové aplikace, kterou chcete převést. Webová aplikace musí mít vybrané ověřování systému Windows i vybraného poskytovatele důvěryhodné identity.
Další informace
Další tipy pro úspěšný převod: Pokud je e-MAILová hodnota použitá pro deklaraci identifikátoru (to je u parametru IdentifierClaimIs ), budou převedeny jenom ty uživatele, jejichž e-mailové adresy jsou naplněné. Všechny uživatelské účty uvedené v souboru. csv, který je definovaný v parametru SourceSkipList , nebudou převedeny do protokolu SAML. Pro převod deklarací Windows na SAML mohou být jména uživatelských účtů uvedena s nebo bez zápisu deklarací identity. Například "contoso\user1" nebo "i:0 #. t | contoso\user1" je přijatelné. Do tohoto souboru CSV byste měli přidat všechny uživatelské účty, které nechcete převést. Měly by to být účty služeb a účty správců.
