Caso prctico Solucin de Active

Directory 2003
Integrantes:
Criales salinas Paolo
Mendoza Vasquez Eduardo
Ormeo Huaman Luigui
Rengifo Almeyda Cristhian
Hernandez Cordero Asly
Vasquez Ccanto Joselyn

Por dnde empezar?

Pues bien, supongamos que tenemos varios sites, y nuestro problema de replicacin est
afectando todo el ambiente, nuestra topologa lgica es en estrella, bsicamente todos los
sites
replican
contra
uno
central.
La clave aqu es simplificar el ambiente en el cual se encuentra el problema, si bien el mismo
afecta a todo el ambiente, centrmonos solamente en dos sitios, tomemos al sitio central, y
algn partner de replicacin. En nuestro caso tomaremos al sitio central, en el cual radica un
controlador de dominio que maneja todos los roles FSMO, como tambin tomaremos a su
partner de replicacin (un sitio remoto), sitio que cuenta con un solo controlador de dominio.
Pongamos los siguientes nombres, como ejemplo:

Nombre del dominio: ejemplo.lab

Nombre

del

sitio

central:

Central

Controlador de dominio en el sitio central: DC01 (con todos los roles FSMO)

Nombre

del

sitio

remoto:

Sucursal

Controlador de dominio en el sitio remoto: DC10

Subred utilizada 192.168.0.0/24

Una vez que tenemos definidos nuestros sitios, comenzaremos a aplicar el siguiente plan de
accin, de manera secuencial, para ir resolviendo los diferentes problemas que se nos
presentan, hasta poder lograr que el ambiente pueda converger y por ende poder llevar a
cabo la replicacin de las particiones de Active Directory de manera exitosa.

Este plan va a estar compuesto por

los siguientes pasos:
1. Topologa
2. Resolucin de nombres
3. Interfaz RPC
4. Seguridad

1. Topologa

Aqu
la
herramienta
de
En el servidor de la sucursal, ejecutar:

diagnstico

bsica

es

repadmin.exe.

c:\>repadmin.exe showreps

En el reporte podemos ver cules son los partners de replicacin definidos para el server de
la
Sucursal
Como la replicacin es inbound (el server inicia la replicacin y se trae los cambios del
partner) nos interesa sobre todo la seccin del reporte que se llama INBOUND NEIGHBORS
En el caso de Sucursal, el reporte muestra:
==== INBOUND NEIGHBORS ======================================
DC=ejemplo,DC=lab
Central\DC01
via
RPC
DC
object
GUID:
de11d929-55f9-4dc6-b702-xxxxxxxxxxx
Last attempt @ 2010-03-03 01:21:50 failed, result -2146893022 (0x80090322):
Cant retrieve message string -2146893022 (0x80090322), error 1815.
200
consecutive
failure(s).
Last success @ (never).
CN=Configuration,DC=ejemplo,DC=lab
Central\DC01
via
RPC
DC
object
GUID:
de11d929-55f9-4dc6-b702-xxxxxxxxxxx
Last attempt @ 2010-03-03 01:21:50 failed, result -2146893022 (0x80090322):
Cant retrieve message string -2146893022 (0x80090322), error 1815.
99
consecutive
failure(s).
Last success @ 2009-11-25 06:23:05.
CN=Schema,CN=Configuration,
DC=ejemplo,DC=lab
Central\DC01
via
RPC
DC
object
GUID:
de11d929-55f9-4dc6-b702-xxxxxxxxxxx
Last attempt @ 2010-03-03 01:21:50 failed, result -2146893022 (0x80090322):
Cant retrieve message string -2146893022 (0x80090322), error 1815.
99
consecutive
failure(s).
Last success @ 2009-11-25 06:23:07.
DC=DomainDnsZones,

DC=ejemplo,DC=lab
Central\DC01
via
RPC
DC
object
GUID:
de11d929-55f9-4dc6-b702-xxxxxxxxxxx
Last
attempt
@
2010-03-03
01:21:50
failed,
result
1256
(0x4e8):
Cant
retrieve
message
string
1256
(0x4e8),
error
1815.
99
consecutive
failure(s).
Last success @ 2009-11-25 06:23:08.

DC=ForestDnsZones,

DC=ejemplo,DC=lab
Central\DC01
via
RPC
DC
object
GUID:
de11d929-55f9-4dc6-b702-xxxxxxxxxxx
Last
attempt
@
2010-03-03
01:21:50
failed, result
1256
(0x4e8):
Cant
retrieve
message
string
1256
(0x4e8),
error
1815.
99
consecutive
failure(s).
Last success @ 2009-11-25 06:23:09.

