Control de aplicaciones basadas en Active Directory local (Kerberos) mediante Gobierno de id. de Microsoft Entra

  • Artículo

Importante

La versión preliminar pública de Escritura diferida de grupos V2 en Sincronización de Microsoft Entra Connect ya no estará disponible después del 30 de junio de 2024. Esta característica se interrumpirá en esta fecha y ya no se admitirá en Sincronización Connect para aprovisionar grupos de seguridad en la nube en Active Directory.

Ofrecemos una funcionalidad similar en Microsoft Entra Cloud Sync denominada Aprovisionamiento de grupos en Active Directory que puede usar en lugar de Escritura diferida de grupos v2 para aprovisionar grupos de seguridad en la nube en Active Directory. Estamos trabajando para mejorar esta funcionalidad en Cloud Sync junto con otras nuevas características que estamos desarrollando en Cloud Sync.

Los clientes que usan esta característica en vista previa (GB) en Connect Sync deben cambiar su configuración de Connect Sync a Cloud Sync. Puede optar por mover toda la sincronización híbrida a Cloud Sync (si es compatible con sus necesidades). También puede ejecutar Sincronización en la nube en paralelo y mover solo el aprovisionamiento de grupos de seguridad en la nube en Active Directory a Sincronización en la nube.

Para los clientes que aprovisionan grupos de Microsoft 365 en Active Directory, puede seguir usando Escritura diferida de grupos v1 para esta funcionalidad.

Puede evaluar el traslado exclusivo a Sincronización en la nube. mediante el asistente de sincronización del usuario.

Escenario: administre aplicaciones locales con grupos de Active Directory aprovisionados desde la nube y administrados en ella. La sincronización en la nube de Microsoft Entra permite controlar completamente las asignaciones de aplicaciones en AD mientras aprovecha las características de Gobierno de Microsoft Entra ID para controlar y corregir las solicitudes relacionadas con el acceso.

Con el lanzamiento del agente de aprovisionamiento 1.1.1370.0, la sincronización en la nube ahora tiene la capacidad de aprovisionar grupos directamente en el entorno de Active Directory local. Puede utilizar las características de gobernanza de identidades para controlar el acceso a las aplicaciones basadas en AD, por ejemplo, incluyendo un grupo en un paquete de acceso de administración de derechos.

Dibujo conceptual del aprovisionamiento de grupos de Microsoft Entra Cloud Sync en AD.

Vea el vídeo de reescritura de grupos

Para obtener información general sobre la sincronización en la nube del aprovisionamiento de grupos en Active Directory y lo que puede hacer para usted, consulte el vídeo siguiente.

Requisitos previos

Los siguientes requisitos previos son necesarios para implementar este escenario.

  • Cuenta de Microsoft Entra con al menos un rol de Administrador híbrido.
  • Entorno local de Active Directory Domain Services con el sistema operativo Windows Server 2016 o posterior.
    • Se requiere para el atributo de esquema de AD: msDS-ExternalDirectoryObjectId.
  • Aprovisionamiento del agente con la versión de compilación 1.1.1367.0 o posterior.

Nota:

Los permisos para la cuenta de servicio se asignan solo durante la instalación limpia. En caso de que esté actualizando desde la versión anterior, los permisos deben asignarse manualmente mediante un cmdlet de PowerShell:

$credential = Get-Credential 

 Set-AADCloudSyncPermissions -PermissionType UserGroupCreateDelete -TargetDomain "FQDN of domain" -TargetDomainCredential $credential

Si los permisos se establecen manualmente, debe asegurarse de que las propiedades Leer, Escribir, Crear y Eliminar estén disponibles para todos los objetos de usuario y grupos descendientes.

Estos permisos no se aplican a los objetos AdminSDHolder de forma predeterminada

Cmdlets de PowerShell de gMSA del agente de aprovisionamiento de Microsoft Entra

  • El agente de aprovisionamiento debe poder comunicarse con los controladores de dominio en los puertos TCP/389 (LDAP) y TCP/3268 (catálogo global).
    • Se necesita para la búsqueda del catálogo global, para filtrar las referencias de pertenencia no válidas.
  • Microsoft Entra Connect, con la versión de compilación 2.2.8.0 o posterior
    • Se necesita para admitir la pertenencia de usuarios locales sincronizados mediante Microsoft Entra Connect.
    • Se necesita para sincronizar AD:user:objectGUID con Microsoft Entra ID:user:onPremisesObjectIdentifier.

Grupos compatibles

