Control de aplicaciones basadas en Active Directory local (Kerberos) mediante Gobierno de id. de Microsoft Entra
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. La característica seguirá funcionando más allá de la fecha de interrupción; sin embargo, ya no recibirá soporte técnico después de esta fecha y puede dejar de funcionar en cualquier momento sin previo aviso.
Ofrecemos una funcionalidad similar en Microsoft Entra Cloud Sync denominada Aprovisionamiento de grupos en Active Directory que puedes 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. Puedes optar por mover toda la sincronización híbrida a Cloud Sync (si es compatible con tus necesidades). También puedes 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, puedes seguir usando Escritura diferida de grupos v1 para esta funcionalidad.
Puedes evaluar el traslado exclusivo a Sincronización en la nube, mediante el asistente de sincronización del usuario.
Escenario: administra 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 aprovechas 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. Puedes 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.
Mira 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 ti, consulta 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 de identidad híbrida.
- 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és 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, debes asegurarte 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 Grupos de seguridad creados en la nube
- Grupos de pertenencia asignada o dinámica
- Solo contienen usuarios sincronizados locales o grupos de seguridad creados en la nube
- Las cuentas de usuario locales que están sincronizadas y que son miembros de este grupo de seguridad creado en la nube pueden ser del mismo dominio o entre dominios, pero todos deben ser del mismo bosque
- Escritos con el ámbito de grupos de AD universal. El entorno local debe admitir el ámbito del grupo universal
- No 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, mediante 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 el usuario 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
Domain Admins
, se deben actualizar 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
- 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.
- 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.
- Creación de un nuevo grupo de seguridad en Microsoft Entra ID.
- Use el aprovisionamiento de grupo en AD para aprovisionar este grupo en AD.
- 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
- 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.
- 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.
- En Administración de derechos, asignar los usuarios sincronizados que necesitan acceso a la aplicación basada en AD al paquete de acceso.
- 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.
- 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á:
- Los usuarios de Microsoft Entra, que están asignados por una característica de gobernanza y después acceden a la aplicación para tener el vale Kerberos adecuado. Este vale contiene el SID de grupos existentes. Las reglas de anidamiento de grupos de AD permiten el 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
- 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.
- Si el grupo existente es
Domain Admins
,Domain Guests
,Domain Users
,Enterprise Admins
,Enterprise Key Admins
,Group Policy Creation Owners
,Key Admins
,Protected Users
oSchema 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. - 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
- 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.
- Si se usa un proxy de aplicación para permitir que los usuarios se conecten a la aplicación, configure el proxy de aplicación.
- Creación de un nuevo grupo de seguridad en Microsoft Entra ID.
- Use el aprovisionamiento de grupo en AD para aprovisionar este grupo en AD.
- 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
- Mediante Usuarios y equipos de Active Directory, agregue el nuevo grupo de AD como miembro del grupo de AD existente.
- 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.
- En Administración de derechos, asigne los usuarios sincronizados que necesitan acceso a la aplicación basada en AD al paquete de acceso, incluidos los usuarios miembros del grupo de AD existente que aún necesiten acceso.
- 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.
- Mediante Usuarios y equipos de Active Directory, quitar los miembros existentes, aparte del nuevo grupo de AD, del grupo de AD existente.
- 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