Compartir a través de

Solucionar problemas de error de derechos de acceso insuficientes

  • Artículo

Problema

El aprovisionamiento de usuarios entrantes en Active Directory funciona según lo previsto para la mayoría de los usuarios. Pero, para algunos usuarios, los registros de aprovisionamiento muestran el siguiente error:

ERROR: InsufficientAccessRights-SecErr: The user has insufficient access rights.. Access is denied. \nError Details: Problem 4003 - INSUFF_ACCESS_RIGHTS. 
OR

ERROR: 
"Message":"The user has insufficient access rights.",
"ResponseResultCode":"InsufficientAccessRights",
"ResponseErrorMessage":"00002098: SecErr: DSID-03150F94, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0",
The user has insufficient access rights.

Los registros de aprovisionamiento muestran el código de error: HybridSynchronizationActiveDirectoryInsufficientAccessRights.

Causa

De forma predeterminada, la cuenta provAgentgMSA$ de GMSA del agente de aprovisionamiento tiene permiso de lectura y escritura para todos los objetos de usuario del dominio. Hay dos causas posibles que podrían provocar el error anterior.

  • Causa 1: el objeto de usuario forma parte de una unidad organizativa que no hereda los permisos de nivel de dominio.
  • Causa 2: el objeto de usuario pertenece a un grupo de Active Directory protegido. Por diseño, los objetos de usuario se rigen por los permisos asociados a un contenedor especial denominado AdminSDHolder. Esto explica por qué la cuenta provAgentgMSA$ no puede actualizar estas cuentas que pertenecen a grupos de Active Directory protegidos. Puede intentar invalidar y proporcionar explícitamente el acceso de escritura de la cuenta de provAgentgMSA$ a las cuentas de usuario, pero eso no funcionará. A fin de proteger las cuentas de usuario con privilegios de un uso incorrecto de los permisos delegados, hay un proceso en segundo plano denominado SDProp que se ejecuta cada 60 minutos y garantiza que los usuarios que pertenecen a un grupo protegido siempre se administren mediante permisos definidos en el contenedor AdminSDHolder. Incluso el enfoque de agregar la cuenta provAgentgMSA$ al grupo de administrador del dominio no funcionará.

Resolución

En primer lugar, confirme lo que está causando el problema. Para comprobar si la causa 1 es el origen del problema:

  1. Abra la consola de administración de usuarios y equipos de Active Directory.
  2. Seleccione la unidad organizativa asociada al usuario.
  3. Haga clic con el botón derecho y vaya a Propiedades -> Seguridad -> Avanzada. Si se muestra el botón Habilitar herencia, confirma que Cause-1 es el origen del problema.
  4. Haga clic en Habilitar herencia para que los permisos de nivel de dominio se apliquen a esta unidad organizativa.

    Nota

    Recuerde comprobar toda la jerarquía desde el nivel de dominio hasta la unidad organizativa que contiene las cuentas afectadas. Todas las unidades organizativas o contenedores primarios deben tener habilitada la herencia, por lo que los permisos aplicados en el nivel de dominio pueden pasar en cascada al objeto final.

Si la causa 1 no es el origen del problema, la causa 2 podría serlo. Hay dos opciones de resolución posibles.

Opción 1: Quitar el usuario afectado del grupo de AD protegido para buscar la lista de usuarios regidos por este permiso de AdminSDHolder, Cx puede invocar el siguiente comando:

Get-AdObject -filter {AdminCount -gt 0}

Artículos de referencia:

  • Este es un script de PowerShell de ejemplo que se puede usar para borrar la marca AdminCount y volver a habilitar la herencia en los usuarios afectados.
  • Siga los pasos documentados en este artículo: Buscar cuentas huérfanas (cuentas que no forman parte de un grupo protegido, pero que aún así tienen la marca AdminCount establecida en 1).

La opción 1 podría no funcionar siempre

