Directorio activo hybrido en Azure

Ambos nombres son equivalentes, describen un atributo que no cambia durante la vida de un objecto. Se trata de identificar de forma única en un entorno local y en Azure AD.

Por defecto se calcula codificando en Base 64 la propiedad objectGUID del servidor local, por ejemplo:

$Usuario = Get-ADuser nombreDeUsuario -Properties * -server localhost
$ImmutableID = [system.convert]::ToBase64String(([GUID]($Usuario.ObjectGUID)).tobytearray())

Realmente no debería cambiarse, pero en ocasiones nos encontramos en la necesidad de hacerlo, bien por una migración de directorio, eliminación de usuarios, replicación con errores… Si en lugar de utilizar el objectGUID utilizariamos un atributo personalizado no tendríamos este problema pero conllevaría la gestión y administración del mismo, si dentro de la empresa cada uno tiene un identificador único personal podría utilizarse para calcular el sourceAnchor.

Esta propiedad se establece durante la instalación inicial, solo si se desinstala correctamente se puede volver a establecer con un valor personalizado, desde la versión 1.1.524.0 se facilita el atributo ms-DS-ConsistencyGuidcomo atributo de los usuarios a utilizar como sourceAnchor.

Podemos visualizar la propiedad actual desde PowerShell:

Import-Module AzureAD
$O365Cred = Get-Credential
$O365Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $O365Cred -Authentication Basic -AllowRedirection
Import-PSSession $O365Session
Connect-AzureAD -Credential $O365Cred
Get-AzureADUser -ObjectId nombreUsuario@midominio.com | Select objectID, UserPrincipalName, ImmutableID

Si bien, en la documentación aparece, la posibilidad de establecer el valor en nulo para desvincular las cuentas creadas localmente de la nube mediante powershell:

Set-AzureADUser -ObjectId nombreUsuario@midominio.com -ImmutableID $null

No genera ningún resultado ni modificación del objeto, por lo menos a fecha de hoy.

Como alternativa, podemos crear un usuario temporal en nuestro directorio, sincronizar e intercambiar sourceAnchor, asignando otro incorrecto al usuario a eliminar posteriormente.

 

 

Actualizar esquema directorio activo: Windows Server 2019

Una de las tareas previas a la actualización in-place para servidores, físico y virtuales, con rol de Directorio Activo es la actualización/preparación del esquema AD. En este ejemplo se utiliza desde Server 2012 R2 a Server 2019, con el CD accesible desde la máquina en la ruta: D:\sources\adprep\adprep /forestprep ejecutamos el comando y esperamos a que finalice.

Dependiendo de la complejidad, y número de servidores, en el bosque comprobaremos que los cambios se han aplicado. Podemos realizarlo con los comandos dsquery:

dsquery * cn=schema,cn=configuration,dc=nombredominio,dc=local -scope base -attr objectVersion

Mediante powershell:

Get-ADObject "cn=schema,cn=configuration,dc=nombredominio,dc=local" -properties objectversion

Mediante la herramienta visual ADSIEdit.msc, comprobamos la revisión:

Y la versión del esquema:

Dependiendo de la versión del sistema operativo, objectVersion tendrá el valor correspondiente:

Ya podremos seguir con la actualización, comprobando el nivel funcional actual del directorio activo y replicando dede el maestro de operaciones:

D:\support\adprep>adprep /domainprep /gpprep
Adprep actualizó correctamente la información de todo el dominio.
Adprep va a actualizar la información de objeto de directiva de grupo (GPO) en el FSMO del maestro de infraestructura miservidor.dominio.local.
La operación gpprep 2 se realizó correctamente.
La operación gpprep 3 se realizó correctamente.
Adprep actualizó correctamente la información de objeto de directiva de grupo (GPO).

 

Forzar sincronización Azure AD Connect

El tiempo mínimo programable para la sincronización entre un entorno local y cloud dentro de las capacidades actuales de Azure Active Directory Connect es de 30 minutos, en ocasiones necesitaremos replicar de manera urgente cambios antes de este tiempo.

Nos aseguraremos de tener el modulo de sincronización con el comando: «Import-Module ADSync» y consultamos la configuracióna actual «Get-ADSyncScheduler«.

El comando «Start-ADSyncSyncCycle Delta» fuerza la sincronización entre el AD local y el Azure AD, realiza la comparación de ambos y solo realiza la actualización de los cambios (DELTA)

Es posible realizar una sincronización completa (FULL) con el comando: 

Start-ADSyncSyncCycle -PolicyType Initial

lo que en algunos escenarios puede llegar a demorarse dependiendo del número de objetos.

Sincronizar hora y fecha

En ocasiones es necesario utilizar otra fuente o servidor NTP diferentes al predeterminado, deberíamos sincronizar nuestro dominio principal con un servidor externo, existen diversos escenarios pero en todos ellos podemos utilizar el siguiente comando, en este caso contra servidores horarios de España:

net stop w32time
w32tm /config /syncfromflags:manual /manualpeerlist:"es.pool.ntp.org"
w32tm /config /reliable:yes
net start w32time

Podemos conocer el estado de los controladores de dominio y los equipos con los comando:

w32tm /monitor
w32tm /query /configuration

Ten en cuenta que las máquinas virtuales pueden tener activados servicios de sincronización adicional con la máquina host, que interfieren como en HyperV:

Para forzar la re sincronización utilizada el mismo comando:

w32tm /resync