Limpieza de SIDHistory tras migraciones de AD

sIDHistory existe por una buena razón: cuando un usuario o un grupo se traslada de un dominio a otro, conserva sus SID antiguos para que los recursos que siguen con permisos para la identidad antigua sigan funcionando. En la práctica, las migraciones terminan, los dominios de origen se retiran y los SID antiguos permanecen en miles de objetos durante una década. Cada uno de esos valores es una identidad adicional que viaja en el token del usuario y un lugar en el que un atacante con suficientes derechos puede ocultar privilegios: un valor de historial de SID que apunta a Domain Admins concede derechos de Domain Admins sin aparecer en la lista de miembros del grupo.

El pilar sobre confianzas y límites de bosque trata el filtrado del historial de SID en la confianza. Esta guía se centra en los propios objetos: encontrar todos los valores de sIDHistory, separar las entradas peligrosas de los restos de migraciones, volver a asignar permisos a los recursos para que los SID antiguos dejen de ser necesarios, eliminar los valores por fases y supervisar para que no aparezcan otros nuevos sin que nadie lo advierta.

Antes de tocar nada, acuerde quién es el responsable. La limpieza del historial de SID afecta a los equipos de identidad, servidores de archivos, aplicaciones y seguridad, y cuando falla, los usuarios finales lo notan. Designe un responsable del programa, un contacto por aplicación y un plan de comunicación que indique a los usuarios piloto qué deben notificar y dónde.

Por qué el historial de SID residual es un riesgo

• Privilegios ocultos. Los tokens incluyen el historial de SID, así que un usuario normal con el SID de un grupo privilegiado en sIDHistory es, a efectos prácticos, miembro de ese grupo. Las revisiones de pertenencia a grupos, adminCount y la mayoría de los informes de administradores no lo muestran.
• Persistencia. Agregar historial de SID requiere normalmente la API de migración con derechos de Domain Admin en el dominio de destino, pero un atacante que ya ha alcanzado Tier 0 puede escribirlo directamente con herramientas como Mimikatz o DSInternals. Sobrevive a los restablecimientos de contraseña y es fácil pasarlo por alto durante la respuesta a incidentes.
• Tokens sobredimensionados. Los usuarios con muchos SID antiguos y muchos grupos pueden superar los límites de tamaño del token Kerberos, lo que provoca errores de autenticación intermitentes.
• Exposición de la confianza. Si mantiene el historial de SID funcionando a través de una confianza, tiene que dejar relajado el filtrado de SID, lo que debilita la propia confianza. Consulte Filtrado de SID y autenticación selectiva.

Medir: inventariar todos los valores

$forestSids = (Get-ADForest).Domains | ForEach-Object { (Get-ADDomain $_).DomainSID.Value }

Get-ADObject -LDAPFilter "(sIDHistory=*)" -Properties sIDHistory, objectClass, samAccountName, whenChanged |
  ForEach-Object {
    $obj = $_
    foreach ($sid in $obj.sIDHistory) {
        $prefix = $sid.AccountDomainSid.Value
        [pscustomobject]@{
            Object       = $obj.samAccountName
            Class        = $obj.objectClass
            HistorySid   = $sid.Value
            SourceDomain = $prefix
            Rid          = [int]($sid.Value.Split('-')[-1])
            Builtin      = $sid.Value.StartsWith('S-1-5-32-')
            SameForest   = $forestSids -contains $prefix
            WhenChanged  = $obj.whenChanged
        }
    }
  } | Export-Csv .\sidhistory-inventory.csv -NoTypeInformation

Ejecútelo en cada dominio del bosque. El CSV es su línea de base y la evidencia que necesitará más adelante, ya que los valores eliminados no pueden volver a escribirse sin más.

Agrupe los resultados por SourceDomain. Normalmente verá uno o dos SID de dominios antiguos, uno por cada migración histórica, y un recuento de objetos para cada uno. Asocie cada prefijo a un dominio de origen conocido a partir de los registros de migración; si el origen sigue existiendo y hay una confianza establecida, Translate() sobre un SID de muestra lo resolverá.

Auditar: clasificar por riesgo

Clasifique cada valor en una de estas tres categorías.

Crítico: investigar como incidente

