Windows server

«Recuperar» claves privadas de certificados SSL en IIS

fernando

En ocasiones es posible tener alguna que otra dificultad a la hora de crear peticiones (CSR) o renovar si no se realizan los pasos con cuidado en IIS. Debemos tener en cuenta que a la hora de crear una petición de certificado, la clave privada se almacena en el equipo que la realiza y solo en este es posible recuperarla.

Pese a ello en ocasiones se producen errores en el proceso, llegados a este extremo podemos intentar dos opciones:

  1. Desde la linea de comandos podemos intentar reparar el almacen de certificados: 
    certutil -repairstore my "ThumbprintDelCertificadoConoSinEspacios"

    Si el comando encuentra las claves privadas asociadas al certificado indicado con el thumprint las asocia, en otros casos es posible que muestre errores del tipo «Insertar tarjeta inteligente» ya que busca en todos los medios y proveedores criptográficos existentes, en tal caso no podrá acabar.

    NOTA: este comando también se puede utilizar para asociar las claves privadas con la renovación de un certificado CER de manera rápida dentro del mismo equipo, es decir, certificado completo del año 2010 (PFX) y renovación de 2011 (CER) en el mismo almacén de certificados.

  2. Si hemos solicitado el certificado a una autoridad online, es posible que tenga almacenadas las claves privadas en la solicitud web, en este caso podremos unirlas con el certificado de respuesta para obtener el PFX resultante mediante OpenSSL, puedes probar online pero nunca en producción 
    openssl pkcs12 -export -inkey clave.pem -in pki.crt -out certificadoCompleto.pfx

 

NOTA: Una pequeña aclaración rápida, los archivos CRT contienen la información entre las etiquetas —–BEGIN CERTIFICATE—– y —–END CERTIFICATE—– mientras que las claves de ficheros PEM utilizan: —–BEGIN RSA PRIVATE KEY—– y —–END RSA PRIVATE KEY—– habitualmente.

Eliminación de catálogo global (GC) no accesible

fernando

En entornos con varios servidores actuando conjuntamente con funciones de directorio activo, bien como lectura, replicado… o cualquier escenario posible, recuperación de backups, virtualizaciones fallidas, virus… podemos llegar a querer eliminar cualquier registro del servidor ya no disponible.

Echaremos un vistazo a las referencias que pueda quedar en los DNS, sobre todo en el caso de estar integrados con el directorio.

Con los sitios y servicios debemos hacer lo mismo:

Si intentamos crear un usuario con uno de los servidores no disponible para el sitio, con el mismo nivel como catálogo global replicado, aparecerá un error del tipo:

El servicio de directorio no puede asignar un identificador relativo.

Si estamos seguros que el servidor no va a poder ser restaurado y queremos eliminar todo rastro, deberemos acudir a la linea de comandos.

Conectaremos con el servidor que tenemos activo, consultando y seleccionando el dominio/sitio/servidor que queremos limpiar de nuestra infraestructura.

ntdsutil 
metadata cleanup 
connections
connect to server SERVIDORBUENO
q
select operation target 
list domains
select domain 0
list sites 
select site 0
list servers in site
select server 5 // OJO servidor que queremos eliminar
q
remove selected server

Debemos tener en cuenta que cualquiera de estas acciones no es reversible y puede suponer el fallo de servicios si no se realiza con cuidado.

 

En el caso de iniciar el proceso sin haber transferido las funciones FSMO del equipo, se intenta realizar de forma segura (si es accesible) en el proceso de eliminación.

Error 0x800f0831 añadiendo roles

Error 0x800f0831 añadiendo roles

fernando

Al intentar añadir cualquier rol nuevo, siempre aparece este error. Las reparaciones con SFC / DISM online y local muestran errores o no sirven:

dism.exe /online /Cleanup-Image /StartComponentCleanup /ResetBase
dism.exe /online /Cleanup-Image /RestoreHealth /Source:wim:X:\sources\install.wim:1 /LimitAccess
dism.exe /online /cleanup-image /restorehealth

Revisando el registro %WinDir%\Logs\CBS\CBS.log nos encontramos errores con los paquetes de idioma preinstalados STATUS_SXS_ASSEMBLY_MISSING…

Leer más →

Forzar sincronización Azure AD Connect

fernando

El tiempo mínimo programable para la sincronización entre un entorno local y cloud dentro de las capacidades actuales de Azure Active Directory Connect es de 30 minutos, en ocasiones necesitaremos replicar de manera urgente cambios antes de este tiempo.

Nos aseguraremos de tener el modulo de sincronización con el comando: «Import-Module ADSync» y consultamos la configuracióna actual «Get-ADSyncScheduler«.

El comando «Start-ADSyncSyncCycle Delta» fuerza la sincronización entre el AD local y el Azure AD, realiza la comparación de ambos y solo realiza la actualización de los cambios (DELTA)

Es posible realizar una sincronización completa (FULL) con el comando: 

Start-ADSyncSyncCycle -PolicyType Initial

lo que en algunos escenarios puede llegar a demorarse dependiendo del número de objetos.

SYSVOL y NETLOGON en Windows Server

fernando

A la hora de migrar, actualizar o eliminar un controlador de dominio hay que tener en cuenta que una vez eliminado los equipos que todavía estén incluidos no tendrán donde verificar sus credenciales, a lo sumo la caché local de las últimas utilizadas en el equipo. El escenario habitual suele darse a la hora de añadir un nuevo servidor y repartir las tareas de verificación y roles entre varios equipos en una infraestructura de red más fiable.

Si nos encontramos ante la situación de no disponer de las carpetas indicadas en un equipo, lo más seguro es que debamos revisar donde residen los roles principales, mediante el comando:

netdom query FSMO

Con el cual obtenemos el listado de los 5 roles y la máquina en la que residen:

– Maestro de esquema
– Maestro nomecl. dominios
– PDC
– Administrador de grupos
– Maestro de infraestructura

A la hora de jubilar un controlador de dominio, debemos tener todas las funciones transferidas, si en un equipo nos tenemos las carpetas del sistema SYSVOL y NETLOGON debemos preparar un DC y eliminar el anterior con DCPROMO.EXE para forzar la sincronización de las carpetas realizaremos los siguientes pasos

En el servidor ANTIGUO:

1. Desde la consola de línea de comandos, ejecutamos:
2. Paramos el servicio «net stop ntfrs»
3. Abrimo el registro de windows REGEDIT
4. Accedemos a la clave
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\
Parameters\Backup\Restore\Process
Startup
5. Editamos el valor «BurFlags» DWORD introduciendo «D4»
6. Volvemos a iniciar el servicio «net start ntfrs»

En el servidor NUEVO debemos ejecutar los mismos pasos pero la clave a sustituir en este caso es:

5. Editamos el valor «BurFlags» DWORD introduciendo «D2»

Reiniciamos los servicios en los dos servidores dos veces para forzar. La sincronización de las carpetas comenzará de inmediato.