Compartilhar via


Controlar aplicativos baseados no Active Directory local (Kerberos) usando o Microsoft Entra ID Governance

Importante

A visualização pública do grupo Write-back 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 receberá mais suporte no Connect Sync para provisionar grupos de segurança de nuvem para o Active Directory.

Oferecemos uma funcionalidade semelhante no Microsoft Entra Cloud Sync chamada Provisionamento de grupos para o Active Directory que pode ser usada em vez do grupo Writeback v2 para provisionar grupos de segurança de nuvem para o Active Directory. Estamos trabalhando para aprimorar essa funcionalidade no Cloud Sync, juntamente com outros novos recursos que estamos desenvolvendo no Cloud Sync.

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

Para clientes que provisionam grupos do Microsoft 365 para o Active Directory, é possível continuar usando o Group Writeback v1 para essa capacidade.

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

Cenário: gerenciar aplicativos locais com grupos do Active 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, aproveitando os recursos de Governança do Microsoft Entra ID para controlar e corrigir quaisquer solicitações relacionadas ao acesso.

Com a versão do agente de provisionamento 1.1.1370.0, a sincronização de nuvem agora tem a capacidade de provisionar grupos diretamente para seu ambiente do Active Directory local. Com isso, você pode usar recursos de governança de identidade para controlar o acesso a aplicativos baseados em AD, como incluir um grupo em um pacote de acesso de gerenciamento de direitos.

Desenho conceitual do Provisionamento de Grupo do Microsoft Entra Cloud Sync no AD.

Assista ao vídeo de write-back do grupo

Para obter uma excelente visão geral do provisionamento de grupo de sincronização na nuvem para o Active 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 Híbrido.
  • Ambiente local do Active Directory Domain Services com o sistema operacional Windows Server 2016 ou posterior.
    • Necessário para o atributo de esquema do AD – msDS-ExternalDirectoryObjectId.
  • Agente de provisionamento com a versão de build 1.1.1367.0 ou posterior.

Observação

As permissões para a conta de serviço são atribuídas somente 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 a definição todas as propriedades de Leitura, Gravação, Criação e Exclusão para todos os Grupos e objetos de usuário descendentes.

Essas permissões não são aplicadas a objetos AdminSDHolder por padrão

Cmdlets do PowerShell do Agente de Provisionamento gMSA do Microsoft Entra

  • O agente de provisionamento deve ser capaz de se comunicar com os 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 versão de build 2.2.8.0 ou posterior.
    • Necessário para dar suporte à associação de usuário local sincronizada usando o Microsoft Entra Connect.
    • Necessário para sincronizar o AD:user:objectGUID ao Microsoft Entra ID:user:onPremisesObjectIdentifier.

Grupos com suporte

Para esse cenário, há suporte apenas para os seguintes grupos:

  • há suporte apenas para 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 locais e/ou grupos de segurança adicionais criados na nuvem
  • as contas de usuário locais que são sincronizadas e são membros desse grupo de segurança criado na nuvem podem ser do mesmo domínio ou entre domínios, mas todas elas devem ser da mesma floresta
  • o write-back desses grupos são feitos com o escopo de grupos AD universal. Seu ambiente local deve dar suporte ao escopo do grupo universal
  • não há suporte para grupos com mais de 50 mil membros
  • cada grupo aninhado filho direto conta como um membro no grupo de referência

Cenários com suporte

As seções a seguir discutem os cenários com suporte para o provisionamento de grupo de sincronização de nuvem.

Configurar cenários com suporte

Se você quiser controlar se um usuário é capaz de se conectar a um aplicativo do Active Directory que usa a autenticação do Windows, você pode usar o Proxy de Aplicativo e um grupo de segurança do Microsoft Entra ID. 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 de nuvem para garantir que um usuário do AD tenha essas associações de grupo antes do usuário acessar os aplicativos.

As seções a seguir discutem os cenários com suporte para o provisionamento de grupo de sincronização de nuvem. As opções de cenário servem para garantir que os usuários atribuídos ao aplicativo tenham associações de grupo quando se autenticarem 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 que o aplicativo estava verificando para incluir o novo grupo como membro

Antes de começar, verifique se você é um administrador de domínio no domínio em que o aplicativo está instalado. Verifique se você pode entrar em um controlador de domínio ou se tem as ferramentas de Administração de Servidor Remoto para administração do Active Directory Domain Services (AD DS) instaladas no computador Windows.

Configurar a opção de novos grupos

