Hola a todos,

Creo bastante oportuno hablar un poco acerca de esta propiedad de las que podemos dotar a nuestros Controladores de dominio.

Algunas abreviaturas para seguir este artículo, y disculpar por las definiciones en Inglés pero me parece más correcto así:

AD DS: Active Directory Domain Services

DC: Domain Controller

GC: Global Catalog

DNS: Domain Name System

UPNs: User Principal Names (daniel@contoso,com)

FSMO: Flexible Single Master Operations

 

La importancia de un buen diseño de AD DS es fundamental para el correcto funcionamiento de nuestro entorno, hay que tener en cuenta muchas variables, requerimientos, seguridad, topología geográfica, y un sin fin de variables que pueden hacer que nuestro diseño sea de una manera determinada, y apropiada para nuestra organización, o clientes.  Lo cierto es que a día de hoy parece que AD DS es de los productos más sencillos de desplegar, todos conocemos la errónea creencia del Siguiente, siguiente y siguiente y ya tienes un Dominio … y nada más lejos de la realidad los que nos dedicamos de verdad a esto sabemos que un mal diseño de AD DS puede afectar al negocio de tu cliente, y generar una auténtica catástrofe en entornos grandes que son Productivos.

En la arquitectura de AD DS hay bastantes factores a tener en cuenta, el núcleo por así decir sobre el que se sustenta nuestro AD DS es el servicio DNS, del que ya he escrito algunas entradas, y seguiré profundizando en sucesivas entradas, y otro factor muy importante es la topología de nuestro entorno, y por esa razón creo conveniente la entrada de hoy. En los foros de Microsoft en los cuales colaboro siempre que puedo, veo muchas consultas relacionadas con Global Catalog, y Universal Group Member Caching, pues bien veamos en profundidad que es cada una, que aportan, cuando usarlos y cuando no. 

Global Catalog

La definición sobre que es un GC sería algo así como un DC que almacena una copia completa de todos los objetos de su AD (aquí se refiere a los objetos de su propio dominio …del que forma parte el DC), y una copia parcial de todos los objetos de otros dominios en el bosque. Por lo tanto tiene replicas parciales de todas las particiones de dominios del bosque, estás réplicas parciales son distribuidas mediante replicación Multimaster (al igual que AD DS).

Por lo tanto podríamos decir que GC nos ofrece una funcionalidad crítica, y que pasa desapercibida en numerosas ocasiones.

Pero … ¿que hace exactamente un GC, o mejor dicho como aplica en el día a día su propia definición?

Tiene tres principales usos que serían:

Logon: Otra función es la de poder resolver los UPNs a la hora de hacer logon por ejemplo, como sabéis a la hora de validarnos en AD DS podemos hacerlo de varias maneras, las más común es hacerlo mediante domain_name\username, y otra es hacerlo mediante el UPN, el UPN usa formato de dirección de correo electrónico tipo daniel@contoso.com. El GC en este caso es el encargado de resolver o traducir el UPN a username.

Membresía de Grupos Universales : los grupos universales son un grupo de seguridad, y para refrescar un poco la memoria sobre ellos los grupos universales nos permiten aplicar permisos sobre cualquier recurso de nuestro dominio, y pueden contener objetos de cualquier dominio con el que tengamos relación de confianza. La membresía de los grupos Universales es almacenada en los GC, y replicada a través del forest.

image Os estaréis preguntando que tiene de especial esta funcionalidad del GC … los grupos universales están en AD DS… Si hacemos un poco de memoria en AD DS, cuando se introdujeron los grupos universales en AD DS en la versión Windows Server 2000 modo de funcionalidad Windows 2000 Nativo, resultaba que que si nuestro AD DS contaba con muchos grupos Universales, esto podía afectar al tráfico de red que generaban, ya que la información era replicada cada vez que se modificaba alguna propiedad de un objeto. En Windows 2003 se introdujo una mejora que fue la replicación de la membresía de grupos universales reduciendo drásticamente la carga de replicación.

