Espero publicar algunos artículos sobre uso de SSL y certificados en diferentes infraestructuras cuando disponga de algo mas de tiempo libre, entretanto dejo una breve descripción de los principales elementos que componen una infraestructura de clave publica (PKI).

PKI (public key infrastructure, infraestructura de clave publica): una PKI provee la posibilidad de intercambiar datos a través de una red publica de forma segura usando criptografía de clave publica. Una PKI consiste de diferentes elementos; entidades emisoras de certificados (CA), directorios que guardan estos certificados y certificados x.509 que son emitidos a entidades de seguridad en la red.

Entidad emisora de certificados / Certificate Authority (CA): se trata de una entidad que emite certificados y que asegura que la clave publica (public key) que se encuentra en un certificado emitido por ella pertenece realmente a la persona, organizacion o entidad que se especifica en el mismo certificado.

Authority Information Access (AIA): una extensión de certificado que contienes direcciones URI donde obtener el certificado de la CA emisora. Puede contener direcciones HTTP, FTP, LDAP o URLs de ficheros.

Certificate Revocation List (CRL): una lista firmada digitalmente emitida por una CA que contiene una lista de certificados emitidos por la CA que han sido revocados con su correspondiente razón de forma que se consulta para comprobar si los certificados han sido recovados y porque.

CRL Distribution Point (CDP): una extensión del certificado que nos indica donde se puede obtener la CRL de una CA, puede contener múltiples direcciones de fichero, HTTP, FTP o URLs LDAP.

Delta Certificate Revocation List (Delta CRL): un tipo de CRL que nos indica los cambios realizados respecto a la revocación de certificados que han sido hechos desde la publicación de la ultima CRL completa, se usa para ahorrar ancho de banda en entornos donde se revocan gran numero de certificados.

Protocolo de estado de certificados en línea (Online Certificate Status Protocol, OCSP): se trata de un protocolo que permite validar en tiempo real el estado de un certificado. CryptoAPI llamara al servicio OCSP y este proveerá una respuesta inmediata del estado de validación del certificado. Habitualmente OCSP realizara una consulta contra una CRL para obtener esta información.

| Enlace  

NETDOM.exe nos permite gestionar desde la línea de comando gran parte de la administración de un dominio en cuanto a la gestión de cuentas de equipos, relaciones de confianza e inclusos en dominios con nivel funcional Windows Server 2003 renombrar un controlador de dominio. NETDOM lo podemos encontrar entre las Support Tools que se incluyen en el CD de Windows Server 2003, también es posible ejecutarlo desde Windows XP para lo cual es necesario instalar previamente el Administration Tools Pack (adminpak.msi).



Renombrar un controlador de dominio no equivale a renombrar el dominio ni el bosque, tampoco es posible renombrar domain controllers que sean CA (Certificate Authority / Entidad Emisora de Certificados) debido a la naturaleza del servicio donde preservar el nombre de equipo es fundamental.



Disponemos de dos parámetros aplicables a todas las acciones, si queremos ver con detalle las operaciones que realiza NETDOM debemos usar el parámetro /verbose que nos enumerara las acciones que realice de manera que podemos detectar posibles fallos. Si nos es necesario reiniciar el equipo en cuestión sobre el que realicemos alguna acción podemos especificar el parámetro /reboot que por defecto realizara el reboot 20 segundos después de la ejecución con exito del comando. Si lo que necesitamos es ayuda con la sintaxis especifica de alguna opción podemos usar simplemente NETDOM HELP OPCION o bien NETDOM OPCION /?.

Para otros ejemplos distintos de uso de todas las opciones podéis ver ejemplos de uso de NETDOM para todo tipo de tareas ademas de la sintaxis completa de NETDOM, ambos cortesía de la pagina de TechNet.

| Enlace  

Una relación de confianza (trust relationship) se trata de de una relación mediante la cual un usuario se puede autentificar, aparte de en los recursos de su propio dominio, en los recursos del dominio o bosque con el cual se establece este tipo de relación. Por defecto los dominios dentro de un mismo bosque se crean con una relación de confianza implícita entre ellos. Para configurar nuevas relaciones de confianza o ver las que están actualmente establecidas y con que características se puede realizar a través de la línea de comando con NETDOM o por la consola Dominios y confianzas de Active Directory desde también podremos crear una nueva confianza mediante un asistente grafico que nos guiara por todos los pasos necesarios que lo hará mucho menos tedioso que usando NETDOM. En Dominios y confianzas de Active Directory debemos ir a Propiedades->Confía en del dominio en cuestión donde podemos tanto ver las relaciones existente como crear una nueva.





Las relaciones de confianza pueden ser unidireccionales (one-way) o bidireccionales (two-way), es decir que pueden funcionar en un sentido solo o en ambos. Se considera relación de entrada (incoming trust) cuando los usuarios del dominio o bosque en que la configuramos pueden ser autentificados por el otro dominio mientras que se considera de salida (outgoing trust) cuando en el dominio que la configuramos se pueden autentificar usuarios de otro dominio o bosque.



También es posible configurar si queremos que la autenticación se pueda realizar en todos los recursos del dominio (domain-wide) o bien si la queremos hacer selectiva (selective) de forma que solo se pueda realizar en unos determinados servidores que especifiquemos. De igual manera podemos seleccionar si la relación de confianza queremos que sea transitiva o intransitiva, si elegimos que sea transitiva también se confiara en dominios que a su vez confíe en ellos el dominio con el que tenemos establecida el trust transitivo.



Según se confíe en un forest, dominio de NT4 o de directorio activo o un realm de Kerberos, dominio no-windows con autenticación Kerberos), se pueden establecer distintos tipos de trust:

