Você está offline; aguardando reconexão

Polecenia aplikacji SPWebApplication konwersji nie mogą konwertować z oświadczeń systemu Windows do SAML w programie SharePoint Server 2013

WAŻNE: Ten artykuł został przetłumaczony przy użyciu oprogramowania firmy Microsoft do tłumaczenia maszynowego i może być poprawiony przy użyciu technologii Community Translation Framework (CTF). Firma Microsoft udostępnia artykuły tłumaczone maszynowo, poprawione przez społeczność, a także tłumaczone przez tłumaczy profesjonalnych, aby zapewnić dostęp do wszystkich artykułów w bazie wiedzy w wielu językach. Artykuły tłumaczone maszynowo i poprawione mogą zawierać błędy pisowni, składniowe i gramatyczne. Firma Microsoft nie ponosi odpowiedzialności za żadne nieścisłości, błędy ani szkody spowodowane przez niepoprawne tłumaczenia zawartości ani przez korzystanie z niej przez klientów. Więcej o strukturze CTF: http://support.microsoft.com/gp/machine-translation-corrections/pl.

Anglojęzyczna wersja tego artykułu to: 3042604
Symptomy
Rozważ następujący scenariusz:
  • Korzystać z aplikacji sieci web programu Microsoft SharePoint Server 2013 uwierzytelniania oświadczeń systemu Windows (za pomocą [NTLM] Windows Challenge/Response lub Kerberos).
  • Zdecydujesz się przejść do roszczeń zaufanego dostawcy przy użyciu dostawcy na bazie bezpiecznego stosowania Markup Language SAML takich jak Active Directory Federation Services (AD FS).
  • Warto zapoznać się z instrukcjami Migracja systemu Windows twierdzi, uwierzytelniania, do uwierzytelniania oświadczeń jednokrotnego 2013 serwera programu SharePoint temat w witrynie sieci Web Microsoft Developer Network (MSDN).
  • Uruchom następujące polecenie:

    Konwertuj SPWebApplication-id $wa-do roszczeń ZAUFANE-domyślne-od roszczeń-WINDOWS - TrustedProvider $tp - SourceSkipList $csv - RetainPermissions

W tym scenariuszu pojawi się następujący komunikat o błędzie:

Uwierzytelniania oświadczeń SAML oparty jest niezgodny.

Przyczyna
Ten problem występuje, ponieważ zaufane wystawcy tokenów tożsamości nie został utworzony przy użyciu konfiguracji domyślnej. Domyślna konfiguracja musi używane polecenia Convert SPWebApplication działał poprawnie.

Polecenie Convert SPWebApplication wymaga określonej konfiguracji dla zaufanego dostawcy dla niego ma być zgodna z konwersją oświadczeń systemu Windows do SAML lub na odwrót.

W szczególności zaufane wystawcy tokenów tożsamości musi zostać utworzony przy użyciu parametrów UseDefaultConfiguration i IdentifierClaimIs .

Można sprawdzić, czy Twój zaufane tożsamości wystawcy tokenów został utworzony przy użyciu parametru UseDefaultConfiguration przez uruchomienie poniższych skryptów środowiska Windows PowerShell.

Uwaga: Te skrypty Załóżmy, że tylko jeden zaufany dostawca tożsamości utworzonych w bieżącej farmie.

$tp = Get-SPTrustedIdentityTokenIssuer$tp.claimtypes 

Dostępne są następujące typy oświadczeń, ten skrypt powinien produkcji, że:
  • 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/,AdresEmail
  • http://schemas.xmlsoap.org/ws/2005/05/Identity/Claims/głównej nazwy użytkownika


#Get the Identity claim:$tp = Get-SPTrustedIdentityTokenIssuer$tp.IdentityClaimTypeInformation 



Oświadczenie tożsamości musi być jedną z następujących czynności:
  • WindowAccountName
  • AdresEmail
  • NAZWA UPN

Przykład danych wyjściowych do $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 : PRAWDA


Powinny istnieć dostawcy oświadczenia niestandardowego o takiej samej nazwie jak wystawcy tokenów i powinny być typu SPTrustedBackedByActiveDirectoryClaimProvider.
Uruchom, aby zobaczyć, czy dostawcy oświadczeń jest obecny i zgodne:

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

