Rotación de contraseña con tarjeta inteligente Active Directory

Rotación de contraseña con tarjeta inteligente en Active Directory

La rotación de contraseña con tarjeta inteligente en Active Directory importa porque estas cuentas conservan un secreto de contraseña de red. Sin renovación automática de contraseña, el secreto aleatorio establecido por Windows puede persistir hasta que se cambie explícitamente. La afirmación de que «nunca cambia de forma predeterminada» necesita una precisión inmediata: Microsoft documenta la renovación como habilitada para los dominios nuevos, mientras que los dominios existentes requieren configuración. Considérelo un riesgo en dominios donde la renovación está ausente o deshabilitada, en lugar de una propiedad universal del Active Directory moderno. La documentación de Microsoft sobre las novedades de Windows Server 2016 establece esa distinción.

La opción de la cuenta y el ajuste de rotación del dominio responden a preguntas distintas. La primera determina si el usuario debe utilizar una tarjeta inteligente para el inicio de sesión interactivo inicial, incluido Escritorio remoto. El segundo controla el mantenimiento del secreto basado en contraseña que sigue siendo relevante para la autenticación de red. Una revisión que se detiene en la casilla de la cuenta deja sin responder la segunda pregunta. La documentación de Microsoft sobre cuentas describe tanto la restricción interactiva como el hash NT restante.

Para los administradores, el objetivo útil va por tanto más allá de «poner la casilla en verde». Determine qué identidades requieren la tarjeta, si su dominio admite y habilita la renovación, y cómo demostrará un restablecimiento correcto en una cuenta representativa. Esta guía sigue esa secuencia: inspeccionar la cuenta y el dominio, interpretar los hallazgos y después probar la remediación con un piloto. Los comandos siguientes son ejemplos basados en documentación; ninguno se ejecutó contra un dominio para este artículo.

El bit es un requisito de autenticación

La opción corresponde al indicador acumulativo userAccountControl denominado SMARTCARD_REQUIRED, con valor hexadecimal 0x40000 y decimal 262144. Pueden coexistir otros indicadores. Leer el atributo completo como si debiera ser igual a 0x40000 omitiría las cuentas que llevan opciones adicionales. La referencia de Microsoft sobre UserAccountControl enumera el indicador y explica los valores acumulativos.

Windows aleatoriza el secreto de la cuenta cuando se habilita el requisito. La guía administrativa de Microsoft describe una contraseña aleatoria inicialmente desconocida y advierte de que alguien con derechos para restablecer contraseñas puede establecer después un valor conocido y utilizar determinadas vías de acceso a la red. Exigir la tarjeta no elimina la importancia de esos permisos de restablecimiento. La guía de Microsoft sobre privilegios mínimos detalla explícitamente esa capacidad administrativa que permanece.

Cómo funcionan el secreto restante y la renovación

Aleatorio no significa sustituido periódicamente

La referencia de Microsoft sobre cuentas indica que, sin el comportamiento adicional de renovación, el valor generado permanece hasta que se establece una contraseña nueva o se deshabilita y vuelve a habilitar el requisito de tarjeta inteligente. Un valor inicial de alta entropía aborda las conjeturas; mantener el mismo valor después de su robo es otra preocupación. Esa es la distinción que motiva esta revisión, sin afirmar que todas las cuentas con tarjeta inteligente tengan la contraseña más antigua de su dominio. El comportamiento documentado de las cuentas respalda la persistencia y el mecanismo de sustitución manual.

La autenticación de Windows también debe permitir el acceso posterior a recursos de red. La documentación de Microsoft sobre los procesos de credenciales describe la conservación del hash NT correspondiente en su modelo de credenciales después del inicio de sesión con tarjeta inteligente. Esto establece por qué importa el secreto. No establece que un atacante pueda extraer un hash de cualquier equipo independientemente de sus protecciones o de la sesión real. Mantenga la existencia de una credencial, su exposición y su robo como preguntas de investigación separadas.

