Kommandoen Konverter SPWebApplication kan ikke konvertere fra Windows-krav til SAML i SharePoint Server 2013

Symptomer

Tenk deg følgende:

• Du bruker Windows-kravgodkjenning (via Windows forespørsel/svar [NTLM] eller Kerberos) i et webprogram for Microsoft SharePoint Server 2013.

• Du bestemmer deg å bytte til klarert leverandør krav ved hjelp av en sikker Application Markup Language SAML-basert leverandør, for eksempel Active Directory Federation Services (AD FS).

• Du går gjennom trinnene i migrering av Windows-kravgodkjenning til SAML-basert kravgodkjenning i SharePoint Server 2013 emnet på webområdet Microsoft Developer Network (MSDN).

• Du kjører du følgende kommando:
  
  

  Konverter SPWebApplication-id $wa-til krav-KLARERTE-standard-fra krav-WINDOWS - TrustedProvider $tp - SourceSkipList $csv - RetainPermissions

I dette scenariet får du følgende feilmelding:

Årsak

Dette problemet oppstår fordi klarerte tokenutsteder for identitet ikke ble opprettet ved hjelp av standardkonfigurasjonen. Standardkonfigurasjonen må brukes for kommandoen Konverter SPWebApplication skal fungere riktig.

Kommandoen Konverter SPWebApplication krever en bestemt konfigurasjon for leverandøren klarert å være kompatibel med konvertering fra Windows-krav til SAML eller omvendt.

Spesielt må klarert tokenutsteder for identitet opprettes ved hjelp av parameterne UseDefaultConfiguration og IdentifierClaimIs .

Du kan sjekke om dine klarerte identitet tokenutsteder ble opprettet ved hjelp av parameteren UseDefaultConfiguration ved å kjøre følgende Windows PowerShell-skript.

Merk: Disse skriptene forutsetter at du har bare én klarert identitetsleverandør opprettet i den gjeldende farmen.

$tp = Get-SPTrustedIdentityTokenIssuer$tp.claimtypes 

Hvilke krav som skal sende dette skriptet er som følger:

• 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 

Den identitetskrav må være ett av følgende:

• WindowAccountName

• Epostadresse

• UPN
  

Eksempel på utdata for $tp. IdentityClaimTypeInformation:
DisplayName: e-post
InputClaimType: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
MappedClaimType: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress#IsIdentityClaim : True


Det må være en egendefinert kravleverandør med samme navn som tokenutsteder, og den må være av typen SPTrustedBackedByActiveDirectoryClaimProvider.
Kjør dette for å se om kravleverandør er til stede og kompatibel:

 $tp = Get-SPTrustedIdentityTokenIssuer
$name = $tp.name
$cp = Get-SPClaimProvider $name
if($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"}

Oppløsning

Hvis du vil løse dette problemet, sletter og oppretter klarerte tokenutsteder for identiteten. Følg disse trinnene:

1. Kjør skriptet nedenfor:
   
   

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

   
   Lag en kopi av utdata fra skriptet for fremtidig referanse. Spesielt må vi verdien for Name-egenskapen slik at den nye tokenutsteder kan opprettes ved hjelp av samme navn, og vi trenger identiteten hevder slik at den nye kravleverandør kan opprettes ved hjelp av samme identitetskrav. Så lenge det samme navnet som brukes for tokenutsteder og samme kravet blir brukt som identitetskrav, opprettholde alle brukere tillatelsene i webprogrammet når tokenutsteder opprettes på nytt.
   
   

2. Fjern gjeldende klarert identitetsleverandør fra leverandør av godkjenning for alle webprogrammer som bruker den.

3. Slett tokenutsteder ved å kjøre følgende kommando:
   
   

   Remove-SPTrustedIdentityTokenIssuer -Identity "TheNameOfYourTokenIssuer"

   
   

4. Opprett tokenutsteder på nytt. Hvis du vil gjøre dette, med fremgangsmåten i emnet Implementer SAML-basert godkjenning i SharePoint Server 2013 på Microsoft TechNet-webområdet for mer informasjon.
   
   Viktig Når du kjører kommandoen Ny SPTrustedIdentityTokenIssuer , må du bruke parameterne UseDefaultConfiguration og IdentifierClaimIs . UseDefaultConfiguration -parameteren er bare en bryter. Mulige verdier for parameteren IdentifierClaimIs er som følger:

   • NAVN PÅ FORRETNINGSFORBINDELSE

   • E-POST

   • HOVEDSTOL BRUKERNAVN

   
   
   Eksempelskript:
   
   

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

5. I Sentraladministrasjon av SharePoint, kan du legge til din nye klarerte identitet tokenutsteder tilbake til godkjenningstjenester for webprogrammet du forsøker å konvertere. Web-applikasjonen må ha både Windows-godkjenning og mål klarert identitetsleverandør valgt.

Hvis du vil ha mer informasjon

Flere tips for vellykket konvertering:

Hvis e-verdien brukes for ID-kravet (det vil si for parameteren IdentifierClaimIs ), konverteres bare brukere som har e-postadresser er utfylt i Active Directory.

Brukerkontoer som er oppført i CSV-filen som er definert i SourceSkipList -parameteren vil ikke konverteres til SAML. Brukernavn for kontoen kan vises med eller uten krav-notasjonen for konvertering fra Windows-krav til SAML. Hvis du for eksempel enten "contoso\user1" eller "i:0 # .w | contoso\user1" er akseptabel. Du bør legge til denne CSV-filen brukerkontoer som du ikke vil konvertere. Ta med service og administratorkontoer.