Ayer termine de instalar y configurar Azure AD connect. Para los que no lo sepáis, Azure AD connect es el programa que se utiliza para sincronizar objetos de tu directorio activo local con el directorio activo de azure. Podéis acceder a la estupenda documentación de Microsoft aquí.
El caso es que después de terminar la configuración, estuve repasando que las primeras sincronizaciones fueran correctas cuando vi que aparecía una tarea con errores en Azure AD sync service. El fallo era el siguiente:
Como podéis ver, esta tarea de export, que ya os voy diciendo que era una sincronización de contraseñas, falla por un problema de permisos. La verdad es que era un poco confuso, ya que había seguido la documentación de Microsoft para la implementación al pie de la letra y cumplido todos los prerrequisitos. ¿Se me escapaba algo?
Al final, la respuesta era bastante sencilla. Este directorio activo no lo desplegué yo, así que hay algunas cosillas “heredadas”. Una de ellas es que una Unidad Organizativa concreta tenia modificada la seguridad. Básicamente, alguien había desactivado la herencia en dicha Unidad Organizativa. La desactivación de la herencia en la OU, se propago a los objetos contenidos en esta, básicamente usuarios, pero, además, al mover los usuarios fuera de dicha OU, los usuarios mantenían la herencia desactivada.
Para volver a activar la herencia en los usuarios que la tienen desactivada, primero necesitáis encontrar dichos usuarios. Podéis hacerlo fácilmente con este script en powershell:
$UOs = @()
$estadoUsuario = @()
$UOs = Get-ADOrganizationalUnit -Filter * -Properties * | sort canonicalname | select distinguishedname, canonicalname
$UOs += Get-ADObject -SearchBase (Get-ADDomain).distinguishedname -SearchScope OneLevel -LDAPFilter '(objectClass=container)' -Properties * | sort canonicalname | select distinguishedname, canonicalname
foreach($UO in $UOs)
{
"Comprobando - " + $UO.distinguishedname + " ..."
$estadoUsuario += Get-ADUser -Filter * -SearchBase $UO.distinguishedname -SearchScope OneLevel -Properties * | where {($_.nTSecurityDescriptor.AreAccessRulesProtected -eq $true) -and ($_.enabled -eq $true)} | select @{n='OU';e={$UO.distinguishedname}}, displayname, userprincipalname,samAccountName, @{n='Herencia Deshabilitada';e={$_.nTSecurityDescriptor.AreAccessRulesProtected}}
}
$estadoUsuario | out-gridview
Tened en cuenta, que por ejemplo la cuenta de Administrador tiene la herencia deshabilitada por defecto (así que no la habilitéis):
Una vez que sabéis el o los usuarios que tienen la herencia deshabilitada, podéis habilitar la herencia de 2 formas. La primera, consiste en usar el complemento de usuarios y equipos de directorio activo, y pulsando con el botón derecho sobre el usuario, elegir propiedades:
A continuación, pulsaremos en el botón de avanzada:
Ahora solo tendremos que pulsar en el botón de habilitar herencia y aceptar todos los cuadros de dialogo que aparezcan.
Eso habilita la herencia para ese usuario y debería dejar de darnos problemas en la replicación. La otra forma es hacerlo con powershell, para lo cual usaremos el siguiente código:
$nombreUsuario = "user1" #<-- cambiar esta variable por el nombre del usuario
$usuario = Get-ADUser $nombreUsuario -Properties *
$usuario.nTSecurityDescriptor.SetAccessRuleProtection($false,$true)
$rutaAD = "AD:\" + $usuario.DistinguishedName
Set-Acl -AclObject $usuario.ntsecurityDescriptor -path $rutaAD
Y listo.
Un saludo a todos!
Muchas gracias! Me aparecía el mismo error y no daba con la tecla :)
ResponderEliminarObrigado, muito legal o artigo e resolveu meu problema com poucos minutos!!
ResponderEliminarEstimado , tengo una duda , si tengo al menos 10 cuentas de usuarios que pertenecen al grupo administradores , conviene habilitar la herencia o dejarla por default desactivada?
ResponderEliminar