Solución de Problemas 20 min de lectura

Active Directory y Microsoft Entra ID: guía práctica de diagnóstico y resolución para helpdesk (2026)

Guía práctica para equipos de helpdesk sobre Active Directory y Microsoft Entra ID. Cubre bloqueos de cuentas, sincronización con Entra Connect, unión híbrida, GPO, acceso condicional y scripts de PowerShell listos para usar en 2026.

Editorial Team

Introducción: Active Directory sigue siendo el corazón de la identidad corporativa

Si llevas tiempo trabajando en helpdesk o administración de TI, esto no te sorprenderá: Active Directory (AD) sigue siendo el pilar fundamental sobre el que se construye la identidad corporativa en la mayoría de las organizaciones. Y no parece que vaya a cambiar pronto.

Ahora bien, en 2026 la cosa se ha complicado bastante. Con la transición acelerada hacia Microsoft Entra ID (lo que antes conocíamos como Azure Active Directory), el panorama de identidad ya no es tan sencillo como antes.

La realidad es que las organizaciones viven en un mundo híbrido. Cuentas de usuario sincronizadas entre AD local y Entra ID, dispositivos unidos a dominios que también necesitan registro en la nube, directivas de grupo conviviendo con políticas de acceso condicional... y una cantidad creciente de aplicaciones SaaS que dependen de autenticación federada. Honestamente, a veces se siente como hacer malabares con demasiadas pelotas a la vez.

Esta guía está pensada para técnicos de helpdesk y administradores de TI (tanto junior como senior) que necesitan dominar el diagnóstico y resolución de problemas en estos entornos. Vamos a cubrir desde los bloqueos de cuentas más básicos hasta la configuración de Entra Connect Sync, pasando por la unión híbrida de dispositivos y las políticas de acceso condicional. Todo con comandos prácticos, scripts de PowerShell y flujos de trabajo que puedes aplicar desde el primer día.

Así que, vamos al grano.

Bloqueos de cuentas en Active Directory: el pan de cada día del helpdesk

Por qué las cuentas se bloquean (y por qué es más complicado de lo que parece)

El bloqueo de cuentas es, sin exageración, el ticket más común en cualquier helpdesk que gestione Active Directory. A primera vista parece sencillo — el usuario se equivoca de contraseña y la cuenta se bloquea — pero la realidad es que las causas subyacentes suelen ser mucho más variadas de lo que uno esperaría:

  • Credenciales obsoletas en servicios: Un servicio de Windows, una tarea programada o una aplicación que almacena las credenciales del usuario y sigue intentando autenticarse con la contraseña antigua después de un cambio. Este es probablemente el causante más silencioso.
  • Sesiones de escritorio remoto desconectadas: Si un usuario cambia su contraseña pero tiene una sesión RDP desconectada en un servidor, esa sesión intentará renovar el ticket Kerberos con la contraseña antigua.
  • Dispositivos móviles con Exchange ActiveSync: El teléfono del usuario sigue intentando sincronizar el correo con la contraseña anterior. Un clásico que genera mucha frustración (y muchas llamadas al helpdesk).
  • Unidades de red mapeadas con credenciales almacenadas: El Administrador de credenciales de Windows puede guardar contraseñas viejas que provocan intentos fallidos silenciosos.
  • Ataques de fuerza bruta: No hay que descartarlo. Un número anómalo de bloqueos puede indicar un intento de ataque real.

Localización del origen del bloqueo paso a paso

El objetivo aquí es claro: encontrar exactamente qué equipo o servicio está generando los intentos fallidos de autenticación. Este es el flujo de trabajo que recomiendo:

Paso 1: Identificar el controlador de dominio que procesó el bloqueo

# Usar PowerShell para encontrar el DC que bloqueó la cuenta
# Requiere el módulo ActiveDirectory
Import-Module ActiveDirectory

# Buscar eventos de bloqueo (Event ID 4740) en el PDC Emulator
$pdcEmulator = (Get-ADDomain).PDCEmulator
$usuario = "nombre.usuario"

Get-WinEvent -ComputerName $pdcEmulator -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4740
} -MaxEvents 50 | Where-Object {
    $_.Properties[0].Value -eq $usuario
} | Select-Object TimeCreated,
    @{N='Usuario';E={$_.Properties[0].Value}},
    @{N='OrigenBloqueo';E={$_.Properties[1].Value}} |
    Format-Table -AutoSize

El campo OrigenBloqueo (Caller Computer Name) te dirá exactamente desde qué equipo se están originando los intentos fallidos. Esa es la pieza clave del rompecabezas.

Paso 2: Investigar el equipo de origen

Una vez que ya sabes qué equipo es el culpable, toca buscar qué está generando las autenticaciones fallidas:

