On the way to Virtualization

Microsoft ha detectado un elevado número de casos de soporte relacionados con problemas de autenticación NTLM tras la instalación del parche MS15-027. (KB30002657)

La recomendación pasa por probar extensivamente el parche antes de ponerlo en producción o considerar posponer la instalación del mismo hasta que el grupo de producto (el cual está activamente investigando este incidente) haya podido encontrar la causa raíz del problema y nos proporcione una solución al mismo.

Los síntomas que pueden aparecer son diversos e incluyen los siguientes:

1. Clientes Outlook no pueden conectar a servidores Exchange
2. Falla el autodiscover de Outlook
3. El transporte de correos puede verse impactado
4. Las sesiones RDP fallan
5. El acceso a carpetas compartidas falla
6. La autenticación NTLM falla con el mensaje 0xc000006d / STATUS_LOGON_FAILURE
7. Otros…

En el KB se describe parte del problema;

http://support.microsoft.com/kb/3002657

1. Introducción a la migracion:
El procedimiento de migración se basa en líneas generales en un backup de la base de datos y logs de las Autoridades de Certificación en la PKI Windows Server 2003 y una restauración de los mismos en una PKI nueva Windows Server 2012. También, se realiza una exportación de la configuración del servicio de certificados de las Autoridades de Certificación en la PKI Windows Server 2003 y una importación en la PKI Windows Server 2012.

Todo este procedimiento se basa en la siguiente documentación:

http://technet.microsoft.com/en-us/library/ee126102(v=ws.10).aspx
http://technet.microsoft.com/es-es/library/cc742515(v=ws.10).aspx
http://blogs.technet.com/b/xdot509/archive/2013/07/07/upgrading-your-pki-to-windows-server-2012-new-video.aspx
http://technet.microsoft.com/es-es/library/65bf928e-ea43-4849-94b4-79ea2e5b6a48#BKMK_BackupCAPolicy
http://technet.microsoft.com/es-es/library/dn486797.aspx

2. Preparando el entorno de origen.
Antes de empezar la migración se tienen que realizar dos pasos importantes:
 Ampliar el periodo de validez de las CRLs.
 Backup de las Autoridades de Certificación.

2.1. Ampliar el periodo de validez de las CRLs.
Antes de comenzar la migración de la CA, se recomienda ampliar el periodo de validez de la CRL más allá de la duración prevista de la migración. Esto es necesario para permitir la validación de certificados durante el proceso de migración.
Recomendamos por tanto realizar una publicación manual de la CRL para resetear el tiempo de validez de la misma, o bien asegurarnos de tener un intervalo de publicación (tanto base como delta) suficientemente largo.
Podéis encontrar más información sobre ambos aspectos en los siguientes artículos:
Manually publish the certificate revocation list
http://technet.microsoft.com/library/cc778151(WS.10).aspx
Schedule the publication of the certificate revocation list
http://technet.microsoft.com/library/cc781735(WS.10).aspx
Mostramos una captura de ejemplo de la ventana de configuración de los tiempos de publicación de la CRL:

 2.2. Backup de la CAs origen
El siguiente paso es hacer un backup de las CA origen abarcando desde el propio servidor hasta las plantillas de la CA. Para ello, podéis seguir los siguientes pasos:
2.2.1. Backup del servidor:
Realizar un backup del system state de la CA origen siguiendo los pasos descritos en el apartado “To Back Up the System State (Including Registry Settings)” del siguiente artículo:
How to use the backup feature to back up and restore data in Windows Server 2003
http://support.microsoft.com/kb/326216/en-us

2.2.2. Backup de la lista de plantillas
o Entrar con privilegios de administrador en la CA.
o Abrir un CMD.
o Ejecutar: certutil.exe –catemplates > catemplates.txt
o Comprobar que el fichero catemplates.txt contiene la lista de plantillas.

2.3. Backup del algoritmo de firma y CSP.
Durante la instalación de la CA en el servidor de destino, se puede especificar el algoritmo de firma y CSP utilizados por dicha CA, o aceptar la configuración por defecto. Si la CA origen no está usando la configuración por defecto, deberíamos llevar a cabo el siguiente procedimiento para guardar ambos datos:
o Entrar con privilegios de administrador en la CA.
o Abrir un CMD.
o Ejecutar: certutil.exe –getreg ca\csp\* > csp.txt
o Comprobar que el fichero csp.txt contiene los datos del CSP.

3. Migración de la CA.
A partir de ahora entramos en el procedimiento de la migración de los datos de la CA antigua a la nueva. Dentro del mismo hay diferentes pasos que iremos describiendo a continuación.

