Поделиться через

Использование поставщика удостоверений (IdP) SAML 2.0 для единого входа

  • Статья

В этом документе содержатся сведения об использовании поставщика удостоверений на основе профилей SP-Lite, совместимого с SAML 2.0, в качестве предпочитаемой службы токенов безопасности (STS) или поставщика удостоверений. Это удобно при наличии локального каталога пользователей и хранилища паролей, доступ к которым возможен с помощью SAML 2.0. Этот существующий каталог пользователя можно использовать для входа в Microsoft 365 и других ресурсов, защищенных идентификатором Майкрософт. Профиль SAML 2.0 SP-Lite основан на широко использующемся стандарте федеративных удостоверений SAML (Security Assertion Markup Language) для предоставления единого входа и структуры обмена атрибутами.

Примечание.

Для списка сторонних поставщиков удостоверений, протестированных для использования с Microsoft Entra ID, смотрите в списке совместимости федерации Microsoft Entra

Корпорация Майкрософт поддерживает процесс входа, интегрируя облачную службу Microsoft, такую как Microsoft 365, с правильно настроенным поставщиком удостоверений (IdP) на основе профиля SAML 2.0. Поставщики удостоверений SAML 2.0 являются сторонними продуктами, поэтому Корпорация Майкрософт не предоставляет поддержку развертывания, настройки, устранения неполадок, связанных с ними. После настройки интеграции с поставщиком удостоверений SAML 2.0 ее правильность можно протестировать с помощью анализатора подключений Майкрософт, который подробно описывается ниже. Для получения дополнительных сведений о своем поставщике удостоверений на основе профилей SAML 2.0 SP-Lite обратитесь в предоставившую его организацию.

Внимание

В этом сценарии единого входа с помощью поставщиков удостоверений SAML 2.0 доступен только ограниченный набор клиентов, в число которых входят приведенные далее.

  • Веб-клиенты, такие как Outlook Web Access и SharePoint Online
  • Клиенты с широкими возможностями электронной почты, использующие обычную проверку подлинности и поддерживаемый метод доступа Exchange, например IMAP, POP, Active Sync, MAPI и т. д. Для развертывания необходимо иметь конечную точку расширенного клиентского протокола, в том числе:
    • Microsoft Outlook 2010/Outlook 2013/Outlook 2016, Apple iPhone (различные версии iOS);
    • различные устройства Google Android;
    • Windows Phone 7, Windows Phone 7.8 и Windows Phone 8.0;
    • почтовый клиент Windows 8 и Windows 8.1;
    • почтовый клиент Windows 10.

Все остальные клиенты недоступны в этом сценарии входа с поставщиком удостоверений SAML 2.0. Например, классический клиент Lync 2010 не может войти в службу с помощью поставщика удостоверений SAML 2.0, настроенного для единого входа.

Требования к протоколу Microsoft Entra SAML 2.0

Этот документ содержит подробные требования к протоколу и форматированию сообщений, которые поставщик удостоверений SAML 2.0 должен реализовать для федеративной интеграции с идентификатором Microsoft Entra, чтобы включить вход в одну или несколько облачных служб Майкрософт (например, Microsoft 365). Зависимая сторона SAML 2.0 (SP-STS) для облачной службы Microsoft, используемой в этом сценарии, — это Microsoft Entra ID.

Рекомендуется убедиться, что выходные сообщения поставщика удостоверений SAML 2.0 максимально соответствуют предоставленным образцам трассировок. Кроме того, используйте определенные значения атрибутов из предоставленных метаданных Microsoft Entra, где это возможно. После того как вы будете довольны выходными сообщениями, вы можете протестировать с помощью анализатора подключения Майкрософт, как описано ниже.

Метаданные Microsoft Entra можно скачать из этого URL-адреса: https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml Клиентам в Китае, которые используют созданную для Китая версию Microsoft 365, следует использовать следующую конечную точку федерации: https://nexus.partner.microsoftonline-p.cn/federationmetadata/saml20/federationmetadata.xml.

Требования к протоколу SAML

В этом разделе подробно описывается, как составляются пары, состоящие из запроса и ответного сообщения. Это поможет вам правильно форматировать свои сообщения.

