Compartilhar via

Usar um IdP (provedor de identidade) SAML 2.0 para logon único

  • Artigo

Este documento contém informações sobre como usar um provedor de identidade baseado em um perfil de SP-Lite em conformidade com SAML 2.0 como o provedor de identidade/STS (serviço de token de segurança) preferencial. Esse cenário é útil quando você já tem um diretório de usuários e um repositório de senhas locais que podem ser acessados usando SAML 2.0. Esse diretório de usuário existente pode ser usado para logon no Microsoft 365 e em outros recursos protegidos pelo Microsoft Entra ID. O perfil de SP-Lite compatível com SAML 2.0 baseia-se no padrão de identidade federada amplamente utilizado SAML (Security Assertion Markup Language) para fornecer uma estrutura de logon e troca de atributos.

Observação

Para obter uma lista de IDPS de terceiros que foram testados para uso com o Microsoft Entra ID, consulte a lista de compatibilidade de federação do Microsoft Entra

A Microsoft dá suporte a essa experiência de logon como a integração de um serviço de nuvem da Microsoft, como o Microsoft 365, com seu IdP baseado em um perfil SAML 2.0 configurado corretamente. Provedores de identidade SAML 2.0 são produtos de terceiros e, portanto, a Microsoft não dá suporte às melhores práticas de implantação, configuração e solução de problemas relacionadas a eles. Depois de configurada corretamente, a integração com o provedor de identidade SAML 2.0 pode ser testada quanto à configuração correta usando a Ferramenta Analisador de Conectividade da Microsoft, que é descrita em mais detalhes abaixo. Para obter mais informações sobre seu provedor de identidade baseado em um perfil de SP-Lite compatível com SAML 2.0, solicite essas informações à organização que o forneceu.

Importante

Somente um conjunto limitado de clientes está disponível neste cenário de logon com provedores de identidade SAML 2.0, entre os quais:

  • Clientes baseados na Web, como o Outlook Web Access e o SharePoint Online
  • Clientes ricos em email que usam autenticação básica e um método de acesso do Exchange com suporte, como IMAP, POP, Sincronização Ativa, MAPI e assim por diante. (o ponto de extremidade do Protocolo de Cliente Avançado é necessário para ser implantado), incluindo:
    • Microsoft Outlook 2010/Outlook 2013/Outlook 2016, Apple iPhone (diversas versões do iOS)
    • Diversos dispositivos Google Android
    • Windows Phone 7, Windows Phone 7.8 e Windows Phone 8.0
    • Cliente de email do Windows 8 e Cliente de email do Windows 8.1
    • Cliente de email do Windows 10

Todos os outros clientes estão indisponíveis neste cenário de logon com seu Provedor de identidade SAML 2.0. Por exemplo, o cliente de desktop do Lync 2010 não pode entrar no serviço com seu Provedor de Identidade SAML 2.0 configurado para logon único.

Requisitos do protocolo Microsoft Entra SAML 2.0

Esse documento contém requisitos detalhados sobre o protocolo e a formatação de mensagens que seu provedor de identidade SAML 2.0 deve implementar para federar com o Microsoft Entra ID para habilitar o logon em um ou mais serviços de nuvem da Microsoft (como o Microsoft 365). A terceira parte confiável SAML 2.0 (SP-STS) para um serviço de nuvem da Microsoft usado nesse cenário é o Microsoft Entra ID.

Recomenda-se que você garanta que as mensagens de saída do seu provedor de identidade SAML 2.0 sejam as mais semelhantes possíveis aos rastreamentos de amostra fornecidos. Além disso, use valores de atributo específicos dos metadados fornecidos do Microsoft Entra sempre que possível. Quando estiver satisfeito com suas mensagens de saída, você pode fazer o teste com o Analisador de Conectividade da Microsoft, conforme descrito abaixo.

Os metadados do Microsoft Entra podem ser baixados dessa URL: https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml. Para clientes na China que usam a instância específica da China do Microsoft 365, o seguinte ponto de extremidade de federação deve ser usado: https://nexus.partner.microsoftonline-p.cn/federationmetadata/saml20/federationmetadata.xml.

Requisitos do protocolo SAML

