Resetear clave kerberos en Controlador de dominio - krb_ap_err_modified

Cada equipo con Windows mantiene un historial de contraseñas de cuentas de equipo que contiene las contraseñas actual y anteriores utilizadas para la cuenta. Cuando dos equipos intentan autenticarse entre sí y aún no se ha recibido un cambio de la contraseña actual, Windows usa la contraseña anterior. Si la secuencia de cambios de contraseña supera dos cambios, los equipos implicados no se pueden comunicar y el usuario puede recibir mensajes de error. Por ejemplo, puede recibir mensajes de error de "Acceso denegado" cuando se produce la replicación de Active Directory.

Este comportamiento también se aplica a la replicación entre los controladores de dominio del mismo dominio. Si los controladores de dominio que no se replican residen en dos dominios diferentes, observe la relación de confianza más detenidamente.

No se puede cambiar la contraseña de cuenta de equipo mediante el complemento Usuarios y equipos de Active Directory, pero puede restablecer la contraseña si usa la herramienta Netdom.exe. La herramienta Netdom.exe se incluye en las herramientas de soporte de Windows.

En el visor de sucesos vamos encontar los siguientes eventos:
Id. de  suceso: 4  - Origen: Kerberos
krb_ap_err_modified

 

Tambien verán eventos de Sistema - NTDS KCC de Advertencia y error.

Utilizar Netdom.exe para restablecer una contraseña de cuenta de equipo

Instale las herramientas de soporte de Windows Server 2003 en el controlador de dominio cuya contraseña desea restablecer. 

1. Si desea restablecer la contraseña para un controlador de dominio de Windows, debe detener el servicio Centro de distribución de claves Kerberos y definir su tipo de inicio en Manual.
2. Quite la caché de vales Kerberos del controlador de dominio donde aparecen los errores. Puede hacerlo si reinicia el equipo o utiliza las herramientas KLIST, Kerbtest o KerbTray.
3. En un símbolo del sistema, escriba el comando siguiente:
   netdom resetpwd /s:servidor /ud:dominio\Usuario /pd:*
   A continuación se ofrece una descripción de este comando:
   • /s:servidor es el nombre del controlador de dominio que se utiliza para establecer la contraseña de cuenta de equipo. Es el servidor donde se ejecuta el KDC.
   • /ud:dominio\Usuario es la cuenta de usuario que realiza la conexión con el dominio que especificó en el parámetro /s. Debe tener el formato dominio\Usuario. Si se omite este parámetro, se utilizará la cuenta de usuario actual.
   • /pd:* especifica la contraseña de la cuenta de usuario que se especificó en el parámetro /ud. Utilice un asterisco (*) cuando se le solicite la contraseña.
   Por ejemplo, el equipo controlador de dominio local es Servidor1 y el controlador de dominio de Windows al mismo nivel es Servidor2. Si ejecuta Netdom.exe en el Servidor1 con los parámetros siguientes, la contraseña se cambia localmente y se escribe de manera simultánea en el Servidor2; asimismo, la replicación propaga el cambio a otros controladores de dominio:
   netdom resetpwd /s:servidor2 /ud:miDominio\administrator /pd:*
4. Reinicie el servidor cuya contraseña ha cambiado. En este ejemplo, se trata del Servidor1.

Una vez reiniciado, si vemos que sigue sin replicar, nos vamos a la MMC Sitios y Servicios de Active Directory, desplegamos el arbol y en cada NTDS Setting de cada Controlador de dominio le damos  Comprobar topología de replicación, esperamos un minuto y forzamos la replica.
Chequeamos que los Controladores de Dominio estén replicando correctamente. Podemos usar la herramienta repadmin /showreps o Replmon.

 

En la imagen se puede ver como se soluciono el error de replica.
Si llega a fallar, volvemos a realizar los pasos nuevamente.

Solucionar reversión de USN en Active Directory

Hace unos dias nos llamaron de una empresa por un problema que tenían en su Active Directory. La cuestión es que hacia unos días unos de sus Controladores de dominio dejaron de replicar despues de un abrupto corte de energía por lo cual los administradores resolvieron restaurar un backup (imagen de disco) que hacian diariamente a través de Symantec Recovery. El problema no solo que no se solucionó sino que la situación se agravó al ver que cuando querían forzar la réplica el Controlador de dominio arrojaba el siguiente error... "el servidor de destino está actualmente rechazando las peticiones de réplica".
Cuando nos dijeron cual era el método de recuperación que habían utilizado, instantaneamente se nos vino la idea de cual era el problema, seguramente se habia producido una reversión de USN. Solo faltaba comprobar y poner manos a la obra.
Antes de comprobar veamos que es una reversión de USN. Veamos un ejemplo para clarificar: (Ejemplo de Microsoft)

