Бөлісу құралы:

Использование поставщика удостоверений (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 365, с правильно настроенным поставщиком удостоверений на основе профилей 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 Entra.

Рекомендуется убедиться, что выходные сообщения поставщика удостоверений 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 Algorithm должен соответствовать приведенному в следующем примере: <ds:SignatureMethod Algorithm="https://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

Примечание.

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

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

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

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

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

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

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

Внимание

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

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

Ниже приведена пара сообщений, состоящая из запроса и ответа и используемая при обмене сообщениями единого входа. Ниже приведен пример сообщения запроса, отправляемого идентификатором Microsoft Entra в пример поставщика удостоверений 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 включен, как описано во внутреннем обновленииdomainfederation-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, чтобы включить единый вход к одной или нескольким облачным службам Майкрософт (например, Microsoft 365) с помощью протокола SAML 2.0. Проверяющая сторона SAML 2.0 для облачной службы Майкрософт, используемая в этом сценарии, — это идентификатор Microsoft Entra.

Добавление метаданных Microsoft Entra

Поставщик удостоверений SAML 2.0 должен соответствовать сведениям о проверяющей стороне Идентификатора Microsoft Entra. Идентификатор 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 и в свою очередь всем облачным службам, на которые вы подписаны. Инструкции по загрузке и установке командлетов см. в разделе "Установка пакета SDK Для Microsoft Graph PowerShell".

Настройка доверия между поставщиком удостоверений 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 Подключение или PowerShell.

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

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

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

  1. Подключение в каталог Microsoft Entra в качестве администратора клиента с помощью Подключение-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 (Microsoft 365) с помощью PowerShell или Microsoft Entra Подключение.
  6. Настройка синхронизации каталогов с помощью Microsoft Entra Подключение.

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

Примечание.

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

Проверка правильной настройки единого входа с помощью средства

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

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

Next Steps