Hola a todos. Soy Tolu Igbon, del equipo de Directorio Activo.
Un caso común que tratamos en el área de soporte de Directory Services es el siguiente error al intentar arrancar una entidad certificadora (CA) subordinada:
The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613)
El comportamiento puede producirse nada más intentar arrancar la CA por primera vez, o pasado un tiempo (semanas, meses) tras haber estado funcionando con normalidad.
Antes de comenzar con el diagnóstico del error, vamos a comenzar por recordar algunos conceptos básicos sobre el funcionamiento de certificados:
Basic Certificate Validation:
For a certificate to function properly, the following items must validate correctly (at a minimum):
1. Subject name: The subject of the certificate must match the resource subject that is being used. For example, when using https the subject in the certificate being used on the web server must match the https URL that users will use to connect to the https website. Subject name is analogous to the name on a driver’s license.
2. Validity Period: The (Valid From) and (Valid To) must be within the time frame the certificate is planning on being used. This is much like the expiration of a driver’s license. Validity period is analogous to the expiration date on a driver’s license.
3. Trust: The certificate must be used by a trusted Certificate Authority. Trust is analogous to the State that issued a driver’s license. Because the State that issued the license is a member of the union that makes up the United States we trust the issuer of the license.
4. Chain Building: Chain building is the process of building a trust chain, or certification path, from the end certificate to a root CA that is trusted by the security principal. The chain-building process will validate the certification path by checking each certificate in the certification path from the end certificate to the root CA’s certificate.
5. Key Usage: To help control the usage of a certificate outside of its intended purpose, the optional Enhanced Key Usage extension can be included in the certificate by the CA. The Enhanced Key Usage extension contains a list of usages for which the certificate is valid. These usages, also known as intended purposes, are displayed on the General tab of the certificate dialog box. This is important when evaluating why a certificate may not be working correctly. Key Usage is analogous to driver’s license endorsements (types of vehicles that can be driven with this license).
6. Revocation Checking: Each certificate in the certificate chain is verified to ensure that none of the certificates are revoked. A certificate can be revoked prior to the expiration date to disavow the certificate. Revocation Checking is analogous to checking a driver’s license against a State database to verify that a driver’s license has not been revoked for a violation.
En el caso que nos interesa hoy, el punto clave es el 6, donde se habla sobre la comprobación de revocación.
El certificado de la CA subordinada, al igual que cualquier certificado de usuario/cliente, viene con un campo/atributo “CRL Distribution Points” (CDP) donde se especifican uno o varios
· Puntos de acceso al directorio activo (rutas LDAP),
· Servidores web (direcciones http/https) o
· Recursos compartidos de red.
En estos CDP el cliente puede encontrar una lista de certificados revocados firmada por su CA emisora y comprobar si su propio certificado es válido o no.
El error recibido en el caso que estamos tratando nos indica que no se puede comprobar el estado de revocación de nuestro certificado (el de la propia CA Subordinada) porque o bien el servidor de revocación (donde comprobamos la lista de certificados revocados) está fuera de línea (apagado) o no se puede acceder a él.
En este caso, esto impide que arranquen los servicios de la CA, mientras que en otros escenarios, como en el inicio de sesión a través de tarjetas inteligentes (SmartCard), podría implicar que el usuario no pueda iniciar sesión en el dominio.
Troubleshooting/Solución
En el escenario que tratamos hoy, tenemos varias opciones para el diagnóstico/resolución del problema, en función de cómo esté configurado nuestro entorno:
1. Podría ser que la CA raíz que actualiza las listas de revocación (CRLs) realmente esté “offline” (y que la CRL que tiene la CA subordinada esté caducada)
· Es una práctica común mantener una CA Raíz apagada e inaccesible por cuestiones de seguridad
· Para resolver el problema, debería ser suficiente con volver a arrancar la CA raíz y publicar una nueva CRL. Normalmente, la CA Raíz publicará su lista (de larga duración) en un servidor web que se mantendrá en línea para que los clientes (la CA subordinada) puedan verificar la CRL por HTTP.
2. La CA Raíz o, en su defecto, el servidor donde se publican las CRLs sí está en línea y tiene publicada una CRL actualizada pero nuestro cliente (la CA Subordinada) no puede acceder a ella
· Normalmente, para verificar si podemos acceder correctamente a un CDP por HTTP podemos:
o Intentar navegar a la URL en una ventana de Internet Explorer
P.ej http://ServidorWeb/Crl/Archivo.crl
o Utilizar la herramienta Certutil para comprobar si podemos acceder
P.ej certutil -URL [URL]
certutil -URL http://ServidorWeb/Crl/Archivo.crl
o O podemos exportar una copia del certificado cuya revocación queremos comprobar y ejecutar el comando
certutil -url <exportedcert.cer>
En el cuadro de dialogo “Verify and Retrieve”que nos aparece, seleccionamos “From CDP” y verificamos el resultado
En el 99% de los casos, nosotros (el usuario con el que hemos hecho las pruebas) podremos acceder correctamente a la CRL por los métodos anteriores.
Entonces, la pregunta sería: ¿por qué el mensaje de error indica que el servidor de revocación esta fuera de línea? La clave está en el contexto de seguridad con el que se intenta acceder al CDP.
La CA funciona bajo el contexto de la cuenta Local System, o dicho de otra manera, de la propia cuenta de máquina. Por lo tanto, deberemos verificar si la cuenta de maquina puede acceder a los CDP al igual que nuestro usuario puede hacerlo.
Esta vez, para realizar las comprobaciones anteriormente descritas, utilizaremos la herramienta AT.exe (el programador de tareas de Windows Server 2003) para poder ejecutar los comandos en el contexto de Local System.
(NOTA: La correcta ejecución de las pruebas con AT.exe depende de que el programador de tareas este configurado para ejecutarse bajo la cuenta Local System – configuración por defecto en Windows)
· Programamos una tarea para lanzar una ventana de comandos a las 15:00:
AT 15:00 /INTERACTIVE CMD.EXE
· A las 15:00 se lanza una ventana de comandos en el contexto de Local System
· Desde esta ventana de comandos lanzamos Internet Explorer (iexplore.exe) y ejecutamos Certutil de nuevo para comprobar si la cuenta de maquina puede acceder correctamente a los CDP por http
Bajo el supuesto que estamos tratando hoy, en la mayoría de los casos, Certutil fallará al intentar verificar la URL especificada, e Internet Explorer mostrará un error de acceso o un cuadro de diálogo solicitando credenciales para acceder a la URL a través del proxy.
En este punto, ya habríamos determinado el origen del problema: La CA Subordinada efectivamente no puede acceder a la información de revocación porque la cuenta de maquina no puede acceder a la URL a través del proxy.
La solución suele radicar en dar permisos a nivel de proxy para que la máquina pueda acceder correctamente, o modificar las opciones de Proxy en la configuración de Internet Explorer (en el contexto de Local System)
Una vez hechos los cambios pertinentes, podemos comprobar que la maquina ya accede correctamente al CDP, y la CA ya podrá arrancar correctamente.
Enlaces de interés:
· Certificate Revocation and Status Checking
· Basic CRL checking with Certutil
· Troubleshooting Certificate Status and Revocation
- Tolu Igbon
Se esta publicando el nuestros blogs en Ingles un anuncio que cambiará la forma en que se aplican los pasos recomendados en nuestros KB para modificar el sistema.
Esto se produce en respuesta a los comentarios por parte de los usuarios de que, en algunos casos, los pasos a seguir publicados en nuestros artículos, podían resultar complicados y si no se seguían correctamente podían, no solo no solucionarlo, sino agravar el problema.
Esta nueva funcionalidad esta publicada ampliamente en el siguiente artículo:
“Fix it” – The Next Evolution of KB Articles and WER
En resumen, se comenzará a añadir a los nuevos artículos publicados el siguiente icono (para ver un ejemplo visitar KB 934885)
Fix this problem
Si se pulsa, no comenzará automáticamente a solucionar el problema en la máquina, sino que se realizara la descarga de un paquete MSI el cual, al ser ejecutado, realizará las modificaciones indicadas en el articulo.
En principio los Wizard están todos en ingles, pero funcionan en otros idiomas de instalación.
Si queréis ampliar la información sobre esta nueva funcionalidad esta publicado en el siguiente Blog Fix it for me.
También se podrá seguir mediante una WebCast el Martes 19 de Febrero, los detalles, (en Ingles ya que la webcast será en ese idioma)
Want to learn about Fix it, Microsoft’s newest support offering? Join John Bukowski (Architect) and Brian Kinchen (Senior Program Manager) for an overview of the capabilities and features of Fix it, demonstrations, and a live Question and Answer session. Microsoft Fix it represents a new phase of automated self-help by providing resolutions to problems with the click of a button. Requirements for Attending this Event We strongly suggest you test your computer's configuration to ensure you are running the most current version of Microsoft Office Live Meeting: https://events.livemeeting.com/LM2007test.htm Note: If you are unable to click this link, you can also copy and paste the link into the address bar of your browser. When you enter the test event, you will be prompted to install and run the Office Live Meeting Client software if you have not downloaded it already. If you cancel the software installation, you will be given a link to attend the event using the Microsoft Web Access, a browser-based client. Once entered, you should see the Office Live Meeting client with a slide that indicates your test is successful. If you are not able to see the slides, please contact Event Support: http://www.livemeeting.com/ask or call 1-800-893-8779 in the US or Canada, or 1-971-544-3222 in other regions. Login Details for Live Event Session on Microsoft Fix it On the day of the event, please perform the following actions no later than 15 minutes before the event begins. The Webcast starts at: 1 PM or 13:00 PST Thursday February 19, 2009 4 PM or 16:00 EST Thursday February 19, 2009 9 PM or 21:00 GMT Thursday February 19, 2009 View the Internet Portion of the Event Click the attendee meeting URL: https://www.livemeeting.com/cc/lmevents/join?id=MSFT14185&role=attend&pw=ATT1485J1357. If you can’t click the above meeting URL, click the following link: https://www.livemeeting.com/cc/lmevents/join When you click on either URL, the Join Meeting page appears. In the following fields, verify or enter this information: Name: (Enter your first and last name) Meeting ID: MSFT14185 Entry Code: ATT1485J1357 If prompted, install and run the Office Live Meeting software (recommended) or launch the Microsoft Web Access client (for Attendees unable to install the software, as well as anyone joining using a Macintosh). It will take a few moments for the Office Live Meeting client to launch. On the next page, please enter your e-mail and company name in their respective fields, if necessary, and click Continue.
Want to learn about Fix it, Microsoft’s newest support offering? Join John Bukowski (Architect) and Brian Kinchen (Senior Program Manager) for an overview of the capabilities and features of Fix it, demonstrations, and a live Question and Answer session. Microsoft Fix it represents a new phase of automated self-help by providing resolutions to problems with the click of a button.
Requirements for Attending this Event We strongly suggest you test your computer's configuration to ensure you are running the most current version of Microsoft Office Live Meeting: https://events.livemeeting.com/LM2007test.htm
Note: If you are unable to click this link, you can also copy and paste the link into the address bar of your browser. When you enter the test event, you will be prompted to install and run the Office Live Meeting Client software if you have not downloaded it already. If you cancel the software installation, you will be given a link to attend the event using the Microsoft Web Access, a browser-based client. Once entered, you should see the Office Live Meeting client with a slide that indicates your test is successful. If you are not able to see the slides, please contact Event Support: http://www.livemeeting.com/ask or call 1-800-893-8779 in the US or Canada, or 1-971-544-3222 in other regions.
Login Details for Live Event Session on Microsoft Fix it On the day of the event, please perform the following actions no later than 15 minutes before the event begins. The Webcast starts at:
View the Internet Portion of the Event
Un saludo.
Consulta con el equipo de Windows.
En Windows Server 2003, los drivers de impresora en un servidor de impresión en clúster son almacenados en un disco compartido y replicados a todos los nodos del clúster. Los drivers son guardados en un directorio bajo el raíz del disco compartido del cual el servicio spooler o cola de impresión depende, llamado PrinterDrivers
Nota Este nombre de carpeta no podrá ser cambiado aunque haya una propiedad privada de recurso que de pie a ello.
Cuando un driver de impresora es actualizado, es establecido el valor TimeStamp en el registro al sello de fecha y hora incluidas en el driver. Cuando el recurso spooler o cola de impresión su estado pasa a Online, él comprueba este valor bajo la siguiente rama del registro:
HKLM\Cluster\Resources\%GUID%\Parameters\Environments\Windows NT x86\Drivers\Version-3\%DriverName%\TimeStamp
Y lo compara con el valor:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Print\Cluster\%GUID%\Windows NT x86\Version-3\%DriverName%\TimeStamp
Nota %GUID% corresponde al identificador en el registro del recurso spooler o cola de impresión
Si él encuentra que la versión bajo la primera rama es mas nuevo que el de la segunda, el driver actualizado es descargado desde el disco compartido al disco del sistema operativo del nodo.
Se comprueba driver por driver, y si hay alguna diferencia de versión, son descargados desde la carpeta o directorio \PrinterDrivers del disco compartido a la siguiente ruta local del nodo %SystemRoot%\System32\Spool\ResourceGUID\Drivers, donde ResourceGUID es el identificador único global (GUID) que representa al recurso spooler o cola de impresión. Estos drivers son mantenidos aparte de cualquier driver instalado en el nodo o de otro recurso spooler en configuraciones activo/activo.
Imagen 1: Directorio con el GUID del recurso spooler
En un servidor de impresión no en clúster, los drivers para cada sistema operativo son almacenados en directorios diferentes. Una simple impresora puede tener diferentes drivers cargados y cada uno de estos está almacenado en una carpeta diferente bajo Drivers. El Cluster mantiene las mismas convenciones en la separación de drivers bajo cada carpeta GUID de cada recurso de spooler o cola de impresión.
La replicación de todos los drivers puede incrementar el tiempo que a un recurso spooler o cola de impresión pasar su estado a online, porque cuando un driver es actualizado, el spooler debe comprobar la lista de todas las impresoras pare ver cuáles son las impresoras afectadas (y ver si usa algún archivo actualizado) y si así fuera, decir a la impresora que actualice su información de driver. No se pasara el estado del recurso spooler o cola de impresión a Online hasta que esta comprobación y actualización este completa. Este retraso no afectara a otros nodos hasta que el recurso spooler se ponga online por primera vez en ellos. Cuando tu agregas un gran número de colas de impresión y drivers de una vez, es altamente recomendado que después de haberlas añadido, muevas el recurso spooler o cola de impresión a cada uno de los nodos en el clúster. Esto necesita ser hecho solo una vez, y cuando el recurso es puesto online ocurrirá la replicación de los driver. Esto asegura que todos los nodos tienen los drivers más actuales. El tiempo de failover será menor después que la que mayoría de los drivers estén replicados para las siguientes impresoras que añadas.
El spooler y otras aplicaciones no deberían copiar drivers de impresora directamente al disco compartido, porque si se produjese un failover el proceso de carga de drivers obtendría un error de E/S. Esto es el por qué los drivers son descargados y mantenidos en cada uno de los nodos localmente. Cuando se accede a un driver, se usa rutas UNC (\\%VirtualServer%\print$\%GUID%) en vez de la ruta local al driver (%SystemRoot%\System32\spool\Driver).
El sitio de Windows Update es seguro usarlo en los clúster. Si es usado el actualizara los drivers en el nodo local y también en los servidores virtuales, pero para poder hacerlo el recurso spooler debe estar online en el nodo donde se está usando Windows Update.
A la hora de borrar un recurso cuando un nodo está offline, la próxima vez que el nodo este online borrara la carpeta GUID del nodo local.
Cuando borras un recurso spooler, ocurren dos cosas:
El resto de los nodos (sin hacer caso si están online u offline) llevaran a cabo una limpieza cuando el Servicio de clúster inicie (ya que había una marca para borrado porque los archivos del driver estaban en uso). Esto es debido a cuando un recurso es borrado el servicio de clúster solo notifica a la DLL de recursos en el nodo donde el recurso está siendo borrado.
Una cosa a tener en cuenta a la par de la replicación de los drivers entre los discos compartidos y los nodos es la información que se pasan los nodos a través de la rama CLUSTER del registro. A veces debemos ser cuidadosos a la hora de agregar muchas impresoras y tenemos configurado un reseteo del log de quórum cada pocos KB. En un movimiento o failover puede perderse información relacionada con colas de impresión si es muy bajo el valor.
Para incrementarlo sigue estos pasos:
Nota Introducir un valor múltiplo de 64. Por ejemplo, 5120 o 8192.
Nota Este valor es global y solo necesita cambiarse en un nodo. El servicio de clúster llevara este cambio al resto de nodos y el cambio es dinámico no es necesario reiniciar el servicio de clúster.
Troubleshooting (solucionando problemas)
Cuando una carpeta de un driver esta corrupta, cualquier impresora cuyo driver este corrupto no imprimirá. Puedes encontrar en alguna situación que una impresora en un nodo puede imprimir correctamente, pero desde otro nodo por la misma impresora no es posible. Esto puede ser debido a un driver corrupto o faltan archivos del driver en el nodo. Para corregir esto tú puedes manualmente forzar el borrado de todos los drivers del nodo y luego llevar a cabo una replicación completa desde el nodo que no tiene problemas.
Ya que el Servicio de clúster comprueba si las versiones coinciden en el failover, sería raro que en un failover el recurso spooler no propagara los drivers correctos al otro nodo..
Si la carpeta GUID en uno de los nodos esta corrupta puedes hacer una de estas cosas:
Con esta última opción el servicio de clúster copiara los drivers del disco compartido al disco local del nodo:
Esto causara que el recurso Spooler recree los drivers en el nodo local. Los driver viejos pueden ser movidos dentro de una carpeta llamada old dependiendo si pueden ser borrados o no. Si los driver en el nodo problemático todavía parecen estar corruptos, reinicia el nodo después de que lo hayas quitado de Possible Owners. Cuando tú hagas esto, cualquier driver que tuvieran handles abiertos serán cerrados. Normalmente este paso no es necesario.
Nosotros recomendamos que uses drivers de nivel 3 en pro de la estabilidad del clúster. Evita los de nivel 2 o de modo núcleo. Ellos pueden causar un stop e inestabilidad en el sistema.
Si por cualquier razón, la carpeta \PrinterDrivers en el disco compartido se pierde o la información que contiene se daña o se borra, tu puedes usar uno de los siguientes métodos para recuperarla:
· Restaurar de un backup.
· Copiar desde la carpeta %SystemRoot%\System32\Spool\SpoolerResource GUID a %SharedSpoolerDisk% y renombrar SpoolerResource GUID a PrinterDrivers.
· Reinstalar las impresoras (la carpeta PrinterDrivers es recreada cuando un driver es instalado).
Como ya hemos hablado otras veces, con 2008 se he realizado un rediseño del antiguo clúster MSCS que utilizábamos en versiones anteriores de Windows.
De entre todos los cambios introducidos hoy nos centraremos en el registro.
HKLM\Cluster
También conocida como “Cluster hive”, continua siendo la clave principal dentro del registro, almacenando información sobre la configuración del clúster. Residente en todos los nodos del clúster es también replicada al disco de witness en caso de haberse definido.
Las claves modificadas son:
HKLM\Cluster\Checkpoints
HKLM\Cluster\Dependencies
HKLM\Cluster\Groups
HKLM\Cluster\Networks
HKLM\Cluster\Nodes
HKLM\Cluster\Quorum
HKLM\Cluster\ResourceTypes
HKLM\System\CCS\Services\clusdisk
HKLM\System\CCS\Services\ClusSvc
HKLM\System\CCS\Services\Netft
A continuación adjunto el acceso al documento con toda la información, pantallazos y ejemplos de configuración.
Espero que os resulte de utilidad.
Un saludo, Paloma García
Técnico de Soporte Microsoft Premier