Este reporte nos muestra el partner para cada uno de los contenedores del AD, y por los
general (a menos que tengamos alguna configuracin particularmente macabra) el partner de
replicacin
maneja
todos
los
contenedores.
En nuestro caso, tenemos el partner que es: Central\DC01.
El servidor es el que se encuentra en la central, que es consistente con nuestro modelo de
replicacin
en
estrella.
Si en algn otro sitio remoto (otra sucursal) vemos que los inbound partner no es el servidor
de Central, entonces tendramos que revisar la definicin de ese site y sus enlaces en el AD
Sites
and
Services
y
forzar
la
regeneracin
de
la
topologa.
En este caso podemos ver que la replicacin inbound ha fallado desde el 25 de nov. del 2009
en ambos servidores.
Last success @ 2009-11-25 06:23:09.

La causa de la falla viene despus:

failed, result 1256 (0x4e8):

El
error
1256
se
traduce
como:
Error
Code
1256
System error code 1256 means "The remote system is not available. For information about
network troubleshooting see Windows Help." This error code may also display as
"ERROR_HOST_DOWN" or as the value 0x4E8. System Error Codes: Code 1200 to Code
1299

2. Resolucin de nombres
Tenemos que verificar
y
el
Para ello podemos
Del reporte de

que el servidor de la Sucursal puede resolver correctamente el nombre

GUID
del
partner
de
replicacin.
ejecutar, en el server de la Sucursal, el comando Nslookup
repadmin podemos ver los GUIDs de los servidores:
Central\DC01
DC object GUID: de11d929-55f9-4dc6-b702-xxxxxxxxxxx

En este caso, las pruebas serian:

c:\>Nslookup
c:\>Nslookup de11d929-55f9-4dc6-b702-xxxxxxxxxxx._msdcs.ejemplo.lab

dc01.ejemplo.lab

El resultado del primer query debe ser la IP actual del server, el resultado del segundo query
debe ser el alias y la IP del server:
C:\>
Nslookup
de11d929-55f9-4dc6-b702-xxxxxxxxxxx._msdcs.ejemplo.lab
Server:
DNSServer.ejemplo.lab
Address:
192.168.0.1
Name:
dc01.ejemplo.lab
Address:
192.168.0.1
Aliases: de11d929-55f9-4dc6-b702-xxxxxxxxxxx._msdcs.ejemplo.lab

Si alguna de estas pruebas retorna la direccin incorrecta, entonces tenemos que verificar la
configuracin del DNS primario en el server remoto y corregir el problema.
Posiblemente sea una buena prctica configurar el DNS primario del servidor remoto a dc01
mientras ponemos a funcionar la replicacin.
Tengamos en cuenta que si cambias la configuracin del DNS en el servidor remoto, lo
recomendable es reiniciar el server o, al menos, ejecutar los comandos:
c:\>Ipconfig
c:\>Net
c:\>Net start netlogon

stop

/registerdns
netlogon

De esta forma estamos asegurando que el server se est registrando en el DNS.

3. Puertos RPC
Cuando estemos seguros que la resolucin esta OK, podemos pasar a probar los puertos
RPC, la mejor herramienta para esto esRPCdump.exe
En el server remoto, ejecuta el comando
c:\>rpcdump /s <partner_dc> /v /i > endpoints.txt

luego
c:\>notepad endpoints.txt

En este caso, el comando seria:

c:\>rpcdump /s dc01.ejemplo.local /v /i > endpoints.txt

En el archivo endpoints.txt, buscamos el UUID e3514235-4b06-11d1-ab04-00c04fc2dcd2

El resultado debe ser igual a:

ProtSeq:ncacn_ip_tcp
Endpoint:1025
NetOpt:
Annotation:MS
NT
Directory
IsListening:YES
StringBinding:ncacn_ip_tcp:xx.xx.xx.xx[1025]
UUID:e3514235-4b06-11d1-ab04-00c04fc2dcd2
ComTimeOutValue:RPC_C_BINDING_DEFAULT_TIMEOUT
VersMajor 4 VersMinor 0

DRS

Interface

