Partilhar via

Governar aplicativos locais baseados no Ative Directory (Kerberos) usando o Microsoft Entra ID Governance

  • Artigo

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. Esse recurso será descontinuado nesta data e você não terá mais suporte no Connect Sync para provisionar grupos de segurança na nuvem para o Ative Directory. O recurso continuará a operar após a data de descontinuação; No entanto, deixará de receber apoio após esta data e poderá deixar de funcionar a qualquer momento sem aviso prévio.

Oferecemos funcionalidade semelhante no Microsoft Entra Cloud Sync chamada Provisionamento de Grupo para o Ative Directory que você pode usar em vez do Writeback de Grupo v2 para provisionar grupos de segurança de nuvem para o Ative Directory. Estamos a trabalhar para melhorar esta funcionalidade no Cloud Sync, juntamente com outras novas funcionalidades que estamos a desenvolver no Cloud Sync.

Os clientes que usam esse recurso de visualização no Connect Sync devem alternar sua configuração do Connect Sync para o Cloud Sync. Você pode optar por mover toda a sincronização híbrida para o Cloud Sync (se ele atender às suas necessidades). Você também pode executar o Cloud Sync lado a lado e mover apenas o provisionamento do grupo de segurança na nuvem para o Ative Directory para o Cloud Sync.

Para clientes que provisionam grupos do Microsoft 365 para o Ative Directory, você pode continuar usando o Write-back de Grupo v1 para esse recurso.

Você pode avaliar a mudança exclusivamente para o Cloud Sync usando o assistente de sincronização do usuário.

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.

Desenho conceitual do Microsoft Entra Cloud Sync's Group Provision to AD.

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 são suportados grupos de segurança criados na nuvem
  • Esses grupos podem ter associação atribuída ou dinâmica
  • Esses grupos só podem conter usuários 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
  • esses grupos são escritos de volta com o escopo de grupos AD de universal. Seu ambiente local deve suportar o escopo de grupo universal
  • Não há suporte para grupos com mais de 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 de o usuário acessar 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 que acessam o aplicativo.
  • para modernização de aplicativos, para reduzir a dependência de grupos AD DS existentes. Os aplicativos que atualmente verificam a Domain Admins associação ao grupo precisarão ser atualizados para também verificar se há um grupo AD recém-criado.

Use as etapas a seguir para que os aplicativos usem novos grupos.

Criar aplicativo e grupo

  1. 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.
  2. Se você estiver usando o proxy de aplicativo para permitir que os usuários se conectem ao aplicativo, configure o proxy de aplicativo.
  3. Crie um novo grupo de segurança no Microsoft Entra ID.
  4. Use o Provisionamento de Grupo para AD para provisionar esse grupo para AD.
  5. 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

  1. 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.
  2. 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.
  3. No Gerenciamento de Direitos, atribua os usuários sincronizados que precisam de acesso ao aplicativo baseado no AD ao pacote de acesso.
  4. 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.
  5. 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, posteriormente, acessam o aplicativo, para ter um tíquete Kerberos apropriado. Este bilhete conterá os grupos existentes SID. Esse 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

  1. 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.
  2. Se o grupo existente for Domain Admins, Domain Guests, , Enterprise AdminsDomain Users, Enterprise Key Admins, Group Policy Creation OwnersKey AdminsProtected Users, ou , então Schema Adminsvocê 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.
  3. 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

  1. 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.
  2. Se o proxy de aplicativo for usado para permitir que os usuários se conectem ao aplicativo, configure o proxy de aplicativo.
  3. Crie um novo grupo de segurança no Microsoft Entra ID.
  4. Use o Provisionamento de Grupo para AD para provisionar esse grupo para AD.
  5. 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

  1. Usando Usuários e Computadores do Ative Directory, adicione o novo grupo do AD como membro do grupo do AD existente.
  2. 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.
  3. No Gerenciamento de Direitos, atribua os usuários sincronizados que precisam de acesso ao aplicativo baseado no AD ao pacote de acesso. Isso inclui todos os membros de usuário do grupo AD existente que continuarão a precisar de acesso.
  4. 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.
  5. Usando Usuários e Computadores do Ative Directory, remova os membros existentes, além do novo grupo AD, do grupo AD existente.
  6. 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

Passos Seguintes