• SameForest es True. Las migraciones legítimas copian SID del dominio de origen al dominio de destino; un valor de su propio bosque, y en especial del mismo dominio, no es un artefacto de migración.
• Rid es inferior a 1000, sea cual sea el dominio, en particular 500, 512, 518 y 519, o Builtin es True, en particular S-1-5-32-544 (Administrators). Los SID integrados no llevan prefijo de dominio, así que SourceDomain aparece vacío para ellos. Los RID y SID privilegiados integrados en el historial de SID son una técnica de persistencia clásica.
• Valores en objetos cuyo whenChanged es muy posterior a la última migración conocida.

No se limite a eliminarlos. Capture el objeto y sus metadatos (repadmin /showobjmeta indica el DC de origen y la hora del cambio de sIDHistory) y revise sus registros de eventos en busca de los eventos 4765 y 4766 en torno a ese momento. Después, elimine el valor y rote las credenciales de la cuenta.

Heredado con dependencias activas

Valores de un dominio de origen que todavía tiene recursos con permisos asignados a sus SID: servidores de archivos migrados con los permisos intactos, aplicaciones con ACL que usan SID antiguos, inicios de sesión de SQL. Primero hay que volver a asignarles permisos.

Heredado sin dependencias

Valores de un dominio de origen que se retiró hace años y cuyos recursos se reconstruyeron. Suelen ser la mayoría y pueden eliminarse con seguridad tras un piloto.

Aplicar: volver a asignar permisos antes de eliminar

El objetivo es sustituir cada ACE que haga referencia a un SID antiguo por otra que haga referencia al SID actual de la misma entidad de seguridad. Herramientas:

• La traducción de seguridad de ADMT (asistente Translate Objects) funciona si ADMT y la base de datos de migración siguen existiendo.
• icacls /substitute sustituye un SID por otro en las ACL NTFS: icacls D:\Shares /substitute <OldSID> <NewSID> /t /c. Use antes /save para conservar una copia restaurable de las ACL.
• Los permisos a nivel de aplicación (inicios de sesión de SQL asignados a SID antiguos, permisos de buzones de Exchange, permisos de sitios de SharePoint) necesitan sus propias herramientas.

Localice lo que hace referencia a SID antiguos en los servidores de archivos antes y después de la traducción:

$oldPrefix = "S-1-5-21-1111111111-2222222222-3333333333"   # SID del dominio de origen antiguo
Get-ChildItem D:\Shares -Directory -Recurse -ErrorAction SilentlyContinue |
  ForEach-Object {
    $rules = (Get-Acl $_.FullName).GetAccessRules($true, $true, [Security.Principal.SecurityIdentifier])
    $hits  = $rules | Where-Object { $_.IdentityReference.Value -like "$oldPrefix-*" }
    if ($hits) { [pscustomobject]@{ Path = $_.FullName; Count = @($hits).Count } }
  }

Una ACE de una entidad de seguridad cuyo único vínculo con el SID antiguo es el historial de SID se resuelve en la interfaz gráfica como el nombre de la cuenta actual; por eso los análisis de ACL deben trabajar con SID sin procesar y no con nombres para mostrar. Incluya también las ACL de los objetos de AD: las delegaciones en las OU a veces hacen referencia a grupos migrados por su SID antiguo. La guía de auditoría de ACL explica cómo volcarlas.

Aplicar: eliminación por fases

Elimine por oleadas: empiece por un piloto con usuarios de TI, continúe con los departamentos y deje los grupos para el final (el historial de SID de un grupo afecta a todos sus miembros).

# Eliminar todo el historial de SID de un objeto, registrando lo eliminado
$user = Get-ADUser "jdoe" -Properties sIDHistory
$user.sIDHistory | ForEach-Object { "{0};{1}" -f $user.SamAccountName, $_.Value } |
  Add-Content .\sidhistory-removed.log
foreach ($sid in $user.sIDHistory) {
    Set-ADUser $user -Remove @{ sIDHistory = $sid.Value }
}

# Eliminar solo los valores de un dominio antiguo concreto en un grupo piloto
$oldPrefix = "S-1-5-21-1111111111-2222222222-3333333333"
Get-ADGroupMember "SIDH-Pilot" | Get-ADUser -Properties sIDHistory |
  ForEach-Object {
    $u = $_
    $u.sIDHistory | Where-Object { $_.AccountDomainSid.Value -eq $oldPrefix } |
      ForEach-Object { Set-ADUser $u -Remove @{ sIDHistory = $_.Value } }
  }