Si el valor de IsListening es YES, entonces los puertos 135 y 1025 estn escuchando.
Si el valor de IsListening es NO, tienes un problema de puertos cerrados, bien sea por un FW
intermedio,
o
por
el
FW
de
alguno
de
los
dos
servidores.
Si el archivo no tiene ningn endpoint reportado, entonces el puerto que probablemente est
bloqueado es el 135.

4. Seguridad
Lo primero que hay que hacer es verificar los grupos que tienen derecho a contactar el
servidor por la red (User Rights: Access this computer from the network)
La mejor manera de ver estos derechos es ejecutando
C:\>Rsop.msc

Expandimos: Computer Configuration->Windows Settings->Security Settings->Local Policies>User Right Assignment

Doble click en el derecho llamado Access this computer from the network y verifica que,
como mnimo, los siguientes grupos tienen este derecho:

Everyone

Authenticated Users

Enterprise Domain Controllers

Si este derecho no est otorgado a estos grupos, tendramos que verificar las polticas
aplicadas al dominio (Default Domain Policy) o a los controladores de dominio (Default
Domain Controller Policy).
Verifiquemos que los relojes este sincronizados entre el servidor de la agencia y el PDC del
dominio.
Si los relojes no estn sincronizados y sabes cul es el PDC, puedes usar el comando:
C:\>net time \\pdc /set /y

Si no recordamos el nombre del PDC, tenemos que averiguarlo ? y podemos hacerlo con la
herramienta netdom, entre otras, como sigue:
C:\>netdom query fsmo

Posterior a ellos, deberamos verificar que el servicio KDC est funcionando

En la consola de Active Directory Users and Computers buscamos el objeto del controlador
de domino de la sucursal y verificamos, en la pestaa General, que el check de Trust this
computer for delegation est marcada.
Usando adsiedit.msc expandimos el contenedor Domain, expandimos el objeto del dominio
DC=ejemplo, dc=lab, expandimos la OU=Domain Controllers, y hacemos un click derecho
en
el
objeto
del
controlador
de
dominio
CN=dc10,
por
ejemplo.
Seleccionar Properties y buscar userAccountControl. EL valor de este atributo debe ser
532480. Hacemos esta misma prueba tanto en la maquina remota como en la maquina del
sitio central. La idea aqu es verificar que el valor de este atributo del objeto dc10 sea 532480
en las dos copias del AD.
En el servidor de la agencia, instala el tool klist.exe y ejecuta los siguientes comandos:
C:\>net
C:\>at system_time /interactive cmd.exe

stop

kdc

(donde system_time debe ser la hora local ms uno o dos minutos)

Cuando abramos el command prompt (Esta ventana NO se va a abrir si estas conectado va
TS al servidor. Este paso tienes que hacerlo directo en la consola del server. A menos que
agreguemos el switch /console cuando ejecutas el comando mstsc), ejecuta los comandos
c:\>klist
c:\>ipconfig
c:\>nbtstat -R

purge
/flushdns

Los siguientes pasos son para el reset del secure channel entre los DCs. Este paso es el que
probablemente arregle el problema entre DC01 y DC10. Esto debemos hacerlo en el servidor
que est fallando en traerse la replicacin, en este caso, en los servidores de la sucursal. El
servicio del KDC debe seguir detenido.
Ejecuta el comando
c:\>netdom resetpwd /server:PDCe /userd:ejemplo\Administrator /password:*

En este comando, el server PDCe es el partner de replicacin (que tiene el KDC funcionando,
y que no necesariamente es el KDC del dominio)
En este caso, el procedimiento lo vas a realizar en dc10 y el comando es:
c:\>netdom resetpwd /server:dc01 /userd:ejemplo\Administrator /password:*

Una vez resincronizado el password y desde el server de la sucursal, accedemos al servidor

central con su FQDN para conseguir nuevos tickets Kerberos, por ejemplo:
c:\>net use \\dc01.ejemplo.lab\IPC$

inicia el servicio del KDC

c:\>net start kdc

Los
pasos
siguientes
solo
deben
hacerse
en
el
servidor
DC01
Abrir AD Sites and Services, seleccionar el servidor dc01, y luego NTDS Settings.
Eliminar las conexiones inbound del controlador de dominio con problemas (DC10) y luego
ejecuta
c:\>repadmin /kcc

Para forzar la replicacin con el servidor de la central, ejecutamos el comando:

c:\>repadmin /syncall /d /e dc10 DC=ejemplo,DC=lab

Verificar los SPN registrados. Podemos utilizar

En el servidor de la sucursal, ejecutamos el comando:

