Simptomi
Iedomājieties šādu scenāriju:
-
Microsoft SharePoint Server 2013 Web lietojumprogrammā izmantojat Windows prasības autentifikāciju (izmantojot Windows izaicinājumu/atbildi [NTLM] vai Kerberos).
-
Jūs izlemjat pārslēgties uz uzticama pakalpojumu sniedzēja prasībām, izmantojot drošas lietojumprogrammas iezīmēšanas valodas (SAML) pakalpojumu sniedzēju, piemēram, Active Directory Federācijas pakalpojums (AD FS).
-
Jūs pārskatāt darbības, kas minētas šajā Windows piemēra AUTENTIFIKĀCIJU SAML prasībām autentifikāciju SharePoint Server 2013 tēmā Microsoft Developer Network (MSDN) tīmekļa vietnē.
-
Palaidiet šādu komandu:
Convert-SPWebApplication-ID $wa-uz prasībām-uzticami-noklusējuma-no prasībām-WINDOWS-TrustedProvider $tp-SourceSkipList $csv-RetainPermissions
Šajā scenārijā tiek parādīts šāds kļūdas ziņojums:
SAML pamatotā pretenzija autentifikācija nav saderīga.
Cēlonis
Šī problēma rodas tāpēc, ka uzticamo identitātes marķiera izdevējs netika izveidots, izmantojot noklusējuma konfigurāciju. Lai komanda pārvērst-SPWebApplication darbotos pareizi, jāizmanto noklusējuma konfigurācija. Komandai Konvertēt-SPWebApplication nepieciešama specifiska uzticamā pakalpojumu sniedzēja konfigurācija, lai tā būtu saderīga ar pāreju no Windows prasībām uz SAML vai otrādi. Īpaši uzticams identitātes marķiera izdevējs ir jāveido, izmantojot parametrus UseDefaultConfiguration un IdentifierClaimIs . Varat pārbaudīt, vai uzticamas identitātes marķiera izdevējs ir izveidots, izmantojot parametru UseDefaultConfiguration , palaižot šādus Windows PowerShell skriptus.Piezīme. Šajos skriptos tiek pieņemts, ka jums ir tikai viens uzticams identitātes nodrošinātājs, kas izveidots pašreizējā fermā.
$tp = Get-SPTrustedIdentityTokenIssuer$tp.claimtypes
Šajā skriptā izcelto prasību tipi ir šādi:
-
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
Identitātes prasībā ir jābūt vienai no šīm:
-
WindowAccountName
-
EmailAddress
-
UPN
Piemēram, $tp izvade. IdentityClaimTypeInformation: DisplayName: e-pasta InputClaimType: http://schemas.xmlsoap.org/ws/2005/05/Identity/Claims/EmailAddressMappedClaimType: http://schemas.xmlsoap.org/ws/2005/05/Identity/Claims/EmailAddress#IsIdentityClaim : patiess ir jābūt pielāgotam prasības nodrošinātājam ar tādu pašu nosaukumu kā marķiera emitentam, un tam jābūt tipa SPTrustedBackedByActiveDirectoryClaimProvider. Izpildiet šo darbību, lai noskaidrotu, vai prasības nodrošinātājs ir prezentēšana un saderība:
$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"}Risinājums
Lai atrisinātu šo problēmu, izdzēsiet un pēc tam atkārtoti izveidojiet uzticamo identitātes marķiera izdevēju. Lai to izdarītu, veiciet tālāk norādītās darbības.
-
Palaidiet šādu skriptu:
$tp = Get-SPTrustedIdentityTokenIssuer$tp | fl$tp.name$tp.IdentityClaimTypeInformation
Veidojiet šī skripta rezultāta kopiju turpmākai atsaucei. Jo īpaši ir jānorāda rekvizīta Name vērtība, lai jauno marķierierīces emitentu varētu izveidot, izmantojot tādu pašu nosaukumu, un mums ir jāpieprasa identitātes prasība, lai jauno pieprasījumu sniedzēju varētu izveidot, izmantojot to pašu identitātes norādi. Kamēr vien marķiera emitentam tiek lietots tas pats nosaukums, bet tas pats attiecas uz identitātes norādi, visi lietotāji saglabās savas atļaujas tīmekļa lietojumprogrammā pēc tam, kad ir atkārtoti izveidots marķiera izdevējs.
-
Noņemiet pašreizējo uzticamo identitātes pakalpojumu sniedzēju no autentifikācijas nodrošinātājiem jebkurai tīmekļa lietojumprogrammai, kas to pašlaik izmanto.
-
Izdzēsiet marķierierīces emitentu, izpildot šādu komandu:
Remove-SPTrustedIdentityTokenIssuer -Identity "TheNameOfYourTokenIssuer"
-
Atkārtoti izveidojiet marķiera izdevēju. Lai to izdarītu, veiciet šajā rakstā no2013 rādītās darbības, lai iegūtu papildinformāciju.Svarīgi Palaižot komandu New-SPTrustedIdentityTokenIssuer , ir jāizmanto parametri UseDefaultConfiguration un IdentifierClaimIs . Parametrs UseDefaultConfiguration ir tikai slēdzis. IdentifierClaimIs parametra iespējamās vērtības ir šādas:
-
KONTA NOSAUKUMS
-
E-pasta
-
LIETOTĀJA GALVENAIS NOSAUKUMS
Skripta piemērs:
$ap = New-SPTrustedIdentityTokenIssuer -Name $tokenIdentityProviderName -Description $TrustedIdentityTokenIssuerDescription -realm $siteRealm -ImportTrustCertificate $adfsCert-SignInUrl $signInUrl -UseDefaultConfiguration -IdentifierClaimIs EMAIL -RegisteredIssuerName $siteRealm
-
-
Centrālajā administrēšanā pievienojiet jauno uzticamo identitātes marķiera apliecinājumu, lai saņemtu tās tīmekļa lietojumprogrammas autentifikācijas nodrošinātājus, kuru mēģināt konvertēt. Tīmekļa lietojumprogrammai jābūt atlasītai gan Windows autentifikācijai, gan uzticamo identitātes pakalpojumu sniedzējam.
Papildinformācija
Papildu padomi sekmīgai konvertēšanai: ja e-pasta vērtība tiek izmantota identifikatora pieprasījumam (tas ir, IdentifierClaimIs parametram), tiks konvertēti tikai tie lietotāji, kuru e-pasta adreses ir aizpildītas pakalpojumā Active Directory. Visi lietotāju konti, kas ir uzskaitīti. csv failā, kas ir definēti parametrā SourceSkipList , netiks konvertēti SAML. Lai veiktu pāreju no Windows prasības uz SAML, lietotāju kontu nosaukumus var uzskaitīt ar vai bez prasībām notācijas. Piemēram, "contoso\user1" vai "i:0 #. w | contoso\user1" ir pieņemams. Šim. csv failam ir jāpievieno visi lietotāju konti, kurus nevēlaties konvertēt. Šeit jāiekļauj pakalpojumu konti un administratora konti.