Esta seção detalha como os pares de mensagens de solicitação e resposta são reunidos para ajudá-lo a formatar suas mensagens corretamente.

O Microsoft Entra ID pode ser configurado para funcionar com provedores de identidade que usam o perfil SAML 2.0 SP Lite com alguns requisitos específicos, conforme listado abaixo. Usando as mensagens de solicitação e resposta SAML de exemplo junto com testes automatizados e manuais, você pode trabalhar para obter interoperabilidade com o Microsoft Entra ID.

Requisitos do bloco de assinatura

Dentro da mensagem de resposta SAML, o nó de Assinatura contém informações sobre a assinatura digital da mensagem em si. O bloco de assinatura tem os seguintes requisitos:

  1. O próprio nó de declaração precisa ser assinado
  2. O algoritmo RSA-sha1 precisa ser usado como o DigestMethod. Outros algoritmos de assinatura digital não são aceitos. <ds:DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1"/>
  3. Você também pode assinar o documento XML.
  4. O algoritmo de transformação precisa corresponder aos valores no seguinte exemplo: <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. O algoritmo SignatureMethod precisa corresponder ao seguinte exemplo: <ds:SignatureMethod Algorithm="https://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

Observação

Para melhorar a segurança, o algoritmo SHA-1 foi preterido. Use um algoritmo mais seguro, como o SHA-256. Mais informações podem ser encontradas em.

Associações com suporte

Associações são os parâmetros de comunicação relacionados ao transporte que são necessários. Os requisitos a seguir se aplicam às associações

  1. HTTPS é o transporte obrigatório.
  2. O Microsoft Entra ID requer HTTP POST para envio de token durante a entrada.
  3. O Microsoft Entra ID usará HTTP POST para a solicitação de autenticação para o provedor de identidade e REDIRECIONAR para a mensagem de saída para o provedor de identidade.

Atributos necessários

Esta tabela mostra os requisitos para atributos específicos na mensagem SAML 2.0.

Atributo Descrição
NameID O valor dessa declaração deve ser o mesmo que o ImmutableID do usuário do Microsoft Entra. Ela pode ter até 64 caracteres alfanuméricos. Qualquer caractere seguro não HTML deve ser codificado, por exemplo, um caractere "+" é mostrado como ".2B".
IDPEmail O nome UPN é listado na resposta SAML como um elemento com o nome IDPEmail. O UPN (UserPrincipalName) do usuário no Microsoft Entra ID/Microsoft 365. O UPN tem o formato de endereço de email. Valor UPN no Windows Microsoft 365 (Microsoft Entra ID).
Emissor Precisa ser um URI do provedor de identidade. Não reutilize o Emissor das mensagens de amostra. Se você tiver vários domínios de nível superior em seus locatários do Microsoft Entra, o Emissor deverá corresponder à configuração de URI especificada configurada por domínio.

Importante

O Microsoft Entra ID atualmente oferece suporte ao seguinte URI de formato do NameID para SAML 2.0:urn:oasis:names:tc:SAML:2.0:nameid-format:persistent.

Mensagens de exemplo de solicitação e resposta SAML

Um par de mensagens de solicitação e resposta é mostrado para a troca de mensagens de logon. A seguir está uma mensagem de solicitação de exemplo que é enviada do Microsoft Entra ID para um provedor de identidade SAML 2.0 de exemplo. O provedor de identidade SAML 2.0 de exemplo é o Serviços de Federação do Active Directory (AD FS), configurado para usar o protocolo SAML-P. Testes de interoperabilidade também foram concluídos com outros provedores de identidade 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>

Se isSignedAuthenticationRequestRequired estiver ativado conforme explicado em internaldomainfederation-update, a solicitação seria semelhante a esse exemplo:

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

A seguir está uma mensagem de resposta de exemplo que é enviada do provedor de identidade compatível com SAML 2.0 de exemplo para o 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>

Configurar seu provedor de identidade em conformidade com SAML 2.0

Essa seção contém diretrizes sobre como configurar seu provedor de identidade SAML 2.0 para federar com o Microsoft Entra ID para habilitar o acesso de logon único a um ou mais serviços de nuvem da Microsoft (como o Microsoft 365) usando o protocolo SAML 2.0. A terceira parte confiável SAML 2.0 para um serviço de nuvem da Microsoft usado nesse cenário é o Microsoft Entra ID.

