Symptom
Tänk dig följande situation:
-
Du använder Windows-anspråksautentisering (via Windows Challenge/Response [NTLM] eller Kerberos) i ett Microsoft SharePoint Server 2013-webb program.
-
Du bestämmer dig för att byta till betrodda leverantörs anspråk med hjälp av en SAML-baserad (Secure program Markup Language) provider, till exempel AD FS (Active Directory Federation Services).
-
Du läser igenom stegen i migreringen av Windows-anspråksautentisering till SAML-baserad anspråksautentisering i SharePoint Server 2013 -avsnittet på webbplatsen för Microsoft Developer Network (MSDN).
-
Du kör följande kommando:
Convert-SPWebApplication-ID $wa-till anspråk-tillförlitliga-standard-från-anspråk-WINDOWS-TrustedProvider $tp-SourceSkipList $csv-RetainPermissions
I det här scenariot visas följande fel meddelande:
SAML-baserad anspråksautentisering är inte kompatibel.
Orsak
Det här problemet uppstår på grund av att den betrodda identitets-utfärdaren inte skapades med standard konfigurationen. Standard konfigurationen måste användas för att kommandot Convert-SPWebApplication ska fungera korrekt. Kommandot Convert-SPWebApplication kräver en särskild konfiguration för den betrodda leverantören för att den ska vara kompatibel med konvertering från Windows-anspråk till SAML eller vice versa. Specifikt måste utgivaren av Trusted Identity token skapas med parametrarna UseDefaultConfiguration och IdentifierClaimIs . Du kan kontrol lera om den betrodda identitets utfärdarens utgivare skapades genom att använda parametern UseDefaultConfiguration genom att köra följande Windows PowerShell-skript.Obs! Dessa skript förutsätter att du bara har en betrodd identitets leverantör skapad i den aktuella Server gruppen.
$tp = Get-SPTrustedIdentityTokenIssuer$tp.claimtypes
Följande anspråks typer bör matas ut:
-
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
Identitets anspråk måste vara något av följande:
-
WindowAccountName
-
EmailAddress
-
ANGIVET
Exempel på utdata för $tp. IdentityClaimTypeInformation: DisplayName: e-InputClaimType: http://schemas.xmlsoap.org/WS/2005/05/Identity/Claims/EmailAddressMappedClaimType: http://schemas.xmlsoap.org/WS/2005/05/Identity/Claims/EmailAddress#IsIdentityClaim : true det ska finnas en anpassad fordrings leverantör med samma namn som token-utgivaren och den bör vara av typen SPTrustedBackedByActiveDirectoryClaimProvider. Kör detta för att se om anspråksprovidern är tillgänglig och kompatibel:
$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"}Lösning
Lös problemet genom att ta bort och återskapa utgivaren av den betrodda identitets-token. Gör så här:
-
Kör följande skript:
$tp = Get-SPTrustedIdentityTokenIssuer$tp | fl$tp.name$tp.IdentityClaimTypeInformation
Skapa en kopia av utdata från det här skriptet för framtida referens. I synnerhet behöver vi värdet för egenskapen name så att den nya token-utgivaren kan skapas med samma namn och vi behöver identitets anspråk så att den nya anspråksprovidern kan skapas med samma identitets anspråk. Så länge det här namnet används för token-utgivaren och samma anspråk används som identitets anspråk behåller alla användare sin behörighet i webb programmet efter att token-utgivaren har återskapats.
-
Ta bort den aktuella betrodda identitets leverantören från autentiseringsproviders för ett webb program som använder den för tillfället.
-
Ta bort token-utgivaren genom att köra följande kommando:
Remove-SPTrustedIdentityTokenIssuer -Identity "TheNameOfYourTokenIssuer"
-
Återskapa token-utgivaren. Det gör du genom att följa stegen i avsnittet implementera SAML-baserad identifiering i SharePoint Server 2013 på Microsoft TechNet-webbplatsen för mer information.Viktigt! När du kör kommandot ny-SPTrustedIdentityTokenIssuer måste du använda parametrarna UseDefaultConfiguration och IdentifierClaimIs . Parametern UseDefaultConfiguration är bara en växel. Möjliga värden för parametern IdentifierClaimIs är följande:
-
KONTO-NAMN
-
E-
-
ANVÄNDARENS HUVUD NAMN
Exempel skript:
$ap = New-SPTrustedIdentityTokenIssuer -Name $tokenIdentityProviderName -Description $TrustedIdentityTokenIssuerDescription -realm $siteRealm -ImportTrustCertificate $adfsCert-SignInUrl $signInUrl -UseDefaultConfiguration -IdentifierClaimIs EMAIL -RegisteredIssuerName $siteRealm
-
-
I Central administration lägger du till en ny betrodd identitets utfärdares utgivare i autentiseringsprovidern för det webb program du försöker konvertera. Webb programmet måste ha både Windows-inloggningsautentisering och den betrodda tillförlitliga identitets leverantören markerad.
Mer information
Ytterligare tips för lyckad konvertering: om e-postvärdet används för identitets anspråk (det vill säga IdentifierClaimIs -parametern) kommer endast de användare vars e-postadresser är ifyllda i Active Directory att konverteras. Alla användar konton som listas i CSV-filen som definieras i SourceSkipList -parametern konverteras inte till SAML. För konvertering från Windows-anspråk till SAML kan användar konto namnen visas med eller utan anspråk. Antingen är "contoso\user1" eller "i:0 #. w | contoso\user1" acceptabelt. Du bör lägga till den. csv-filen som du vill konvertera. Dessa bör inkludera tjänst konton och administratörs konton.