1. Un administrador promueve tres controladores de dominio en un dominio. (En este ejemplo, los controladores de dominio son DC1, DC2 y DC2 y el dominio es Contoso.com). DC1 y DC2 están asociados de replicación directos. DC2 y DC3 también están asociados de replicación directos. DC1 y DC3 no son directos los asociados de replicación, pero reciban actualizaciones de origen a través de forma transitiva DC2.
2. Un administrador crea 10 cuentas de usuario que corresponden para los USN de 1 a 10 en DC1. Todas estas cuentas replican a DC2 y DC3.
3. En DC1, se captura una imagen de disco de un sistema operativo. Esta imagen tiene un registro de los objetos que corresponden a los locales de los USN de 1 a 10 en DC1.
4. Los siguientes cambios se realizan en Active Directory:
   • Las contraseñas para todas las cuentas de usuario 10 que estaban creado en el paso 2 se restablecen en DC1. Estas contraseñas se corresponden con los USN (11) a través de 20. Todos los 10 actualizado contraseñas replicar a DC2 y DC3.
   • 10 nuevas cuentas de usuario que se corresponden con los USN 21 a través de 30 se crean en DC1. Estas cuentas de 10 usuario replican a DC2 y DC3.
   • 10 cuentas de equipo nueva que se corresponden con los USN (31) a 40 se crean en DC1. Estas cuentas de 10 equipo replican a DC2 y DC3.
   • 10 nuevos grupos de seguridad que se corresponden con los USN 41 a través de 50, se crean en DC1. Estos grupos de 10 seguridad replican a DC2 y DC3.
5. DC1 experimenta un error de hardware o de un error de software. El administrador utiliza un utilidad de imágenes de disco para copiar el sistema operativo imagen que se creó en el paso 3, en su lugar. DC1 se inicia ahora con un activo Base de datos de directorio que tenga conocimiento de los USN de 1 a 10.
   
   Debido a que se ha copiado la imagen del sistema operativo en su sitio y  no se ha utilizado la restauración del estado del sistema, DC1 sigue utilizando el mismo ID. de invocación que creó la copia inicial de la base de datos y todos los cambios hasta a 50 de USN. DC2 y DC3 mantienen el mismo identificador de invocación de DC1 así como unvector de actualizaciónde 50 de USN de DC1.

El problema surge de la restauración, ya  que la imagen creada al disco no admite la restauracion del Estado del Sistema correctamente. 
Para solucionar este invonveniente, tenemos dos vías.
Primer caminio:  Restaurar el estado de sistema de un respaldo realizado con un software que admita el respaldo/restauración del active Directory.

Segundo camino: Elegir un controlador de dominio como principal y forzar a los demás a la despromoción y borrado de metadatos. Luego promocionar nuevos Controladores de dominio.
  

Resguardando emails

A raíz de un fallo en el servicio de Outlook (antes Hotmail) que dejó sin correos electronicos a miles de personas la semana pasada, recibí muchas consultas sobre como resguardar aquellos correos electrónicos tan preciados que tenemos almacenado en nuestro buzón.

Existen varios mecanismos que podemos utilizar con tal fín, pero todos tienen sus ventajas y desventajas. Es por esto que vamos a utilizar uno que a mi entender es el mas simple de configurar y además es un sistema online, por lo cual lo vamos a poder acceder desde cualquier lugar que tengamos acceso a internet. La idea es simple, tener una cuenta de correo en GMAIL que contenga todos los correos de nuestra cuenta en Outlook.

Vamos a empezar, entes que nada hay que tener en cuenta que solo se sincronizan aquellos correos que se encuentran en la bandeja de entrada.

Lo primero es registrarnos en gmail.com y obtener una cuenta de correo. Una vez que ingresamos a ella la configuramos para que obtenga todos los correos que nos llegan a Outlook. Para esto nos vamos a Configuración. (Ver imagen)

Allí nos aparecerá una ventana como la siguiente y seleccionamos la opción Reenvío y correo POP/IMAP.

Acá nos tenemos que fijar que el estado POP esté habilitado. Si no lo está, lo habilitamos y nos vamos a la sección Cuentas.

Allí debemos ir donde dice Añadir una cuenta de correo POP3 tuya y seguimos los pasos tal cual muestra las siguientes imágenes:

Ingresamos nuestra cuenta en Outlook/Hotmail que queremos resguardar:

 Ingresamos la contraseña de nuestra cuenta y tildamos donde dice Dejar una copia de los mensajes recuperados en el servidor y le damos añadir cuenta.

Listo. Nuestra cuenta de Gmail estará sincronizando nuestra bandeja de entrada de Hotmail/Outlook cada pocos minutos.

Cambiar hostname en Solaris 11

Con Solaris 11 el cambio de hostname se realiza de forma diferente a lo que estabamos acostumbrados a Solaris 10. Veamos como hacerlo: 

1 - Primero chequeamos la configuracíón actual:

root@solaris11:~# svccfg -s system/identity:node listprop config
config                 application       
config/enable_mapping boolean     true
config/nodename       astring     solaris11
config/loopback       astring     solaris11

2 - Seteamos el nuevo hostname a nuevo-hostame

root@solaris11:~# svccfg -s system/identity:node setprop config/nodename="nuevo-hostame"
root@solaris11:~# svccfg -s system/identity:node setprop config/loopback="nuevo-hostame"

3- Refrescamos las propiedades:

root@solaris11:~# svccfg -s system/identity:node refresh

4 - Reiniciamos el servicio:

root@solaris11:~# svcadm restart system/identity:node

5 - Verificamos que los cambios se hayas realizado:

root@solaris11:~# svccfg -s system/identity:node listprop config
config                 application       
config/enable_mapping boolean     true
config/nodename       astring     nuevo-hostame
config/loopback       astring     nuevo-hostame

root@solaris11:~# hostname
nuevo-hostame

Si nos fijamos en el último paso, el hostname del prompt no ha cambiado. Tenemos que cerrar el shell y abrirlo y ya se verá el cambio.