Gerenciar autenticação
A autenticação do Power Platform envolve uma sequência de solicitações, respostas e redirecionamentos entre o navegador do usuário e o Power Platform ou os serviços do Azure. A sequência segue o fluxo de concessão de código de autenticação do Microsoft Entra ID.
Você pode escolher entre três modelos de identidade principais no Microsoft 365 ao configurar e gerenciar contas de usuário:
Identidade na nuvem: gerencie suas contas de usuário somente no Microsoft 365. Nenhum servidor local é necessário para gerenciar os usuários, tudo é feito na nuvem.
Identidade sincronizada: sincronize os objetos do diretório local com o Microsoft 365 e gerencie os usuários no ambiente local. Você também pode sincronizar as senhas para que os usuários tenham a mesma senha no local e na nuvem, mas eles precisarão entrar novamente para usar o Microsoft 365.
Identidade federada: sincronize os objetos do diretório local com o Microsoft 365 e gerencie os usuários no ambiente local. Os usuários têm a mesma senha no local e na nuvem e não precisam entrar novamente para usar o Microsoft 365. Geralmente, esse comportamento é chamado de logon único.
É importante considerar cuidadosamente qual modelo de identidade usar desde o início. Considere o tempo, a complexidade existente e o custo. Esses fatores se manifestam de forma diferente para cada organização. Sua escolha deve ser com base no porte de sua empresa e na amplitude de seus recursos de TI.
Entender a identidade do Microsoft 365 e o Microsoft Entra ID
O Microsoft 365 usa o Microsoft Entra ID, o serviço de autenticação e identidade de usuário baseado na nuvem, para gerenciar usuários. Decidir como configurar o gerenciamento de identidade entre sua infraestrutura local e o Microsoft 365 é uma decisão inicial e fundamental para sua infraestrutura de nuvem. Pode ser difícil alterar essa configuração posteriormente, então, considere cuidadosamente as opções para determinar o que funciona melhor para sua organização.
Você pode escolher entre dois modelos de autenticação principais no Microsoft 365 para configurar e gerenciar contas de usuário: autenticação de nuvem e autenticação federada.
Autenticação de nuvem
Se você não tiver um ambiente existente do Active Directory local, isso poderá influenciar sua escolha de serviços de autenticação e identidade. Abaixo estão alguns modelos de autenticação e gerenciamento de identidade a serem considerados.
Somente nuvem
Com o modelo somente nuvem, você gerencia suas contas de usuário apenas no Microsoft 365. Nenhum servidor local é necessário. Você cria e gerencia usuários no Centro de administração do Microsoft 365 ou usando os cmdlets do PowerShell do Windows PowerShell. A identidade e a autenticação são gerenciadas completamente na nuvem pelo Microsoft Entra ID.
Geralmente, o modelo somente nuvem é uma boa opção se:
Você não tem outro diretório de usuário local.
Você tem um diretório local complexo e apenas deseja evitar o trabalho de integração com ele.
Você tem um diretório local existente, mas deseja executar uma avaliação ou um piloto do Microsoft 365. Posteriormente, você poderá fazer a correspondência entre os usuários da nuvem e os usuários locais quando estiver pronto para se conectar ao diretório local.
Sincronização de hash de senha com logon único contínuo
A sincronização de hash de senha com logon único contínuo é a maneira mais simples de habilitar a autenticação para objetos de diretório locais no Microsoft Entra ID. Com a sincronização de hash de senha (PHS), você sincroniza os objetos de conta de usuário do Active Directory local com o Microsoft 365 e gerencia os usuários no ambiente local. Os hashes de senhas de usuário são sincronizados do Active Directory local com o Microsoft Entra ID de modo que os usuários tenham a mesma senha tanto no ambiente local quanto na nuvem.
Quando as senhas são alteradas ou redefinidas no local, os novos hashes de senha são sincronizados com o Microsoft Entra ID. Dessa forma, os usuários podem usar a mesma senha para recursos locais e na nuvem. As senhas nunca são enviadas ou armazenadas no Microsoft Entra ID em texto sem formatação. Alguns recursos Premium do Microsoft Entra ID, como a proteção de identidade, exigem PHS, seja qual for o método de autenticação selecionado. Com o logon único contínuo, os usuários são conectados automaticamente no Microsoft Entra ID quando usam dispositivos corporativos e estão conectados à rede da empresa.
Autenticação de passagem com logon único contínuo
A autenticação de passagem com logon único contínuo fornece validação de senha simples para serviços de autenticação do Microsoft Entra ID. Ele usa um software agente em execução em um ou mais servidores locais para validar usuários diretamente com seu Active Directory local. Com a PTA (autenticação de passagem), você sincroniza os objetos de conta de usuário do Active Directory local com o Microsoft 365 e gerencia os usuários no ambiente local.
Esse modelo permite que os usuários entrem em recursos e aplicativos locais e do Microsoft 365 usando suas contas e senhas locais. Essa configuração valida senhas de usuários diretamente no Active Directory local sem enviar hashes de senha para o Microsoft 365. Organizações com um requisito de segurança para aplicar imediatamente estados de contas de usuários locais, políticas de senhas e horários de logon devem usar esse método de autenticação. Com o logon único contínuo, os usuários são conectados automaticamente no Microsoft Entra ID quando usam dispositivos corporativos e estão conectados à rede da empresa.
Logon único
Por padrão, o Dynamics 365 Online usa o Microsoft Entra ID para autenticação. No entanto, muitas organizações em todo o mundo usam seu Active Directory local para fazer autenticação interna.
O logon único contínuo (SSO Contínuo) do Microsoft Entra ID conecta automaticamente os usuários quando eles estão em seus dispositivos corporativos e conectados a sua rede corporativa. Quando o SSO está habilitado, os usuários não precisam digitar suas senhas (ou, muitas vezes, nem seus nomes de usuário) para entrar no Microsoft Entra. Esse recurso fornece aos usuários acesso fácil a aplicativos baseados na nuvem, sem a necessidade de mais componentes locais.
É possível combinar o SSO Contínuo com os métodos de entrada Sincronização de hash de senha ou Autenticação de passagem. O SSO Contínuo não é aplicável ao AD FS (Serviços de Federação do Active Directory).*
Observação
O SSO Contínuo precisa que o dispositivo do usuário ingresse em um domínio, mas não precisa que o dispositivo ingresse no Microsoft Entra.
Principais benefícios
Excelente experiência do usuário
Os usuários são conectados automaticamente nos aplicativos locais e baseados em nuvem.
Os usuários não precisam inserir as senhas várias vezes.
Fácil de implantar e administrar
Nenhum outro componente é necessário no local para que isso funcione.
Funciona com qualquer método de autenticação de nuvem: Sincronização de hash de senha ou Autenticação de passagem.
Pode ser implementado para alguns ou todos os usuários por meio de política de grupo.
Considerações
O nome de usuário de logon pode ser o nome de usuário padrão local (userPrincipalName) ou outro atributo configurado no Microsoft Entra Connect (ID Alternativa). Qualquer uma dessas opções funciona, pois o SSO Contínuo usa a declaração securityIdentifier no tíquete Kerberos para procurar o objeto de usuário correspondente no Microsoft Entra ID.
O SSO Contínuo é um recurso adaptável. Se falhar por qualquer motivo, a experiência de entrada retornará ao comportamento normal ou seja, o usuário deve inserir sua senha na página de entrada.
Se um aplicativo incluir um parâmetro domain_hint (OpenID Connect) ou whr (SAML) em sua solicitação de entrada do Microsoft Entra para identificar seu locatário ou um parâmetro login_hint para identificar o usuário, o usuário será conectado automaticamente sem precisar inserir um nome de usuário ou senha.
Os usuários também obterão uma experiência de entrada silenciosa se um aplicativo (por exemplo,
https://contoso.crm.dynamics.com
) enviar solicitações de entrada aos pontos de extremidade de locatário do Microsoft Entra (comohttps://login.microsoftonline.com/contoso.com
ouhttps://login.microsoftonline.com <tenant_ID>
), em vez do ponto de extremidade comum do Microsoft Entra (https://login.microsoftonline.com/common
).É possível sair. Isso permite que os usuários escolham outra conta do Microsoft Entra ID para entrar, em vez de serem conectados automaticamente usando o SSO Contínuo.
Os clientes Win32 do Microsoft 365 (Outlook, Word, Excel e outros) com versões 16.0.8730.xxxx e superiores dão suporte a um fluxo não interativo. Para o OneDrive, você precisa ativar o Recurso de configuração silenciosa do OneDrive para habilitar uma experiência de Entrada silenciosa.
Ele pode ser habilitado pelo Microsoft Entra Connect.
É um recurso gratuito; você não precisa de licenças pagas do Microsoft Entra ID para usá-lo.
Federar um único ambiente de floresta do AD para a nuvem
O tutorial a seguir orientará você na criação de um ambiente de identidade híbrida usando a federação. Esse ambiente pode ser usado para testes ou para se familiarizar mais com o funcionamento de uma identidade híbrida.
Tutorial: Federar um único ambiente de floresta do AD para a nuvem
Acesso condicional do Microsoft Entra
As políticas de Acesso Condicional no Microsoft Entra ID, em sua forma mais simples, são instruções if-then: if, se um usuário quiser acessar um recurso, then, então ele deverá concluir uma ação.
Exemplo: um gerente de folha de pagamento que deseja acessar o aplicativo de folha de pagamento criado com o Power Apps precisa executar a autenticação multifator para acessá-lo.
Os administradores lidam com duas metas principais:
Capacitar os usuários a serem em qualquer lugar e a qualquer momento.
Proteger os ativos da organização.
Usando políticas de Acesso Condicional, você pode aplicar os controles de acesso corretos quando necessário para manter sua organização segura, sem afetar os usuários, quando os controles não forem necessários. As políticas de Acesso Condicional são aplicadas após a conclusão da autenticação de primeiro fator.
Somente Administradores globais podem configurar políticas de Acesso Condicional. Eles não podem ser configurados pelos administradores do Microsoft Power Platform ou do Dynamics 365.
Para saber como configurar políticas de Acesso Condicional, consulte Planejar uma implantação de Acesso Condicional.