# En el equipo de origen, buscar credenciales almacenadas
cmdkey /list

# Eliminar credenciales obsoletas
cmdkey /delete:targetname

# Verificar servicios que ejecutan con la cuenta del usuario
Get-WmiObject Win32_Service | Where-Object {
    $_.StartName -like "*nombre.usuario*"
} | Select-Object Name, StartName, State

# Verificar tareas programadas con credenciales del usuario
Get-ScheduledTask | Where-Object {
    $_.Principal.UserId -like "*nombre.usuario*"
} | Select-Object TaskName, TaskPath, State

Paso 3: Revisar el Administrador de credenciales de Windows

Instruye al usuario para que abra el Panel de control > Administrador de credenciales y elimine cualquier entrada con credenciales antiguas. Presta especial atención a las de tipo "Credenciales de Windows" y "Credenciales genéricas" relacionadas con recursos corporativos. Es impresionante la cantidad de veces que esto resuelve el problema.

Configuración óptima de la política de bloqueo de cuentas

Una buena política de bloqueo equilibra seguridad y productividad. Estas son las recomendaciones que mejor funcionan en 2026:

  • Umbral de bloqueo de cuenta: Entre 10 y 15 intentos fallidos. Menos de 10 genera demasiados tickets innecesarios; más de 15 podría ser demasiado permisivo frente a ataques.
  • Duración del bloqueo: 30 minutos para usuarios estándar. Para cuentas privilegiadas (administradores), configurar en 0 — es decir, requiere desbloqueo manual.
  • Restablecer el contador después de: 30 minutos. Debe ser igual o menor que la duración del bloqueo.

Para verificar la política actual:

# Ver la política de bloqueo de cuentas actual del dominio
Get-ADDefaultDomainPasswordPolicy | Select-Object `
    LockoutThreshold,
    LockoutDuration,
    LockoutObservationWindow

# Para políticas de contraseña detalladas (Fine-Grained Password Policies)
Get-ADFineGrainedPasswordPolicy -Filter * | Select-Object `
    Name,
    Precedence,
    LockoutThreshold,
    LockoutDuration,
    LockoutObservationWindow,
    AppliesTo

Microsoft Entra Connect Sync: la columna vertebral de la identidad híbrida

Fecha límite crítica: septiembre de 2026

Esto es algo que todo administrador y equipo de helpdesk debe tener muy presente: todos los servicios de sincronización de Microsoft Entra Connect Sync dejarán de funcionar el 30 de septiembre de 2026 si no se está ejecutando la versión 2.5.79.0 o superior. No es una sugerencia — es obligatorio.

Para verificar tu versión actual:

# Verificar la versión de Entra Connect instalada
Get-ADSyncGlobalSettings | Select-Object -ExpandProperty Parameters |
    Where-Object { $_.Name -eq "Microsoft.Synchronize.ServerConfigurationVersion" }

# Método alternativo: verificar desde el registro
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Azure AD Connect" |
    Select-Object Version

# Verificar la versión del servicio de sincronización
Get-ADSyncScheduler | Select-Object *

Si la versión es inferior a 2.5.79.0, la actualización debería ser prioridad número uno. Microsoft también recomienda evaluar la migración a Microsoft Entra Cloud Sync, el nuevo cliente de sincronización basado en la nube que es más ligero y se administra completamente desde el portal de Entra. Personalmente, creo que es una buena alternativa para entornos que no necesitan configuraciones de sincronización muy complejas.

Diagnóstico de problemas de sincronización

Los problemas de sincronización son especialmente frustrantes porque sus síntomas pueden ser muy sutiles: un usuario que no aparece en Entra ID, un grupo que no tiene los miembros correctos, un cambio de contraseña que no se replica... Aquí va un flujo de trabajo sistemático para atacarlos:

Verificar el estado general de la sincronización:

# Verificar el estado del programador de sincronización
Get-ADSyncScheduler

# Resultado esperado:
# AllowedSyncCycleInterval : 00:30:00
# CurrentlyEffectiveSyncCycleInterval : 00:30:00
# SyncCycleEnabled : True
# NextSyncCycleStartTimeInUTC : (fecha futura)
# SyncCycleInProgress : False

# Verificar los últimos resultados de sincronización
Get-ADSyncRunProfileResult -NumberRequested 5 | Select-Object `
    ConnectorName,
    RunProfileName,
    Result,
    StartDate,
    EndDate

Investigar errores de sincronización específicos:

# Obtener errores de exportación (los más comunes)
Get-ADSyncCSObject -ConnectorName "dominio.com - Entra ID" -ObjectType User |
    Where-Object { $_.HasExportError -eq $true } |
    Select-Object DistinguishedName, ExportError

# Buscar un objeto específico que no se sincroniza
$csObject = Get-ADSyncCSObject -DistinguishedName "CN=Usuario,OU=Usuarios,DC=dominio,DC=com" `
    -ConnectorName "dominio.com"