En este escenario, solo se admiten los siguientes grupos:

  • solo se admiten los grupos de seguridad creados en la nube
  • estos grupos pueden tener una pertenencia asignada o dinámica
  • estos grupos solo pueden contener usuarios sincronizados locales o grupos de seguridad creados en la nube
  • las cuentas de usuario locales que se sincronizan y son miembros de este grupo de seguridad creado en la nube, pueden ser del mismo dominio o de varios distintos, pero todas deben ser del mismo bosque
  • estos grupos se vuelven a escribir con el ámbito de grupos de AD universal. El entorno local debe admitir el ámbito del grupo universal
  • no se admiten grupos de más de 50 000 miembros
  • cada grupo anidado secundario directo cuenta como un miembro del grupo de referencia

Escenarios admitidos

En las secciones siguientes se describen los escenarios que se admiten con el aprovisionamiento del grupo de sincronización en la nube.

Configurar escenarios admitidos

Si quiere controlar si un usuario puede conectarse a una aplicación de Active que use la autenticación de Windows, puede usar el proxy de aplicación y un grupo de seguridad de Microsoft Entra ID. Si una aplicación comprueba las pertenencias a grupos de AD de un usuario, a través de Kerberos o LDAP, puede usar el aprovisionamiento de grupos de sincronización en la nube para asegurarse de que un usuario de AD tenga esas pertenencias a grupos antes de que acceda a las aplicaciones.

En las secciones siguientes se describen dos opciones de escenario compatibles con el aprovisionamiento de grupos de sincronización en la nube. Las opciones de escenario están diseñadas para asegurarse de que los usuarios asignados a la aplicación tienen pertenencias a grupos cuando se autentican en la aplicación.

  • Crear un nuevo grupo y actualizar la aplicación, si ya existe, para comprobar el nuevo grupo o
  • Crear un nuevo grupo y actualizar los grupos existentes, que la aplicación estaba comprobando, para incluir el nuevo grupo como miembro

Antes de empezar, asegúrese de que es administrador de dominio en el dominio donde está instalada la aplicación. Asegúrese de que puede iniciar sesión en un controlador de dominio, o bien de que tiene instaladas en su PC Windows las herramientas de administración remota del servidor para la administración de Active Directory Domain Services (AD DS).

Configurar la nueva opción de grupos

En esta opción de escenario, actualizará la aplicación para comprobar el SID, el nombre o el nombre distintivo (DN) de los nuevos grupos creados por el aprovisionamiento del grupo de sincronización en la nube. Este escenario es aplicable a lo siguiente:

  • implementaciones para nuevas aplicaciones que se conectan a AD DS por primera vez.
  • nuevas cohortes de usuarios que acceden a la aplicación.
  • para la modernización de aplicaciones, para reducir la dependencia de los grupos de AD DS existentes. Las aplicaciones que actualmente comprueban la pertenencia al grupo de Domain Admins deberán actualizarse para comprobar también si hay un grupo de AD recién creado.

Siga estos pasos para que las aplicaciones usen nuevos grupos.

Crear una aplicación y un grupo

  1. Desde el Centro de administración de Microsoft Entra, cree una aplicación en Microsoft Entra ID que represente la aplicación basada en AD y configure la aplicación para requerir la asignación de usuarios.
  2. Si el proxy de aplicación se usará para permitir que los usuarios se conecten a la aplicación, configure el proxy de aplicación.
  3. Creación de un nuevo grupo de seguridad en Microsoft Entra ID.
  4. Use el aprovisionamiento de grupo en AD para aprovisionar este grupo en AD.
  5. Inicie Usuarios y equipos de Active Directory y espere a que se cree el nuevo grupo de AD resultante en el dominio de AD. Cuando esté presente, registre el nombre distintivo (DN), el dominio, el nombre de cuenta y el SID del nuevo grupo de AD.

Configurar la aplicación para usar un nuevo grupo

  1. Si la aplicación usa AD a través de LDAP, configure la aplicación con el nombre distintivo (DN) del nuevo grupo de AD. Si la aplicación usa AD a través de Kerberos, configure la aplicación con el SID o el nombre de dominio y cuenta del nuevo grupo de AD.
  2. Crear un paquete de acceso. Agregar la aplicación de #1, el grupo de seguridad de #3, como recursos en el paquete de acceso. Configurar una directiva de asignación directa en el paquete de acceso.
  3. En Administración de derechos, asignar los usuarios sincronizados que necesitan acceso a la aplicación basada en AD al paquete de acceso.
  4. Esperar a que el nuevo grupo de AD se actualice con los nuevos miembros. Mediante Usuarios y equipos de Active Directory, confirmar que los usuarios correctos están presentes como miembros del grupo.
  5. En la supervisión de su dominio de AD, permitir únicamente a la cuenta gMSA que ejecuta el agente de aprovisionamiento, la autorización para cambiar la pertenencia al nuevo grupo de AD.

Ahora puede controlar el acceso a la aplicación de AD a través de este nuevo paquete de acceso.

Configurar la opción de grupos existentes

