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

VIKTIG: Denne artikkelen ble oversatt med maskinoversettelsesprogramvare fra Microsoft og muligens redigert av Microsoft Community via CTF-teknologi i stedet for av en oversetter. Microsoft tilbyr både menneskelig oversatte og maskinoversatte/Community-redigerte artikler, slik at du får tilgang til alle artiklene i vår Knowledge Base på ditt eget språk. En maskinoversatt eller Community-redigert artikkel er imidlertid ikke alltid perfekt. Den kan inneholde feil i vokabular, syntaks eller grammatikk, mye likt en fremmedspråklig som forsøker å snakke språket ditt. Microsoft har ikke ansvar for unøyaktige opplysninger, feil eller skade forårsaket av feilaktig oversettelse av innholdet eller kundenes bruk av informasjonen. Microsoft oppdaterer jevnlig maskinoversettelsesprogramvaren og -verktøyene for å forbedre redigering av maskinoversatte tekster.

Den engelske versjonen av denne artikkelen er den følgende: 3042604
Symptom
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 den Krav migrering av Windows-godkjenning 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:

SAML-basert krav-godkjenning er ikke kompatibel.

Å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.

Obs! 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/Epostadresse
  • 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 $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"}

Løsning
Hvis du vil løse dette problemet, sletter og oppretter klarerte tokenutsteder for identiteten. Følg denne fremgangsmåten:
  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, følger du trinnene i den Implementere SAML-basert godkjenning i SharePoint Server 2013 emnet på Microsoft TechNet-webområdet for mer informasjon.

    Viktig Når du kjører den Nye SPTrustedIdentityTokenIssuer -kommandoen, må du bruke den UseDefaultConfiguration og IdentifierClaimIs Parametere. Den UseDefaultConfiguration parameteren er bare en bryter. Mulige verdier den IdentifierClaimIs parameteren 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 begge Windows-godkjenning og målet valgt klarert identitetsleverandør.
Mer informasjon
Additionaltips for vellykket konvertering:

Hvis e-verdien brukes for ID-kravet (det vil si for parameterenIdentifierClaimIs), 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 Nr. w|contoso\user1" er akseptabel. Du bør legge til denne CSV-filen brukerkontoer som du ikke vil konvertere. Ta med service og administratorkontoer.

Advarsel: Denne artikkelen er autooversatt

Egenskaper

Artikkel-ID: 3042604 – Forrige gjennomgang: 12/02/2015 12:48:00 – Revisjon: 2.0

Microsoft SharePoint Foundation 2013, Microsoft SharePoint Server 2013

  • kbexpertiseinter kbprb kbsurveynew kbmt KB3042604 KbMtno
Tilbakemelding