Caducidad de cuentas AD: revisar antes de ampliar el acceso

Revisión de la caducidad de cuentas AD: decidir antes del vencimiento

Una revisión de la caducidad de cuentas AD convierte las próximas fechas de fin de acceso en decisiones con un responsable asignado. Una cuenta próxima a caducar puede pertenecer a un contratista cuyo encargo termina, a un empleado con acceso temporal o a una identidad de usuario utilizada por una aplicación. La primera pregunta es si la fecha de fin prevista sigue siendo correcta. Ampliar todas las cuentas que aparecen en un informe anula el propósito de asignar una fecha de fin.

La revisión necesita el instante de caducidad, el responsable, la necesidad empresarial que continúa y las dependencias que deben retirarse o transferirse. Debe cubrir todas las poblaciones de usuarios pertinentes. La pertenencia a grupos privilegiados afecta a la urgencia y a los derechos que deben retirarse, pero no es un requisito previo para revisar un vencimiento próximo.

Una cuenta próxima a caducar no constituye evidencia de compromiso. La caducidad de la cuenta también es independiente de la caducidad de la contraseña: son propiedades distintas de la cuenta y problemas operativos diferentes. Esta guía propone un procedimiento de revisión; no presenta resultados de un dominio real ni prescribe una política universal de renovación.

Cómo accountExpires representa una fecha de fin

El atributo AD accountExpires almacena Windows FILETIME: intervalos de 100 nanosegundos contados desde el 1 de enero de 1601 UTC. Microsoft define dos valores para una cuenta que nunca caduca: 0 y 9223372036854775807, también escrito 0x7FFFFFFFFFFFFFFF. Ninguno es un vencimiento futuro que deba incluirse en un calendario de caducidad. Microsoft Learn: atributo Account-Expires

Distinga el instante almacenado de una instrucción empresarial como «el acceso termina el viernes». Pregunte si el responsable se refiere al comienzo de ese día, al final de un turno o a un instante UTC concreto. Registre la zona horaria acordada y la hora exacta antes de realizar un cambio. Sin ese contexto, una fecha puede terminar el acceso antes de lo que pretendía el responsable.

Este tema se solapa con nuestro artículo sobre cuentas deshabilitadas, caducadas y bloqueadas que permanecen en grupos privilegiados. Ese artículo trata las cuentas que ya se encuentran en un estado no válido mientras persiste su pertenencia privilegiada. Esta revisión actúa antes de la caducidad, en todas las poblaciones de usuarios, para asignar la decisión y coordinar los cambios de acceso. Si la cuenta ya ha caducado, inclúyala en el proceso existente de baja y revisión de pertenencias en lugar de tratarla como un vencimiento futuro.

La guía sobre la duración de los tickets Kerberos y la contención de conexiones explica por qué el estado de la cuenta, los tickets emitidos y las conexiones autenticadas requieren evidencias separadas. Aplique esa distinción al planificar una fecha de fin de acceso. Una revisión ordinaria de caducidad no es un hallazgo de incidente y no justifica suponer un robo de tickets.

Detección: crear un inventario de caducidades

1. Definir el alcance y un horizonte explícito

Empiece por el dominio, el servidor de directorio, la base de búsqueda y el instante de referencia. Registre el horizonte de revisión como una elección operativa local. Los ejemplos siguientes requieren el módulo PowerShell ActiveDirectory y un contexto de directorio autorizado. Son comandos ilustrativos adaptados de la documentación, no comandos ejecutados en un entorno AD. Sustituya cada servidor, DN e identidad de ejemplo por valores verificados.

Microsoft documenta Search-ADAccount -AccountExpiring con -TimeSpan para un periodo desde el instante actual o con -DateTime para un vencimiento. -UsersOnly limita la población de objetos a usuarios. El siguiente ejemplo elige un horizonte de informe de treinta días; esta elección no es un requisito de Microsoft. Microsoft Learn: Search-ADAccount

$server = 'dc01.example.com'
$searchBase = 'OU=People,DC=example,DC=com'
Search-ADAccount -AccountExpiring -UsersOnly -TimeSpan '30.00:00:00' -Server $server -SearchBase $searchBase |
    Select-Object DistinguishedName, Name, Enabled, AccountExpirationDate

Para una revisión programada, un vencimiento absoluto puede ser más fácil de reproducir. Este ejemplo independiente construye un DateTime UTC en lugar de depender de una cadena de fecha ligada a la configuración regional:

$deadlineUtc = [datetime]::new(2026, 11, 3, 18, 0, 0, [DateTimeKind]::Utc)
Search-ADAccount -AccountExpiring -UsersOnly -DateTime $deadlineUtc -Server $server -SearchBase $searchBase |
    Select-Object DistinguishedName, Name, Enabled, AccountExpirationDate