En esta opción de escenario, agregará un nuevo grupo de seguridad de AD como miembro de un grupo anidado de un grupo existente. Este escenario es aplicable a las implementaciones de aplicaciones que tienen una dependencia codificada de forma dura en un nombre de cuenta de grupo determinado, SID o nombre distintivo (DN).

El anidamiento de ese grupo en las aplicaciones existentes del grupo de AD permitirá:

  • Que los usuarios de Microsoft Entra asignados por una característica de gobernanza (y que posteriormente accedan a la aplicación) tengan un vale de kerberos adecuado. Este vale contendrá el SID de grupos existentes. Las reglas de anidamiento de grupos de AD permiten este anidamiento.

Si la aplicación utiliza LDAP y sigue la pertenencia a grupos anidados, la aplicación verá que los usuarios de Microsoft Entra tienen el grupo existente como una de sus pertenencias.

Determinar la idoneidad del grupo existente

  1. Inicie Usuarios y equipos de Active Directory y registre el nombre distintivo (DN), el tipo y el ámbito del grupo de AD existente que usa la aplicación.
  2. Si el grupo existente es Domain Admins, Domain Guests, Domain Users, Enterprise Admins, Enterprise Key Admins, Group Policy Creation Owners, Key Admins, Protected Users o Schema Admins, deberá cambiar la aplicación para que use un nuevo grupo, como se ha descrito anteriormente, ya que estos grupos no se pueden usar en la sincronización en la nube.
  3. Si el grupo tiene un ámbito global, cambie el grupo para que tenga un ámbito universal. Un grupo global no puede tener grupos universales como miembros.

Crear una aplicación y un grupo

  1. Desde el Centro de administración de Microsoft Entra, cree una aplicación en Microsoft Entra ID que represente la aplicación basada en AD y configure la aplicación para requerir la asignación de usuarios.
  2. Si el proxy de aplicación se usará para permitir que los usuarios se conecten a la aplicación, configure el proxy de aplicación.
  3. Creación de un nuevo grupo de seguridad en Microsoft Entra ID.
  4. Use el aprovisionamiento de grupo en AD para aprovisionar este grupo en AD.
  5. Inicie Usuarios y equipos de Active Directory y espere a que se cree el nuevo grupo de AD resultante en el dominio de AD. Cuando esté presente, registre el nombre distintivo (DN), el dominio, el nombre de cuenta y el SID del nuevo grupo de AD.

Configurar la aplicación para usar un nuevo grupo

  1. Mediante Usuarios y equipos de Active Directory, agregue el nuevo grupo de AD como miembro del grupo de AD existente.
  2. Crear un paquete de acceso. Agregar la aplicación de #1, el grupo de seguridad de #3, como recursos en el paquete de acceso. Configurar una directiva de asignación directa en el paquete de acceso.
  3. En Administración de derechos, asignar los usuarios sincronizados que necesitan acceso a la aplicación basada en AD al paquete de acceso. Esto incluye los miembros de usuario del grupo de AD existente que seguirán necesitando acceso.
  4. Esperar a que el nuevo grupo de AD se actualice con los nuevos miembros. Mediante Usuarios y equipos de Active Directory, confirmar que los usuarios correctos están presentes como miembros del grupo.
  5. Mediante Usuarios y equipos de Active Directory, quitar los miembros existentes, aparte del nuevo grupo de AD, del grupo de AD existente.
  6. En la supervisión de su dominio de AD, permitir únicamente a la cuenta gMSA que ejecuta el agente de aprovisionamiento, la autorización para cambiar la pertenencia al nuevo grupo de AD.

A continuación, se podrá controlar el acceso a la aplicación de AD a través de este nuevo paquete de acceso.

Solucionar problemas

Un usuario que sea miembro del nuevo grupo de AD y se encuentre en un PC Windows que ya haya iniciado sesión en un dominio de AD, podría tener un vale existente emitido por un controlador de dominio de AD que no incluya la pertenencia al nuevo grupo de AD. Esto se debe a que es posible que el vale se haya emitido antes de que el aprovisionamiento del grupo de sincronización en la nube los agregue al nuevo grupo de AD. El usuario no podrá presentar el vale para acceder a la aplicación, por lo que deberá esperar a que expire y se emita uno nuevo, o bien purgar sus vales, cerrar la sesión y volver a entrar en el dominio. Consulte el comando klist para obtener más información.

Clientes existentes de escritura diferida de grupo de Microsoft Entra Connect v2

Si usa la escritura diferida de grupo de Microsoft Entra Connect v2, tendrá que migrar a una sincronización en la nube aprovisionada en AD antes de poder aprovechar el aprovisionamiento de grupo de sincronización en la nube. Consulte Migrar la escritura diferida de grupos de Microsoft Entra Connect Sync V2 a Microsoft Entra Cloud Sync

Pasos siguientes