Sintomi
Considerare lo scenario descritto di seguito:
-
Si usa l'autenticazione delle attestazioni Windows (tramite Windows Challenge/Response [NTLM] o Kerberos) in un'applicazione Web di Microsoft SharePoint Server 2013.
-
Si decide di passare alle attestazioni di provider attendibili usando un provider basato su SAML (Secure Application Markup Language), ad esempio Active Directory Federation Services (ADFS).
-
È possibile esaminare i passaggi della migrazione dell'autenticazione delle attestazioni di Windows all'autenticazione delle attestazioni basata su SAML nell'argomento SharePoint Server 2013 nel sito Web Microsoft Developer Network (MSDN).
-
Si esegue il comando seguente:
Convert-SPWebApplication-ID $wa-per le ATTESTAzioni-TRUSTED-DEFAULT-from CLAIMs-WINDOWS-TrustedProvider $tp-SourceSkipList $csv-RetainPermissions
In questo scenario viene visualizzato il messaggio di errore seguente:
L'autenticazione delle attestazioni basata su SAML non è compatibile.
Causa
Questo problema si verifica perché l'autorità di emissione attendibile del token di identità non è stata creata utilizzando la configurazione predefinita. Per il corretto funzionamento del comando Convert-SPWebApplication è necessario usare la configurazione predefinita. Il comando Convert-SPWebApplication richiede una configurazione specifica per il provider attendibile affinché sia compatibile con la conversione da attestazioni Windows a SAML o viceversa. In particolare, l'emittente del token di identità attendibile deve essere creato usando i parametri UseDefaultConfiguration e IdentifierClaimIs . Puoi verificare se l'emittente del token di identità attendibile è stato creato usando il parametro UseDefaultConfiguration eseguendo gli script di Windows PowerShell seguenti.Nota: Questi script presuppongono che sia stato creato un solo provider di identità attendibile all'interno della farm corrente.
$tp = Get-SPTrustedIdentityTokenIssuer$tp.claimtypes
I tipi di attestazioni che questo script deve restituire sono i seguenti:
-
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
L'attestazione di identità deve essere una delle seguenti:
-
WindowAccountName
-
EmailAddress
-
UPN
Esempio di output per $tp. IdentityClaimTypeInformation: DisplayName: InputClaimType di posta elettronica: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/EmailAddressMappedClaimType: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/EmailAddress#IsIdentityClaim : vero deve essere presente un provider di attestazioni personalizzato con lo stesso nome dell'emittente del token e deve essere di tipo SPTrustedBackedByActiveDirectoryClaimProvider. Eseguire questa operazione per verificare se il provider di attestazioni è presente e compatibile:
$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"}Risoluzione
Per risolvere il problema, eliminare e quindi ricreare l'emittente del token di identità attendibile. A tal fine, attenersi alla seguente procedura:
-
Eseguire lo script seguente:
$tp = Get-SPTrustedIdentityTokenIssuer$tp | fl$tp.name$tp.IdentityClaimTypeInformation
Creare una copia dell'output di questo script per riferimento futuro. In particolare, è necessario il valore per la proprietà Name in modo che il nuovo emittente del token possa essere creato usando lo stesso nome e sia necessaria l'attestazione di identità in modo che il nuovo provider di attestazioni possa essere creato usando la stessa attestazione di identità. Finché viene usato lo stesso nome per l'emittente di token e la stessa attestazione viene usata come attestazione di identità, tutti gli utenti manterranno le autorizzazioni nell'applicazione Web dopo che l'emittente del token viene ricreata.
-
Rimuovere il provider di identità attendibile corrente dai provider di autenticazione per qualsiasi applicazione Web attualmente in uso.
-
Eliminare il token Issuer eseguendo il comando seguente:
Remove-SPTrustedIdentityTokenIssuer -Identity "TheNameOfYourTokenIssuer"
-
Ricrea l'emittente del token. A questo scopo, seguire i passaggi descritti nell'argomento implementare l'autenticazione basata su SAML in SharePoint Server 2013 nel sito Web Microsoft TechNet per altre informazioni.Importante Quando si esegue il comando New-SPTrustedIdentityTokenIssuer , è necessario usare i parametri UseDefaultConfiguration e IdentifierClaimIs . Il parametro UseDefaultConfiguration è solo un'opzione. I valori possibili per il parametro IdentifierClaimIs sono i seguenti:
-
NOME ACCOUNT
-
Posta elettronica
-
USER-PRINCIPAL-NAME
Esempio di script:
$ap = New-SPTrustedIdentityTokenIssuer -Name $tokenIdentityProviderName -Description $TrustedIdentityTokenIssuerDescription -realm $siteRealm -ImportTrustCertificate $adfsCert-SignInUrl $signInUrl -UseDefaultConfiguration -IdentifierClaimIs EMAIL -RegisteredIssuerName $siteRealm
-
-
In Amministrazione centrale aggiungere di nuovo l'emittente del token di identità attendibile ai provider di autenticazione per l'applicazione Web che si sta provando a convertire. L'applicazione Web deve avere sia l'autenticazione di Windows che il provider di identità attendibile di destinazione selezionato.
Ulteriori informazioni
Altri suggerimenti per la conversione riuscita: se il valore di posta elettronica viene usato per l'attestazione di identificatore (ovvero per il parametro IdentifierClaimIs ), verranno convertiti solo gli utenti i cui indirizzi di posta elettronica vengono popolati in Active Directory. Tutti gli account utente elencati nel file CSV definito nel parametro SourceSkipList non verranno convertiti in SAML. Per la conversione da attestazioni Windows a SAML, i nomi degli account utente possono essere elencati con o senza la notazione delle attestazioni. Ad esempio, "Contoso\Utente1" o "i:0 #. w | Contoso\Utente1" è accettabile. Devi aggiungere al file CSV tutti gli account utente che non vuoi convertire. Questi devono includere account di servizio e account di amministratore.
