Il comando Converti-SPWebApplication non può convertire da attestazioni di Windows di SAML in SharePoint Server 2013

IMPORTANTE: il presente articolo è stato tradotto tramite un software di traduzione automatica di Microsoft ed eventualmente revisionato dalla community Microsoft tramite la tecnologia CTF (Community Translation Framework) o da un traduttore professionista. Microsoft offre articoli tradotti manualmente e altri tradotti automaticamente e rivisti dalla community con l’obiettivo di consentire all'utente di accedere a tutti gli articoli della Knowledge Base nella propria lingua. Tuttavia, un articolo tradotto automaticamente, anche se rivisto dalla community, non sempre è perfetto. Potrebbe contenere errori di vocabolario, di sintassi o di grammatica. Microsoft declina ogni responsabilità per imprecisioni, errori o danni causati da una traduzione sbagliata o dal relativo utilizzo da parte dei clienti. Microsoft aggiorna frequentemente il software e gli strumenti di traduzione automatica per continuare a migliorare la qualità della traduzione.

Clicca qui per visualizzare la versione originale in inglese dell’articolo: 3042604
Sintomi
Si consideri lo scenario seguente:
  • Si utilizza l'autenticazione delle attestazioni di Windows (tramite Challenge/Response di Windows [NTLM] o Kerberos) in un'applicazione web di Microsoft SharePoint Server 2013.
  • Si decide di passare ai crediti Provider attendibile utilizzando un provider basato su protezione SAML Application Markup Language, quali Active Directory Federation Services (ADFS).
  • Esaminare i passaggi di Autenticazione per l'autenticazione basata su SAML attestazioni in SharePoint Server 2013 attestazioni di migrazione di Windows argomento sul sito Web Microsoft Developer Network (MSDN).
  • Eseguire il comando seguente:

    Converti-SPWebApplication-id $wa-di ATTESTAZIONI ATTENDIBILI-predefinito-da crediti-WINDOWS - TrustedProvider $tp SourceSkipList - $csv - RetainPermissions

In questo scenario, viene visualizzato il seguente messaggio di errore:

Autenticazione di attestazione basata su SAML non sono compatibili.

Cause
Questo problema si verifica perché l'emittente Token identità attendibili non è stato creato utilizzando la configurazione predefinita. La configurazione predefinita da utilizzare per il comando Converti-SPWebApplication per funzionare correttamente.

Il comando Converti-SPWebApplication richiede una configurazione specifica per il Provider attendibili per esso è compatibile con la conversione da attestazioni di Windows a SAML o viceversa.

In particolare, l'emittente Token identità attendibili devono essere creato utilizzando i parametri UseDefaultConfiguration e IdentifierClaimIs .

È possibile verificare se l'emittente Token identità attendibili è stato creato utilizzando il parametro UseDefaultConfiguration eseguendo i seguenti script di Windows PowerShell.

Nota: Questi script presuppongono che sia disponibile un solo che provider di identità attendibile creato all'interno della farm corrente.

$tp = Get-SPTrustedIdentityTokenIssuer$tp.claimtypes 

I tipi di attestazione che deve generare questo script 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/SID di gruppo
  • 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 



Attestazione d'identità deve essere una delle seguenti:
  • WindowAccountName
  • EmailAddress
  • UPN

Output di esempio per $tp. IdentityClaimTypeInformation:
DisplayName: Email
InputClaimType: http://schemas.xmlsoap.org/ws/2005/05/Identity/claims/EmailAddress
MappedClaimType: http://schemas.xmlsoap.org/ws/2005/05/Identity/claims/EmailAddress#IsIdentityClaim : True


Dovrebbe esserci un provider di attestazione personalizzata con lo stesso nome come emittente del token e deve essere di tipo SPTrustedBackedByActiveDirectoryClaimProvider.
Eseguire questa operazione per verificare se il provider di attestazioni è presente ed è 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 questo problema, eliminare e quindi ricreare attendibili identità emittente del Token. A tale scopo, attenersi alla seguente procedura:
  1. 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 della proprietà Name in modo che la nuova emittente di Token possono essere creato utilizzando lo stesso nome, e abbiamo bisogno di identità richiedere in modo che il nuovo provider di attestazioni possono essere creati utilizzando attestazione d'identità stesso. Purché lo stesso nome viene utilizzato per l'emittente del token e il credito stesso viene utilizzato come attestazione d'identità, tutti gli utenti verranno mantenute le autorizzazioni all'interno dell'applicazione web dopo l'emittente del token viene ricreato.

  2. Rimuovere il Provider di identità attendibili corrente dal provider di autenticazione per qualsiasi applicazione web che si sta utilizzando.
  3. Eliminare l'emittente del token utilizzando il comando seguente:

    Remove-SPTrustedIdentityTokenIssuer -Identity "TheNameOfYourTokenIssuer"

  4. Ricreare l'emittente del token. A tale scopo, seguire i passaggi di Implementare l'autenticazione basata su SAML in SharePoint Server 2013 argomento sul sito Web Microsoft TechNet per ulteriori informazioni.

    Importante Quando si esegue il Nuovo-SPTrustedIdentityTokenIssuer comando, è necessario utilizzare il UseDefaultConfiguration e IdentifierClaimIs parametri. Il UseDefaultConfiguration parametro è solo un'opzione. Valori possibili per il IdentifierClaimIs parametro sono i seguenti:
    • NOME DI ACCOUNT
    • MESSAGGIO DI POSTA ELETTRONICA
    • NOME UTENTE-PRINCIPALE


    Script di esempio:

    $ap = New-SPTrustedIdentityTokenIssuer -Name $tokenIdentityProviderName -Description $TrustedIdentityTokenIssuerDescription -realm $siteRealm -ImportTrustCertificate $adfsCert-SignInUrl $signInUrl -UseDefaultConfiguration -IdentifierClaimIs EMAIL -RegisteredIssuerName $siteRealm
  5. In Amministrazione centrale, aggiungere la nuova emittente Token identità attendibile al provider di autenticazione per l'applicazione web che si desidera convertire. L'applicazione web deve avere entrambi Autenticazione di Windows e di destinazione selezionato il Provider di identità attendibile.
Informazioni
Additionaltips per la conversione ha esito positivo:

Se il valore del messaggio di posta elettronica viene utilizzato per l'attestazione dell'identificatore (vale a dire per il parametroIdentifierClaimIs), verranno convertiti solo gli utenti con indirizzi di posta elettronica vengono inseriti in Active Directory.

Gli account utente elencati nel file CSV che è definito nel parametro SourceSkipList non essere convertiti in SAML. Per conversione da a SAML attestazioni di Windows, è possibile elencare i nomi degli account utente con o senza la notazione di attestazioni. Ad esempio, il "contoso\user1" o "i:0 n. w|contoso\user1" è accettabile. È necessario aggiungere al file CSV gli account utente che si desidera convertire. Ovvero gli account di servizio e account amministratore.

Avviso: questo articolo è stato tradotto automaticamente

Proprietà

ID articolo: 3042604 - Ultima revisione: 12/01/2015 23:53:00 - Revisione: 2.0

Microsoft SharePoint Foundation 2013, Microsoft SharePoint Server 2013

  • kbexpertiseinter kbprb kbsurveynew kbmt KB3042604 KbMtit
Feedback