El ajuste del dominio habilita la expiración según la directiva

El atributo booleano del dominio msDS-ExpirePasswordsOnSmartCardOnlyAccounts controla la expiración de las contraseñas de cuentas que solo usan tarjeta inteligente según la directiva de contraseñas. No es el bit de tarjeta inteligente de cada usuario. La definición del atributo en MS-ADA2 identifica su finalidad.

La función requiere un nivel funcional del dominio Windows Server 2016 o superior. La versión del sistema operativo de un controlador de dominio no demuestra por sí sola ese requisito, y aquí se exige el nivel del dominio, no un requisito inventado del nivel de bosque. La página de novedades de Microsoft también documenta la opción del Centro de administración de Active Directory para dominios existentes. La descripción de la función de renovación es la referencia para estos requisitos de despliegue.

El restablecimiento forma parte del procesamiento de un inicio de sesión apto

Durante el procesamiento de AS-REQ de PKINIT, el KDC solicita el restablecimiento de la contraseña de la cuenta que solo usa tarjeta inteligente bajo las condiciones definidas en el procedimiento de restablecimiento de MS-PKCA. Su finalización correcta hace que reinicie el procesamiento de la solicitud original.

El servicio que responde aplica las reglas de expiración y validación de la especificación normativa de restablecimiento de MS-SAMS. Una contraseña no expirada devuelve éxito sin sustitución. Aquí, expiración significa la condición calculada por el protocolo, que también considera las reglas de duración de los tickets; no es simplemente el umbral de edad del dominio que usa el colector. Para una contraseña expirada, la validación incluye el atributo del dominio habilitado, un nivel funcional del dominio suficiente, el bit de tarjeta inteligente y la ausencia de DONT_EXPIRE_PASSWD. Un restablecimiento correcto genera secretos nuevos y actualiza pwdLastSet a la hora actual.

Este es un procesamiento de inicio de sesión sujeto a condiciones de directiva y protocolo. No es un temporizador en segundo plano, una sustitución garantizada en cada inicio de sesión ni un calendario universal de días fijos. Como inferencia operativa, una cuenta que rara vez realiza un inicio de sesión apto puede conservar una fecha antigua aunque la renovación esté habilitada. Investigue la directiva y el uso real de esa cuenta antes de atribuir una causa a la fecha.

Medir la cuenta y el dominio por separado

Utilice un controlador de dominio identificado por nombre para obtener lecturas comparables y sustituya corp.example, dc01.corp.example, el nombre distinguido del dominio y admin-pilot por valores reales. Conserve la identidad, la hora de recopilación y los resultados brutos junto con el registro del cambio. Los ejemplos se construyen a partir de parámetros de cmdlets documentados; no se presentan como comandos exactos copiados literalmente de Learn ni como resultados de una auditoría de un cliente.

Paso 1 — Inventariar las cuentas con el requisito

Get-ADUser documenta -Filter, -Properties y -Server. El modelo de objetos de Active Directory documenta SmartcardLogonRequired y la propiedad PasswordLastSet derivada de pwdLastSet.

Get-ADUser -Filter {SmartcardLogonRequired -eq $true} -Properties pwdLastSet,PasswordLastSet,PasswordNeverExpires,Enabled,adminCount -Server dc01.corp.example

Lea el estado de habilitación y la excepción de expiración junto con las fechas. Conserve las cuentas deshabilitadas en el inventario si resulta útil, pero distíngalas de la población habilitada que evalúa el detector de rotación. Una fecha aporta evidencia sobre el mantenimiento de la contraseña; no fecha de forma independiente cuándo se habilitó el bit de tarjeta inteligente.

Para cada cuenta, registre su propietario, el flujo de inicio de sesión esperado, la directiva aplicable y las excepciones de expiración. Recopile por separado los detalles del flujo y de la propiedad; Get-ADUser no los establece.

Paso 2 — Identificar el dominio y el nivel funcional

