Governar aplicativos locais baseados no Ative Directory (Kerberos) usando o Microsoft Entra ID Governance
Importante
A visualização pública do Group Writeback v2 no Microsoft Entra Connect Sync não estará mais disponível após 30 de junho de 2024. Esta funcionalidade será descontinuada nesta data e não terá mais suporte para a Sincronização de Ligação para aprovisionar grupos de segurança na cloud para o Active Directory. A funcionalidade continuará a operar após a data de descontinuação. No entanto, deixará de receber suporte após esta data e poderá deixar de funcionar a qualquer momento sem aviso prévio.
Oferecemos funcionalidade semelhante na Sincronização da Cloud do Microsoft Entra chamada Aprovisionamento de Grupo para o Active Directory que pode utilizar em vez da Repetição de Escrita de Grupo v2 para aprovisionar grupos de segurança da cloud para o Active Directory. Estamos a trabalhar para melhorar esta funcionalidade na Sincronização da Cloud, juntamente com outras novas funcionalidades que estamos a desenvolver na Sincronização da Cloud.
Os clientes que usam esta funcionalidade de pré-visualização na Sincronização de Ligação devem alternar a sua configuração da Sincronização de Ligação para a Sincronização na Cloud. Pode optar por mover toda a sincronização híbrida para a Sincronização na Cloud (se esta atender às suas necessidades). Também pode executar a Sincronização na Cloud lado a lado e mover apenas o aprovisionamento do grupo de segurança da cloud para o Active Directory para a Sincronização na Cloud.
Para clientes que aprovisionam grupos do Microsoft 365 para o Active Directory, pode continuar a utilizar a Repetição de Escrita de Grupo v1 para esta capacidade.
Pode avaliar a mudança exclusivamente para a Sincronização na Cloud utilizando o assistente de sincronização do utilizador.
Cenário: gerencie aplicativos locais com grupos do Ative Directory que são provisionados e gerenciados na nuvem. O Microsoft Entra Cloud Sync permite que você controle totalmente as atribuições de aplicativos no AD enquanto aproveita os recursos de Governança de ID do Microsoft Entra para controlar e corrigir quaisquer solicitações relacionadas ao acesso.
Com o lançamento do agente de provisionamento 1.1.1370.0, a sincronização na nuvem agora tem a capacidade de provisionar grupos diretamente para seu ambiente local do Ative Directory. Você pode usar recursos de governança de identidade para controlar o acesso a aplicativos baseados em AD, por exemplo, incluindo um grupo em um pacote de acesso de gerenciamento de direitos.
Assista ao vídeo de write-back do grupo
Para obter uma visão geral do provisionamento de grupo de sincronização na nuvem para o Ative Directory e o que ele pode fazer por você, confira o vídeo abaixo.
Pré-requisitos
Os pré-requisitos a seguir são necessários para implementar esse cenário.
- Conta do Microsoft Entra com pelo menos uma função de Administrador de Identidade Híbrida .
- Ambiente local dos Serviços de Domínio Ative Directory com sistema operacional Windows Server 2016 ou posterior.
- Necessário para o atributo Esquema do AD - msDS-ExternalDirectoryObjectId.
- Agente de provisionamento com compilação versão 1.1.1367.0 ou posterior.
Nota
As permissões para a conta de serviço são atribuídas apenas durante a instalação limpa. Caso você esteja atualizando da versão anterior, as permissões precisam ser atribuídas manualmente usando o cmdlet do PowerShell:
$credential = Get-Credential
Set-AADCloudSyncPermissions -PermissionType UserGroupCreateDelete -TargetDomain "FQDN of domain" -TargetDomainCredential $credential
Se as permissões forem definidas manualmente, você precisará garantir que Ler, Gravar, Criar e Excluir todas as propriedades de todos os Grupos descendentes e objetos de Usuário.
Essas permissões não são aplicadas a objetos AdminSDHolder por padrão
Cmdlets do agente de provisionamento do Microsoft Entra gMSA PowerShell
- O agente de provisionamento deve ser capaz de se comunicar com um ou mais controladores de domínio nas portas TCP/389 (LDAP) e TCP/3268 (Catálogo Global).
- Necessário para pesquisa de catálogo global para filtrar referências de associação inválidas.
- Microsoft Entra Connect com build versão 2.2.8.0 ou posterior.
- Necessário para suportar a associação de usuário local sincronizada usando o Microsoft Entra Connect.
- Necessário para sincronizar AD:user:objectGUID com o Microsoft Entra ID:user:onPremisesObjectIdentifier.
Grupos suportados
Para esse cenário, somente os seguintes grupos são suportados:
- Apenas os grupos de segurança criados na nuvem são suportados
- Grupos de associação atribuídos ou dinâmicos
- Contêm apenas utilizadores sincronizados no local e/ou grupos de segurança criados na nuvem
- As contas de usuário locais sincronizadas e que são membros desse grupo de segurança criado na nuvem podem ser do mesmo domínio ou entre domínios, mas todas devem ser da mesma floresta
- Escrito de volta com o escopo de grupos AD de universal. Seu ambiente local deve suportar o escopo de grupo universal
- Não superior a 50.000 membros
- Cada grupo aninhado filho direto conta como um membro no grupo de referência
Cenários suportados
As seções a seguir discutem os cenários compatíveis com o provisionamento de grupo de sincronização na nuvem.
Configurando cenários suportados
Se quiser controlar se um usuário pode se conectar a um aplicativo do Ative Directory que usa a autenticação do Windows, você pode usar o proxy do aplicativo e um grupo de segurança do Microsoft Entra. Se um aplicativo verificar as associações de grupo do AD de um usuário, via Kerberos ou LDAP, você poderá usar o provisionamento de grupo de sincronização na nuvem para garantir que um usuário do AD tenha essas associações de grupo antes que o usuário acesse os aplicativos.
As seções a seguir discutem duas opções de cenário compatíveis com o provisionamento de grupo de sincronização na nuvem. As opções de cenário destinam-se a garantir que os usuários atribuídos ao aplicativo tenham associações de grupo quando se autenticam no aplicativo.
- Criar um novo grupo e atualizar o aplicativo, se ele já existir, para verificar o novo grupo, ou
- Criar um novo grupo e atualizar os grupos existentes, o aplicativo estava verificando, para incluir o novo grupo como membro
Antes de começar, certifique-se de que é um administrador de domínio no domínio onde a aplicação está instalada. Certifique-se de que consegue iniciar sessão num controlador de domínio ou de ter as ferramentas de Administração de Servidor Remoto para administração dos Serviços de Domínio Ative Directory (AD DS) instaladas no seu PC Windows.
Configurando a nova opção de grupos
Nesta opção de cenário, você atualiza o aplicativo para verificar o SID, nome ou nome distinto de novos grupos criados pelo provisionamento de grupo de sincronização na nuvem. Este cenário é aplicável a:
- Implantações para novos aplicativos sendo conectados ao AD DS pela primeira vez.
- Novos grupos de usuários acessando o aplicativo.
- Para modernização de aplicativos, para reduzir a dependência de grupos AD DS existentes.
Os aplicativos, que atualmente verificam a associação ao
Domain Admins
grupo, precisam ser atualizados para também verificar se há um grupo do AD recém-criado.
Use as etapas a seguir para que os aplicativos usem novos grupos.
Criar aplicativo e grupo
- Usando o centro de administração do Microsoft Entra, crie um aplicativo no Microsoft Entra ID representando o aplicativo baseado em AD e configure o aplicativo para exigir atribuição de usuário.
- Se você estiver usando o proxy de aplicativo para permitir que os usuários se conectem ao aplicativo, configure o proxy de aplicativo.
- Crie um novo grupo de segurança no Microsoft Entra ID.
- Use o Provisionamento de Grupo para AD para provisionar esse grupo para AD.
- Inicie Usuários e Computadores do Ative Directory e aguarde até que o novo grupo do AD resultante seja criado no domínio do AD. Quando estiver presente, registre o nome distinto, o domínio, o nome da conta e o SID do novo grupo do AD.
Configurar o aplicativo para usar o novo grupo
- Se o aplicativo usa o AD via LDAP, configure o aplicativo com o nome distinto do novo grupo do AD. Se o aplicativo usar o AD via Kerberos, configure o aplicativo com o SID ou o nome do domínio e da conta do novo grupo do AD.
- Crie um pacote de acesso. Adicione o aplicativo de #1, o grupo de segurança de #3, como recursos no Access Package. Configure uma política de atribuição direta no pacote de acesso.
- No Gerenciamento de Direitos, atribua os usuários sincronizados que precisam de acesso ao aplicativo baseado no AD ao pacote de acesso.
- Aguarde até que o novo grupo do AD seja atualizado com os novos membros. Usando Usuários e Computadores do Ative Directory, confirme se os usuários corretos estão presentes como membros do grupo.
- No monitoramento de domínio do AD, permita apenas a conta gMSA que executa o agente de provisionamento, autorização para alterar a associação no novo grupo do AD.
Agora você pode controlar o acesso ao aplicativo AD por meio desse novo pacote de acesso.
Configurando a opção de grupos existentes
Nesta opção de cenário, você adiciona um novo grupo de segurança do AD como um membro aninhado de um grupo existente. Este cenário é aplicável a implantações para aplicativos que têm uma dependência codificada em um determinado nome de conta de grupo, SID ou nome distinto.
Aninhar esse grupo no grupo AD existente de aplicativos permitirá:
- Os usuários do Microsoft Entra, que são atribuídos por um recurso de governança e, em seguida, acessam o aplicativo, para ter o tíquete Kerberos apropriado. Este ticket contém o SID de grupos existentes. O aninhamento é permitido pelas regras de aninhamento de grupo do AD.
Se o aplicativo usar LDAP e seguir a associação de grupo aninhada, o aplicativo verá os usuários do Microsoft Entra como tendo o grupo existente como uma de suas associações.
Determinar a elegibilidade do grupo existente
- Inicie Usuários e Computadores do Ative Directory e registre o nome, o tipo e o escopo distintos do grupo AD existente usado pelo aplicativo.
- Se o grupo existente for
Domain Admins
,Domain Guests
, ,Enterprise Admins
Domain Users
,Enterprise Key Admins
,Group Policy Creation Owners
Key Admins
Protected Users
, ou , entãoSchema Admins
você precisará alterar o aplicativo para usar um novo grupo, conforme descrito acima, pois esses grupos não podem ser usados pela sincronização na nuvem. - Se o grupo tiver Escopo Global, altere o grupo para ter Escopo Universal. Um grupo global não pode ter grupos universais como membros.
Criar aplicativo e grupo
- No centro de administração do Microsoft Entra, crie um aplicativo no Microsoft Entra ID representando o aplicativo baseado em AD e configure o aplicativo para exigir atribuição de usuário.
- Se o proxy de aplicativo for usado para permitir que os usuários se conectem ao aplicativo, configure o proxy do aplicativo.
- Crie um novo grupo de segurança no Microsoft Entra ID.
- Use o Provisionamento de Grupo para AD para provisionar esse grupo para AD.
- Inicie Usuários e Computadores do Ative Directory e aguarde até que o novo grupo do AD resultante seja criado no domínio do AD, Quando ele estiver presente, registre o nome distinto, o domínio, o nome da conta e o SID do novo grupo do AD.
Configurar o aplicativo para usar o novo grupo
- Usando Usuários e Computadores do Ative Directory, adicione o novo grupo do AD como membro do grupo do AD existente.
- Crie um pacote de acesso. Adicione o aplicativo de #1, o grupo de segurança de #3, como recursos no Access Package. Configure uma política de atribuição direta no pacote de acesso.
- No Gerenciamento de Direitos, atribua os usuários sincronizados que precisam de acesso ao aplicativo baseado no AD ao pacote de acesso, incluindo quaisquer usuários membros do grupo AD existente que ainda precisem de acesso.
- Aguarde até que o novo grupo do AD seja atualizado com os novos membros. Usando Usuários e Computadores do Ative Directory, confirme se os usuários corretos estão presentes como membros do grupo.
- Usando Usuários e Computadores do Ative Directory, remova os membros existentes, além do novo grupo AD, do grupo AD existente.
- No monitoramento de domínio do AD, permita apenas a conta gMSA que executa o agente de provisionamento, autorização para alterar a associação no novo grupo do AD.
Em seguida, você poderá controlar o acesso ao aplicativo AD por meio desse novo pacote de acesso.
Resolução de Problemas
Um usuário que seja membro do novo grupo do AD e esteja em um PC Windows já conectado a um domínio do AD pode ter um tíquete existente emitido por um controlador de domínio do AD que não inclua a nova associação ao grupo do AD. Isso ocorre porque o tíquete pode ter sido emitido antes do provisionamento do grupo de sincronização na nuvem adicioná-los ao novo grupo do AD. O usuário não poderá apresentar o ticket para acesso ao aplicativo, e por isso deve esperar que o ticket expire e um novo ticket seja emitido, ou limpar seus tickets, fazer logout e login novamente no domínio. Consulte o comando klist para obter mais detalhes.
Clientes existentes do grupo de write-back do Microsoft Entra Connect v2
Se estiver a utilizar o write-back de grupo do Microsoft Entra Connect v2, terá de mudar para o aprovisionamento de sincronização na nuvem para o AD antes de poder tirar partido do aprovisionamento do grupo de sincronização na nuvem. Consulte Migrar write-back do grupo Microsoft Entra Connect Sync V2 para o Microsoft Entra Cloud Sync