$csObject | Select-Object ObjectType, HasSyncError, HasExportError, SyncError

# Forzar una sincronización Delta manualmente
Start-ADSyncSyncCycle -PolicyType Delta

# Forzar sincronización completa (usar con precaución en entornos grandes)
Start-ADSyncSyncCycle -PolicyType Initial

Errores comunes de sincronización y sus soluciones

Error: InvalidSoftMatch — Ocurre cuando Entra Connect intenta hacer coincidir un objeto local con uno en la nube pero los atributos de anclaje no coinciden. La solución pasa por verificar que el atributo proxyAddresses o userPrincipalName sea consistente en ambos lados.

Error: DataValidationFailed — Un atributo contiene caracteres no válidos o excede la longitud máxima. Muy común con el campo displayName (límite de 256 caracteres) o direcciones SMTP con formato incorrecto. He visto este error más veces de las que me gustaría admitir.

Error: LargeObject — El usuario tiene más de 15.000 asignaciones de grupo o un atributo que excede el tamaño máximo permitido. Solución: revisar las membresías de grupo y hacer limpieza de las que ya no son necesarias.

# Verificar los errores de sincronización desde el portal
# También se puede usar PowerShell con Microsoft Graph
Connect-MgGraph -Scopes "Directory.Read.All"

# Obtener errores de aprovisionamiento
Get-MgAuditLogProvisioning -Filter "status/errorCode ne null" -Top 20 |
    Select-Object ActivityDateTime,
    @{N='SourceIdentity';E={$_.SourceIdentity.DisplayName}},
    @{N='Error';E={$_.Status.ErrorCode}},
    @{N='Detalle';E={$_.Status.FailureReason}}

Unión híbrida de dispositivos a Microsoft Entra ID

¿Qué es la unión híbrida y por qué importa?

La unión híbrida a Microsoft Entra (Hybrid Entra Join) permite que los dispositivos unidos a un dominio de Active Directory local también estén registrados en Microsoft Entra ID. ¿Por qué es tan importante? Porque habilita varias cosas fundamentales:

  • Aplicar políticas de acceso condicional basadas en el estado del dispositivo.
  • Habilitar el inicio de sesión único (SSO) a recursos en la nube.
  • Gestionar dispositivos con Microsoft Intune en escenarios de cogestión.
  • Cumplir con requisitos de cumplimiento que exigen que el dispositivo sea "conocido" y "conforme".

Diagnóstico de dispositivos que no completan la unión híbrida

Uno de los problemas más reportados en 2026 es el de dispositivos que quedan en estado "Pendiente" en el portal de Entra ID sin completar nunca el registro. Es más común de lo que parece, y la herramienta principal de diagnóstico es dsregcmd:

:: Ejecutar en el dispositivo afectado (como administrador)
dsregcmd /status

:: Buscar estas secciones en la salida:
:: +----------------------------------------------------------------------+
:: | Device State                                                          |
:: +----------------------------------------------------------------------+
::     AzureAdJoined : YES (debe ser YES para unión híbrida)
::     EnterpriseJoined : NO
::     DomainJoined : YES (debe ser YES)
::
:: +----------------------------------------------------------------------+
:: | Tenant Details                                                        |
:: +----------------------------------------------------------------------+
::     TenantName : dominio.com
::     TenantId : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
::
:: +----------------------------------------------------------------------+
:: | Device Registration Status                                            |
:: +----------------------------------------------------------------------+
::     DeviceRegistered : YES (este es el indicador clave)

Si AzureAdJoined muestra NO en un dispositivo que debería estar unido de forma híbrida, toca investigar. Vamos por partes:

Verificación 1: La tarea programada de unión automática

:: Verificar que la tarea de unión automática existe y se ejecuta
schtasks /query /TN "\Microsoft\Windows\Workplace Join\Automatic-Device-Join" /V

:: Ejecutar la tarea manualmente para forzar el intento de registro
schtasks /run /TN "\Microsoft\Windows\Workplace Join\Automatic-Device-Join"

Verificación 2: Conectividad con los endpoints de Microsoft

# El dispositivo necesita alcanzar estos endpoints
$endpoints = @(
    "enterpriseregistration.windows.net",
    "login.microsoftonline.com",
    "device.login.microsoftonline.com",
    "autologon.microsoftazuread-sso.com"
)