Use una sola forma de horizonte por consulta. Conserve la hora de la consulta y su vencimiento: una consulta relativa ejecutada más tarde tiene una ventana distinta. Estas búsquedas mediante cmdlets son entradas para la investigación, no una reproducción declarada de las comparaciones estrictas de límites de EtcSec. Examine las fechas devueltas y el estado de habilitación antes de asignar una acción.

2. Leer el atributo sin procesar y normalizar las fechas

Recupere accountExpires explícitamente con Get-ADUser -Properties. Microsoft documenta el acceso a atributos LDAP adicionales mediante este parámetro, junto con -SearchBase y -Server para seleccionar el contexto del directorio. Microsoft Learn: Get-ADUser

Este inventario ilustrativo conserva el valor sin procesar e informa del estado de conversión. Distingue deliberadamente un valor no disponible o no válido de un valor centinela documentado que indica que la cuenta nunca caduca:

Get-ADUser -Filter * -Server $server -SearchBase $searchBase -Properties accountExpires,manager,description |
    ForEach-Object {
        $raw = $_.accountExpires
        $expiryUtc = $null
        $state = 'Missing or invalid'
        if ($null -ne $raw -and [string]$raw -ne '') {
            try {
                $value = [long]$raw
                if ($value -eq 0 -or $value -eq [long]::MaxValue) {
                    $state = 'Never expires'
                } else {
                    $expiryUtc = [datetime]::FromFileTimeUtc($value)
                    $state = 'Dated'
                }
            } catch {
                $state = 'Missing or invalid'
            }
        }
        [pscustomobject]@{
            DistinguishedName = $_.DistinguishedName
            Enabled = $_.Enabled
            RawAccountExpires = $raw
            ExpirationUtc = $expiryUtc
            DateState = $state
            Manager = $_.Manager
            Description = $_.Description
        }
    }

FromFileTimeUtc convierte un tiempo de archivo en un DateTime UTC y rechaza las entradas fuera de rango. Los dos valores centinela de ausencia de caducidad se tratan antes de la conversión. Las etiquetas de error de este ejemplo son etiquetas propuestas para la revisión, no salidas del analizador del colector. Microsoft Learn: DateTime.FromFileTimeUtc

Los campos manager y description del directorio son pistas para encontrar un responsable, no una prueba de que la persona indicada autorizó el acceso. Confirme al responsable mediante el contrato vigente, la solicitud de acceso o el registro del servicio. Mantenga visible la responsabilidad sin resolver en lugar de usar un campo vacío como permiso para renovar.

3. Convertir las fechas en un registro de acciones

Para cada identidad dentro del alcance, conserve su identificador estable, el atributo sin procesar, la caducidad normalizada, el estado de habilitación, la marca temporal de revisión y la fuente de directorio. Añada la fecha de fin empresarial, el responsable, las dependencias, la decisión y la referencia del cambio. Distinga las cuentas ya caducadas, las que nunca caducan y las fechas ilegibles de la cola de vencimientos próximos.

Una dependencia de aplicación debe convertirse en una tarea para el propietario del servicio. No debe transformar silenciosamente una identidad limitada en el tiempo en una permanente. Decida cómo continuará el trabajo, quién será responsable de la sustitución o transición y qué evidencia cerrará esa tarea.

Corrección: confirmar la fecha de fin o autorizar una ampliación acotada (Remediation)

1. Decidir antes de editar la cuenta

Confirme primero la fecha de referencia y la población; después envíe cada vencimiento a su responsable. Pregunte si la fecha de fin original sigue siendo válida y si el usuario sigue necesitando el mismo acceso. Registre la respuesta con su fuente de aprobación. La falta de respuesta deja la revisión sin resolver; no autoriza una ampliación.

Cuando el acceso deba terminar según lo previsto, coordine la retirada de derechos, la revisión de pertenencias y el traspaso de aplicaciones con los equipos responsables. Cuando el trabajo continúe, exija una nueva fecha de fin acotada y un motivo autorizado. Separe ambos resultados en el registro para que una renovación masiva no se confunda con una corrección completada.

2. Aplicar únicamente la fecha aprobada

Microsoft documenta Set-ADAccountExpiration para establecer una hora de caducidad exacta. Su parámetro -DateTime supone la hora local salvo que se indique lo contrario; omitir la hora significa medianoche local. Use el instante exacto aprobado y regístrelo explícitamente. Microsoft Learn: Set-ADAccountExpiration