Get-ADDomain acepta una identidad de dominio y un servidor y devuelve información del dominio, incluidos DomainMode y DistinguishedName.

Get-ADDomain -Identity corp.example -Server dc01.corp.example

Utilice la identidad del dominio devuelta para confirmar que las lecturas posteriores apuntan al contexto de nomenclatura previsto. Registre el nivel funcional por separado del inventario de sistemas operativos de los controladores de dominio. Si no se puede obtener el resultado o identifica el dominio equivocado, resuelva ese problema de medición antes de extraer conclusiones sobre la disponibilidad de la función.

Paso 3 — Leer el atributo del dominio y la directiva de edad de contraseña

Get-ADObject documenta la lectura de un objeto por identidad con propiedades LDAP adicionales. Lea el objeto raíz del dominio, en lugar de una OU o un usuario individual:

Get-ADObject -Identity 'DC=corp,DC=example' -Properties msDS-ExpirePasswordsOnSmartCardOnlyAccounts,maxPwdAge -Server dc01.corp.example

Conserve el valor bruto de maxPwdAge junto con el ajuste del dominio. La comparación de edad del colector descrita más adelante utiliza un valor en días derivado de esa directiva. No lo sustituya por un objetivo de edad arbitrario para describirlo después como un requisito de renovación de Microsoft.

Trate un atributo ausente, un valor false y una lectura fallida como situaciones de investigación distintas. Confirme el controlador, la identidad del dominio, los permisos y la integridad de la respuesta. Una vista vacía en la consola no basta para demostrar que una recopilación correcta devolvió false.

Detección: decidir qué pregunta responde la evidencia

Comience con dos poblaciones: cuentas habilitadas que requieren la tarjeta e identidades administrativas que no la requieren. En la primera, determine si la renovación está habilitada antes de evaluar la edad. En la segunda, confirme las responsabilidades administrativas reales antes de decidir dónde corresponde el requisito. Estos son pasos de revisión derivados de los criterios de los detectores, no pruebas de una intrusión.

La tabla resume smartcard-rotation.go:48 y admin-no-smartcard.go:24, examinados íntegramente para este artículo. Su implementación se detalla en «Cómo detecta EtcSec esta situación».

Un registro de evidencia útil separa la observación de configuración, la observación de edad de la cuenta y la causa confirmada. Por ejemplo, una fecha antigua con la renovación habilitada justifica investigar; no demuestra que el atributo del dominio deba estar deshabilitado en secreto. Evite describir el nombre del detector como el diagnóstico de todas las cuentas que devuelve.

Por qué la consecuencia del ataque sigue siendo condicional

Si realmente se roba un secreto NT aún vigente, su uso depende de los protocolos de autenticación y los derechos disponibles en la vía hacia el objetivo. Nuestra guía de Pass-the-Hash explica esa reutilización condicional mediante NTLM. También separa Overpass-the-Hash, que obtiene material de autenticación Kerberos bajo las condiciones pertinentes, de Pass-the-Ticket, que reutiliza un ticket. No infiera que poseer el hash NT de un usuario proporciona todos los tickets en un dominio basado en AES.

Mantenga preciso el objetivo de endurecimiento: reducir la persistencia de un secreto de contraseña reutilizable. No describa un restablecimiento correcto como revocación universal de tickets ya emitidos, sesiones de red existentes o certificados. Estos necesitan sus propias decisiones de respuesta a incidentes.

Remediación: habilitar la renovación mediante un piloto controlado (Remediation)

Paso 1 — Establecer requisitos y responsabilidades

Antes de cambiar el dominio, nombre al administrador responsable, seleccione una cuenta piloto representativa y confirme el nivel funcional del dominio. Revise la directiva real de contraseñas del piloto y sus excepciones de expiración. Organice una forma de probar su inicio de sesión con tarjeta inteligente y el acceso necesario a la red, con un procedimiento de recuperación acordado.