Идентификатор Microsoft Entra можно настроить для работы с поставщиками удостоверений, которые используют профиль SAML 2.0 SP Lite с определенными требованиями, как описано ниже. Используя примеры сообщений запроса SAML и ответов вместе с автоматизированным и ручным тестированием, вы можете обеспечить взаимодействие с идентификатором Microsoft Entra.

Требования к блоку подписи

В ответном сообщении SAML узел Signature содержит сведения о цифровой подписи самого сообщения. К блоку подписи предъявляются указанные ниже требования.

  1. Узел утверждения должен быть подписан.
  2. В качестве метода DigestMethod необходимо использовать алгоритм RSA-sha1. Другие алгоритмы цифровой подписи не принимаются. <ds:DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1"/>
  3. Вы также можете подписать XML-документ.
  4. Значения алгоритма Transform Algorithm должны соответствовать приведенным в следующем примере: <ds:Transform Algorithm="https://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#"/>
  5. Алгоритм SignatureMethod должен соответствовать приведенному в следующем примере: <ds:SignatureMethod Algorithm="https://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

Примечание.

Для повышения уровня безопасности алгоритм SHA-1 считается устаревшим. Убедитесь, что используется более безопасный алгоритм, например SHA-256. Дополнительные сведения можно найти.

Поддерживаемые привязки

Привязки — это обязательные параметры взаимодействия, связанные с транспортом. В отношении привязок действуют указанные ниже требования.

  1. HTTPS — это обязательный протокол передачи данных.
  2. Идентификатор Microsoft Entra требует HTTP POST для отправки токена во время входа.
  3. Идентификатор Microsoft Entra использует HTTP POST для запроса проверки подлинности у поставщика удостоверений и редирект для передачи сообщения о выходе поставщику удостоверений.

Требуемые атрибуты

В таблице ниже приведены требования к определенным атрибутам в сообщении SAML 2.0.

Атрибут Описание
ИдентификаторИмени Значение этого утверждения должно совпадать с неизменяемым идентификатором пользователя Microsoft Entra. Это должно быть буквенно-цифровое значение длиной до 64 символов. Все небезопасные знаки HTML должны кодироваться, например, знак "+" должен быть представлен как ".2B".
IDPEmail Имя основного пользователя (UPN) отображается в ответе SAML в качестве элемента с именем IDPEmail. Имя основного пользователя (UserPrincipalName, UPN) пользователя в Microsoft Entra ID / Microsoft 365. UPN указывается в формате адреса электронной почты. Значение UPN в Windows Microsoft 365 (идентификатор Microsoft Entra).
Издатель Требуется, чтобы это был URI (универсальный код ресурса) поставщика удостоверений. Не используйте эмитента из примеров сообщений. Если у вас несколько доменов верхнего уровня в клиентах Microsoft Entra, издатель должен соответствовать указанному параметру URI, настроенному для каждого из них.

Внимание

Microsoft Entra ID в настоящее время поддерживает следующий URI формата NameID для SAML 2.0: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent.

Примеры сообщений SAML с запросом и ответом

Ниже приведена пара сообщений, состоящая из запроса и ответа и используемая при обмене сообщениями единого входа. Ниже приведен пример сообщения запроса, отправляемого от Microsoft Entra ID к примеру поставщика удостоверений SAML 2.0. Примером поставщика удостоверений SAML 2.0 является службы федерации Active Directory (AD FS), настроенные на использование протокола SAML-P. Тестирование взаимодействия также завершено с другими поставщиками удостоверений 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>

Если параметр isSignedAuthenticationRequestRequired включен, как объяснено в разделе internaldomainfederation-update, тогда запрос будет выглядеть следующим образом:

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

Ниже приведен пример сообщения-ответа, отправляемого от образцового поставщика удостоверений, совместимого с SAML 2.0, в 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>

Настройка поставщика удостоверений, совместимого с SAML 2.0

В этом разделе содержатся рекомендации по настройке поставщика удостоверений SAML 2.0 для федерации с Microsoft Entra ID, чтобы включить единый вход к одной или нескольким облачным службам Майкрософт (например, Microsoft 365) с помощью протокола SAML 2.0. Стороной, зависящей от SAML 2.0 в облачной службе Microsoft, используемой в этом сценарии, является Microsoft Entra ID.