Hay un proceso denominado Proceso de propagación de descriptores de seguridad (SDPROP) que se ejecuta cada hora en el controlador de dominio que contiene el rol FSMO del emulador de PDC. Este proceso es el que establece el atributo AdminCount en 1. La función principal del SDPROP es proteger las cuentas de Active Directory con privilegios elevados, lo que garantiza que no se puedan eliminar ni se pueda modificar sus derechos, de forma accidental o intencional, por usuarios o procesos con menos privilegios. Hay un proceso denominado Proceso de propagación de descriptores de seguridad (SDPROP) que se ejecuta cada hora en el controlador de dominio que contiene el rol FSMO del emulador de PDC. Este proceso es el que establece el atributo AdminCount en 1. La función principal de SDPROP es proteger las cuentas de Active Directory con privilegios elevados. El proceso SDPROP garantiza que las cuentas no se puedan eliminar o tener derechos modificados accidentalmente o intencionadamente por los usuarios o procesos con menos privilegios.

Artículos de referencia que explican el motivo en detalle:

Opción 2: modificar los permisos predeterminados del contenedor AdminSDHolder

Si la opción 1 no es factible y no funciona según lo previsto, pida a Cx que compruebe con el administrador de AD y con los administradores de seguridad, si pueden modificar los permisos predeterminados del contenedor AdminSDHolder. En este artículo se explica la importancia del contenedor AdminSDHolder. Una vez que Cx obtiene la aprobación interna para actualizar los permisos del contenedor AdminSDHolder, hay dos maneras de actualizar los permisos.

  • Usar ADSIEdit como se describe en este artículo.
  • Usar el script de línea de comandos DSACLS. Este es un script de ejemplo que se podría usar como punto de partida y Cx puede ajustarlo según sus requisitos.

$dcFQDN = "<FQDN Of The Nearest RWDC Of Domain>"
$domainDN = "<Domain Distinguished Name>"
$domainNBT = "<Domain NetBIOS Name>"
$dsaclsCMD = "DSACLS '\\$dcFQDN\CN=AdminSDHolder,CN=System,$domainDN' /G '$domainNBT\provAgentgMSA$:RPWP;<Attribute To Write To>'"
Invoke-
Expression $dsaclsCMD | Out-Null

Si Cx necesita más ayuda para solucionar problemas de permisos de AD local, póngase en contacto con el equipo de soporte técnico de Windows Server. En este artículo sobre los problemas de AdminSDHolder con Microsoft Entra Connect, se incluyen más ejemplos sobre el uso de DSACLS.

Opción 3: asignar control total a la cuenta provAgentgMSA

Asigne permisos de control total a la cuenta provAgentGMSA. Se recomienda este paso si hay problemas con el traslado de un objeto de usuario de una unidad organizativa de contenedor a otra cuando el objeto de usuario no pertenece a un grupo de usuarios protegido.

En este escenario, pida a Cx que complete los pasos siguientes y vuelva a probar la operación de traslado.

  1. Inicie sesión en el controlador de dominio de AD como administrador.
  2. Abra la línea de comandos de PowerShell con run como administrador.
  3. En el símbolo del sistema de PowerShell, ejecute el siguiente comando de DSACLS que concede control total o completo genérico a la cuenta de GMSA del agente de aprovisionamiento. dsacls "dc=contoso,dc=com" /I:T /G "CN=provAgentgMSA,CN=Managed Service Accounts,DC=contoso,DC=com:GA"

Reemplace dc=contoso,dc=com por el nodo raíz o el contenedor de unidad organizativa adecuado. Si usa una cuenta de GMSA personalizada, actualice el valor de DN de provAgentgMSA.

Opción 4: omitir la cuenta de GMSA y usar la cuenta de servicio creada manualmente Esta opción solo se debe usar como solución temporal para desbloquear hasta que se investigue y resuelva el problema del permiso de GMSA. Se recomienda usar la cuenta de GMSA. Puede establecer la opción del Registro para omitir la configuración de GMSA y volver a configurar el agente de aprovisionamiento de Microsoft Entra Connect para usar una cuenta de servicio creada manualmente con los permisos adecuados.

Pasos siguientes