Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
As organizações estão cada vez mais adotando uma abordagem em nuvem para modernizar suas soluções de IAM (Gerenciamento de Identidade e Acesso). Para o caminho para a iniciativa de nuvem, a Microsoft modelou cinco estados de transformação para se alinhar às metas de negócios do cliente. A transição da SOA (Fonte de Autoridade) para usuários do AD DS (Active Directory Domain Services) local para a nuvem é uma etapa fundamental neste percurso. Esse processo, conhecido como minimização do AD DS, reduz a complexidade da infraestrutura local gerenciando usuários diretamente na nuvem.
Este artigo apresenta o conceito de SOA de usuário, seus benefícios e o cenário que ele suporta. Ele também descreve as principais considerações e pré-requisitos para os administradores de TI que planejam transferir o gerenciamento de usuários para a nuvem usando a ID do Microsoft Entra. Usando o SOA do usuário, as organizações podem simplificar o gerenciamento do ciclo de vida do usuário, habilitar recursos avançados de governança e adotar totalmente uma postura de primeira nuvem. Para obter um guia sobre como usar o SOA do usuário para arquitetos de TI, consulte: Cloud-First gerenciamento de identidades: Diretrizes para arquitetos de TI.
Vídeo: Fonte de autoridade do usuário do Microsoft Entra
Confira este vídeo para obter uma introdução ao SOA e como ele pode ajudá-lo a mudar para a nuvem:
Cenário SOA do usuário
As próximas seções explicam mais detalhes sobre o cenário compatível com o SOA do usuário.
Minimizando usuários do AD e governando o ciclo de vida do usuário com a Governança de ID do Microsoft Entra
Cenário: você modernizou alguns ou todos os seus aplicativos e removeu a necessidade de usar usuários do AD DS para acesso. Por exemplo, esses aplicativos agora usam declarações de usuário com SAML (Security Assertion Markup Language) ou OpenID Connect da ID do Microsoft Entra em vez de sistemas de federação, como o AD FS. No entanto, esses aplicativos ainda dependem do usuário sincronizado existente para gerenciar o acesso. Ao implementar o SOA do usuário, você pode editar o usuário na nuvem, remover completamente o usuário do AD DS e controlar o usuário por meio dos recursos de Governança de ID do Microsoft Entra.
Autenticação sem senha de usuários transferidos pelo SOA
Cenário: você transferiu o SOA para usuários e agora deseja permitir que eles acessem recursos locais e de nuvem. Em vez de remover completamente os usuários do local, introduza a autenticação sem senha do Cloud Kerberos Trust para permitir que eles mantenham uma presença híbrida, permitindo que eles continuem acessando seus recursos locais, permitindo também que eles acessem recursos de nuvem. Métodos de autenticação sem senha, como o Windows Hello para Empresas ou chaves de segurança FIDO2, podem ser usados para permitir que esses usuários acessem seus recursos locais e recursos de nuvem, como arquivos do Azure por meio do Microsoft Entra Private Access. O uso de autenticação sem senha também permite que a autenticação multifator nos usuários transferidos para SOA incremente a segurança. A autenticação sem senha também permite habilitar políticas de Acesso Condicional nos recursos locais, permitindo maior controle e segurança sobre esses recursos. A conta de usuário deve permanecer no Active Directory para que esse cenário funcione.
Pré-requisitos para transferir o SOA do usuário
Antes de começar a transferir o SOA para usuários em sua organização, seu ambiente deve atender aos seguintes pré-requisitos:
- O sistema de RH na nuvem foi configurado e integrado com êxito à ID do Microsoft Entra. As alterações em usuários provisionados a partir do sistema de RH devem ir diretamente para o Microsoft Entra ID. Para obter mais informações, consulte: Altere a configuração dos usuários no provisionamento do sistema de RH.
- Nenhuma carga de trabalho do Exchange local. Se você estiver usando o Exchange Server local no momento, migre os usuários e as caixas de correio para a nuvem e remova o Exchange Server local. Para obter mais informações, consulte: Preparar a configuração do Microsoft Exchange.
- Qualquer método de autenticação funciona para usuários de nuvem, mas se estiver usando aplicativos baseados em Kerberos, a autenticação sem senha será necessária.
- O tipo de Confiança Kerberos na Nuvem deve ser utilizado.
- Os usuários destinados à transferência SOA não estão associados a nenhum aplicativo que exija autenticação de senha. Se qualquer um dos usuários para os quais você deseja transferir SOA tiver dependências de senha, não há suporte para a transferência do SOA. Se os usuários estiverem usando a autenticação federada usando o Serviço de Federação do Active Directory, não há suporte para a transferência do SOA. Se sua organização usa um provedor de identidade de autenticação de federação de terceiros e planeja transferir o SOA dos usuários, você deve gerenciar a conta do Active Directory manualmente. Com esse processo, você deve manter a senha usando a ferramenta de sincronização de terceiros.