Adicionar metadados do Microsoft Entra

Seu provedor de identidade SAML 2.0 precisa aderir às informações sobre a terceira parte confiável do Microsoft Entra ID. O Microsoft Entra ID publica metadados em https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml.

É recomendável que você sempre importe os metadados mais recentes do Microsoft Entra ao configurar seu provedor de identidade SAML 2.0.

Observação

O Microsoft Entra ID não lê metadados do provedor de identidade.

Adicionar o Microsoft Entra ID como uma terceira parte confiável

Você deve habilitar a comunicação entre o provedor de identidade SAML 2.0 e o Microsoft Entra ID. Essa configuração dependerá de seu provedor de identidade específico e você deve consultar a documentação dele. Normalmente, você definiria a ID da terceira parte confiável como a ID da entidade dos metadados do Microsoft Entra.

Observação

Verifique se o relógio no servidor de seu provedor de identidade SAML 2.0 está sincronizado com uma fonte de horário precisa. Um relógio com horário impreciso pode fazer com que os logons federados falhem.

Instalar o PowerShell para fazer logon no provedor de identidade SAML 2.0

Depois de configurar seu provedor de identidade SAML 2.0 para uso com o logon do Microsoft Entra, a próxima etapa é baixar e instalar o módulo do Microsoft Graph PowerShell. Depois de instalado, você usará esses cmdlets para configurar seus domínios do Microsoft Entra como domínios federados.

O módulo do Microsoft Graph PowerShell é um download para gerenciar os dados de suas organizações no Microsoft Entra ID. Esse módulo instala um conjunto de cmdlets no PowerShell; você executa esses cmdlets para configurar o acesso de logon único ao Microsoft Entra ID e, por sua vez, a todos os serviços de nuvem nos quais você está inscrito. Para obter instruções sobre como baixar e instalar os cmdlets, consulte Instalar o SDK do Microsoft Graph PowerShell.

Configurar uma relação de confiança entre seu provedor de identidade SAML e o Microsoft Entra ID

Antes de configurar a federação em um domínio do Microsoft Entra, ele deve ter um domínio personalizado configurado. Você não pode federar o domínio padrão fornecido pela Microsoft. O domínio padrão da Microsoft termina com onmicrosoft.com. Você executará uma série de cmdlets do PowerShell para adicionar ou converter domínios para logon único.

Cada domínio do Microsoft Entra que você deseja federar usando seu provedor de identidade SAML 2.0 deve ser adicionado como um domínio de logon único ou convertido para ser um domínio de logon único de um domínio padrão. Adicionar ou converter um domínio configura uma relação de confiança entre o provedor de identidade SAML 2.0 e o Microsoft Entra ID.

O procedimento a seguir descreve a conversão de um domínio padrão existente em um domínio federado usando SP-Lite compatível com o SAML 2.0.

Observação

Seu domínio pode passar por uma interrupção que afetará usuários até duas horas após você executar esta etapa.

Configurando um domínio no diretório do Microsoft Entra para federação

  1. Conecte-se ao seu diretório do Microsoft Entra como administrador de locatário:

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

  2. Configure seu domínio do Microsoft 365 desejado para usar a federação com 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. Você pode obter a cadeia de caracteres codificada em Base64 do certificado de autenticação em seu arquivo de metadados do IDP. Um exemplo desse local é fornecido abaixo, mas pode ser ligeiramente diferente com base em sua implementação.

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

Para obter mais informações, consulte New-MgDomainFederationConfiguration.

Observação

Use $ecpUrl = "https://WS2012R2-0.contoso.com/PAOS" somente se configurar uma extensão ECP para o seu provedor de identidade. Clientes do Exchange Online, exceto pelo aplicativo OWA (Outlook Web Application), dependem de ponto de extremidade ativa baseado em POST. Se o seu STS SAML 2.0 implementar um ponto de extremidade ativo semelhante à implementação de ECP do Shibboleth de um ponto de extremidade ativo, é possível que esses clientes avançados interajam com o serviço do Exchange Online.