Nessa opção de cenário, você atualizará o aplicativo para verificar o SID, nome ou nome diferenciado de novos grupos criados pelo provisionamento do grupo de sincronização de nuvem. Esse cenário é aplicável a:

  • implantações para novos aplicativos conectados ao AD DS pela primeira vez.
  • novas coortes de usuários que acessam o aplicativo.
  • para modernização de aplicativos, para reduzir a dependência de grupos existentes do AD DS. Os aplicativos que atualmente verificam se há associação ao grupo Domain Admins precisarão ser atualizados para verificar também 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

  1. Usando o Centro de administração do Microsoft Entra, crie um aplicativo no Microsoft Entra ID representando o aplicativo baseado no AD e configure o aplicativo para exigir a 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. Criar um grupo de segurança em Microsoft Entra ID.
  4. Use o Provisionamento de grupo para o AD para provisionar esse grupo ao AD.
  5. Inicie Usuários e Computadores do Active Directory e aguarde até que o novo grupo do AD resultante seja criado no domínio do AD. Quando estiver presente, registre o nome diferenciado, 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 usar o AD via LDAP, configure o aplicativo com o nome diferenciado 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 do n° 1 e o grupo de segurança do n° 3 como recursos no Pacote de Acesso. 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 em 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 Active Directory, confirme se os usuários corretos estão presentes como membros do grupo.
  5. No monitoramento de domínio do AD, permita que apenas a conta gMSA que executa o agente de provisionamento tenha autorização para alterar a associação no novo grupo do AD.

Em seguida, você poderá controlar o acesso ao aplicativo do AD por meio desse novo pacote de acesso.

Configurar a opção de grupos existente

Nessa opção de cenário, você adicionará um novo grupo de segurança do AD como um membro de grupo aninhado de um grupo existente. Esse cenário é aplicável a implantações para aplicativos que tenham uma dependência codificada em um nome de conta de grupo específico, SID ou nome diferenciado.

Aninhar esse grupo no grupo de aplicativos existente do AD irá permitir que:

  • Os usuários do Microsoft Entra ID, atribuídos por um recurso de governança e, posteriormente, acessem o aplicativo, tenham um tíquete Kerberos apropriado. Esse tíquete irá conter o SID dos grupos existentes. Esse aninhamento é permitido pelas regras de aninhamento de grupo do AD.

Se o aplicativo usar o LDAP e seguir a associação de grupo aninhada, o aplicativo verá os usuários do Microsoft Entra ID como tendo o grupo existente como uma de suas associações.

Determinar a qualificação do grupo existente

  1. Inicie Usuários e Computadores do Active Directory e registre o nome diferenciado, o tipo e o escopo do grupo do AD existente usado pelo aplicativo.
  2. Se o grupo existente for Domain Admins, Domain Guests, Domain Users, Enterprise Admins, Enterprise Key Admins, Group Policy Creation Owners, Key Admins, Protected Users ou Schema 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 de nuvem.
  3. Se o escopo do grupo for Global, altere o grupo para ter um 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 no AD e configure o aplicativo para exigir a atribuição de usuário.
  2. Configure o proxy de aplicativo se ele for usado para permitir que os usuários se conectem ao aplicativo.
  3. Criar um grupo de segurança em Microsoft Entra ID.
  4. Use o Provisionamento de grupo para o AD para provisionar esse grupo ao AD.
  5. Inicie Usuários e Computadores do Active 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 diferenciado, 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 Active Directory, adicione o novo grupo do AD como membro do grupo do AD existente.
  2. Crie um pacote de acesso. Adicione o aplicativo do n° 1 e o grupo de segurança do n° 3 como recursos no Pacote de Acesso. 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 em AD ao pacote de acesso. Isso inclui todos os membros do usuário do grupo existente do AD que continuarão precisando de acesso.
  4. Aguarde até que o novo grupo do AD seja atualizado com os novos membros. Usando usuários e computadores do Active Directory, confirme se os usuários corretos estão presentes como membros do grupo.
  5. Usando Usuários e Computadores do Active Directory, remova os membros existentes do grupo existente do AD, menos o novo grupo do AD.
  6. No monitoramento de domínio do AD, permita que apenas a conta gMSA que executa o agente de provisionamento tenha autorização para alterar a associação no novo grupo do AD.

Em seguida, você poderá controlar o acesso ao aplicativo do AD por meio desse novo pacote de acesso.

Solução de problemas

Um usuário que for membro do novo grupo do AD e estiver em um computador Windows já conectado a um domínio do AD poderá ter um tíquete existente emitido por um controlador de domínio do AD que não inclua a nova associação de grupo do AD. Isso ocorre porque o tíquete pode ter sido emitido antes de o provisionamento do grupo de sincronização de nuvem ter os adicionado ao novo grupo do AD. O usuário não poderá apresentar o tíquete para acesso ao aplicativo e, portanto, deverá aguardar o tíquete expirar e um novo ser emitido, ou limpar seus tíquetes, fazer logoff e fazer logon novamente no domínio. Consulte o comando klist para obter mais detalhes.

Clientes existentes do write-back de grupo do Microsoft Entra Connect v2

Se você estiver usando o write-back v2 do grupo do Microsoft Entra Connect, precisará migrar do provisionamento de sincronização de nuvem para o AD antes de poder aproveitar o provisionamento do grupo de sincronização de nuvem. Confira Migrar o grupo de write-back v2 do Microsoft Entra Connect Sync para o Microsoft Entra Cloud Sync

Próximas etapas