Käsk Convert-SPWebApplication ei saa teisendada Windowsi nõuetest SAML rakenduses SharePoint Server 2013

Sümptomid

Arvestage järgmise stsenaariumiga.

• Kasutate Microsoft SharePoint Server 2013 veebirakenduses Windowsi nõuete autentimist (Windowsi väljakutse/vastuse [NTLM] või Kerberose kaudu).

• Otsustate aktiveerida usaldusväärse pakkuja nõuded, kasutades turvalist rakendust Markup Language (SAML)-põhine pakkuja (nt Active Directory Federation Services (AD FS)).

• Vaadake üle Windowsi nõuete migreerimise juhised autentimise kohta SAML-põhiste nõuete autentimise rakenduses SharePoint Server 2013 teemas Microsoft Developer NETWORKI (MSDN) veebisaidil.

• Käivitage järgmine käsk:

  Convert-SPWebApplication-ID $wa-to nõuded-usaldusväärsed-vaikimisi-alates NÕUETEst-WINDOWS-TrustedProvider $tp-SourceSkipList $csv-RetainPermissions

Selle stsenaariumi korral kuvatakse järgmine tõrketeade:

Põhjus

See probleem ilmneb seetõttu, et usaldusväärse identiteedi loa väljaandjat ei loodud vaikimisi konfiguratsiooni abil. Käsu convert-SPWebApplication abil õigesti töötamiseks tuleb kasutada vaikimisi konfiguratsiooni. Käsk convert-SPWebApplication nõuab usaldusväärsele pakkujale kindlat konfiguratsiooni, et see ühilduks Windowsi nõuete teisendamisega SAML või vastupidi. Täpsemalt peab usaldusväärse identiteedi tõendi väljaandja olema loodud UseDefaultConfiguration ja IdentifierClaimIs parameetrite abil. Saate kontrollida, kas teie usaldusväärse identiteedi tõendi väljaandja on loodud parameetri UseDefaultConfiguration abil, käivitades järgmised Windows PowerShelli skriptid.Märkus. Need skriptid eeldavad, et teil on praeguses serveripargis loodud ainult ühe usaldusväärse identiteedi pakkuja.

$tp = Get-SPTrustedIdentityTokenIssuer$tp.claimtypes 

Selle skripti väljundiks olevad argumendid on järgmised.

• 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 

Identiteedi väide peab olema ühte järgmistest.

• WindowAccountName

• EmailAddress

• UPN

$Tp väljundi näide. IdentityClaimTypeInformation: DisplayName: e-posti InputClaimType: http://schemas.xmlsoap.org/ws/2005/05/Identity/claims/EmailAddressMappedClaimType: http://schemas.xmlsoap.org/ws/2005/05/Identity/claims/EmailAddress#IsIdentityClaim : True peaks olema kohandatud nõude pakkuja, kellel on sama nimi kui sümboolne väljaandja, ning see peaks olema tüüpi SPTrustedBackedByActiveDirectoryClaimProvider. Käivitage see, et näha, kas nõude pakkuja on olemas ja ühilduv.

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

Lahendus

Selle probleemi lahendamiseks kustutage ja looge uuesti usaldusväärse identiteedi tõendi väljaandja. Selleks toimige järgmiselt.

1. Käivitage järgmine skript.

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

   Tee selle skripti väljundi koopia edaspidiseks kasutamiseks. Eelkõige vajame atribuuti Name, nii et uue loa väljaandjat saab luua sama nimega ja me vajame identiteedi väidet nii, et uue nõude pakkuja saab luua sama identiteedi nõude abil. Kui loa väljaandja jaoks kasutatakse sama nime ja sama nõuet kasutatakse identiteedi nõudena, säilitavad kõik kasutajad oma load veebirakenduses pärast seda, kui loa väljaandja on uuesti loodud.

2. Saate praeguse usaldusväärse identiteedi pakkuja eemaldada autentimise pakkujatelt mis tahes veebirakenduses, mis seda parajasti kasutab.

3. Kustutage turbelubade väljaandja, käivitades järgmise käsu:

   Remove-SPTrustedIdentityTokenIssuer -Identity "TheNameOfYourTokenIssuer"

4. Looge uuesti loa väljaandja. Selleks järgige lisateabe saamiseks SharePoint Server 2013 teemas SAML-põhine autentimine rakenduses Microsoft TechNeti veebisaidil olevaid juhiseid.NB! Kui käivitate uue SPTrustedIdentityTokenIssuer käsu, peate kasutama UseDefaultConfiguration ja IdentifierClaimIs parameetreid. Parameeter UseDefaultConfiguration on vaid lüliti. Parameetri IdentifierClaimIs võimalikud väärtused on järgmised.

   • KONTO NIMI

   • MEILIKONTO

   • KASUTAJA-PRINCIPAL-NAME

   Näide skript:

   $ap = New-SPTrustedIdentityTokenIssuer -Name $tokenIdentityProviderName -Description $TrustedIdentityTokenIssuerDescription -realm $siteRealm -ImportTrustCertificate $adfsCert-SignInUrl $signInUrl -UseDefaultConfiguration -IdentifierClaimIs EMAIL -RegisteredIssuerName $siteRealm

5. Lisage administreerimiskeskuses uus usaldusväärse identiteediga väljaandja tagasi veebirakenduse autentimise pakkujatele, mida proovite teisendada. Veebirakendusel peab olema nii Windowsi autentimine kui ka valitud sihtmärk usaldusväärse identiteedi pakkuja.

Lisateave

Lisanäpunäited edukaks teisendamiseks: kui MEILISÕNUMI väärtust kasutatakse identifikaatoriga (st IdentifierClaimIs parameeter), teisendatakse ainult need kasutajad, kelle meiliaadressid on Active Directorys asustatud. Mis tahes Kasutajakontod, mis on loetletud CSV-failis, mis on määratletud SourceSkipList parameetris, ei teisendata SAML. Windowsi nõuetest SAML üleminekuks saab kasutajakontode nimesid loetleda koos nõuete märke või nendeta. Näiteks on lubatud kas "contoso\user1" või "i:0 #. w | contoso\user1". Selle CSV-faili juurde tuleks lisada kõik kasutajakontod, mida te ei soovi teisendada. Need peaksid sisaldama teenuse kontosid ja administraatori kontosid.