Príznaky
Zoberme si nasledujúcu situáciu:
-
Vo webovej aplikácii Microsoft SharePoint Server 2013 používate overovanie pohľadávok systému Windows (cez Windows Challenge/Response [NTLM] alebo Kerberos).
-
Rozhodli ste sa prepnúť na dôveryhodného poskytovateľa pohľadávok prostredníctvom poskytovateľa služby secure Application Markup Language (SAML), ako sú napríklad služby Active Directory Federation Services (AD FS).
-
Prezrite si kroky v migrácii systému Windows deklarácie pohľadávok na overenie pohľadávok na základe SAML v téme SharePoint Server 2013 na webovej lokalite Microsoft Developer Network (MSDN).
-
Spustite nasledujúci príkaz:
Konverzia – SPWebApplication – id $wa – na nároky – dôveryhodné – predvolené – z pohľadávok – WINDOWS-TrustedProvider $tp-SourceSkipList $csv-RetainPermissions
V tomto scenári sa zobrazí nasledujúce chybové hlásenie:
Overenie deklarácie na základe SAML nie je kompatibilné.
Príčina
Tento problém sa vyskytuje, pretože Vydavateľ tokenu dôveryhodných identít sa nevytvoril pomocou predvolenej konfigurácie. Ak chcete, aby príkaz convert-SPWebApplication fungoval správne, musí sa použiť predvolená konfigurácia. Príkaz convert-SPWebApplication vyžaduje konkrétnu konfiguráciu dôveryhodného poskytovateľa, aby bola kompatibilná s konverziou z Windowsu na SAML alebo naopak. Konkrétne je nutné, aby sa vydavateľ tokenu dôveryhodnej identity vytvoril pomocou parametrov UseDefaultConfiguration a IdentifierClaimIs . Spustením nasledujúcich skriptov prostredia Windows PowerShell môžete skontrolovať, či sa vydavateľ tokenu dôveryhodnej identity vytvoril pomocou parametra UseDefaultConfiguration .Poznámka: Tieto skripty predpokladajú, že máte v rámci aktuálnej farmy vytvorený iba jeden dôveryhodný poskytovateľ identity.
$tp = Get-SPTrustedIdentityTokenIssuer$tp.claimtypes
Typ deklarácie, že tento skript by mal byť výstupom, je nasledujúci:
-
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
Žiadosť o identitu musí byť jedna z týchto možností:
-
WindowAccountName
-
EmailAddress
-
UPN
Príklad výstupu pre $tp. IdentityClaimTypeInformation: DisplayName: E-mail InputClaimType: http://schemas.xmlsoap.org/WS/2005/05/identity/claims/EmailAddressMappedClaimType: http://schemas.xmlsoap.org/WS/2005/05/identity/claims/EmailAddress#IsIdentityClaim : True tam by mal byť vlastný Poskytovateľ deklarácie s rovnakým názvom ako emitent tokenu a mal by byť typu SPTrustedBackedByActiveDirectoryClaimProvider. Spustite toto, ak chcete zistiť, či je poskytovateľ deklarácie prítomný a kompatibilný:
$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"}
Riešenie
Ak chcete tento problém vyriešiť, odstráňte a znova vytvorte dôveryhodného vydavateľa tokenu identity. Postupujte podľa nasledujúcich krokov:
-
Spustite nasledujúci skript:
$tp = Get-SPTrustedIdentityTokenIssuer$tp | fl$tp.name$tp.IdentityClaimTypeInformation
Vytvorte kópiu výstupu tohto skriptu na budúce použitie. Potrebujeme najmä hodnotu vlastnosti Name, aby sa nový emitent tokenov mohol vytvoriť pomocou rovnakého názvu a potrebujeme nárok na identitu, aby sa nový poskytovateľ deklarácií mohol vytvoriť pomocou rovnakého nároku na identitu. Pokiaľ sa na emitenta tokenu použije rovnaký názov a použije sa rovnaké tvrdenie ako nárok na identitu, všetci používatelia si budú zachovávať svoje povolenia v rámci webovej aplikácie po opätovnom vytvorení vydavateľa tokenu.
-
Odstráňte aktuálneho poskytovateľa dôveryhodných identít z poskytovateľov overovania pre ľubovoľnú webovú aplikáciu, ktorá ju aktuálne používa.
-
Odstránenie vydavateľa tokenu spustením nasledujúceho príkazu:
Remove-SPTrustedIdentityTokenIssuer -Identity "TheNameOfYourTokenIssuer"
-
Znova vytvorte vydavateľa tokenu. Ak to chcete urobiť, postupujte podľa krokov v téme implementácia overovania na základe SAML v SharePoint serveri 2013 na webovej lokalite Microsoft TechNet a získajte ďalšie informácie.Dôležité upozornenie: Keď spustíte príkaz New-SPTrustedIdentityTokenIssuer , musíte použiť parametre UseDefaultConfiguration a IdentifierClaimIs . Parameter UseDefaultConfiguration je len prepínač. Možné hodnoty parametra IdentifierClaimIs sú nasledovné:
-
NÁZOV KONTA
-
E-mail
-
USER-PRINCIPAL NAME
Príklad skriptu:
$ap = New-SPTrustedIdentityTokenIssuer -Name $tokenIdentityProviderName -Description $TrustedIdentityTokenIssuerDescription -realm $siteRealm -ImportTrustCertificate $adfsCert-SignInUrl $signInUrl -UseDefaultConfiguration -IdentifierClaimIs EMAIL -RegisteredIssuerName $siteRealm
-
-
V centrálnej správe pridajte nového dôveryhodného vydavateľa tokenu identity späť na poskytovateľov overovania pre webovú aplikáciu, ktorú sa pokúšate skonvertovať. Webová aplikácia musí mať vybraté overovanie systému Windows a vybratie cieľového dôveryhodného poskytovateľa identity.
Ďalšie informácie
Ďalšie tipy na úspešnú konverziu: Ak sa použije hodnota e-MAILu pre pohľadávku identifikátora (to znamená pre parameter IdentifierClaimIs ), skonvertujú sa len tí používatelia, ktorých e-mailové adresy sú vyplnené v službe Active Directory. Všetky používateľské kontá, ktoré sú uvedené v súbore. csv, ktorý je definovaný v parametri SourceSkipList , sa nekonvertujú na SAML. Pri konverzii z Windowsu na SAML sa môžu názvy používateľských kont uvádzať aj bez zápisu pohľadávok. Napríklad "contoso\user1" alebo "i:0 #. w | contoso\user1" je prijateľná. Do súboru. CSV by ste mali pridať všetky používateľské kontá, ktoré nechcete skonvertovať. Tieto by mali zahŕňať kontá služby a kontá správcu.