Cuando un usuario se autentica, el DC debe poder ver los miembros de los grupos universales para determinar si permite autenticar a ese usuario en el dominio o no, por consiguiente debe existir al menos un GC en el AD DS, y por esa razón siempre el primer DC que se instala es GC. Si un GC está disponible localmente por ejemplo en el mismo site que el DC que intenta localizarlo contactará con el, si hubiera un GC en una ubicación remota el DC contactará con el GC remoto seguramente a través de una red WAN, y eso afectará al rendimiento, y al tiempo que se tarda en autenticar al usuario, por esa razón es muy importante tener un GC al menos en cada site.

Búsquedas en AD DS: El GC se encarga de procesar las peticiones de búsquedas sobre nuestro AD DS, esto que quiere decir, en definitiva quiere decir que cuando hacemos una búsqueda en AD DS el encargado de recibir dicha petición, y procesarla es el GC. Pongamos como ejemplo que abro una consola de Active directory users and computers, y haga una búsqueda cualquiera, la petición de búsqueda será enviada a un GC a través del puerto TCP 3268 (puerto específico para GC), y el GC procesará la petición.  ¿Cómo sabe a que GC enviar la consulta? Como ya hemos comentado al principio,el servicio DNS es fundamental en nuestra infraestructura de AD DS, y se basa en el para poder funcionar, y localizar los distintos servicios dentro de AD DS, los GC tienen un registro SRV denominado _gc que les identifica como GC, por lo tanto el servidor DNS identifica un GC, y se le envía la petición TCP por el puerto 3268.

image

Recomendaciones:

  • Tener al menos 2 GC por motivos de alta disponibilidad.
  • A día de hoy es altamente recomendado que todos los DCs sean GC en entornos denominados single-domain forest, ya que todos los DCs tienen la única partición de dominio en el forest. También lo es en entornos multi-domain.
  • Infrastructure Operation Master FSMO… no hacer GC a un DC que tiene el rol FSMO Infrastructure Master, a menos que todos los DCs sean GC, o el bosque tenga un único dominio.
  • ¿Existe alguna aplicación que requiera de un GC? Por ejemplo Exchange requiere el uso de GC, en esos casos hay que tener en cuenta el uso de GCs.

image Esto es solo una pequeña introducción a los GC, podemos investigar tanto como queramos, y en base a la estructura de la empresa el diseño será de una manera u otra, lo que está claro es que hay que toma tiempo para estudiar cada caso, los requerimientos, la topología, y el mejor diseño adaptado.

Algo de bibliografía

¿Qué es un GC? http://technet.microsoft.com/en-us/library/cc728188(v=ws.10).aspx

Scope de grupos en AD DS http://technet.microsoft.com/en-us/library/cc755692%28v=ws.10%29.aspx

Ubicación de GC http://technet.microsoft.com/en-us/library/cc732877%28v=ws.10%29.aspx

 

Lo dejamos aquí en esta entrada, profundizaremos más en sucesivas.

Un saludo,

DGM

Como todos sabéis el servicio DNS es el servicio de red más importante, y para Directorio Activo es crucial el uso de DNS, su funcionamiento se basa en DNS.

No voy a entrar a detallar el servicio DNS en si, sino que nos vamos a centrar en ver que novedades ha incluido Microsoft en Windows Server 2012.

  • DNSSEC: Por una parte parece que por fin se ha reforzado el servicio DNS a nivel de seguridad implementando (mejorando) DNS Security Extensions (DNSSEC) que protegerá el servicio, asegurando la autenticidad de las respuestas DNS. Es cierto que ya contábamos con ello en Windows 2008, pero ahora se ha simplificado su configuración y se ha mejorado.  DNSSEC nos protege de lo que comúnmente se denomina ataque man-in-the-middle que se resume como el acto de interceptar una respuesta DNS de un DNS server, y modificar el contenido de dicha respuesta, de tal forma que al cliente le llega la respuesta DNS apuntando hacia otros servidores. DNSSEC protege al cliente de las respuestas DNS falsas. Para proteger la integridad de los datos o respuestas DNS, se firman digitalmente con clave privada/pública, para llevar a cabo esta implementación en Windows Server 2012 se han introducido una serie de registros nuevos:

