Korzystanie z dostawcy tożsamości SAML 2.0 na potrzeby logowania jednokrotnego
Ten dokument zawiera informacje na temat używania dostawcy tożsamości opartego na profilu SP-Lite zgodnego ze standardem SAML 2.0 jako preferowanego dostawcy usługi tokenu zabezpieczającego /dostawcy tożsamości. Ten scenariusz jest przydatny, gdy masz już lokalny katalog użytkownika i magazyn haseł, do którego można uzyskać dostęp przy użyciu protokołu SAML 2.0. Ten istniejący katalog użytkowników może służyć do logowania się do platformy Microsoft 365 i innych zasobów zabezpieczonych za pomocą identyfikatora Entra firmy Microsoft. Profil SAML 2.0 SP-Lite jest oparty na powszechnie używanym standardzie tożsamości federacyjnej Security Assertion Markup Language (SAML), aby zapewnić platformę wymiany logowania i atrybutów.
Uwaga
Aby uzyskać listę identyfikatorów innych firm, które zostały przetestowane do użycia z identyfikatorem Microsoft Entra ID, zobacz listę zgodności federacji firmy Microsoft Entra
Firma Microsoft obsługuje to środowisko logowania jako integrację usługi w chmurze firmy Microsoft, takiej jak Platforma Microsoft 365, z prawidłowo skonfigurowanym dostawcą tożsamości opartym na profilu SAML 2.0. Dostawcy tożsamości SAML 2.0 są produktami innych firm i dlatego firma Microsoft nie zapewnia pomocy technicznej dotyczącej wdrażania, konfiguracji, rozwiązywania problemów z najlepszymi rozwiązaniami dotyczącymi nich. Po prawidłowej konfiguracji integrację z dostawcą tożsamości SAML 2.0 można przetestować pod kątem odpowiedniej konfiguracji przy użyciu narzędzia Microsoft Połączenie ivity Analyzer, które zostało opisane bardziej szczegółowo poniżej. Aby uzyskać więcej informacji na temat dostawcy tożsamości opartego na profilu SAML 2.0 SP-Lite, poproś organizację o jej dostarczenie.
Ważne
W tym scenariuszu logowania jest dostępny tylko ograniczony zestaw klientów z dostawcami tożsamości SAML 2.0, w tym:
- Klienci internetowi, tacy jak Outlook Web Access i SharePoint Online
- Klienci z obsługą poczty e-mail korzystający z uwierzytelniania podstawowego i obsługiwaną metodę dostępu programu Exchange, taką jak IMAP, POP, Active Sync, MAPI itd. (do wdrożenia jest wymagany punkt końcowy protokołu rozszerzonego klienta), w tym:
- Microsoft Outlook 2010/Outlook 2013/Outlook 2016, Apple i Telefon (różne wersje systemu iOS)
- Różne urządzenia z systemem Google Android
- Windows Telefon 7, Windows Telefon 7.8 i Windows Telefon 8.0
- Klient poczty systemu Windows 8 i klient poczty systemu Windows 8.1
- Klient poczty systemu Windows 10
Wszyscy inni klienci nie są dostępni w tym scenariuszu logowania z dostawcą tożsamości SAML 2.0. Na przykład klient klasyczny programu Lync 2010 nie może zalogować się do usługi przy użyciu dostawcy tożsamości SAML 2.0 skonfigurowanego do logowania jednokrotnego.
Microsoft Entra SAML 2.0 wymagania dotyczące protokołu
Ten dokument zawiera szczegółowe wymagania dotyczące formatowania protokołu i komunikatów, które dostawca tożsamości SAML 2.0 musi zaimplementować w celu federacji z identyfikatorem Entra firmy Microsoft, aby umożliwić logowanie się do co najmniej jednej usługi w chmurze firmy Microsoft (np. Microsoft 365). Jednostka uzależniona SAML 2.0 (SP-STS) dla usługi w chmurze firmy Microsoft używana w tym scenariuszu jest identyfikatorem Firmy Microsoft Entra.
Zaleca się, aby upewnić się, że komunikaty wyjściowe dostawcy tożsamości SAML 2.0 są jak najbardziej podobne do podanych przykładowych śladów. Ponadto należy użyć określonych wartości atrybutów z podanych metadanych firmy Microsoft Entra tam, gdzie to możliwe. Gdy będziesz zadowolony z komunikatów wyjściowych, możesz przetestować go za pomocą narzędzia Microsoft Połączenie ivity Analyzer, jak opisano poniżej.
Metadane firmy Microsoft Entra można pobrać z tego adresu URL: https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml. W przypadku klientów w Chinach korzystających z wystąpienia platformy Microsoft 365 specyficznego dla Chin należy użyć następującego punktu końcowego federacji: https://nexus.partner.microsoftonline-p.cn/federationmetadata/saml20/federationmetadata.xml.
Wymagania dotyczące protokołu SAML
W tej sekcji opisano sposób łączenia par komunikatów żądania i odpowiedzi w celu ułatwienia poprawnego formatowania komunikatów.
Identyfikator Entra firmy Microsoft można skonfigurować do pracy z dostawcami tożsamości korzystającymi z profilu SAML 2.0 SP Lite z określonymi wymaganiami, jak pokazano poniżej. Korzystając z przykładowych komunikatów żądania SAML i odpowiedzi wraz z automatycznym i ręcznym testowaniem, możesz pracować nad współdziałaniem z identyfikatorem Entra firmy Microsoft.
Wymagania dotyczące bloku podpisów
W komunikacie odpowiedzi SAML węzeł Podpis zawiera informacje o podpisie cyfrowym dla samego komunikatu. Blok podpisu ma następujące wymagania:
- Sam węzeł asercji musi być podpisany
- Algorytm RSA-sha1 musi być używany jako skrótMethod. Inne algorytmy podpisu cyfrowego nie są akceptowane.
<ds:DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1"/> - Możesz również podpisać dokument XML.
- Algorytm przekształcania musi być zgodny z wartościami w następującym przykładzie:
<ds:Transform Algorithm="https://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#"/> - Algorytm SignatureMethod musi być zgodny z następującym przykładem:
<ds:SignatureMethod Algorithm="https://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
Uwaga
W celu poprawy bezpieczeństwa algorytm SHA-1 jest przestarzały. Upewnij się, że używasz bezpieczniejszego algorytmu, takiego jak SHA-256. Więcej informacji można znaleźć.
Obsługiwane powiązania
Powiązania to wymagane parametry komunikacji związane z transportem. Następujące wymagania dotyczą powiązań
- Protokół HTTPS jest wymaganym transportem.
- Identyfikator Entra firmy Microsoft wymaga żądania HTTP POST na potrzeby przesyłania tokenu podczas logowania.
- Identyfikator Entra firmy Microsoft używa protokołu HTTP POST dla żądania uwierzytelniania do dostawcy tożsamości i przekierowania komunikatu wylogowywanie do dostawcy tożsamości.
Wymagane atrybuty
W tej tabeli przedstawiono wymagania dotyczące określonych atrybutów w komunikacie SAML 2.0.
| Atrybut | opis |
|---|---|
| Identyfikator nazwy | Wartość tej asercji musi być taka sama jak identyfikator ImmutableID użytkownika firmy Microsoft Entra. Może to być maksymalnie 64 znaki alfanumeryczne. Wszystkie znaki bezpieczne nie html muszą być zakodowane, na przykład znak "+" jest wyświetlany jako ".2B". |
| IDPEmail | Główna nazwa użytkownika (UPN) jest wyświetlana w odpowiedzi SAML jako element o nazwie IDPEmail UserPrincipalName (UPN) użytkownika w microsoft Entra ID / Microsoft 365. Nazwa UPN jest w formacie adresu e-mail. Wartość nazwy UPN w usłudze Microsoft 365 (Microsoft Entra ID). |
| Wystawca | Wymagane jest, aby być identyfikatorem URI dostawcy tożsamości. Nie używaj ponownie wystawcy z przykładowych komunikatów. Jeśli masz wiele domen najwyższego poziomu w dzierżawach firmy Microsoft Entra, wystawca musi być zgodny z określonym ustawieniem identyfikatora URI skonfigurowanym dla każdej domeny. |
Ważne
Identyfikator Entra firmy Microsoft obsługuje obecnie następujący identyfikator URI formatu NameID dla protokołu SAML 2.0:urn:oasis:names:tc:SAML:2.0:nameid-format:persistent.
Przykładowe komunikaty żądania SAML i odpowiedzi
Dla wymiany komunikatów logowania jest wyświetlana para komunikatów żądania i odpowiedzi. Poniżej znajduje się przykładowy komunikat żądania, który jest wysyłany z identyfikatora Entra firmy Microsoft do przykładowego dostawcy tożsamości SAML 2.0. Przykładowym dostawcą tożsamości SAML 2.0 jest usługa Active Directory Federation Services (AD FS) skonfigurowana do korzystania z protokołu SAML-P. Testowanie współdziałania zostało również ukończone z innymi dostawcami tożsamości SAML 2.0.
<samlp:AuthnRequest ID="_1e089e5c-a976-4881-af74-3b92c89e7e2c" Version="2.0" IssueInstant="2024-03-12T14:00:18.450Z" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:MicrosoftOnline</Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/></samlp:AuthnRequest>
Jeśli parametr isSignedAuthenticationRequestRequired jest włączony zgodnie z wyjaśnieniem w artykule internaldomainfederation-update, żądanie będzie wyglądać następująco:
<samlp:AuthnRequest ID="_1868c6f2-1fdd-40b9-818f-b4b44efb92c5" Version="2.0" IssueInstant="2024-03-11T16:51:17.120Z" Destination="https://fs.contoso.com/adfs/ls/" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:MicrosoftOnline</Issuer><Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><Reference URI="#_1868c6f2-1fdd-40b9-818f-b4b44efb92c5"><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>aB1cD2eF3gH4iJ5kL6-mN7oP8qR=</DigestValue></Reference></SignedInfo><SignatureValue>cD2eF3gH4iJ5k...L6mN7-oP8qR9sT==</SignatureValue><KeyInfo><ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509SKI>eF3gH4iJ5kL6mN7oP8-qR9sT0uV=</ds:X509SKI></ds:X509Data><ds:KeyName xmlns:ds="http://www.w3.org/2000/09/xmldsig#">MicrosoftOnline</ds:KeyName></KeyInfo></Signature><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/></samlp:AuthnRequest>
Poniżej znajduje się przykładowy komunikat odpowiedzi wysyłany z przykładowego dostawcy tożsamości zgodnego z protokołem SAML 2.0 do usługi Microsoft Entra ID/Microsoft 365.
<samlp:Response ID="_592c022f-e85e-4d23-b55b-9141c95cd2a5" Version="2.0" IssueInstant="2014-01-31T15:36:31.357Z" Destination="https://login.microsoftonline.com/login.srf" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="_049917a6-1183-42fd-a190-1d2cbaf9b144" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://WS2012R2-0.contoso.com/adfs/services/trust</Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</samlp:Status>
<Assertion ID="_7e3c1bcd-f180-4f78-83e1-7680920793aa" IssueInstant="2014-01-31T15:36:31.279Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Issuer>http://WS2012R2-0.contoso.com/adfs/services/trust</Issuer>
<ds:Signature xmlns:ds="https://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="https://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<ds:Reference URI="#_7e3c1bcd-f180-4f78-83e1-7680920793aa">
<ds:Transforms>
<ds:Transform Algorithm="https://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
<ds:DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>CBn/aB1cD2eF3gH4iJ5kL6-mN7oP8qR=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>cD2eF3gH4iJ5kL6mN7-oP8qR9sT==</ds:SignatureValue>
<KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>eF3gH4iJ5kL6mN7oP8-qR9sT0uV=</ds:X509Certificate>
</ds:X509Data>
</KeyInfo>
</ds:Signature>
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">ABCDEG1234567890</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData InResponseTo="_049917a6-1183-42fd-a190-1d2cbaf9b144" NotOnOrAfter="2014-01-31T15:41:31.357Z" Recipient="https://login.microsoftonline.com/login.srf" />
</SubjectConfirmation>
</Subject>
<Conditions NotBefore="2014-01-31T15:36:31.263Z" NotOnOrAfter="2014-01-31T16:36:31.263Z">
<AudienceRestriction>
<Audience>urn:federation:MicrosoftOnline</Audience>
</AudienceRestriction>
</Conditions>
<AttributeStatement>
<Attribute Name="IDPEmail">
<AttributeValue>administrator@contoso.com</AttributeValue>
</Attribute>
</AttributeStatement>
<AuthnStatement AuthnInstant="2014-01-31T15:36:30.200Z" SessionIndex="_7e3c1bcd-f180-4f78-83e1-7680920793aa">
<AuthnContext>
<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</samlp:Response>
Konfigurowanie dostawcy tożsamości zgodnego ze standardem SAML 2.0
Ta sekcja zawiera wskazówki dotyczące konfigurowania dostawcy tożsamości SAML 2.0 w celu federacji z identyfikatorem Microsoft Entra ID w celu włączenia dostępu do logowania jednokrotnego do co najmniej jednej usługi w chmurze firmy Microsoft (takiej jak Microsoft 365) przy użyciu protokołu SAML 2.0. Jednostka uzależniona SAML 2.0 dla usługi w chmurze firmy Microsoft używanej w tym scenariuszu to Microsoft Entra ID.
Dodawanie metadanych entra firmy Microsoft
Dostawca tożsamości SAML 2.0 musi przestrzegać informacji o jednostki uzależnionej Identyfikator entra firmy Microsoft. Identyfikator Entra firmy Microsoft publikuje metadane pod adresem https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml.
Zaleca się, aby podczas konfigurowania dostawcy tożsamości SAML 2.0 zawsze importować najnowsze metadane firmy Microsoft Entra.
Uwaga
Identyfikator entra firmy Microsoft nie odczytuje metadanych od dostawcy tożsamości.
Dodawanie identyfikatora Entra firmy Microsoft jako jednostki uzależnionej
Należy włączyć komunikację między dostawcą tożsamości SAML 2.0 i identyfikatorem Entra firmy Microsoft. Ta konfiguracja jest zależna od określonego dostawcy tożsamości i należy zapoznać się z dokumentacją. Zazwyczaj należy ustawić identyfikator jednostki uzależnionej na taki sam jak entityID z metadanych firmy Microsoft Entra.
Uwaga
Sprawdź, czy zegar na serwerze dostawcy tożsamości SAML 2.0 jest zsynchronizowany z dokładnym źródłem czasu. Niedokładny czas zegara może spowodować niepowodzenie logowania federacyjnego.
Instalowanie programu PowerShell na potrzeby logowania przy użyciu dostawcy tożsamości SAML 2.0
Po skonfigurowaniu dostawcy tożsamości SAML 2.0 do użycia z logowaniem microsoft Entra następnym krokiem jest pobranie i zainstalowanie modułu Microsoft Graph PowerShell . Po zainstalowaniu te polecenia cmdlet będą używane do konfigurowania domen Entra firmy Microsoft jako domen federacyjnych.
Moduł Programu PowerShell programu Microsoft Graph to pobieranie do zarządzania danymi organizacji w usłudze Microsoft Entra ID. Ten moduł instaluje zestaw poleceń cmdlet programu PowerShell; Uruchamiasz te polecenia cmdlet, aby skonfigurować dostęp do logowania jednokrotnego do usługi Microsoft Entra ID i z kolei do wszystkich usług w chmurze, do których subskrybujesz. Aby uzyskać instrukcje dotyczące pobierania i instalowania poleceń cmdlet, zobacz Instalowanie zestawu MICROSOFT Graph PowerShell SDK.
Konfigurowanie zaufania między dostawcą tożsamości SAML i identyfikatorem Entra firmy Microsoft
Przed skonfigurowaniem federacji w domenie Microsoft Entra musi mieć skonfigurowaną domenę niestandardową. Nie można sfederować domeny domyślnej udostępnianej przez firmę Microsoft. Domyślna domena firmy Microsoft kończy się ciągiem onmicrosoft.com.
Uruchomisz serię poleceń cmdlet programu PowerShell, aby dodawać lub konwertować domeny na potrzeby logowania jednokrotnego.
Każda domena firmy Microsoft Entra, która ma zostać sfederowana przy użyciu dostawcy tożsamości SAML 2.0, musi zostać dodana jako domena logowania jednokrotnego lub przekonwertowana na domenę logowania jednokrotnego z domeny standardowej. Dodawanie lub konwertowanie domeny powoduje skonfigurowanie zaufania między dostawcą tożsamości SAML 2.0 i identyfikatorem Entra firmy Microsoft.
Poniższa procedura przeprowadzi Cię przez przekonwertowanie istniejącej domeny standardowej na domenę federacyjną przy użyciu protokołu SAML 2.0 SP-Lite.
Uwaga
Twoja domena może wystąpić awaria, która ma wpływ na użytkowników do 2 godzin po wykonaniu tego kroku.
Konfigurowanie domeny w usłudze Microsoft Entra Directory na potrzeby federacji
Połączenie do usługi Microsoft Entra Directory jako administrator dzierżawy:
Connect-MgGraph -Scopes "Domain.ReadWrite.All"Skonfiguruj żądaną domenę platformy Microsoft 365 do używania federacji z programem SAML 2.0:
$Domain = "contoso.com" $LogOnUrl = "https://WS2012R2-0.contoso.com/passiveLogon" $LogOffUrl = "https://WS2012R2-0.contoso.com/passiveLogOff" $ecpUrl = "https://WS2012R2-0.contoso.com/PAOS" $MyUri = "urn:uri:MySamlp2IDP" $idptokensigningcert = [System.Security.Cryptography.X509Certificates.X509Certificate2]("C:\temp\contosoidptokensign.cer") $MySigningCert = [system.convert]::tobase64string($idptokensigningcert.rawdata) $Protocol = "saml" New-MgDomainFederationConfiguration ` -DomainId $Domain ` -ActiveSignInUri $ecpUrl ` -IssuerUri $MyUri ` -PassiveSignInUri $LogOnUrl ` -PreferredAuthenticationProtocol $Protocol ` -SignOutUri $LogOffUrl ` -SigningCertificate $MySigningCertMożesz uzyskać ciąg zakodowany certyfikatu podpisywania base64 z pliku metadanych dostawcy tożsamości. Poniżej przedstawiono przykład tej lokalizacji, ale może się nieco różnić w zależności od implementacji.
<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <KeyDescriptor use="signing"> <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#"> <X509Data> <X509Certificate> eF3gH4iJ5kL6mN7oP8-qR9sT0uV=</X509Certificate> </X509Data> </KeyInfo> </KeyDescriptor> </IDPSSODescriptor>
Aby uzyskać więcej informacji, zobacz New-MgDomainFederationConfiguration.
Uwaga
Należy użyć $ecpUrl = "https://WS2012R2-0.contoso.com/PAOS" tylko w przypadku skonfigurowania rozszerzenia ecp dla dostawcy tożsamości. Klienci usługi Exchange Online, z wyłączeniem aplikacji Outlook Web Application (OWA), korzystają z aktywnego punktu końcowego post. Jeśli usługa SAML 2.0 STS implementuje aktywny punkt końcowy podobny do implementacji ECP usługi Shibboleth aktywnego punktu końcowego, może być możliwe, aby ci zaawansowani klienci mogli wchodzić w interakcje z usługą Exchange Online.
Po skonfigurowaniu federacji można przełączyć się z powrotem na "niefederacyjną" (lub "zarządzaną"), jednak ukończenie tej zmiany trwa do dwóch godzin i wymaga przypisania nowych losowych haseł do logowania opartego na chmurze do każdego użytkownika. Przełączenie z powrotem na "zarządzane" może być wymagane w niektórych scenariuszach w celu zresetowania błędu w ustawieniach. Aby uzyskać więcej informacji na temat konwersji domeny, zobacz Remove-MgDomainFederationConfiguration.
Aprowizuj podmioty zabezpieczeń użytkowników w usłudze Microsoft Entra ID/ Microsoft 365
Zanim będzie można uwierzytelnić użytkowników na platformie Microsoft 365, musisz aprowizować identyfikator Entra firmy Microsoft przy użyciu podmiotów zabezpieczeń użytkowników odpowiadających asercji w oświadczeniu SAML 2.0. Jeśli te podmioty zabezpieczeń użytkowników nie są znane z wcześniejszego identyfikatora Microsoft Entra ID, nie można ich używać do logowania federacyjnego. Do aprowizowania podmiotów zabezpieczeń użytkowników można użyć programu Microsoft Entra Połączenie lub programu PowerShell.
Microsoft Entra Połączenie może służyć do aprowizowania podmiotów zabezpieczeń domen w katalogu Microsoft Entra Directory z lokalna usługa Active Directory. Aby uzyskać bardziej szczegółowe informacje, zobacz Integrowanie katalogów lokalnych z identyfikatorem Entra firmy Microsoft.
Program PowerShell może również służyć do automatyzowania dodawania nowych użytkowników do identyfikatora Entra firmy Microsoft i synchronizowania zmian z katalogu lokalnego. Aby użyć poleceń cmdlet programu PowerShell, należy pobrać moduł Programu PowerShell programu Microsoft Graph.
W tej procedurze pokazano, jak dodać pojedynczego użytkownika do identyfikatora Entra firmy Microsoft.
Połączenie do katalogu Microsoft Entra Directory jako administrator dzierżawy przy użyciu Połączenie-MgGraph.
Utwórz nową jednostkę użytkownika:
$Password = -join ((48..57) + (97..122) | Get-Random -Count 12 | % {[char]$_}) $PasswordProfile = @{ Password = "$Password" } New-MgUser ` -UserPrincipalName "elwoodf1@contoso.com" ` -DisplayName "Elwood Folk" ` -GivenName "Elwood" ` -Surname "Folk" ` -AccountEnabled ` -MailNickName 'ElwoodFolk' ` -OnPremisesImmutableId ABCDEFG1234567890 ` -OtherMails "Elwood.Folk@contoso.com" ` -PasswordProfile $PasswordProfile ` -UsageLocation "US"
Aby uzyskać więcej informacji, zobacz New-MgUser.
Uwaga
Wartość "UserPrincipalName" musi być zgodna z wartością, która zostanie wysłana dla "IDPEmail" w oświadczeniu SAML 2.0, a wartość "OnPremisesImmutableId" musi być zgodna z wartością wysłaną w asercji "NameID".
Weryfikowanie logowania jednokrotnego przy użyciu protokołu SAML 2.0 IDP
Jako administrator przed zweryfikowaniem logowania jednokrotnego (nazywanego również federacją tożsamości) przejrzyj informacje i wykonaj kroki opisane w poniższych artykułach, aby skonfigurować logowanie jednokrotne przy użyciu dostawcy tożsamości opartego na protokole SAML 2.0 SP-Lite:
- Zapoznano się z wymaganiami protokołu Microsoft Entra SAML 2.0
- Skonfigurowano dostawcę tożsamości SAML 2.0
- Instalowanie programu PowerShell na potrzeby logowania jednokrotnego przy użyciu dostawcy tożsamości SAML 2.0
- Konfigurowanie zaufania między dostawcą tożsamości SAML 2.0 i identyfikatorem Entra firmy Microsoft
- Zainicjowano obsługę administracyjną znanego podmiotu zabezpieczeń użytkownika testowego w usłudze Microsoft Entra ID (Microsoft 365) za pomocą programu PowerShell lub microsoft Entra Połączenie.
- Konfigurowanie synchronizacji katalogów przy użyciu Połączenie firmy Microsoft.
Po skonfigurowaniu logowania jednokrotnego przy użyciu dostawcy tożsamości opartego na protokole SAML 2.0 SP-Lite należy sprawdzić, czy działa prawidłowo. Aby uzyskać więcej informacji na temat testowania logowania jednokrotnego opartego na protokole SAML, zobacz Testowanie logowania jednokrotnego opartego na protokole SAML.
Uwaga
W przypadku przekonwertowania domeny zamiast dodawania domeny może upłynąć do 24 godzin, aby skonfigurować logowanie jednokrotne. Przed zweryfikowaniem logowania jednokrotnego należy zakończyć konfigurowanie synchronizacji usługi Active Directory, synchronizowanie katalogów i aktywowanie zsynchronizowanych użytkowników.
Ręcznie sprawdź, czy logowanie jednokrotne zostało poprawnie skonfigurowane
Weryfikacja ręczna zawiera więcej kroków, które można wykonać, aby upewnić się, że dostawca tożsamości SAML 2.0 działa prawidłowo w wielu scenariuszach. Aby sprawdzić, czy logowanie jednokrotne jest poprawnie skonfigurowane, wykonaj następujące kroki:
- Na komputerze przyłączonym do domeny zaloguj się do usługi w chmurze przy użyciu tej samej nazwy logowania, która jest używana dla poświadczeń firmowych.
- Wybierz wewnątrz pola hasła. Jeśli logowanie jednokrotne jest skonfigurowane, pole hasła jest zacienione i zobaczysz następujący komunikat: "Teraz musisz zalogować się w <firmie>".
- Wybierz link Zaloguj się w <firmie> . Jeśli możesz się zalogować, zostanie skonfigurowane logowanie jednokrotne.