Depois que a federação estiver configurada, você poderá alternar de volta para “não federado” (ou “gerenciado”), no entanto, essa alteração leva até duas horas para ser concluída e requer a atribuição de novas senhas aleatórias para entrada baseada em nuvem a cada usuário. Em alguns cenários, pode ser necessário voltar para a configuração "gerenciado" para redefinir um erro em suas configurações. Para obter mais informações sobre conversão de domínio, consulte Remove-MgDomainFederationConfiguration.

Provisionar entidades de usuário para o Microsoft Entra ID / Microsoft 365

Antes de autenticar seus usuários no Microsoft 365, você deve provisionar o Microsoft Entra ID com entidades de usuário que correspondam à declaração na declaração SAML 2.0. Se essas entidades de usuário não forem conhecidas com antecedência pelo Microsoft Entra ID, elas não poderão ser usadas para entrada federada. O Microsoft Entra Connect ou o PowerShell podem ser usados para provisionar entidades de usuário.

O Microsoft Entra Connect pode ser usado para provisionar entidades de segurança para seus domínios no Microsoft Entra Directory a partir do Active Directory local. Para obter informações mais detalhadas, consulte Integrar seus diretórios locais com o ID do Microsoft Entra.

O PowerShell também pode ser usado para automatizar a adição de novos usuários ao Microsoft Entra ID e para sincronizar alterações do diretório local. Para usar os cmdlets do PowerShell, você deve baixar o módulo do Microsoft Graph PowerShell.

Esse procedimento mostra como adicionar um único usuário ao Microsoft Entra ID.

  1. Conecte-se ao Microsoft Entra Directory como administrador de locatários usando Connect-MgGraph.

  2. Crie uma entidade de usuário:

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

Para obter mais informações, consulte New-MgUser.

Observação

O valor “UserPrincipalName” deve corresponder ao valor que você enviará para “IDPEmail” em sua declaração SAML 2.0 e o valor “OnPremisesImmutableId” deve corresponder ao valor enviado em sua declaração “NameID”.

Verificar o logon único com seu IDP SAML 2.0

Como administrador, antes de verificar e gerenciar o logon único (também chamado de federação de identidades), revise as informações e execute as etapas nos artigos a seguir para configurar o logon único com seu provedor de identidade baseado no SP-Lite compatível com SAML 2.0:

  1. Você analisou os requisitos do protocolo Microsoft Entra SAML 2.0
  2. Você configurou seu provedor de identidade SAML 2.0
  3. Instalar o PowerShell para SSO (logon único) no provedor de identidade SAML 2.0
  4. Configurar uma relação de confiança entre o provedor de identidade SAML 2.0 e o Microsoft Entra ID
  5. Provisionada uma entidade de usuário de teste conhecida para o Microsoft Entra ID (Microsoft 365) por meio do Windows PowerShell ou do Microsoft Entra Connect.
  6. Configure a sincronização de diretórios usando o Microsoft Entra Connect.

Após configurar o SSO com o seu provedor de identidade baseado em SP-Lite compatível com SAML 2.0, verifique se ele está funcionando corretamente. Para obter mais informações sobre como testar o SSO baseado em SAML, consulte Testar logon único baseado em SAML.

Observação

Se você tiver convertido um domínio em vez de adicionar um, poderá levar até 24 horas para configurar o logon único. Antes de verificar o logon único, termine de configurar a sincronização do Active Directory, sincronize seus diretórios e ative seus usuários sincronizados.

Verifique manualmente se o logon único foi configurado corretamente

A verificação manual fornece etapas adicionais que você pode adotar para garantir que seu provedor de identidade SAML 2.0 esteja funcionando corretamente em diversos cenários. Para confirmar que o logon único foi configurado corretamente, conclua as etapas a seguir:

  1. Em um computador ingressado no domínio, entre em seu serviço de nuvem usando o mesmo nome de logon que você usa para suas credenciais corporativas.
  2. Selecione dentro da caixa de senha. Se o logon único estiver configurado, a caixa de senha estará sombreada e você verá a seguinte mensagem: "Agora você precisa entrar na <sua empresa>."
  3. Clique em Entrar no link da <sua empresa>. Se você conseguir entrar, significa que o logon único foi configurado.

Próximas etapas