Este es un plan de cambio recomendado, no un resultado de laboratorio. Su finalidad es poner de manifiesto las dependencias antes de ampliar el cambio. No utilice una operación de escritura correcta como único criterio de aceptación. Decida por adelantado qué lecturas y pruebas de autenticación conservará como evidencia el responsable del cambio.

Las identidades seleccionadas también deben corresponder al uso previsto. La referencia de Microsoft sobre cuentas indica que las cuentas que requieren tarjeta inteligente no pueden utilizarse para iniciar servicios o ejecutar tareas programadas. Revise esas dependencias antes de cambiar el requisito de una cuenta. La guía de Microsoft sobre cuentas establece ese límite.

Paso 2 — Habilitar la renovación del dominio

Después de validar el nivel funcional y planificar el piloto, adapte el ejemplo 6 de Set-ADDomain:

Set-ADDomain -Identity corp.example -PublicKeyRequiredPasswordRolling $true -Server dc01.corp.example

El parámetro documentado establece msDS-ExpirePasswordsOnSmartCardOnlyAccounts en true. Este es un cambio del dominio, aunque la validación comience con una sola cuenta. Inventaríe las identidades afectadas y sus propietarios antes de aplicarlo.

Repita inmediatamente la lectura anterior del objeto de dominio contra el controlador elegido. Después organice un inicio de sesión apto del piloto y repita la lectura del usuario. Registre lo que realmente ocurrió en lugar de insertar una salida esperada en el registro del cambio. Si la fecha no cambia, investigue la aptitud y la directiva antes de repetir cambios a ciegas. Este ejemplo no promete ningún retraso de replicación ni resultado de restablecimiento.

Paso 3 — Usar la sustitución manual solo como procedimiento controlado

Donde aún no pueda utilizarse la renovación automática, la referencia de Microsoft sobre cuentas documenta la sustitución mediante la deshabilitación y posterior habilitación del requisito. Set-ADUser documenta el parámetro booleano -SmartcardLogonRequired. Las siguientes son dos acciones separadas sobre una cuenta piloto.

Primero quite el requisito:

Set-ADUser -Identity admin-pilot -SmartcardLogonRequired $false -Server dc01.corp.example

Después restáurelo:

Set-ADUser -Identity admin-pilot -SmartcardLogonRequired $true -Server dc01.corp.example

Lea de nuevo la cuenta, verifique que el requisito se ha restablecido, pruebe el flujo previsto de inicio de sesión y acceso a red, y confirme el estado replicado pertinente. No afirme que este procedimiento manual siempre actualiza pwdLastSet de forma idéntica al restablecimiento automático normativo. Mida el resultado.

Si un nivel funcional inferior impide la renovación automática, documente el procedimiento manual, la responsabilidad y el calendario de la organización. Elija ese calendario mediante su proceso de riesgos y operaciones; no etiquete el intervalo elegido como requisito de Microsoft para esta función.

Paso 4 — Revisar el perímetro administrativo real

Utilice la selección del detector complementario como lista inicial. La sintaxis siguiente utiliza parámetros documentados de Get-ADUser; los criterios de selección proceden de admin-no-smartcard.go:24.

Get-ADUser -Filter {Enabled -eq $true -and adminCount -eq 1 -and SmartcardLogonRequired -eq $false} -Properties adminCount,userAccountControl -Server dc01.corp.example

Concilie esa lista con las pertenencias actuales a grupos, la administración delegada, la autoridad sobre aplicaciones y las identidades de recuperación. El detector lee un marcador administrativo; no calcula todas las formas de privilegio efectivo. La guía de Microsoft sobre privilegios mínimos aborda los privilegios en grupos del directorio, sistemas miembros y aplicaciones, por lo que la revisión debe extenderse más allá de la población de la consulta. Revise los privilegios administrativos y los derechos de restablecimiento de contraseñas antes de aplicar restricciones a las cuentas.

Validar el cambio sin exagerar el resultado

