Share via

Restaurando un Backup del System State después que la contraseña del DC ha cambiado dos veces.

  • Article

Hace unos meses después de participar en un evento interno, discutía con mi colega Karam Masri y otros PFE cuál sería la casuística observada al recuperar un backup del system state en un DC , de forma no autoritativa, si la contraseña del controlador había cambiado dos veces desde esa copia seguridad… esto por supuesto asumiendo que la contraseña no está en la lista N-2 conservada por defecto…

Como bien es sabido las contraseñas de equipo se actualizan,  si la política de dominio no se modifica, con una frecuencia de cada 30 días. Esto quiere decir que restaurar un copia de seguridad de más de 120 días, es decir N-3, que en muchos casos seria valida ya que no supera el Tombstone Lifetime (TSL) del dominio podría resultar problemático.

 

Tras esta conversación, Karam decidió hacer un laboratorio y me gustaría contarles los resultados

Escenario:

  • 2 DCs (DC1 & DC2), contoso. com
  • Se tomó un system state backup de DC1
  • Usando netdom, 3 veces para cambiar la contraseña de DC1, el cambio se sincroniza correctamente a DC2 (se verifica el version number del atributo password”") . netdom /resetpwd /server:dc1 /userd:administrator /password:*

Hecho esto, se procede con la restauración del System State en DC1 y nos encontramos con:

1) DC1 puede replicar de DC2.  Esto se debe a que DC1 puede auto emitirse un TGS de replicación para el SPN de DC2 usando la contraseña actual de dicho controlador de dominio. Ya que la contraseña de maquina en el registro y la base de datos de DC1 es la misma (producto de la restauración), la session key del TGS puede descifrarse correctamente.

2) DC2 no puede replicar de DC1. Esto se debe a que el TGS que DC2 se autoemite usa la contraseña más reciente de DC1, y entonces DC1 no puede validar el authenticator (Se observa el error ERR_MODIFIED de Kerberos en el visor de sucesos).

 

Si se ejecuta repadmin /replsummary desde DC1 muestra el estatus de ambos controladores, mientras que al ejecutarlo en DC2 reporta errores contactado al DC1.

Aquí, tomando en cuenta que DC1 había replicado correctamente desde DC2, se reinicia DC1 para verificar si como parte de la replicación de su propio objeto de computador actualiza la copia de su contraseña que conserva en el registro. La realidad es que lo que paso:

1) DC1 deja de replicar de  DC2 (access denied error). La razón es que el TGS auto emitido para el SPN de replicación de DC2 tiene la session key cifrada con la nueva contraseña en base de datos, pero el proceso está usando la contraseña antigua (en el registro) para intentar descifrar. DC2 rechaza el autenticador otro error Kerberos  ERR_MODIFIED.

2) Al igual que antes del reinicio, DC2 no puede replicar de DC1.

El comportamiento de repadmin /replsummary es el mismo

 

Esto quiere decir que para poder resolver este escenario, la contraseña tendría que ser reiniciada en DC1 con su servicio de KDC (Kerberos Distribution Center) detenido, y luego la replicación forzada de DC2 a DC1.

Es importante resaltar que este laboratorio no asumió que la contraseña de DC2 hubiera cambiado desde que el backup se ejecutó, por lo que el comportamiento sería diferente y seguro la replicación inicial entre DC1 y DC2 no se llevaría a cabo.

 

Espero les sea de ayuda, puede ser un escenario bastante observable.... y como se dice... es major saberlo y no necesitarlo.... que estar urgido y no tener idea.....