La siguiente ampliación específica ilustrativa utiliza una identidad de ejemplo y un vencimiento UTC. Ejecute primero la vista previa en un entorno autorizado. Aplique la escritura independiente solo después de comprobar que la identidad y la fecha coinciden con la aprobación registrada. Estos comandos no se han ejecutado aquí.

$identity = 'CN=Example User,OU=People,DC=example,DC=com'
$approvedExpiryUtc = [datetime]::new(2026, 12, 1, 18, 0, 0, [DateTimeKind]::Utc)
Set-ADAccountExpiration -Identity $identity -DateTime $approvedExpiryUtc -Server $server -WhatIf

Set-ADAccountExpiration -Identity $identity -DateTime $approvedExpiryUtc -Server $server

No envíe todo el informe de caducidad a esta escritura. Un resultado de consulta establece una condición de fecha; no aporta aprobación alguna para continuar el acceso. Asimismo, eliminar la caducidad es una decisión de política independiente, no una solución rutinaria para un hallazgo de caducidad próxima.

3. Volver a leer y conservar la decisión

Tras el cambio, lea la misma cuenta desde el servidor elegido. Conserve los valores sin procesar anteriores y nuevos, las fechas normalizadas, el servidor, la marca temporal, la aprobación y la referencia del cambio:

Get-ADUser -Identity $identity -Server $server -Properties accountExpires,AccountExpirationDate |
    Select-Object DistinguishedName, Enabled, accountExpires, AccountExpirationDate

Normalice el valor sin procesar con el método del inventario y compárelo con el instante UTC aprobado. Esta lectura de comprobación verifica el valor del servidor seleccionado; cuando el procedimiento dependa de otros controladores de dominio, organice su verificación mediante el proceso del equipo de directorio. Una aprobación guardada sin lectura de comprobación no demuestra que el atributo haya cambiado según lo previsto.

Para las bajas planificadas, conserve evidencia de que se completaron las tareas asignadas de retirada de derechos y transición de servicios. Para las ampliaciones, programe la próxima revisión en torno al nuevo vencimiento. En ambos casos, distinga el atributo de la cuenta de los tickets, las conexiones y el acceso a aplicaciones. El registro debe indicar qué se verificó y qué queda a cargo de otro responsable.

Cómo EtcSec detecta esta situación

El etc-collector de EtcSec implementa ACCOUNT_EXPIRE_SOON en public/internal/audit/detectors/ad/accounts/status/account-expire-soon.go. La inspección estática de Detect() muestra la siguiente lógica; no se ejecutó ninguna auditoría de clientes para este artículo:

1. Tomar el instante de referencia de data.Now.
2. Calcular el límite superior con now.AddDate(0, 0, 30).
3. Omitir cualquier usuario cuyo indicador Disabled sea true.
4. Omitir cualquier usuario cuyo AccountExpires analizado sea el tiempo cero.
5. Seleccionar solo las fechas estrictamente posteriores al instante de referencia y estrictamente anteriores al límite superior.

Los límites inferior y superior quedan excluidos. Se excluyen las cuentas ya caducadas, así como una caducidad exactamente igual al instante de referencia de la auditoría. Count es el número de usuarios seleccionados, no el número de dominios, aprobaciones o tareas de baja pendientes. El detector devuelve un hallazgo Medium con ese recuento; adjunta detalles de los usuarios afectados solo cuando IncludeDetails está habilitado y el recuento es positivo.

Esta comprobación no incluye ninguna condición relacionada con grupos privilegiados, cuentas de servicio o secretos. Cubre a todos los usuarios recopilados que cumplen las condiciones de fecha y estado de habilitación. La ventana de treinta días es una elección de producto declarada, no un requisito de Microsoft, ANSSI o CIS. La implementación utiliza una suma de fechas de calendario; conserve la referencia y los límites de la auditoría al explicar un resultado concreto.

El analizador LDAP rellena AccountExpires mediante parseFileTime en public/internal/providers/ldap/parser.go. La entrada vacía, 0, el valor centinela máximo con signo de 64 bits y los errores de conversión a entero se convierten en tiempo cero sin un diagnóstico por valor en esa función auxiliar. Los valores anteriores al límite de conversión de la época Unix también se convierten en cero. Por tanto, una fecha analizada como cero puede representar datos sin caducidad o una entrada no disponible o inutilizable. El detector omite ambos casos.

Use ACCOUNT_EXPIRE_SOON para iniciar la revisión de responsables y vencimientos. Un recuento positivo no demuestra un ataque, la caducidad de una contraseña, una ampliación no autorizada ni la necesidad de renovar. Cierre la revisión con una decisión documentada sobre la fecha de fin, un estado de atributo verificado y tareas de retirada de acceso o de gestión de dependencias con responsables separados.