Добавьте метаданные Microsoft Entra

Ваш поставщик удостоверений SAML 2.0 должен соответствовать требованиям информации о доверяющей стороне Microsoft Entra ID. Идентификатор Microsoft Entra публикует метаданные по адресу https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml.

Рекомендуется всегда импортировать последние метаданные Microsoft Entra при настройке поставщика удостоверений SAML 2.0.

Примечание.

Идентификатор Microsoft Entra не считывает метаданные от поставщика удостоверений.

Добавить идентификатор Microsoft Entra в качестве доверенной стороны

Необходимо включить связь между поставщиком удостоверений SAML 2.0 и идентификатором Microsoft Entra. Эта конфигурация зависит от конкретного поставщика удостоверений, и для нее следует обратиться к документации. Обычно идентификатор доверяющей стороны должен совпадать с entityID из метаданных Microsoft Entra.

Примечание.

Убедитесь, что часы на сервере поставщика удостоверений SAML 2.0 синхронизированы с источником точного времени. Неточное время может приводить к сбоям при федеративной аутентификации.

Установите PowerShell для входа с использованием удостоверяющего поставщика SAML 2.0

После настройки поставщика удостоверений SAML 2.0 для использования с входом Microsoft Entra необходимо скачать и установить модуль Microsoft Graph PowerShell . После установки эти командлеты будут использоваться для настройки доменов Microsoft Entra в качестве федеративных доменов.

Модуль Microsoft Graph PowerShell — это скачивание для управления данными организации в идентификаторе Microsoft Entra. Этот модуль устанавливает набор командлетов в PowerShell; вы выполняете эти командлеты для настройки единого входа в Microsoft Entra ID, а также ко всем облачным сервисам, на которые у вас есть подписка. Инструкции по загрузке и установке командлетов см. в разделе Установка Microsoft Graph PowerShell SDK.

Настройка доверия между поставщиком удостоверений SAML и идентификатором Microsoft Entra

Прежде чем настраивать федерацию в домене Microsoft Entra, у него должен быть настроен собственный домен. Не удается установить федерацию для домена по умолчанию, предоставляемого корпорацией Майкрософт. Домен по умолчанию от Корпорации Майкрософт заканчивается onmicrosoft.com. Вы запустите ряд командлетов PowerShell для добавления или преобразования доменов для единого входа.

Каждый домен Microsoft Entra, который требуется федеративно использовать с помощью поставщика удостоверений SAML 2.0, должен быть добавлен в качестве домена единого входа или преобразован в качестве домена единого входа из стандартного домена. Добавление или преобразование домена настраивает доверие между поставщиком удостоверений SAML 2.0 и идентификатором Microsoft Entra.

В следующей процедуре содержатся указания по преобразованию существующего стандартного домена в федеративный домен с помощью SAML 2.0 SP-Lite.

Примечание.

После выполнения этого действия домен может стать недоступен для пользователей на срок до 2 часов.

Настройка домена в каталоге Microsoft Entra для федерации

  1. Подключитесь к каталогу Microsoft Entra от имени администратора клиента:

    Connect-MgGraph -Scopes "Domain.ReadWrite.All"

  2. Настройте требуемый домен Microsoft 365 для использования федерации с 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 $MySigningCert

  3. Получить строку сертификата подписи в кодировке base64 можно из файла метаданных IDP. Пример этого расположения приведен ниже, но может немного отличаться в зависимости от реализации.

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

Дополнительные сведения см. в статье New-MgDomainFederationConfiguration.

Примечание.

Использовать атрибут $ecpUrl = "https://WS2012R2-0.contoso.com/PAOS" можно только в том случае, если вы настроили расширение ECP для вашего поставщика удостоверений. Клиенты Exchange Online, исключая Outlook Web Application (OWA), используют активную конечную точку на основе метода POST. Если служба токенов безопасности SAML 2.0 реализует активную конечную точку, аналогичную активной конечной точке в реализации ECP для Shibboleth, то клиенты с расширенным интерфейсом могут взаимодействовать со службой Exchange Online.