Para los grupos, use Set-ADGroup con la misma sintaxis -Remove. Los usuarios reciben el cambio en su siguiente inicio de sesión, cuando se emite un nuevo TGT; pida a los usuarios piloto que cierren sesión y vuelvan a iniciarla, o espere a que caduquen los tickets. Mantenga cada oleada durante un ciclo de negocio completo, incluidos los procesos de cierre de mes, antes de continuar.

La reversión es limitada. No puede volver a escribir sIDHistory con Set-ADUser -Add. Las opciones son repetir una migración con ADMT (solo si el dominio de origen sigue existiendo) o una restauración autoritativa de los objetos afectados desde una copia de seguridad. Por eso la reasignación de permisos y los pilotos van primero.

Planificar el programa de forma realista

En un entorno grande, la limpieza lleva meses, no días, y el orden importa:

1. Semana 1: hallazgos críticos. Los SID del mismo bosque y los RID privilegiados se tratan de inmediato como hallazgos de seguridad, con independencia del resto.
2. Mes 1: evidencia. Complete el inventario en todos los dominios, identifique cada dominio de origen y ejecute análisis de ACL en los servidores de archivos y las bases de datos de las aplicaciones. Calcule el número de ACE que hay que traducir por dominio de origen; es esa cifra, y no el número de objetos, la que determina el esfuerzo.
3. Meses 2-3: traducción. Vuelva a asignar permisos primero en los servidores de archivos, ya que concentran la mayoría de las ACE con SID antiguos, y después en las aplicaciones. Conserve exportaciones de las ACL de antes y después.
4. Meses 3-6: oleadas de eliminación. Piloto, departamentos y después grupos, con al menos un cierre de mes entre oleadas.
5. Por último: la confianza. Cuando no quede ningún valor de un dominio de origen de confianza, vuelva a habilitar el filtrado de SID en esa confianza, o elimine la confianza por completo si solo existía para la migración.

Siga el progreso con dos cifras que se comunican a la dirección: objetos que aún tienen sIDHistory y ACE que todavía hacen referencia a SID antiguos. Ambas deben llegar a cero; una línea plana suele indicar que un equipo de aplicaciones está bloqueado y necesita ayuda, no un recordatorio.

Verificar y supervisar

# Valores restantes, por dominio de origen
Import-Csv .\sidhistory-inventory.csv | Group-Object SourceDomain | Select-Object Name, Count
(Get-ADObject -LDAPFilter "(sIDHistory=*)").Count

# ¿Queda algún historial de SID del mismo dominio? Debería ser cero
$domainSid = (Get-ADDomain).DomainSID.Value
Get-ADObject -LDAPFilter "(sIDHistory=*)" -Properties sIDHistory |
  Where-Object { $_.sIDHistory.AccountDomainSid.Value -contains $domainSid } | Select-Object Name

Para la detección continua, genere alertas sobre:

• 4765 (se agregó historial de SID a una cuenta) y 4766 (un intento de agregar historial de SID falló). Fuera de una migración planificada, cualquier 4765 es un incidente.
• 5136 sobre el atributo sIDHistory, que requiere la auditoría de Directory Service Changes y una SACL en los objetos de usuario y de grupo.
• 4738 y 4742 cuando cambia el campo SID History.

Herramientas como BloodHound y PingCastle también informan del historial de SID que apunta a grupos privilegiados; incluya esas comprobaciones en su evaluación periódica.

Qué se rompe

• El acceso a recursos que siguen con permisos asignados a SID antiguos: los recursos compartidos de archivos, las impresoras, los roles de aplicaciones y los inicios de sesión de SQL devuelven acceso denegado a los usuarios cuyo historial de SID se eliminó antes de la traducción.
• La eliminación del historial de SID de un grupo afecta a todos sus miembros a la vez; una sola ACL olvidada puede dejar sin acceso a todo un departamento.
• El acceso a través de la confianza que dependía silenciosamente del historial de SID mediante una confianza relajada deja de funcionar, que es también el momento en el que puede volver a habilitar el filtrado.
• Las nuevas ejecuciones de ADMT para revertir necesitan el dominio de origen, la confianza y la base de datos de migración, que a menudo ya no existen.
• Los scripts y los informes que resolvían SID antiguos en nombres a través del historial de SID muestran SID sin procesar.

Lecturas relacionadas: el tema Confianzas y diseño de bosque, el pilar de auditoría y detección para la directiva de auditoría en la que se basan los eventos 4765 y 5136, y la gestión de rutas de ataque para seguir los privilegios ocultos junto con las rutas de ACL.