Externo (external trust): es el tipo de confianza mas habitual, es siempre intransitiva y se puede configurar tanto unidireccional como bidireccionalmente. Este tipo de confianza se realizar entre dominios en bosques distintos o bien con un dominio de NT4. Por ejemplo si queremos realizar una migración de usuarios desde un dominio de Windows NT 4 utilizando ADMT deberemos establecer una confianza externa bidireccional entre el dominio de NT y el dominio de directorio activo al que pretendemos migrar los usuarios.

Bosque (cross-forest trust): como su nombre indica en lugar de realizarse entre dominios aquí la relación se establece a nivel de bosque de forma que se compartirán recursos entre ambos bosques. Este tipo de trust que siempre es transitiva y se puede realizar tanto unidireccional o bidireccionalmente se trata de una novedad de Windows Server 2003 por lo que solo se puede realizar si el nivel funcional de bosque de ambos dominios es de 2003.

Territorio (realm trust): este tipo de implantación se da raramente y sirve para interoperar con otros dominios no-windows que usen el protocolo Kerberos v5 para la autenticación como por ej. MIT Kerberos domains.

Acceso directo (shortcut trust): dentro de un bosque se crea implícitamente tanto en dominios con nivel Windows 2000 como Windows Server 2003 una relación de confianza bidireccional entre dominios padres e hijos (parent-child) y de raíz con los árboles (root-tree) de forma que todos los dominios confianza entre sí. Pero si tenemos muchos dominios esto puede funcionar notablemente lento ya que ha de recorrer desde los dominios que se realiza hasta el raíz del bosque, con este tipo de relación se estable una relación de confianza directa entre ambos dominios de forma que funcione de la forma mas rápida posible. Este tipo de confianza es siempre transitiva de forma que también puede beneficiar a otros dominios hijos de los que la forman y se puede configurar como unidireccional o bidireccional.


Tanto si realizamos la confía a través de NETDOM como del asistente se debe crear la confianza en ambos extremos, en una como saliente y en otro como entrante o en ambos como bidireccional, cuando la configuramos en el primer extremo se nos solicitara una contraseña de confianza que deberemos facilitar cuando se cree en el segundo extremo. Al finalizar el proceso de creación de relación se nos pedirá que se confirme si ya se ha creado la relación en el otro extremo para así intentar establecer o no la relación.



En cuanto a la configuración de DNS para realizar un trust lo mas recomendable es crear una zona secundaria del otro dominio o dominio raíz del bosque con el que se creara la confianza en el dominio de origen, de esta forma se evitaran gran numero de errores que se producen si se crean reenviadores o utilizan otras técnicas. Para verificar los dominios en los que una maquina confía podemos hacer uso de la herramienta de línea comando NLTEST.exe que se incluye en las support tools.

| Enlace  

Catalogo Global es un rol adicional que pueden tomar los controladores de dominio tanto en Windows 2000 como en Windows Server 2003, a diferencia de los roles FSMO no es imprescindible para el correcto funcionamiento del active directory por lo que y también tenemos la posibilidad tener mas de uno por bosque o dominio. La función del global catalog es guardar una copircial de solo lectura de todos los objetos del bosque, al igual que el resto del directorio activo se trata de una arquitectura LDAP con la única particularidad de que funciona a través del puerto TCP 3268 en lugar de los puertos TCP 389 o 636 habituales, así que para dirigir consultas LDAP (queries) hacia el global catalog solo se requiere usar ese puerto y no ningún tipo de sintaxis especial.

Cuando configuremos el primer domain controller de un bosque este se configurara por defecto como Global Catalog, también podemos habilitar servidores adicionales de forma manual, para ello debemos ir a la consola de Sitios y servicios de Active Directory, buscar el controlador de dominio que queremos habilitar, o bien deshabilitar, e ir a NTDS Settings -> propiedades y marcar la opción de Catalogo Global.





Que sea accesible un controlador con global catalog es imprescindible en ciertos casos: para realizar una búsqueda entre todos los objetos del forest, para el logon de un usuario, búsquedas en libretas de direcciones de Exchange que tengan que acceder al global address list (GAL), para comprobar la pertenencia a grupos universales y en el caso de que tengamos un bosque con mas de un dominio es necesario cuando usamos el UPN (user principal name, por ej. usuario@dominio) y también cuando un usuario realice logon excepto si tenemos habilitada la opción de universal group membership caching que solo esta disponible en Windows Server 2003 o si hacemos una modificación en el registro (cambiar el valor de IgnoreGCFailures a 1).

La caché de pertenencia al grupo universal (universal group membership caching) se configura nivel de sitio (site) de active directory, se trata de una nueva característica de Windows Server 2003 pero estará disponible si tenemos un domain controller de 2003 aunque el nivel funcional del dominio sea Windows 2000. Para configurar esta opción debemos ir a la consola Sitios y servicios de Active Directory y en cada site en NTDS Site Settings -> propiedades se puede modificar esta opción y también seleccionar desde el site el cual se actualizara esta caché.





No debemos configurar el rol FSMO de maestro de infraestructura (infrastructure master) a un controlador de dominio que sea global catalog a menos que todos los controladores del dominio sean global catalog ya que no actualizaría la información de objetos que no tiene, que es la misión de ese rol, debido el catalogo global contiene copias parciales de todos los objetos del bosque. Si disponemos de ancho de banda suficiente, deberíamos tener si es posible un DC como global catalog en cada site, si el ancho de banda es limitado solo deberíamos posicionar global catalogs en sites con mas de 500 objetos en total entre usuarios y equipos ya que si es menor a eso es mas económico usar universal group membership caching.

| Enlace