foreach ($ep in $endpoints) {
    $test = Test-NetConnection -ComputerName $ep -Port 443 -WarningAction SilentlyContinue
    Write-Host "$ep : $(if($test.TcpTestSucceeded){'OK'}else{'FALLO'})" `
        -ForegroundColor $(if($test.TcpTestSucceeded){'Green'}else{'Red'})
}

Verificación 3: El Service Connection Point (SCP) en Active Directory

El SCP es un objeto en Active Directory que indica a los dispositivos dónde registrarse. Si no está bien configurado, los dispositivos simplemente no sabrán a qué tenant de Entra conectarse (y ahí es donde empiezan los problemas):

# Verificar el SCP en Active Directory
$scp = New-Object System.DirectoryServices.DirectorySearcher
$scp.SearchRoot = "LDAP://CN=Configuration,DC=dominio,DC=com"
$scp.Filter = "(keywords=azureADId:*)"
$result = $scp.FindAll()

if ($result.Count -gt 0) {
    Write-Host "SCP encontrado:" -ForegroundColor Green
    $result | ForEach-Object {
        $_.Properties["keywords"] | ForEach-Object { Write-Host "  $_" }
    }
} else {
    Write-Host "SCP NO encontrado. La unión híbrida no funcionará." -ForegroundColor Red
}

Solución para dispositivos atascados en estado "Pendiente"

Cuando un dispositivo aparece como "Pendiente" en el portal de Entra ID, puede ser porque el objeto del dispositivo fue movido a una OU que no está incluida en el ámbito de sincronización de Entra Connect, o porque hay artefactos de un registro anterior bloqueando el proceso.

La solución paso a paso es sencilla pero hay que seguirla en orden:

  1. En el dispositivo afectado, ejecutar dsregcmd /leave como administrador para desregistrarlo.
  2. Reiniciar el equipo.
  3. Verificar que la OU del equipo en Active Directory esté incluida en el filtrado de Entra Connect Sync.
  4. Esperar un ciclo de sincronización (o forzarlo con Start-ADSyncSyncCycle -PolicyType Delta).
  5. La tarea programada Automatic-Device-Join debería ejecutarse automáticamente tras el reinicio y completar el registro.

Directivas de grupo (GPO): diagnóstico de políticas que no se aplican

Metodología sistemática de troubleshooting con GPResult

Cuando un usuario o equipo no recibe las políticas de grupo esperadas, lo primero siempre es generar un informe de GPResult. No hay atajos aquí:

:: Generar informe HTML completo de las GPOs aplicadas
gpresult /H C:\Temp\gpresult.html /F

:: Ver un resumen rápido en la consola
gpresult /R

:: Generar el informe para un usuario remoto
gpresult /S NOMBRE_EQUIPO /USER dominio\usuario /H C:\Temp\gpresult_remoto.html

El informe HTML es especialmente útil porque muestra de forma visual qué GPOs se aplicaron, cuáles fueron filtradas y por qué razón. Las secciones que debes revisar sí o sí:

  • Objetos de directiva de grupo aplicados: Confirma qué GPOs se aplicaron correctamente.
  • GPOs denegados (filtrados): Muestra las GPOs que fueron evaluadas pero no aplicadas, junto con el motivo — filtrado de seguridad, filtro WMI, etc.
  • Resultado de la extensión del lado cliente: Indica si alguna extensión CSE (Client Side Extension) falló al procesar la política.

Causas comunes de GPOs que no se aplican

1. Filtrado de seguridad incorrecto

Desde una actualización de seguridad de 2022, las GPOs requieren que el objeto Authenticated Users tenga al menos el permiso de Lectura en la GPO, además de que el usuario o equipo objetivo tenga el permiso de Aplicar directiva de grupo. Es un error sorprendentemente común quitar Authenticated Users del filtrado de seguridad sin darse cuenta de las consecuencias:

# Verificar los permisos de una GPO específica
Get-GPPermission -Name "Nombre de la GPO" -All | Select-Object `
    Trustee,
    Permission,
    Inherited |
    Format-Table -AutoSize

# Agregar el permiso de lectura para Authenticated Users si falta
Set-GPPermission -Name "Nombre de la GPO" `
    -PermissionLevel GpoRead `
    -TargetName "Authenticated Users" `
    -TargetType Group

2. Problemas de replicación de SYSVOL

Si SYSVOL no se replica correctamente entre los controladores de dominio, un dispositivo puede recibir una versión desactualizada de la GPO o directamente no encontrar los archivos de la política. Esto suele ser más difícil de detectar porque no siempre produce errores evidentes:

# Verificar el estado de la replicación DFSR de SYSVOL
Get-WmiObject -Class Win32_NTEventLogFile -Filter "LogFileName='DFS Replication'" |
    Select-Object Name, NumberOfRecords

# Usar dfsrdiag para verificar la salud de la replicación
dfsrdiag.exe ReplicationState

# Forzar la replicación entre DCs
repadmin /syncall /AdeP

3. Filtro WMI mal configurado

Los filtros WMI pueden impedir que una GPO se aplique si la consulta WMI no coincide con el equipo. Para verificar si ese es el problema:

# Probar un filtro WMI localmente
# Ejemplo: un filtro que busca Windows 11
Get-WmiObject -Query "SELECT * FROM Win32_OperatingSystem WHERE Version LIKE '10.0.2%'"

# Listar todos los filtros WMI del dominio
Get-ADObject -SearchBase "CN=SOM,CN=WMIPolicy,CN=System,DC=dominio,DC=com" `
    -Filter * -Properties msWMI-Parm1, msWMI-Parm2, msWMI-Name |
    Select-Object @{N='Nombre';E={$_."msWMI-Name"}},
                  @{N='Consulta';E={$_."msWMI-Parm2"}}

Forzar la actualización de directivas de grupo

Para aplicar cambios inmediatamente sin esperar al intervalo de actualización habitual (90 minutos con una variación aleatoria de hasta 30 minutos):

:: Forzar actualización de GPO en el equipo local
gpupdate /force

:: Forzar actualización de GPO en un equipo remoto (requiere WinRM)
Invoke-GPUpdate -Computer "NOMBRE_EQUIPO" -Force -RandomDelayInMinutes 0

:: Forzar actualización en todos los equipos de una OU
Get-ADComputer -SearchBase "OU=Departamento,DC=dominio,DC=com" -Filter * |
    ForEach-Object {
        Invoke-GPUpdate -Computer $_.Name -Force -RandomDelayInMinutes 0
        Write-Host "GPO actualizada en: $($_.Name)"
    }

Acceso condicional en Microsoft Entra ID: diagnóstico desde el helpdesk

Entendiendo las políticas de acceso condicional

El acceso condicional es básicamente el motor de políticas Zero Trust de Microsoft Entra ID. Permite controlar quién accede a qué recursos, desde dónde y bajo qué condiciones. Es extremadamente potente, pero — seamos honestos — también es una de las fuentes más comunes de tickets del tipo "no puedo acceder a..." en el helpdesk.

Las señales que evalúa el acceso condicional incluyen:

  • Identidad del usuario: Quién es, a qué grupos pertenece.
  • Ubicación: Desde qué red o país se conecta.
  • Dispositivo: Si está unido al dominio, si cumple con las políticas de Intune, su plataforma.
  • Aplicación: A qué recurso intenta acceder.
  • Riesgo: Si Microsoft ha detectado un inicio de sesión sospechoso o un usuario comprometido.

Diagnóstico de bloqueos por acceso condicional

Cuando un usuario reporta que no puede acceder a un recurso y sospechas que es un tema de acceso condicional, este es el flujo de diagnóstico que deberías seguir:

Paso 1: Revisar los registros de inicio de sesión en Entra ID

  1. Accede al Centro de administración de Microsoft Entra (entra.microsoft.com).
  2. Navega a Identidad > Supervisión y estado > Registros de inicio de sesión.
  3. Filtra por el usuario afectado y el intervalo de tiempo.
  4. Busca los intentos de inicio de sesión con estado Fallo o Interrumpido.
  5. Haz clic en el evento y selecciona la pestaña Acceso condicional.

La pestaña de acceso condicional muestra todas las políticas que se evaluaron, cuáles se aplicaron y cuáles no. Las políticas marcadas en rojo son las que bloquearon el acceso. Así de simple.

Paso 2: Usar la herramienta "What If" para simular

La herramienta What If del acceso condicional es, en mi opinión, una de las funcionalidades más infravaloradas del portal de Entra. Permite simular un inicio de sesión sin que el usuario tenga que intentarlo realmente:

  1. En el portal de Entra, ve a Protección > Acceso condicional > Directivas.
  2. Haz clic en What If.
  3. Selecciona el usuario, la aplicación de destino, la plataforma del dispositivo, la ubicación y otras condiciones.
  4. Haz clic en What If para ver qué políticas se aplicarían.

Paso 3: Consultar los registros de inicio de sesión con PowerShell

# Conectar a Microsoft Graph con los permisos necesarios
Connect-MgGraph -Scopes "AuditLog.Read.All", "Directory.Read.All"

# Buscar inicios de sesión fallidos del usuario en las últimas 24 horas
$fechaInicio = (Get-Date).AddDays(-1).ToString("yyyy-MM-ddTHH:mm:ssZ")
$usuario = "[email protected]"

$signIns = Get-MgAuditLogSignIn -Filter `
    "userPrincipalName eq '$usuario' and createdDateTime ge $fechaInicio and status/errorCode ne 0" `
    -Top 20

# Mostrar los resultados con detalles de acceso condicional
$signIns | ForEach-Object {
    Write-Host "`n--- Inicio de sesión: $($_.CreatedDateTime) ---" -ForegroundColor Yellow
    Write-Host "App: $($_.AppDisplayName)"
    Write-Host "Estado: $($_.Status.ErrorCode) - $($_.Status.FailureReason)"
    Write-Host "Ubicación: $($_.Location.City), $($_.Location.CountryOrRegion)"
    
    $_.ConditionalAccessPolicies | ForEach-Object {
        $color = if ($_.Result -eq "failure") { "Red" } 
                 elseif ($_.Result -eq "success") { "Green" } 
                 else { "Gray" }
        Write-Host "  Política: $($_.DisplayName) -> $($_.Result)" -ForegroundColor $color
    }
}

Actualización importante: refuerzo de acceso condicional en marzo de 2026

Ojo con esto. Microsoft ha anunciado que a partir del 27 de marzo de 2026 se mejorará la forma en que se aplican las políticas de acceso condicional. En concreto, se está corrigiendo una vulnerabilidad donde las políticas que apuntaban a "todos los recursos" con exclusiones específicas podían eludirse en ciertos escenarios de autenticación OIDC.

El despliegue continuará hasta junio de 2026. Los equipos de helpdesk deben estar preparados para un posible aumento de tickets de acceso denegado a medida que las políticas se apliquen de forma más estricta. Mejor anticiparse que reaccionar.

Restablecimiento de contraseñas y SSPR: autoservicio que reduce tickets

Configuración y diagnóstico del SSPR

El Self-Service Password Reset (SSPR) de Microsoft Entra ID es, sin duda, una de las herramientas más efectivas para reducir la carga del helpdesk. Y los números hablan por sí solos: los tickets de restablecimiento de contraseña representan entre el 20% y el 50% de todas las solicitudes que recibe un helpdesk típico. Implementar SSPR correctamente puede reducir ese volumen de forma drástica.

Para verificar el estado de SSPR para un usuario:

# Verificar si SSPR está habilitado y los métodos de autenticación registrados
Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All"

$userId = "[email protected]"

# Obtener los métodos de autenticación registrados del usuario
Get-MgUserAuthenticationMethod -UserId $userId | Select-Object `
    @{N='Tipo';E={$_.AdditionalProperties["@odata.type"]}},
    Id

# Verificar si el usuario tiene métodos suficientes para SSPR
$methods = Get-MgUserAuthenticationMethod -UserId $userId
$methodCount = ($methods | Where-Object {
    $_.AdditionalProperties["@odata.type"] -ne "#microsoft.graph.passwordAuthenticationMethod"
}).Count

Write-Host "Métodos registrados (excluyendo contraseña): $methodCount"
if ($methodCount -ge 2) {
    Write-Host "El usuario cumple los requisitos para SSPR (2 métodos)." -ForegroundColor Green
} else {
    Write-Host "El usuario NO tiene suficientes métodos para SSPR." -ForegroundColor Red
}

Writeback de contraseñas en entornos híbridos

En entornos híbridos, el writeback de contraseñas permite que cuando un usuario cambia o restablece su contraseña en la nube (a través de SSPR o el portal de My Account), ese cambio se escriba de vuelta en Active Directory local. Sin esta funcionalidad, el usuario acabaría con una contraseña diferente en la nube y on-premises. Un desastre garantizado.

Para verificar que el writeback está funcionando:

# En el servidor de Entra Connect, verificar la configuración
Get-ADSyncAADPasswordResetConfiguration -Connector "dominio.com"

# El resultado debe mostrar:
# PasswordWritebackEnabled : True

# Si no está habilitado, activarlo:
Set-ADSyncAADPasswordResetConfiguration -Connector "dominio.com" -Enable $true

# Verificar los permisos del conector en AD
# La cuenta de servicio de Entra Connect necesita estos permisos en las OUs:
# - Reset Password
# - Write lockoutTime
# - Write pwdLastSet

Si el writeback falla, estos son los errores más habituales:

  • Error 33004: La cuenta de servicio de Entra Connect no tiene permisos suficientes para escribir la contraseña en AD. Solución: verificar y asignar los permisos de delegación correctos.
  • Error 33008: La contraseña no cumple la política de complejidad del dominio local. El usuario necesita elegir una contraseña que cumpla ambas políticas (la de Entra ID y la de AD local).
  • Errores de conectividad: El servidor de Entra Connect no puede comunicarse con los controladores de dominio. Hay que verificar la conectividad de red y la resolución DNS.

Kit de diagnóstico rápido: herramientas esenciales para el helpdesk

Script de diagnóstico integral para Active Directory

Este es uno de esos scripts que vale la pena tener siempre a mano. Reúne las verificaciones más comunes que un técnico de helpdesk necesita realizar sobre una cuenta de usuario:

# Script de diagnóstico rápido de cuenta AD
param(
    [Parameter(Mandatory=$true)]
    [string]$SamAccountName
)

Import-Module ActiveDirectory

$user = Get-ADUser -Identity $SamAccountName -Properties `
    LockedOut, LockoutTime, PasswordLastSet, PasswordExpired, `
    Enabled, LastLogonDate, MemberOf, AccountExpirationDate, `
    msDS-UserPasswordExpiryTimeComputed, BadLogonCount, BadPasswordTime

Write-Host "`n========================================" -ForegroundColor Cyan
Write-Host " Diagnóstico de cuenta: $SamAccountName" -ForegroundColor Cyan
Write-Host "========================================`n" -ForegroundColor Cyan

# Estado de la cuenta
Write-Host "Estado general:" -ForegroundColor Yellow
Write-Host "  Habilitada: $($user.Enabled)"
Write-Host "  Bloqueada: $($user.LockedOut)"
if ($user.LockoutTime) {
    Write-Host "  Hora de bloqueo: $([datetime]::FromFileTime($user.LockoutTime))" -ForegroundColor Red
}

# Contraseña
Write-Host "`nEstado de contraseña:" -ForegroundColor Yellow
Write-Host "  Último cambio: $($user.PasswordLastSet)"
Write-Host "  Expirada: $($user.PasswordExpired)"
if ($user."msDS-UserPasswordExpiryTimeComputed" -ne 0 -and 
    $user."msDS-UserPasswordExpiryTimeComputed" -ne 9223372036854775807) {
    $expiryDate = [datetime]::FromFileTime($user."msDS-UserPasswordExpiryTimeComputed")
    $daysRemaining = ($expiryDate - (Get-Date)).Days
    Write-Host "  Fecha de expiración: $expiryDate ($daysRemaining días restantes)"
}

# Intentos fallidos
Write-Host "`nIntentos fallidos:" -ForegroundColor Yellow
Write-Host "  Contador actual: $($user.BadLogonCount)"
if ($user.BadPasswordTime) {
    Write-Host "  Último intento fallido: $([datetime]::FromFileTime($user.BadPasswordTime))"
}

# Último inicio de sesión
Write-Host "`nActividad:" -ForegroundColor Yellow
Write-Host "  Último inicio de sesión: $($user.LastLogonDate)"
if ($user.AccountExpirationDate) {
    Write-Host "  Cuenta expira: $($user.AccountExpirationDate)" -ForegroundColor $(
        if ($user.AccountExpirationDate -lt (Get-Date)) { "Red" } else { "White" }
    )
}

# Grupos
Write-Host "`nMembresía de grupos ($($user.MemberOf.Count) grupos):" -ForegroundColor Yellow
$user.MemberOf | ForEach-Object {
    $groupName = ($_ -split ",")[0] -replace "CN=", ""
    Write-Host "  - $groupName"
}

# Acción recomendada
Write-Host "`n--- Acción recomendada ---" -ForegroundColor Magenta
if ($user.LockedOut) {
    Write-Host "  La cuenta está BLOQUEADA. Desbloquear con:" -ForegroundColor Red
    Write-Host "  Unlock-ADAccount -Identity $SamAccountName" -ForegroundColor White
}
if ($user.PasswordExpired) {
    Write-Host "  La contraseña está EXPIRADA. El usuario debe cambiarla." -ForegroundColor Red
}
if (-not $user.Enabled) {
    Write-Host "  La cuenta está DESHABILITADA." -ForegroundColor Red
}

Comandos rápidos de referencia para el día a día

Estos son los comandos de PowerShell que todo técnico de helpdesk debería tener a mano. Guárdalos, imprímelos, tatúatelos si hace falta (bueno, quizás eso no):

# === OPERACIONES COMUNES CON CUENTAS AD ===

# Desbloquear una cuenta
Unlock-ADAccount -Identity nombre.usuario

# Restablecer contraseña (el usuario deberá cambiarla en el próximo inicio de sesión)
Set-ADAccountPassword -Identity nombre.usuario `
    -Reset -NewPassword (ConvertTo-SecureString "ContraseñaTemporal123!" -AsPlainText -Force)
Set-ADUser -Identity nombre.usuario -ChangePasswordAtLogon $true

# Habilitar una cuenta deshabilitada
Enable-ADAccount -Identity nombre.usuario

# Buscar usuarios bloqueados en todo el dominio
Search-ADAccount -LockedOut | Select-Object Name, SamAccountName, LockedOut

# Buscar usuarios con contraseña expirada
Search-ADAccount -PasswordExpired | Select-Object Name, SamAccountName, PasswordLastSet

# Buscar cuentas inactivas (sin inicio de sesión en 90 días)
$limite = (Get-Date).AddDays(-90)
Get-ADUser -Filter {LastLogonDate -lt $limite -and Enabled -eq $true} `
    -Properties LastLogonDate |
    Select-Object Name, SamAccountName, LastLogonDate |
    Sort-Object LastLogonDate

# === DIAGNÓSTICO DE REPLICACIÓN ===

# Ver el estado de replicación entre DCs
repadmin /replsummary

# Forzar replicación desde un DC específico
repadmin /replicate DC02 DC01 "DC=dominio,DC=com"

# Verificar la salud de los controladores de dominio
dcdiag /v /c /e

Mejores prácticas de escalamiento para el helpdesk

Cuándo escalar y qué información incluir

No todos los problemas de Active Directory y Entra ID pueden (ni deben) resolverse en el nivel 1 del helpdesk. Saber cuándo escalar y proporcionar la información correcta es tan importante como saber resolver el problema. De hecho, un escalamiento bien hecho puede ahorrar horas de trabajo al equipo de nivel 2.

Escalar inmediatamente si:

  • Se detectan múltiples bloqueos de cuentas privilegiadas (posible ataque en curso).
  • La sincronización de Entra Connect lleva más de 6 horas sin completar un ciclo.
  • Errores de replicación de Active Directory que persisten más de 24 horas.
  • Un controlador de dominio no responde a dcdiag o muestra fallos de autenticación NTLM/Kerberos.
  • Cambios inesperados en esquema o directivas de grupo que nadie del equipo realizó. Esto último es especialmente preocupante.

Información que debe acompañar al escalamiento:

  1. Cronología: Cuándo comenzó el problema, cuándo se detectó, qué cambios se realizaron recientemente.
  2. Alcance: Cuántos usuarios están afectados, en qué ubicaciones, si es intermitente o constante.
  3. Diagnósticos ya realizados: Salida de gpresult, dsregcmd, dcdiag, registros de eventos relevantes y capturas de pantalla.
  4. Acciones tomadas: Qué se ha intentado hasta ahora y cuál fue el resultado.
  5. Impacto en el negocio: Si hay usuarios que no pueden trabajar y qué procesos están bloqueados.

Documentación de incidentes: plantilla recomendada

Cada incidente relacionado con Active Directory o Entra ID debería documentarse con al menos esta información en el sistema de tickets:

  • Síntoma reportado por el usuario: Descripción exacta de lo que experimenta.
  • Categorización: Bloqueo de cuenta / Sincronización / GPO / Unión híbrida / Acceso condicional / Otro.
  • Usuario(s) afectado(s): SamAccountName, UPN, OU de ubicación en AD.
  • Equipo(s) afectado(s): Nombre, sistema operativo, tipo de unión (AD / Hybrid / Entra ID).
  • Comandos de diagnóstico ejecutados: Con sus salidas completas.
  • Causa raíz identificada: O la hipótesis más probable si no se ha confirmado.
  • Solución aplicada: Pasos exactos realizados.
  • Verificación: Cómo se confirmó que el problema quedó resuelto.

Conclusión: preparando el helpdesk para el futuro híbrido

Active Directory y Microsoft Entra ID van a seguir coexistiendo durante años. La transición completa a la nube es inevitable para la mayoría de las organizaciones, pero el camino es largo y está lleno de configuraciones híbridas que necesitan mantenimiento constante.

Estos son los puntos clave que todo equipo de helpdesk debe tener presentes en 2026:

  • Actualizar Entra Connect Sync antes del 30 de septiembre de 2026 a la versión 2.5.79.0 o superior. Sin esta actualización, la sincronización se detendrá por completo. No es negociable.
  • Prepararse para los cambios en acceso condicional de marzo de 2026: El refuerzo de políticas puede generar bloqueos inesperados en usuarios que antes accedían sin problemas.
  • Dominar las herramientas de diagnóstico: dsregcmd, gpresult, dcdiag, los cmdlets de PowerShell para AD y Microsoft Graph. Son las herramientas fundamentales del helpdesk moderno.
  • Implementar SSPR y promoverlo activamente entre los usuarios: Cada contraseña que un usuario puede restablecer por sí mismo es un ticket menos en la cola.
  • Documentar, documentar, documentar: La base de conocimientos del helpdesk es tan valiosa como la infraestructura que soporta.

La infraestructura de identidad no es precisamente lo más glamuroso del mundo de la TI, pero es lo que mantiene a las organizaciones funcionando. Y el helpdesk es la primera línea de defensa cuando algo falla. Con las herramientas, los conocimientos y los flujos de trabajo adecuados, esa primera línea puede resolver la gran mayoría de los problemas antes de que escalen — y honestamente, eso marca toda la diferencia entre un servicio de soporte bueno y uno excelente.

Sobre el Autor Editorial Team

Our team of expert writers and editors.

Artículos Relacionados