Ir al contenido principal

Error id 12294, La base de datos SAM no pudo bloquear la cuenta de administrador...

Últimamente hemos estado teniendo un problema de esos que a todo administrador de sistemas le trae de cabeza... Al menos hasta que lo ha solucionado una vez. Para aquellos de vosotros que habéis llegado hasta aqui después de toparos con el en vuestro trabajo diario y no sabeis muy bien que hacer, voy a indicaros paso por paso como solucionarlo.


El error consiste en el intento reptitivo de bloqueo de la cuenta de Administrador del dominio por parte de una maquina del dominio. Estos errores se generan en el registro de eventos de sistema con el id 12294 y con origen Directory-Services-SAM si es Windows 2008 o SAM si es Windows 2003 o anterior.




El error en si no aunque parece grave, no debe preocuparnos tanto, ya que la cuenta de administrador de dominio nunca se bloquea. Lo que si nos molestara mas, es el hecho de que estos errores saturan nuestro log de eventos de sistema, así como el registro de seguridad del DC.




El problema que nos encontramos cuando intentamos solucionar este error, es que con la configuración por defecto del controlador de dominio, no podemos saber cuál es la maquina que está realizando las peticiones erróneas (bien porque se haya cargado algún servicio con la cuenta de administrador de dominio con una contraseña errónea o bien porque haya en la red un equipo infectado con virus que esté realizando ataques de diccionario contra nuestro DC). Para poder averiguarlo, necesitamos colocar el servicio NETLOGON en modo debug para registrar los intentos de logon erróneos por contraseña incorrecta.

Para hacer lo anterior, tenemos dos opciones. La primera, es modificar en el registro de windows el parámetro:


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DBFlag

Y asignarle el valor hexadecimal: 2080FFFF Esto activara el modo debug del servicio NETLOGON. Para que entre en funcionamiento, deberemos resetear el servicio, para lo cual introduciremos los comandos:

net stop netlogon

Seguido de:

net start netlogon

En una ventana de comandos. Cuando queramos detener el modo debug, realizaremos los mismos pasos, pero asignando el valor 0x0

La segunda opción, bastante más sencilla, se puede utilizar si tienes Windows 2008 o superior o bien si tienes Windows 2003 o inferior con las support tools instaladas. Para activar el modo debug, usaremos el comando:


nltest /dbflag:0x2080ffff

Y para desactivarlo, usaremos:

nltest /dbflag:0x0

No haciendo falta en este caso, reiniciar el servicio.


Una vez que tenemos el modo debug activado, lo hemos dejado un rato funcionando y después lo hemos parado, nos dirigiremos a la carpeta debug dentro de la carpeta de instalación de Windows, y realizaremos una copia del fichero "Netlogon.log" Para trabajar con más comodidad. Lo abrimos, y buscamos la siguiente línea:

[MISC] DbFlag is set to 2080ffff

Esta línea indica que se ha habilitado el modo debug, y a partir de ella, comienza la traza de uso del servicio NETLOGON. Lo siguiente que tenemos que hacer es buscar líneas parecidas a estas:

[LOGON] USERSAD: SamLogon: Transitive Network logon of USERSAD\Administrador from CGARCIACDKXP (via MADRID-DC02) Entered

[LOGON] USERSAD: SamLogon: Transitive Network logon of USERSAD\Administrador from CGARCIACDKXP (via MADRID-DC02) Returns 0xC000006A

La primera línea indica que se ha realizado una petición de logon, el usuario que la ha realizado, la maquina desde la que lo ha hecho y el controlador de dominio que ha atendido la petición. La segunda línea, nos indica los mismos datos, pero además nos muestra el código que ha devuelto dicha petición. Este código es el que nos indica que ha sucedido con esa petición. Aquí os dejo la lista completa de los códigos que se pueden devolver (podéis ver el artículo de Microsoft aquí):

0xC0000234 User logon with Account Locked

0xC000006A User logon with Misspelled or bad Password