Rozwiązanie
Aby rozwiązać ten problem, należy usunąć i ponownie utworzyć zaufane wystawcy tokenów tożsamości. Aby to zrobić, wykonaj następujące kroki:
  1. Uruchom następujący skrypt:

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

    Utwórz kopię danych wyjściowych tego skryptu do użytku w przyszłości. W szczególności, potrzebujemy wartości dla właściwości nazwy nowego wystawcy tokenów mogą być tworzone przy użyciu tej samej nazwie i potrzebujemy tożsamości twierdzą, tak aby nowego dostawcy oświadczeń mogą być tworzone za pomocą samego oświadczenia tożsamości. Tak długo, jak długo tej samej nazwie jest używany dla wystawcy tokenów i tego samego roszczenia jest używany jako oświadczenie tożsamości, wszystkich użytkowników będzie utrzymywać ich uprawnień w ramach aplikacji sieci web po wystawcy tokenów jest utworzony ponownie.

  2. Usuń bieżący zaufanego dostawcy tożsamości od dostawców uwierzytelniania dla dowolnej aplikacji sieci web, która jest on obecnie używany.
  3. Usuń wystawcy tokenów, uruchamiając następujące polecenie:

    Remove-SPTrustedIdentityTokenIssuer -Identity "TheNameOfYourTokenIssuer"

  4. Utwórz ponownie wystawcy tokenów. Aby to zrobić, wykonaj kroki opisane w Uwierzytelnianie oparte na protokole SAML wdrożenia w programie SharePoint Server 2013 temat w witrynie TechNet firmy Microsoft, aby uzyskać więcej informacji.

    Ważne Po uruchomieniu programu Nowy SPTrustedIdentityTokenIssuer polecenia, należy użyć UseDefaultConfiguration i IdentifierClaimIs Parametry. Z UseDefaultConfiguration parametr jest tylko przejście. Możliwe wartości dla IdentifierClaimIs Parametr są następujące:
    • NAZWA KONTA
    • ADRES E-MAIL
    • UŻYTKOWNIK PRINCIPAL-NAME


    Przykładowy skrypt:

    $ap = New-SPTrustedIdentityTokenIssuer -Name $tokenIdentityProviderName -Description $TrustedIdentityTokenIssuerDescription -realm $siteRealm -ImportTrustCertificate $adfsCert-SignInUrl $signInUrl -UseDefaultConfiguration -IdentifierClaimIs EMAIL -RegisteredIssuerName $siteRealm
  5. W administracji centralnej dodać Twoje nowe zaufane tożsamości wystawcy tokenów z powrotem do dostawców uwierzytelniania dla aplikacji sieci web, którą chcesz przekonwertować. Aplikacja sieci web musi mieć zarówno Uwierzytelnianie systemu Windows i miejsce docelowe wybrane zaufanego dostawcy tożsamości.
Więcej informacji
Additionaltips dla udanej konwersji:

Jeśli używana jest wartość E-mail dla oświadczenie identyfikatora (czyli dla parametruIdentifierClaimIs), będą konwertowane tylko tych użytkowników, których adresy e-mail są wypełniane w usłudze Active Directory.

Wszelkie konta użytkowników, które są wymienione w pliku CSV, która jest zdefiniowana w parametrze SourceSkipList nie zostaną przekonwertowane na SAML. Konwersja z oświadczeń systemu Windows do SAML nazwy kont użytkowników można podawać z lub bez notacji roszczeń. Na przykład, albo "sprzedaż\użytkownik1" lub "i: 0 #. w|contoso\user1" jest do przyjęcia. Do tego pliku .csv należy dodawać kont użytkowników, których nie chcesz przekonwertowane. Te powinny obejmować kont usług i kont administratorów.

Ostrzeżenie: ten artykuł przetłumaczono automatycznie

Propriedades

ID do Artigo: 3042604 - Última Revisão: 12/02/2015 12:49:00 - Revisão: 2.0

Microsoft SharePoint Foundation 2013, Microsoft SharePoint Server 2013

  • kbexpertiseinter kbprb kbsurveynew kbmt KB3042604 KbMtpl
Comentários
r="var m=document.createElement('meta');m.name='ms.dqp0';m.content='true';document.getElementsByTagName('head')[0].appendChild(m);" onload="var m=document.createElement('meta');m.name='ms.dqp0';m.content='false';document.getElementsByTagName('head')[0].appendChild(m);" src="http://c1.microsoft.com/c.gif?"> y>