После настройки федерации можно вернуться на "не федеративный" (или "управляемый"), однако это изменение занимает до двух часов, и требуется назначить новые случайные пароли для входа в облако каждому пользователю. Переключение обратно в режим "управляемый" может потребоваться в некоторых сценариях для сброса ошибки в ваших настройках. Дополнительные сведения о преобразовании домена см. в разделе Remove-MgDomainFederationConfiguration.

Подготовка субъектов-пользователей к идентификатору Microsoft Entra ID / Microsoft 365

Прежде чем аутентифицировать ваших пользователей в Microsoft 365, необходимо настроить идентификатор Microsoft Entra с учетными записями пользователей, соответствующими утверждению в SAML 2.0. Если эти субъекты-пользователи заранее не известны идентификатору Microsoft Entra, они не могут использоваться для федеративного входа. Для подготовки субъектов-пользователей можно использовать Microsoft Entra Connect или PowerShell.

Microsoft Entra Connect можно использовать для передачи субъектов к вашим доменам в каталоге Microsoft Entra из локальной службы Active Directory. Дополнительные сведения см. в разделе "Интеграция локальных каталогов с идентификатором Microsoft Entra".

PowerShell также можно использовать для автоматизации добавления новых пользователей в идентификатор Microsoft Entra ID и синхронизации изменений из локального каталога. Чтобы использовать командлеты PowerShell, необходимо скачать модуль Microsoft Graph PowerShell .

В этой процедуре показано, как добавить одного пользователя в идентификатор Microsoft Entra.

  1. Подключитесь к каталогу Microsoft Entra в качестве администратора клиента с помощью Connect-MgGraph.

  2. Создайте новую учетную запись пользователя.

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

Дополнительные сведения см. в статье New-MgUser.

Примечание.

Значение UserPrincipalName должно соответствовать значению, которое будет отправлено для idPEmail в утверждении SAML 2.0, а значение OnPremisesImmutableId должно совпадать со значением, отправленным в утверждении NameID.

Проверьте единую аутентификацию с помощью поставщика удостоверений SAML 2.0

Перед проверкой единого входа (также называемого федерацией удостоверений) и управлением им администратору следует ознакомиться с информацией и выполнить инструкции в указанных ниже статьях, чтобы настроить единый вход с помощью поставщика удостоверений на основе SAML 2.0 SP-Lite:

  1. Вы ознакомились с требованиями к протоколу Microsoft Entra SAML 2.0
  2. Вы настроили поставщика удостоверений SAML 2.0.
  3. Установка PowerShell для единой аутентификации с помощью поставщика удостоверений SAML 2.0
  4. Настройка доверия между поставщиком удостоверений SAML 2.0 и идентификатором Microsoft Entra
  5. Создан тестовый пользователь для Microsoft Entra ID (Microsoft 365) с помощью PowerShell или Microsoft Entra Connect.
  6. Настройте синхронизацию каталогов с помощью Microsoft Entra Connect.

После настройки единого входа с вашим поставщиком удостоверений на основе SAML 2.0 SP-Lite, убедитесь, что он работает правильно. Дополнительные сведения о тестировании единого входа на основе SAML см. в разделе Тестирование единого входа на основе SAML.

Примечание.

Если вы преобразовали домен вместо добавления нового, для настройки единого входа может потребоваться до 24 часов. Перед проверкой единого входа следует завершить настройку синхронизации Active Directory, синхронизировать каталоги и активировать синхронизированных пользователей.

Вручную убедитесь, что единый вход настроен правильно.

Проверка вручную предоставляет дополнительные действия, которые можно предпринять, чтобы убедиться, что поставщик удостоверений SAML 2.0 работает правильно во многих сценариях. Чтобы убедиться, что единый вход настроен правильно, выполните следующие действия.

  1. На присоединенном к домену компьютере войдите в облачную службу, используя то же имя для входа, что и в ваших корпоративных учетных данных.
  2. Выберите внутри поля пароля. Если единый вход настроен, поле пароля затеняется, и вы увидите следующее сообщение: "Теперь вам потребуется войти в <вашу компанию>".
  3. Выберите вход по <ссылке компании> . Если вы можете войти в систему, значит настройка единого входа выполнена.

Следующие шаги