3.1. Backup de la base de datos de la CA y clave privada.
En este paso realizaremos un backup de diferentes datos de la CA, por lo que debemos decidir una localización donde guardarlos. Como ejemplo en esta guía supondremos la carpeta C:\backup\. Los pasos son:
 Entrar en la CA.
 Abrir la consola de Certification Authority.
 Botón derecho sobre el nombre de la CA, All Tasks, Back up CA…

 En la siguiente pantalla hacemos click en Next.

 En la siguiente ventana se seleccionamos los dos checkboxes siguientes:

o Private key and CA certificate.

o Certificate database and certificate database log.

Con estas dos opciones hacemos backup de la base de datos y los logs de la Autoridad Certificadora, de su certificado y clave privada. Además, indicamos la ruta donde alojaremos estos archivos, que en esta guía va a ser C:\backup\Cabackup.

Establecemos la contraseña para cifrar el certificado y la clave privada

Para finalizar hacemos click en Finish.

En la carpeta C:\backup\Cabackup se guardan los siguientes archivos:

 certbkxp.dat

 edb#####.log

 CAName.edb

 CAName.p12 file

3.2. Backup de CertSvc Configuration

El siguiente paso será realizar una exportación de la clave del registro donde se almacenan la configuración de la CA y guardarla en la carpeta C:\Backup\CAConfigBackup.

 Ir a la siguiente clave de registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\

 Click con botón derecho sobre Configuration, Save, e indicar la localización donde guardarlo, por ejemplo C:\Backup\CAConfigBackup.

3.3. Backup de CAPolicy.inf

Si la CA de origen utiliza un fichero CAPolicy.inf personalizado, debemos copiar este fichero a nuestra carpeta de backup. Normalmente este fichero está en %systemroot% (por defecto C:\Windows).

3.4. Eliminación del rol de Certificate Services de la CA origen.

Es importante quitar el rol de CA del servidor de origen después de completar el backup, y antes de instalar el mismo rol en el servidor destino. Las CAs Enterprise y Standalone que son miembros de un dominio,

guardan información de configuración en Directorio Activo. Quitando el rol de la CA eliminamos también esa configuración del directorio activo.

Para ello vamos al panel de control, añadir/eliminar componentes de Windows, quitamos Certificate Services y pulsamos Next.

3.5. Quitar el servidor del dominio.

Puesto que los nombres en dominios deben ser únicos, es necesario eliminar el servidor origen del dominio y borrar su cuenta de máquina de Directorio Activo antes de unir el servidor destino al dominio.

3.6. Copiado a servidor destino.

Ahora debemos copiar las carpetas en las que hayamos creado nuestros archivos de backup al servidor destino. Siguiendo el ejemplo en esta guía, sería lo contenido dentro de C:\Backup (carpetas CABackup y CAConfigBackup).

Como paso adicional, podemos apagar el servidor de origen.

3.7. Preparación del servidor destino

Si el fichero CAPolicy.inf ha sido personalizado en la CA origen, debemos copiar este fichero a la ruta C:\Windows (valor por defecto), antes de instalar el rol de AD CS en el servidor destino.

Instalamos el rol de AD CS en el servidor destino entrando en Server Manager, Roles, Add Roles.

 Seleccionamos Active Directory Certificate Services, pulsamos Next.

 En el paso Role Services, seleccionamos Certification Authortity, y hacemos click en Next.

 En Setup Type, especificar Enterprise or Standalone para hacerlo coincidir con la CA origen, y pulsar Next.

 En CA Type, elegir Root o Subordinate, de forma similar a la CA origen.

 En la siguiente pantalla del asistente debemos seleccionar la siguiente opción para poder usar el certificado y la clave privada que hicimos anteriormente durante el backup CA «Use existing private key» y «Select a certificate and use its associated private key«.

 En la lista de certificados, importar el certificado de la CA y pulsar Next.

 En el paso «Configure Certificate Database«, especificar la ruta a los ficheros de base de datos y logs de la CA anterior.

 Click Install.

3.8. Restaurar datos de la CA.

Una vez configurada la CA nueva tenemos que restaurar la base de datos de la CA Windows Server 2003. Para ello vamos a All Taks y hacemos click en Restore CA.

 A continuación se iniciará el Asistente de restauración de la base de datos de Autoridad Certificadora. Pulsamos Next.

En la siguiente pantalla, sólo seleccionamos el checkbox «Certificate database and certificate database log» y la ruta donde está almacenada los archivos de base de datos (carpeta CAbackup en esta guía).

 Finalizada la restauración hacemos click en Finish.

3.9. Restaurar datos de registro:

El siguiente paso será restaurar los valores de la clave de registro que exportamos previamente de la CA 2003. Antes de proceder a importar dichos valores, recomendamos hacer un backup de los existentes en el servidor 2012 R2, de la misma forma que hicimos la copia en la CA 2003. La clave de registro está en la siguiente ruta:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\ Configuration