image

  • Consideraciones a tener en cuenta a la hora de implementar DNSSEC:
  1. El ámbito de replicación de una zona con DNSSEC no puede ser cambiado mientras la zona permanezca firmada digitalmente.
  2. El tráfico DNS aumenta debido a las peticiones de DNSKEY.
  3. Los mensajes de respuesta DNS pesan más.
  4. Los ficheros de zona tienen un mayor tamaño.
  5. Obviamente lleva cierto nivel más de administración.
  6. Los equipos cliente dedican más tiempo a la hora de autenticar las respuestas.
  • ¿Sobre que tipo de zonas convendría utilizar DNSSEC?

Teniendo en cuenta las consideraciones arriba descritas parece que una zona integrada en Directorio Activo con miles de registros no parece un candidato ideal para DNSSEC. Yo lo enfocaría más sobre que tipo de servicios son más vulnerables de man-in-the-middle… Podríamos empezar con servidores Web y servidores de correo en zona pública.

  • ¿Cómo se configura?

El proceso en si no es muy complicado, pero si conviene saber bien que configuración estamos aplicando, nivel de certificados, encriptación, longitud …. En las propiedades de la zona que queremos configurar con DNSSEC, en el desplegamos seleccionamos DNSSEC y SIGN THE ZONE (firmar la zona)

image

Como es la primera zona que vamos a firmar, procedemos a configurarlo con el asistente

image

Debemos elegir que DNS autoritativo de la zona que vamos a securizar será el Key Master, en este caso la zona está integrada en directorio activo, y cualquiera de los DCs es autoritativo.

image

image

El siguiente paso es configurar el tipo de KSK (Key Signing Key) con los parámetros que creamos oportunos (tipo de encriptación, longitud bits …):

image

Una vez generado aun debemos configurar la ZSK (Zone Signing Key) para firmar la zona con la llave privada.

image

Ahora quedaría configurar la parte de NSEC o NSEC3, estos son los registros encargados de por decirlo de alguna manera combatir la suplantación de identidad. Podemos seleccionar NSEC o NSEC3 no ambos.

Y finalizaríamos la configuración.

 

Es un tema en el que se puede profundizar mucho,entrando más en materia de algoritmos, encriptación …

Dejo algunos enlaces de referencia para profundizar más en el tema:

http://technet.microsoft.com/es-es/library/hh831411.aspx

http://strotmann.de/roller/dnsworkshop/entry/dnssec_validation_in_microsoft_dns

DGM

Hola muy buenas tardes,

Trabajando esta semana en el diseño de las zonas DNS, ha salido a la luz el Efecto Isla, hacía años que no escuchaba este término, he de decir que generó muchos quebraderos de cabeza a los administradores.

A día de hoy, he visto que aún hay técnicos que configuran la parte cliente de sus DNS Servers apuntando a un DNS server distinto de si mismo, y como secundario a si mismo.

El efecto Isla se dió a conocer con la versión de servidor Windows 2000. De echo recuerdo algún que otro ADRAP en los clientes para los que he trabajado, y las recomendaciones para W2003 según el PFE seguían siendo las mismas.

http://support.microsoft.com/kb/275278/en-us#top

EL problema viene dado cuando un DNS server que alberga la zona  _msdcs. ForestDnsName (Root domain), apunta a si mismo como DNS server en la configuración DNS cliente del TCP, no tiene un registro CNAME (el cual especifica el GUID del Domain Controller)  en dicha zona, estos registros CNAME son absolutamente necesarios para qeu la replicación funcione correctamente.

Cada vez que un DC replica con otro DC, este envia un aquery a la zona root (_msdcs. ForestDnsName ) en busca del GUID del otro DC contra el que quiere replicar, si esta query falla, la replicación también. Por consiguiente el DC poco a poco va quedando sin replicación, y se aisla del resto, ya que su contenido no ha recibido ni enviado las últimas modificaciones. Esto provoca inconsistencia en ese DC, y si un servicio, aplicación o usuarios usan ese DC, no están trabajando sobre la correcta versión de la base de datos de AD.

En teoria Microsoft solucionó este problema en W2003, de tal manera que el DC que intenta buscar el CNAME del otro DC para comenzar la replicación no lo encuentra, ahora preguntará por otros registros CNAME, por lo que la replicación sucederá.

 

Saludos

Dani Gracia