Construya el registro de validación alrededor de observaciones que un revisor pueda reproducir: el dominio y el controlador consultados, el nivel funcional, el atributo bruto de renovación, el requisito de la cuenta, la directiva revisada y el resultado de autenticación del piloto. Incluya marcas de tiempo y conserve los errores. Este es un formato recomendado de evidencia, no una afirmación de que un solo comando proporcione todos los elementos.

Distinga «el ajuste está habilitado» de «se ha completado el restablecimiento de una cuenta apta». Si el piloto todavía no debe expirar, una fecha sin cambios puede ser coherente con el flujo documentado. Si el restablecimiento tiene éxito, compare la observación nueva del usuario con la captura anterior. Para cuentas de uso poco frecuente, decida cómo se organizará su validación futura en lugar de suponer que un cambio del dominio renueva inmediatamente todos los secretos.

Por último, repita la evaluación de configuración y examine de nuevo ambas poblaciones. Un hallazgo restante merece investigación; un recuento cero necesita contexto de recopilación. Mantenga disponible el plan de recuperación administrativa mientras se amplía el cambio. El cierre debe describir exactamente lo verificado y lo que aún depende de futuros inicios de sesión o controles separados.

Cómo detecta EtcSec esta situación

SMARTCARD_PASSWORD_ROTATION_DISABLED

La implementación en ad/advanced/other/smartcard-rotation.go:48 primero aborda la falta de información del dominio devolviendo un hallazgo con Count: 0. Después selecciona usuarios habilitados cuyo userAccountControl contiene 0x40000.

Tiene dos ramas reales:

• Ajuste del dominio false: se selecciona cada usuario de esa población habilitada que requiere tarjeta inteligente, independientemente de PasswordLastSet. Un cambio reciente de contraseña no elimina el hallazgo de configuración.
• Ajuste del dominio true: la edad solo se evalúa cuando MaxPasswordAge > 0. La cuenta se selecciona si PasswordLastSet es cero o estrictamente anterior a Now.AddDate(0, 0, -MaxPasswordAge). La igualdad no se selecciona. Con edad máxima cero, esta rama no infiere ningún hallazgo de edad.

Estas ramas están en smartcard-rotation.go:79–87; el umbral de la directiva está en 62–66. El control no utiliza un umbral de días fijos ni demuestra que se haya producido un restablecimiento durante un inicio de sesión concreto.

ADMIN_NO_SMARTCARD

La implementación complementaria en ad/accounts/advanced/admin-no-smartcard.go:24 selecciona usuarios habilitados con AdminCount=true y sin el bit de tarjeta inteligente, mediante las condiciones de 29–41. No examina la edad de la contraseña ni el atributo de renovación del dominio.

Los dos controles evalúan poblaciones de cuentas diferentes. Uno revisa el mantenimiento del secreto tras una tarjeta inteligente obligatoria; el otro identifica cuentas de su selección administrativa sin ese requisito. Ninguno debe presentarse como una eliminación de todos los ataques basados en contraseñas.

Qué no miden estos hallazgos

Ningún Detect() valida el nivel funcional del dominio, calcula la directiva de contraseñas detallada efectiva de cada usuario, comprueba DONT_EXPIRE_PASSWD, demuestra un inicio de sesión o restablecimiento correcto ni elabora un inventario de administradores fuera de adminCount. La recopilación LDAP convierte un atributo de renovación true en un booleano y convierte ausente o false en false; deriva la edad máxima de contraseña de maxPwdAge (providers/ldap/client.go:636,662–669). Ese límite de recopilación importa al interpretar la primera rama.

Un recuento cero puede significar, por tanto, que no hay usuarios seleccionados, una comparación de edad sin umbral positivo o información del dominio no disponible. No demuestra por sí solo una recopilación completa o una rotación funcional. Utilice los hallazgos para orientar las mediciones de cuenta y dominio descritas antes, y conserve la evidencia del piloto que demuestra el comportamiento realmente verificado.