No todos los parámetros del registro deben ser migrados sin realizar cambios desde la CA origen, y otros no deben ser migrados. Si son migrados, deben ser actualizados en el servidor de destino después de la migración puesto que algunos valores están asociados a la propia CA, mientras otros están asociados al dominio, máquina física, versión de Windows, y otros factores que pueden diferir.

La forma recomendada en este caso es editar el fichero antes de importarlo, cambiando o quitando los valores correspondientes. En la siguiente tabla se muestran los parámetros que deben ser transferidos de la CA antigua a la nueva:

Abrir el fichero .reg con un editor de texto.

Si el nombre de la CA destino es diferente de la de origen, buscar en el fichero el nombre de la CA origen. En cada aparición (ver nota posterior), asegurarnos de poner el nombre de la CA destino. Actualizar CAServerName si es necesario.
Importante: Si el nombre del servidor es encontrado como parte del nombre de la CA en Active dentro de Configuration, o en CommonName dentro de CAName, no se deben cambiar estos valores. El nombre de la CA no se debe cambiar en el proceso de migración. Eso significa que la CA de destino debe tener el nombre de la CA anterior, incluso si el nombre del servidor es parte del nombre de la antigua CA.

Comprobar si hay algunos valores que indiquen rutas locales (por ejemplo unidades o path). Si estos han cambiado, actualizarlos correspondientemente. Algunos de esos valores son: DBDirectory, DBLogDirectory, DBSystemDirectory, DBTempDirectory.
Las claves CACertPublicationURLs y CRLPublicationURLs, por defecto contienen path locales. Estos valores pueden ser actualizados posteriormente en la pestaña Extensions de la CA destino.
Una vez realizados los pasos anteriores, para importar el fichero .reg en la máquina de destino, abrir un cmd y ejecutar:
net stop certsvc
reg import
Los pasos anteriores relacionados con los cambios de los valores de registros se realizan con la idea de mantener las rutas de red que la CA anterior utilizaba para publicar CRLs y certificados. Si la CA de origen publicaba por defecto en directorio activo, después de completar el procedimiento anterior, debería existir una extensión con las opciones de publicación habilitadas y rutas LDAP que referencian al nombre de la CA origen, por ejemplo:
ldap:///CN=,CN=,CN=CDP,CN=Public Key Services,CN=Services,.
Dado que muchos administradores configuran extensiones que están personalizadas para su entorno, no se pueden proporcionar instrucciones específicas para estos temas. Recomendamos revisar con detalle las rutas y opciones de publicación asegurando que están configuradas según los requisitos de cada organización.
3.10. Importar plantillas de certificados.
Un paso adicional, únicamente para CA de tipo Enterprise, es importar las plantillas de certificados. Para ello se deben llevar a cabo los siguientes pasos:
o Iniciar sesión en la CA de destino con privilegios de administrador.
o Abrir un CMD.
o Escribir certutil -setcatemplates + y pulsar Enter. El parámetro debe ser sustituido por una lista de nombres de plantillas, separadas por comas. Ejemplo: certutil -setcatemplates +Administrator,User,DomainController
3.11. Comprobación de permisos:
Verificamos los permisos y volvemos añadir la cuenta de equipo, aunque esté agregada a los contenedores Configuration/Services/Public Key Services del ADSIedit como indica el punto Active Directory Permissions for the CA del siguiente artículo:
Performing the Upgrade or Migration
http://technet.microsoft.com/es-es/library/cc742388(v=ws.10).aspx
De esta manera evitamos que aunque la cuenta de equipo se llame igual tenga un SID que haga referencia a la cuenta de equipo de Windows Server 2003.
Desde un ADSI Edit, nos conectamos a la partición de configuración, y vamos a la ruta Services / Public Key Services
Enrollment Services: La cuenta de máquina de la CA tiene permisos de Read y Write para sí mismo en este contenedor.

AIA: Debe tener permisos “Full Control” el grupo “Cert Publishers” en este contenedor. La cuenta de equipo CA tiene que tener “Full Control” son sí misma en este contenedor.

CDP: Debe tener permisos “Full Control” el grupo “Cert Publishers” en este contenedor. La cuenta de equipo CA tiene que tener “Full Control” en cada objeto CRL.

Certification Authorities: Los miembros de los grupo Enterprise Admins y Domain Admins tienen permisos “Full Control” o permisos de Read and Write en este contenedor y la mayoría de los objetos que hay debajo de él. Las ACLs de las plantillas administrativas son configuradas interactivamente por el administrador de la CA.

KRA: La cuenta equipo CA tiene permiso “Full Control” para sí mismo en este contenedor.

OID: Los miembros de los grupo Enterprise Admins y Domain Admins tienen permisos “Full Control” o permisos de Read and Write en este contenedor y la mayoría de los objetos que hay debajo de él.

