Comanda de conversie-SPWebApplication nu poate efectua conversia de la Windows cererile pentru SAML în SharePoint Server 2013

IMPORTANT: Acest articol este tradus cu ajutorul software-ului Microsoft de traducere automată și poate fi corectat prin intermediul tehnologiei Community Translation Framework (CTF). Microsoft oferă articole traduse automat, post-editate de comunitate și articole traduse de oameni, pentru a permite accesul la toate articolele din Baza noastră de cunoștințe în mai multe limbi. Articolele traduse automat și post-editate pot conține greșeli de vocabular, sintaxă și/sau gramatică. Microsoft nu este responsabil de inexactitățile, erorile sau daunele cauzate de traducerea greșită a conținutului sau de utilizarea acestuia de către clienți. Găsiți mai multe informații despre traducerea în colaborare la http://support.microsoft.com/gp/machine-translation-corrections/ro.

Faceți clic aici pentru a vizualiza versiunea în limba engleză a acestui articol: 3042604
Simptome
Să luăm în considerare următorul scenariu:
  • Utilizați Windows cererile de autentificare (prin Windows provocare/răspuns [NTLM] sau Kerberos) într-o aplicație web Microsoft SharePoint Server 2013.
  • Decideți să comutați la furnizor de încredere cererile utilizând un furnizor bazate pe Secure Application Markup Language SAML, cum ar fi Active Directory Federation Services (AD FS).
  • Examinați pașii din Migrare Windows pretinde autentificarea la Autentificarea bazată pe SAML solicitări în SharePoint Server 2013 subiect pe site web Reţea Microsoft pentru dezvoltatori (MSDN).
  • Executaţi următoarea comandă:

    CONVERT-SPWebApplication-id $wa-la cererile de încredere-implicit - din WINDOWS cererile - TrustedProvider $tp - SourceSkipList $csv - RetainPermissions

În acest scenariu, primiţi următorul mesaj de eroare:

SAML bazat pe cererea de autentificare nu este compatibil.

Cauză
Această problemă apare deoarece încredere emitentul simbol identitate nu a fost creat utilizând configurația implicită. Configurația implicită trebuie utilizată pentru Conversia-SPWebApplication comanda să funcționeze corect.

Comanda de Conversie-SPWebApplication necesită o configurație specifică pentru furnizor de încredere pentru acesta să fie compatibil cu conversia de la Windows cererile SAML sau invers.

Mai precis, încredere identitate simbolului emitentul trebuie să se creeze utilizând parametrii UseDefaultConfiguration și IdentifierClaimIs .

Aveți posibilitatea să verificați dacă încredere identitate simbolului emitentul s-a creat utilizând parametrul UseDefaultConfiguration executând următoarele scripturi Windows PowerShell.

Notă: Aceste script-uri, să presupunem că aveți numai una de încredere furnizorul de identități creat în ferma curentă.

$tp = Get-SPTrustedIdentityTokenIssuer$tp.claimtypes 

Tipurile de cerere pe care acest script ar trebui să ieşire sunt după cum urmează:
  • 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 



Cerere de identitate trebuie să fie una dintre următoarele:
  • WindowAccountName
  • EmailAddress
  • UPN

Exemplu de ieşire pentru $tp. IdentityClaimTypeInformation:
DisplayName: E-mail
InputClaimType: http://schemas.xmlsoap.org/WS/2005/05/Identity/claims/EmailAddress
MappedClaimType: http://schemas.xmlsoap.org/WS/2005/05/Identity/claims/EmailAddress#IsIdentityClaim : Adevărate


Ar trebui să existe un furnizor pretenție particularizate cu același nume ca emitentul simbol și ar trebui să fie de tipul SPTrustedBackedByActiveDirectoryClaimProvider.
Executați acest lucru pentru a vedea dacă furnizorul de cerere este prezentă și compatibil:

 $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"}

Rezoluţie
Pentru a rezolva această problemă, ștergeți și creați din nou încredere emitentul simbol identitate. Pentru a face acest lucru, urmați acești pași:
  1. Executați următorul script:

    $tp = Get-SPTrustedIdentityTokenIssuer$tp | fl$tp.name$tp.IdentityClaimTypeInformation

    Efectuați o copie de ieșire acest script pentru referințe ulterioare. În special, avem nevoie de valoarea pentru proprietatea de nume, astfel încât emitentul nou simbol pot fi create utilizând același nume, și avem nevoie identitatea pretind, astfel încât furnizorul de noua cerere pot fi create utilizând același pretenție de identitate. Cât marcă de timp același nume este utilizat pentru emitentului simbol și același cererea este utilizat ca cerere de identitate, toți utilizatorii vor păstra permisiuni lor în aplicația web după emitentului simbol este creat din nou.

  2. Eliminați curentă de încredere furnizorul de identități de furnizori de autentificare pentru orice aplicație web care se utilizează în prezent.
  3. Ștergeți emitentului simbolului executând următoarea comandă:

    Remove-SPTrustedIdentityTokenIssuer -Identity "TheNameOfYourTokenIssuer"

  4. Creați din nou emitentului simbolului. Pentru aceasta, urmați pașii din Implementați Autentificarea bazată pe SAML în SharePoint Server 2013 subiect pe site web Microsoft TechNet pentru mai multe informații.

    Important Când executați Nou-SPTrustedIdentityTokenIssuer comanda, trebuie să utilizați UseDefaultConfiguration și IdentifierClaimIs parametri. The UseDefaultConfiguration parametrul este doar un parametru. Valori posibile pentru IdentifierClaimIs parametru sunt după cum urmează:
    • NUME CONT
    • POȘTĂ ELECTRONICĂ
    • nume de sign-in DE UTILIZATOR PRINCIPAL


    Exemplu de script:

    $ap = New-SPTrustedIdentityTokenIssuer -Name $tokenIdentityProviderName -Description $TrustedIdentityTokenIssuerDescription -realm $siteRealm -ImportTrustCertificate $adfsCert-SignInUrl $signInUrl -UseDefaultConfiguration -IdentifierClaimIs EMAIL -RegisteredIssuerName $siteRealm
  5. În administrare centrală, adăugați noi încredere identitate simbolului emitentul înapoi la furnizori de autentificare pentru aplicația web pe care încercați să efectuați conversia. Trebuie să aveți aplicația web ambele Autentificare Windows și țintă selectat furnizorul de identități de încredere.
Informaţii suplimentare
Additionaltips pentru conversia de succes:

Dacă valoarea de poștă electronică este utilizat pentru argumentul identificator (, pentru parametrulIdentifierClaimIs), se va efectua conversia numai utilizatorii ale căror adrese de poștă electronică sunt populate în Active Directory.

Toate conturile de utilizator care sunt listate în fișierul .csv, care este definit în parametrul SourceSkipList nu va efectua conversia la SAML. Conversia de la Windows cererile pentru SAML, nume de sign-in de cont de utilizator pot fi enumerate cu sau fără notația cereri. De exemplu, fie "contoso\user1" sau "i:0 #. w|contoso\user1" este acceptabil. Va trebui să adăugaţi la acel fișier .csv toate conturile de utilizator care nu doriți transformate. Acestea ar trebui să includă conturile de consolidare servicii și conturile de administrator.

Avertisment: acest articol a fost tradus automat

Proprietăți

ID articol: 3042604 - Ultima examinare: 12/02/2015 12:51:00 - Revizie: 2.0

Microsoft SharePoint Foundation 2013, Microsoft SharePoint Server 2013

  • kbexpertiseinter kbprb kbsurveynew kbmt KB3042604 KbMtro
Feedback