0xC0000072 User logon to account disabled by Administrator

0xC0000193 User logon with Expired Account

0xC0000070 User logon from unauthorized workstation

0xC000006F User logon Outside authorized hours

0xC0000224 User logon with "Change Password at Next Logon" flagged

0xC0000071 User logon with Expired Password

0xC0000064 User logon with Misspelled or Bad User Account

Para solucionar nuestro problema, buscaremos líneas con los códigos terminados en 234 o 6A, que son los que indican bloqueo de cuenta. Una vez que hayamos localizado la maquina que está realizando las peticiones, accederemos a ellas y comprobaremos que los servicios estén correctamente configurados, que no tenga sesiones de terminal server ni carpetas abiertas o mapeadas contra nuestro servidor usando una cuenta de administrador errónea, y por último, que no tenga virus.

Saludos.

Comentarios

  1. Eres el puto amo Gordi...estoy tan cabreado que sólo tengo ganas de partir cabezas....es una pena que nos traten como carnaza...en fin....

    Tal vez, podamos algún día eliminar juntos todo el AD y todo el names en un ataque de furia...;-)

    Bueno, no viene a pelo del blog, lo se, pido disculpas...

    Uno que se sentaba enfrente tuya...

    ResponderEliminar
  2. Excelente, de gran ayuda

    ResponderEliminar
  3. Tremendamente útil. Ahora ya se que ordenador tirar por la ventana.

    Gracias

    ResponderEliminar
  4. Ya, es un poco rebuscado, te dan ganas de colgar al culpable (a no ser que hayas sido tu mismo, claro). Me alegro que os haya sido de ayuda.

    Saludos.

    ResponderEliminar
  5. Muchas gracias por el aporte, muy bueno

    ResponderEliminar

Publicar un comentario

Entradas populares de este blog

Solucionar Error 8344 “Insufficient access rights to perform the operation.” En Azure AD connect

Ayer termine de instalar y configurar Azure AD connect. Para los que no lo sepáis, Azure AD connect es el programa que se utiliza para sincronizar objetos de tu directorio activo local con el directorio activo de azure. Podéis acceder a la estupenda documentación de Microsoft aquí. El caso es que después de terminar la configuración, estuve repasando que las primeras sincronizaciones fueran correctas cuando vi que aparecía una tarea con errores en Azure AD sync service. El fallo era el siguiente: Como podéis ver, esta tarea de export, que ya os voy diciendo que era una sincronización de contraseñas, falla por un problema de permisos. La verdad es que era un poco confuso, ya que había seguido la documentación de Microsoft para la implementación al pie de la letra y cumplido todos los prerrequisitos. ¿Se me escapaba algo? Al final, la respuesta era bastante sencilla. Este directorio activo no lo desplegué yo, así que hay algunas cosillas “heredadas”. Una de ellas es que una Unidad Organi

DNS y reenviadores condicionales...

Resulta que estamos migrando a Windows 2008 R2 para poder poner GPOs personalizadas por OU, y el otro día nos surgió un problemilla relacionado con los reenviadores condicionales del servicio DNS en 2008 (anteriormente, los teníamos en 2003 R2). Se nos paso configurar el reenvío de las peticiones de nuestro subdominio principal a nuestro dominio raíz, lo cual, teníamos hecho mediante el uso de reenviadores condicionales. Entramos en el nuevo servidor DNS para configurarlos y @_@ ¡¡no estaban!! Resulta que los amigos de Microsoft han cambiado las pestañas de opciones del servidor DNS y las han dejado así: Como podéis ver, el reenvío de peticiones basado en sufijo, ha desaparecido. Aparentemente solo se permite el reenvío global de peticiones, ¿no? Bueno, pues no, solo lo han cambiado de sitio. Con Windows 2003, cuando querías configurar el reenvío de peticiones DNS basado en dominio, tenias que hacerlo servidor por servidor, ya que la pestaña correspondiente, se encontraba dent