NTAuthCertificates: Los miembros de los grupo Enterprise Admins y Domain Admins tienen permisos “Full Control” o permisos de Read and Write en este contenedor.

Enrollment Services: Debe tener permisos “Full Control” el grupo “Cert Publishers” en este contenedor.
Arrancamos el servicio de la CA, por ejemplo desde la consola, botón derecho sobre el nombre de la CA, All Tasks, Start Service.

4. Comprobaciones
1. Verificamos las propiedades de la Autoridad Certificadora son correctas.
 Pestaña Extensiones. (CDP, AIA).
 Propiedades de Certificados Revocados.
 Certificados distribuidos, revocados, etc.
2. Verificar autoenrollment:
a. Entrar en un servidor miembro utilizando una cuenta con permisos de Autenroll, Enroll y Read en las plantillas asignadas a la CA de destino.
b. Hacer click en Start, Run.
c. Escribir certmgr.msc, y pulsar OK.
d. Botón derecho sobre Certificates, Current User, All Tasks, y elegir Automatically Enroll and Retrieve Certificates.
e. Next.
f. En “Request Certificates” deberían mostrarse una o más plantillas. Seleccionar la que se desee solicitar, y pulsar Enroll.
g. Finish.
h. En el contenedor Personal, Certificates, debería aparecer una lista de todos los certificados del usuario. Comprobar que está el solicitado anteriormente..

Network Time Protocol (NTP) es uno de los protocolos de internet más viejos (1985) que siguen en uso.
Su propósito, sincronizar los relojes de los sistemas informáticos a través del enrutamiento de paquetes en redes con latencia variable. NTP utiliza UDP como su capa de transporte, usando el puerto 123 y está diseñado para resistir los efectos de la latencia variable.
En un entorno empresarial, es muy importante tener bien implementado el sincronismo horario.
Hablemos de NTP en el ldap de Directorio Activo de Microsoft.

Como sabemos, el sincronismo horario para toda la estructura de Active Directory y sus puesto cliente (en adelante Desktops y Servers), tienen que tener un correcto sincronismo horario. Para que esto funcione, los desktops sincronizan su hora local sobre el controlador de dominio, (en adelante DC) en el cual se han validado, (su logon server) al cual reportan.

Ahora bien, para asegurarnos de que esto funcione correctamente, tenemos que controlar nuestros DCs, para que entre ellos tengan tambien un correcto sincronismo, ¿cómo funciona esto?, basicamente, lo que hacen todos los DCs es contactar al DC con el rol de Primary DC (PDC) y tomar la hora del mismo, con lo que recae toda la responsabilidad sobre dicho DC.

¿Qué debemos configurar del lado de nuestro Active Directory? Lo primero, nuestro PDC con clave NTP y el o los DCs restantes con NT5DS, a su vez, el resto de los objetos computer del dominio (desktops o servers), tambien tienen que tener configurado NT5DS en dicha clave, todo esto, se puede hacer mediante la aplicación de la GPO: Computer Settings – Plantillas Administrativas – System – Time Service

HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/W32Time/Parameters
Key: Type con valor: NT5DS

Esta clave tiene que estar en todos los DCs menos en el PDC, ya que en el mismo en lugar de NT5DS tiene que figurar NTP y a su vez, en la key “NtpServer” se puede poner, el registro DNS o IP del server NTP de la empresa o muy preferiblemente algún NTP externo confiable, de esta forma, se hace que la estructura aplique un orden o un sincronismo horario a todo el bosque y/o dominio.

Con respecto al server NTP, se puede utilizar el de Microsoft (por darte un ejemplo) que es el default que aparece en la clave de registro NTPServer, si el dia de mañana habilitan un NTPServer o apuntamos a uno externo, se tiene que cambiar dicha clave de registro.

Por último, si hemos implementado los cambios de los que hemos hablado, se tiene que reiniciar el servicio Windows Time (W32Time). (net stop w32time – net start w32time)

Para ver el sincronismo horario de los Controladores de Dominio, podemos ejecutar el comando: w32tm /monitor

Personalmente diría que es muy recomendable cambiar la fuente externa del PDC, para que sincronice la hora desde otro site en internet en lugar de la que tenemos localmente.

Adjunto una útil url que utilizo para encontrar los servidores de hora NTP, importante de Stratum 2 y que hay disponibles: https://support.NTP.org/bin/View/Servers/StratumTwoTimeServers

Aplicado el cambio en el PDC ésta sería la configuración NTP:
El proveedor de hora NtpClient está recibiendo datos de hora válidos desde 93.189.33.204 (ntp.m|0x0|0.0.0.0:123-> 93.189.33.204). El nuevo servicio de hora comenzará a anunciarse como hora de origen.