el

siguiente

artculo:

KB 308111

ldifde s nombre-server-de-central -f spndump.txt -p base -l servicePrincipalName -d

cn=dc01,ou=Domain Controllers,dc=ejemplo,dc=lab
para exportar de la base de datos local los SPNs que estn registrados del servidor central.
Si en el archivo spndump.txt falta alguno de los 4 SPN del tipo host/*
HOST/dc01
HOST/dc01.ejemplo.lab
HOST/dc01.ejemplo.lab/ejemplo.lab
HOST/dc01.ejemplo.lab/EJEMPLO
Ejecuta el comando:
C:\>setspn a SPN-faltante nombre-server-de-sucursal, por ejemplo:
C:\>setspn a HOST/dc01.ejemplo.lab dc10

Verificar que la fragmentacin de la red no est daando la autenticacin de Kerberos.

Podemos
utilizar
el
siguiente
artculo:
KB 244474
Desde el server de la sucursal, verifica que el comando:
Ping dc01.ejemplo.lab f l 1472.

Si el resultado del comando es el mensaje Packet needs to be fragmented but DF set.

Entonces es posible que exista un problema de fragmentacin del trafico UDP en la red. Este
problema
puede
causar
las
fallas
de
Kerberos.
La opcin aqu es configurar Kerberos para utilizar solo TCP, como se explica en el artculo de
la KB 244474.

Nota: De forma predeterminada, Windows Server 2008 y Windows Vista

intentar TCP primero para Kerberos.
Una vez aplicado el plan de accin, intentamos una replicacin entre los dos sites designados,
obteniendo el siguiente resultado:
DC=ejemplo,DC=lab,
Replication
failed!
CN=Configuration,DC=ejemplo,DC=lab, replicada con xito @ 2010-03-12 05:21:59.
CN=Schema,CN=Configuration,DC=ejemplo,DC=lab, replicada con xito @ 2010-03-12 05:22:00
DC=DomainDnsZones,DC=ejemplo,DC=lab, replicada con xito @ 2010-03-12 05:22:00
DC=ForestDnsZones,DC=ejemplo,DC=lab, replicada con xito @ 2010-03-12 05:22:01.

En resumen, todas las particiones menos la particin de dominio replicaron esta maana a las
5:20.

Lingering Objects
La particin de dominio fall en su intento de replicacin ya que existen lingering objects. Este,
as como tambin problemas de objetos en estado de tombstone, son problemas que de
seguro encontraremos a lo largo del proceso de troubleshooting de la replicacin de Active
Directory. Dichos problemas iremos solucionndolos a medida que avanzamos sobre el plan
aqu enunciado. Continuando con el problema de lingering objects, lo validamos y
solucionamos de la siguiente manera:
Cuando investigamos el log de Directory Services, encontramos errores de lingering objects
que estn bloqueando la replicacin de la particin de dominio.
El evento es el 1988:
Active Directory Replication encountered the existence of objects in the following partition that
have been deleted from the local domain controllers (DCs) Active Directory database. Not all direct
or transitive replication partners replicated in the deletion before the tombstone lifetime number of
days passed. Objects that have been deleted and garbage collected from an Active Directory
partition but still exist in the writable partitions of other DCs in the same domain, or read-only
partitions of global catalog servers in other domains in the forest are known as lingering
objects.
This event is being logged because the source DC contains a lingering object which does not exist
on the local DCs Active Directory database. This replication attempt has been blocked.
The best solution to this problem is to identify and remove all lingering objects in the forest. Source
DC
(Transport-specific
network
address):
de11d929-55f9-4dc6-b702b63e380f6d91._msdcs.ejemplo.lab
Object:
CN=CD075003-Xerox
WorkCentre PE16ADEL:f2343d56-3bc3-44fb-8b3c-52ea1ecc038d,CN=Deleted
Objects,DC=ejemplo,DC=lab Object GUID: f2343d56-3bc3-44fb-8b3c-52ea1ecc038d

User Action: Remove Lingering Objects: The action plan to recover from this error can be found
athttp://support.microsoft.com/id=314282
If both the source and destination DCs are Windows Server 2003 DCs, then install the support tools
included on the installation CD. To see which objects would be deleted without actually performing
the deletion run repadmin /removelingeringobjects <Source DC> <Destination DC DSA GUID>
<NC> /ADVISORY_MODE. The event logs on the source DC will enumerate all lingering objects.
To remove lingering objects
from a source domain controller run
repadmin
/removelingeringobjects <Source DC> <Destination DC DSA GUID> <NC>. If either source or
destination DC is a Windows 2000 Server DC, then more information on how to remove lingering
objects on the source DC can be found at http://support.microsoft.com/?id=314282 or from your
Microsoft support personnel. If you need Active Directory replication to function immediately at all
costs and dont have time to remove lingering objects, enable loose replication consistency by
unsetting
the
following
registry
key:
Registry
Key:
HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Strict
Replication
Consistency.
Replication errors between DCs sharing a common partition can prevent user and computer
accounts, trust relationships, their passwords, security groups, security group memberships and
other Active Directory configuration data to vary between DCs, affecting the ability to log on, find
objects of interest and perform other critical operations. These inconsistencies are resolved once
replication errors are resolved. DCs that fail to inbound replicate deleted objects within tombstone
lifetime number of days will remain inconsistent until lingering objects are manually removed by an
administrator from each local DC. Lingering objects may be prevented by ensuring that all domain
controllers in the forest are running Active Directory, are connected by a spanning tree connection
topology and perform inbound replication before Tombstone Live number of days pass.

Este error indica que el objeto CD075003-Xerox WorkCentre fue borrado en el servidor de la
Sucursal, pero todava existe en el AD del dc01.
Lo que tenemos que hacer es lo siguiente:
En el servidor dc01 ejecuta el comando:
C:\repadmin /removelingeringobjects dc01.ejemplo.lab 19d40098-6fba-44ae-a8a8-4dd35916b89c
DC=ejemplo,DC=lab /ADVISORY_MODE

Este comando va a generar la lista de lingering objects (desde el punto de vista de dc10) que
existen en dc01
Si todo est bien, y conseguimos el objeto, entonces ejecutamos:
C:\repadmin /removelingeringobjects dc01.ejemplo.lab 19d40098-6fba-44ae-a8a8-4dd35916b89c
DC=ejemplo,DC=lab

Una vez realizado la remocin del objeto en estado de lingering, la replicacin de todas las
particiones de Active Directory se realizaron de manera satisfactoria.
Una vez que tenemos la replicacin funcionando entre los dos sites, el central y la sucursal,
deberamos ir tomando las siguientes sucursales, e ir aplicando este plan de accin, repito

que es posible que nos encontremos con problemas adicionales, como ser algn servidor que
se encuentre en estado de tombstone (adjuntamos un artculo sobre cmo tratar este
inconveniente) o algn problema de conectividad, en tales casos deberemos proceder a
resolverlos y continuar con nuestro plan de accin.

Solucin: Las Mquinas que se Salen del Dominio

Este es un tema que se repite, y no desde hace poco tiempo, con bastante frecuencia,
vamos a tratar de que no suceda, y si sucediera cmo solucionarlo
Quin no ha recibido nunca cuando va a iniciar sesin, un mensaje que alerta que se ha
roto la relacin de confianza de la mquina con el Dominio?
Lo importante en realidad es que no suceda, as que primero vamos a conversar un poco
sobre el tema
En un ambiente de Dominio Active Directory las mquinas, durante su arranque, se
autentican/autentifican en el Dominio, casi como lo hace cualquier cuenta de usuario
Cada mquina usa como nombre de cuenta su propio nombre con el agregado de un
signo $ al final. Por ejemplo, una mquina de nombre SRV1, utiliza la cuenta SRV1$
El por qu usa este caracter diferenciador de cualquier otra cuenta, es una historia muy
larga, pero los viejos Dominios con Windows NT no diferenciaban en su estructura (hoy
diramos
Esquema)
un
usuario de
una
mquina
As que este carcter era lo que usaba el sistema operativo para diferenciarlos
Esta contrasea de la cuenta de mquina peridicamente se cambia. A lo largo de las
diferentes versiones de sistema operativo cambi varias veces, pero actualmente es de
30 das. O sea que cada ese perodo la mquina cambia su contrasea. Si puede
avisarle al Controlador de Dominio entonces mejor, pero si no puede, tambin lo hace
Inclusive a partir de Windows Server 2008, para ayudar a paliar estos problemas, los
Controladores de Dominio, no slo mantienen la ltima versin de la contrasea, sino
tambin la anterior
Pero de todas formas, a veces sucede el problema
Primero enumeremos algunas de las condiciones que pueden provocarla:

Mquinas que hace ms de 30 das estuvieron sin conectividad con un

Controlador de Dominio de su Dominio. Puede ser porque estuvieron apagadas o
fuera de la red

Mquinas recuperadas desde una copia de seguridad (Backup) antiguo

Mquinas con sistema operativo de escritorio recuperadas desde un punto de

restauracin

Mquinas virtuales recuperadas desde un punto de restauracin (Snapshot) del

sistema de virtualizacin

Mquinas con direccin de DNS incorrecta. Por ejemplo por no estar configuradas
para usar *solamente* el o los servidores DNS que resuelven el Dominio. Nunca,
nunca, nunca los del ISP o el Router

Mquinas clonadas sin el correspondiente proceso de SYSPREP

Y seguramente podramos comentar an ms

Y cmo lo soluciona la mayora? Bueno la mayora usa el procedimiento que yo llamo
caverncola (Nearthental Process) :-) que consiste en:
1. Sacar la mquina del Dominio a Grupo de Trabajo
2. Reiniciar
3. Borrar la cuenta de mquina en el Dominio
4. Volver a unir la mquina al Dominio
5. Reinciar
Este, el ms comn, es el peor de todos los procedimientos, porque adems del tiempo
que lleva (2 reinicios) cuando se une nuevamente la mquina al Dominio se le asigna un
nuevo SID (SID = Security ID)
Si entrar en detalles, el SID es anlogo a un nmero de documento. El sistema muestra
en la interfaz grfica nombres de mquinas, usuarios y grupos, pero internamente utiliza
sus
correspondientes
SIDs
Anlogamente a un nmero de documento de persona, nunca ese nmero es reutilizado
Como consecuencia, la mquina, que es la misma, para el Domino es otra totalmente
diferente, aunque se llame igual y est configurada exactamente igual, y sea el mismo
hardware, y sea
Y por lo tanto si se estn ejecutando servicios con la cuenta de mquina, o se ha
agregado la mquina a algn grupo para darle ciertos privilegios, todos eso se pierde
irremediablemente
Si quieren, algo un procedimiento un poco menos malo sera igual al anterior pero, en
lugar de borrar la cuenta de mquina, darle con botn derecho a la cuenta de mquina y
seleccionar
Reset
account
La nica ventaja de este mtodo, es que se mantiene el SID, pero es tedioso como el
anterior
Si uno busca un poco en la Web hay muchsimas soluciones del ms variado tipo: scripts
VBS, NLTEST, NETDOM, Powershell, y seguramente ms

Los scripts me parecen una solucin complicada, salvo que lo tuvieran que ejecutar muy
seguido, lo cual implicara otro problema. Ver las causas posibles al principio de la nota, y
qu hay que solucionar
El comando NLTEST estaba en versiones anteriores del sistema operativo, pero en
Windows Server 2012 ya no est
Powershell, sinceramente no he podido probarlo pero aparentemente se solucionara con
Test-ComputerSecureChannel
-Repair
[Agregado] Probado y tambin funciona sin reiniciar igual que NETDOM
Y todo esto, porque encontr que con NETDOM lo solucionaba muy fcilmente, y muy
importante no haba que reinciar
Una acotacin a tener en cuenta, Microsoft tiene una mala costumbre a veces los
modificadores de los comandos, cambian o directamente desaparecen. Lo que estoy
mostrando es sobre un Windows Server 2012 R2. Si tiene otra versin, y la sintaxis le da
error, revise la ayuda con NETDOM /?
Me puse con las mquinas de mi laboratorio VMware de pruebas, y recuper dos
mquinas virtuales con Snapshots lo ms alejados posible en el tiempo para hacer que
se produzca el problema. Fueron un Controlador de Dominio (DC1) y un servidor miembro
(SRV1)
Cre un usuario nuevo en el Dominio, para asegurarme que no se usaran cached
credentials, y trat de inciar sesin en SRV1. Ac est el resultado

Entonces inici sesin con un administrador local del servidor

Inici una lnea de comandos (CMD.EXE) ejecutndola como administrador, y en la

misma us NETDOM con la siguiente sintaxis:
NETDOM
RESETPWD
/PasswordD:<Contrasea>

/s:<NombreDC>

/UserD:<DOMINIO\Administrador>

Y ahora lo interesante. Sin reiniciar el servidor pude inciar sesin con el usuario nuevo
creado al principio, ya est solucionado el problema, sin cambio de SID y muy
rpidamente