Limite 48 Horas!!!!!

Buenas a todos, en primer lugar quería pedir disculpas por este mes de ausencia en mi blog, ha habido algunos cambios en mi entorno laboral y aún estoy intentando engancharme a la nueva estructura, también he tenido que renovar alguna certificación por lo que entre unas cosas y otras no he tenido mucho tiempo para actualizar el blog. Aclarado todo esto quería incluir entre los demás artículos un ajuste importante en la configuración de Active Directory que viene a completar varios puntos que se tocaron en otros post.

Como sabéis el valor de marca horaria es muy importante para muchos temas de validación, es aspecto fundamental de Active Directory que la hora sea correcta tanto en los clientes como en los servidores. Como ya he comentado en otro post, el PDC Emulator es el servidor contra el cual va a sincronizar todo el dominio. El orden exacto es que el PDC sincronice la hora contra un servidor NTP fiable, los DCs lo harán contra el PDC y los servidores miembro y clientes contra el DC de validación. Las configuraciones de sincronización de hora se deben establecer tal y como describo en el post Configuración y Tuning de Active Directory (Parte I). En el Post de Configuración y Tuning de Active Directory (Parte II) hacía mención al valor de TombStone LifeTime, si recordáis este valor determinaba entre otras cosas durante cuánto tiempo como máximo pueden estar sin replicar dos controladores de dominio para que uno considere al otro como válido.

Ahora vamos a plantear el siguiente escenario, yo he configurado el PDC Emulator de mi dominio para que apunte a un servidor de hora en Internet, el resto de controladores de dominio están configurados en NT5DS para seguir la jerarquía del dominio. Supongamos que alguien con fines no muy saludables suplanta la identidad del servidor NTP de internet y le envía a mi controlador de dominio una actualización de fecha y hora del año 2006, ¿Qué podría ocurrir?. Según Microsoft esto es un riesgo importante ya que los controladores de dominio podrían considerar que ese servidor ha superado el tiempo establecido en el Tombstone Lifetime y dejar esa máquina fuera del dominio. Ahora, supongamos que mi dominio tiene 8 DCs y la actualización que le llega al PDC emulator desde su servidor de hora es del año 2010, ¿Qué ocurriría entonces?. Bien es este caso el servidor que determina cual es la hora correcta está configurado en el año 2010 y podría considerar que el resto de DCs están fuera de ese límite de tiempo establecido por el Tombstone, por lo que entendería que el resto de DCs no son válidos y los consideraría fuera de dominio.

Para evitar este tipo de confusiones se puede establecer que nuestros DCs no acepten como actualizaciones válidas de hora aquellas que superen las 48 horas tanto de atraso como de adelanto. Si esto ocurre, en cualquier caso lo más traumático que nos podría ocurrir sería que dejaran de validar clientes contra nuestro dominio ya que como sabéis el límite que establece kerberos para determinar si un cliente es válido o no es de 300 segundos, en ningún caso las máquinas se saldrían del dominio.

Para poder activar estas opciones tenemos que acceder a la siguiente clave de registro:
HKLM\System\CurrentControlSet\Services\W32Time\Config
Una vez allí tenemos las opciones MaxNegPhaseCorrection y MaxPosPhaseCorrection que nos permitirán establecer en segundos el tiempo máximo que se espera recibir como sincronización de hora tanto positivo como negativo. Para establecer las 48 horas recomendadas por Microsoft tendremos que colocar el valor en 2880 segundos.

Espero que esta información os sea de utilidad y como siempre espero vuestros comentarios.

Soluciones con Etherchannel de Capa2

Hay mucha gente que aun no conoce el concepto de Etherchannel y por culpa de este desconocimiento estamos perdiendo una gran ventaja del switching actual. Un Etherchannel nos permite sumar la velocidad nominal de cada puerto físico y así obtener un único enlace troncal de alta velocidad. Supongamos que tenemos la topología de la siguiente figura:

Cuando tenemos una serie de servidores que salen por un único enlace trocal, pueda ser que el tráfico generado llegue a colapsar el enlace. Una de las soluciones más prácticas que se suele implementar en estos casos es el uso de Etherchannel. Cuando generamos un Etherchannel lo que estamos haciendo es sumar la velocidad de los puertos que agregamos al enlace lógico obteniendo el siguiente resultado.

Esta es una solución muy implementada en servidores Blade, un servidor de estas características es una maquina diseñada para poder ahorrar espacio en los CPD, reducir consumo y simplificar la administración. Un chasis de Blade incorpora las fuentes de alimentación, elementos de ventilación y de conectividad LAN y SAN. Los servidores son delgadas tarjetas que incorporan los componentes propios del servidor como el procesador la memoria y los buses.

Un chasis de Blade puede tener hasta 16 servidores dependiendo del fabricante y estos chasis en su parte posterior suelen llevar entre uno y cuatro switches. Si queremos sacar todo este tráfico hacia el exterior sin sufrir colapsos en los troncales la solución más recomendable es configurar un Etherchannel. La conexión física quedaría como se puede ver a continuación:

Existen varias formas de configurar un Etherchannel, el objetivo de este post no es explicar en profundidad como funciona cada uno de los protocolos, pero intentaré dejar lo suficientemente claro cuando usar cada uno de ellos. Podemos configurar un Etherchannel de tres formas diferentes, Port Aggregation Protocol (PAgP), Link Aggregation Control Protocol (LACP) o en modo ON, además ambos extremos se han de configurar en el mismo modo. Cuando se configura PAgP o LACP el switch negocia con el otro extremo que puertos deben ponerse activos, aquellos puertos que no sean compatibles se dejan desactivados en versiones anteriores a la 12.2(35) SE, a partir de esta versión el puerto queda activo pero no se agrega al Etherchannel, este puerto seguirá trabajando de forma independiente. Cuando configuramos en modo ON no se realiza ningún tipo de negociación, el switch obliga a todos los puertos compatibles a ponerse activos.

PAgP es un protocolo propietario de Cisco, PAgP se encarga de agrupar puertos de características similares de forma automática. PAgP es capaz de agrupar puertos de la misma velocidad, modo dúplex, troncales o de asignación a una misma VLAN.
PAgP se puede configurar de dos modos:
• Auto, establece el puerto en una negociación pasiva, el puerto solo responderá a paquetes PAgP cuando los reciba, pero nunca iniciará la negociación.
• Desirable, establece el puerto en modo de negociación activa, este puerto negociará el estado cuando reciba paquetes PAgP y también podrá iniciar una negociación contra otros puertos.

Hay que tener en cuenta que un puerto en modo desirable puede formar grupo con otro puerto en el mismo modo, también podrá formar grupo con un puerto en modo auto. Dos puertos en modo auto nunca podrán formar grupo ya que ninguno de ellos puede iniciar una negociación.

LACP es un protocolo definido en el estándar 802.1ad y que puede ser implementado en switches cisco. LACP y PAgP funcionan de forma muy similar ya que LACP también puede agrupar puertos por su velocidad, modo dúplex, trocales, VLAN nativas, etc.

LACP también tiene dos modos de configuración:
• Activo, un puerto en este estado es capaz de iniciar negociaciones con otros puertos para establecer el grupo.
• Pasivo, un puerto en este estado es un puerto que no iniciará ningún tipo de negociación pero si responderá a las negociaciones generadas por otros puertos.
Al igual que LAgP, dos puertos pasivos nunca podrán formar grupo.

El modo ON es un modo de configuración en el cual se establece toda la configuración del puerto de forma manual, no existe ningún tipo de negociación entre los puertos para establecer un grupo. En este tipo de configuración es totalmente necesario que ambos lados estén en modo ON.

Podríamos profundizar aún más pero creo que con esto es suficiente, se puede aplicar diferentes configuraciones a un Etherchannel según las necesidades, establecer prioridades y otras opciones pero nos extenderíamos demasiado, por eso voy a pasar a explicar una configuración sencilla en la cual generamos un Etherchannel de cuatro puertos en modo ON. Como ya he comentado es imprescindible configurar los puertos en modo ON en ambos lados y no requiere mucho esfuerzo.

Cuando se crea un Etherchannel todos los puertos que pertenecen a este adquieren todos los parámetros del primer puerto agregado al grupo, por eso una recomendación es configurar este primer puerto con todas las opciones que le queramos establecer (STP, VLANs, etc…).

También sería importante seguir estas recomendaciones:
• No se debe configurar un puerto en dos grupos diferentes.
• No se debe configurar un puerto en dos modos diferentes, LACP y PAgP.
• No configurar Switched Port Analyzer (SPAN) como parte de un Etherchannel.
• No configurar securización de puertos.
• Asignar todos los puertos del Etherchannel a la misma VLAN o configurar todos como troncales.
• Verificar que todos los puertos del grupo están en un mismo modo de encapsulación, ISL o 802.1Q

En la Web de cisco podréis encontrar más detalladamente todas estas recomendaciones y alguna más.

Configuración de link troncal de Etherchannel L2 modo ON (Switch 1)

Switch1# configure terminal
Switch1(config)# interface range gigabitethernet0/1 - 4
Switch1(config-if-range)# switchport mode trunk
Switch1(config-if-range)# channel-group 1 mode on
Switch1(config-if-range)# exit
Switch1(config)# exit
Switch1# copy run start

Configuración de link troncal de Etherchannel L2 modo ON (Switch 2)

Switch2# configure terminal
Switch2(config)# interface range gigabitethernet0/1 - 4
Switch2(config-if-range)# switchport mode trunk
Switch2(config-if-range)# channel-group 1 mode on
Switch2(config-if-range)# exit
Switch2(config)# exit
Switch2# copy run start

Configuración de link troncal de Etherchannel L2 con LACP (Switch 1)

Switch# configure terminal
Switch1(config)# interface range gigabitethernet0/1 - 4
Switch1(config-if-range)# switchport mode trunk
Switch1(config-if-range)# channel-group encapsulation LACP
Switch1(config-if-range)# channel-group 1 mode active
Switch1(config-if-range)# exit
Switch1(config)# exit
Switch1# copy run start

Configuración de link troncal de Etherchannel L2 con LACP (Switch 2)

Switch2# configure terminal
Switch2(config)# interface range gigabitethernet0/1 - 4
Switch2(config-if-range)# switchport mode trunk
Switch2(config-if-range)# channel-group encapsulation LACP
Switch2(config-if-range)# channel-group 1 mode active
Switch2(config-if-range)# exit
Switch2(config)# exit
Switch2# copy run start

Una vez hecho esto podemos configurar la interfaz lógica de la siguiente forma:

Switch1# configure terminal
Switch1(config)# interface port-channel 1
Switch1(config-if)#

Desde este modo de configuración podemos configurar parámetros que se aplicaran a todos los puertos del grupo. Para chequear que el Etherchannel esta funcionando usamos el siguiente comando:

Switch1> show port channel 1
Port Status Channel Channel Neighbor Neighbor
mode status device port
----- ---------- ------- ----------- ------------------------- ----------
0/1 connected on channel Switch2 0/1
0/2 connected on channel Switch2 0/2
0/3 connected on channel Switch2 0/3
0/4 connected on channel Switch2 0/4
Switch1>

Como ya he comentado, este es un tema que podríamos extenderlo bastante más pero creo que con estos datos podríais configurar un Etherchannel sencillo para evitar que se pueda saturar un enlace troncal o aprovechar los puertos del switch que viene integrado en el chasis del Blade. Espero que os haya sido de utilidad y como siempre espero vuestros comentarios.

Configuración y Tuning de Active Directory (Parte II)

Como lo prometido es deuda, aquí vamos con la segunda parte de ajustes para mejorar el rendimiento de nuestro Directorio Activo. Tal vez algunos de estos puntos ya os resulten familiares, pero creo que es importante recordarlos ya que en muchos sitios he visto que no se siguen estas Best practices.

Activar Notificación

Existen casos en los cuales por la distribución de nuestra red física tendremos que repartir nuestros DCs en diferentes Sites. En ciertas topologías y como Best Practice se establecen dos Sites principales de los cuales cuelgan el resto de los sites de la topología, en estos casos y cuando el ancho de banda nos lo permita, nos interesa habilitar la notificación entre los sites principales. Esta configuración nos va a permitir que las modificaciones de cualquier objeto de nuestro AD sea notificado inmediatamente entre estos dos sites principales, a partir de ahí estos sites replicaran cuando corresponda contra el resto.

Supongamos que tenemos la configuración de Sites que se muestra a continuación:

Para habilitar la notificación entre los sites 1 y 2 debemos realizar los siguientes pasos, accedemos al ADSI Edit y accedemos al contenedor Sites. Una vez allí hacemos clic con el botón derecho en el site link donde queremos habilitar la notificación y seleccionamos la opción de propiedades como indica la imagen:

Una vez hecho esto, buscamos el atributo opciones, estará establecido en <not set> para habilitar la notificación tenemos que establecer el valor en 0001, con esto la notificación quedará activada y cada vez que se haga un cambio en el site 1 se replicará automáticamente al site 2.

Definición de Subredes

Otro error muy típico dentro de la configuración de AD, es no definir las subredes apropiadas, cuando solo tenemos un site no es un problema demasiado grave, pero cuando tenemos más de un site y sobretodo estos están físicamente separados por líneas de anchos de banda bajos, puede provocar un retardo en la validación importante.

Si no definimos las subredes y las asignamos al site apropiado, esto puede provocar que clientes de un site se vayan a validar a otro site lejano. Solucionar esto es muy sencillo, basta con abrir Active Directory Sites and Services (Sitios y servicios de Active Directory) y en el contenedor de Subnets agregar la dirección de subred, la máscara y asociarla al site correspondiente como se ve en la imagen.

Con esto es suficiente para solventar el problema y cada cliente validará contra el controlador de dominio más cercano. Ya sé que es una configuración de libro pero, me sorprende ver en muchos sitios que esta parte de la configuración no se realiza.

Cambiar el Tombstone Lifetime

Existe un valor que sorprendentemente muy pocos conocen y juega un papel vital en nuestro directorio activo, es lo que conocemos como Tombstone Lifetime, este valor está establecido por defecto a 60 días en dominios levantados antes de Windows 2003 Server SP1, a partir de aquí se establece en 180 días. Cuando eliminamos un objeto del directorio activo, este de forma automática pasa a un contenedor que no está visible denominado Deleted Objects, este contenedor es una especie de papelera de reciclaje en la cual los objetos eliminados se conservan por un tiempo igual al Tombstone Lifetime. Otro de los límites marcados por este valor es durante cuánto tiempo puede estar sin validar, por ejemplo, un Controlador de Dominio. Supongamos que se corta la comunicación entre dos Controladores de Dominio y el valor de Tombstone está muy bajo, cuando ambos controladores de dominio vuelvan a contactar, el DC se dará cuenta de que ha sobrepasado el tiempo valido y cortará automáticamente la replicación para evitar problemas con objetos ya eliminados entre otros puntos.

También hay que tener en cuenta que un backup de un controlador de dominio ya no se considera válido si este fue realizado en un tiempo superior al indicado en el Tombstone. La recomendación es que se realice una copia diaria, aunque el intervalo de esta copia puede variar en función del número de modificaciones que se ejecuten en nuestro Active Directory. Mucha gente, no lo toca este valor y lo deja según viene por defecto, como he comentado son 60 días antes de SP1 de 2003 y 180 días en cualquier dominio levantado a partir de esta versión, pero en algunas ocasiones necesitamos modificar este valor. Hay que tener cuidado ya que si se establece un tiempo muy bajo y se producen cortes de comunicaciones entre DCs tendríamos problemas. En ese caso tendríamos que realizar un dcpromo /forceremoval, eliminar el objeto a mano del Directorio Activo y volver a promocionar este servidor.

Existen varias formas para personalizar el Tombstone Lifetime, se puede realizar mediante ADSI Edit o con un script, pasare de detallar como realizarlo en cada ocasión:

ADSI Edit:

Abrimos ADSI Edit y seleccionamos Configuration>CN=Configuration, < ForestRootDN >, en mi caso como se puede ver en la imagen ForestRootDN es igual a DC=mqta,DC=inet por lo cual el resultado es, Configuration>CN=Configuration, DC=mqta,DC=inet>CN=Services>CN=Windows NT. Una vez aquí, hacemos clic con el botón derecho en CN=Directory Service y marcamos sus propiedades.

Una vez hecho esto buscamos el atributo tombstoneLifetime y colocamos el valor deseado

Script en vbs

Creamos un notepad, insertamos el texto que tenemos abajo, sustituímos <dias> por la nueva configuración, lo guardamos con extensión .vbs y una vez hecho esto, se ejecuta en un DC.

intTombstoneLifetime = <dias>

set objRootDSE = GetObject("LDAP://RootDSE")

set objDSCont = GetObject("LDAP://cn=Directory Service,cn=Windows NT," & "cn=Services," & objRootDSE.Get("configurationNamingContext") )

objDSCont.Put "tombstoneLifetime", intTombstoneLifetime

objDSCont.SetInfo

WScript.Echo "Successfully set the tombstone lifetime to " & intTombstoneLifetime

Espero que estos puntos os sean de ayuda y como siempre espero vuestros comentarios.

Información interesante sobre Cisco

Mientras continuo preparando cosillas sobre Cisco, aquí os dejo un link muy interesante donde encontraréis bastante información sobre manuales de Cisco, especialmente CCNA y otra documentación que seguro que os será de bastante utilidad.

http://www.garciagaston.com.ar

No se me ha olvidado, os debo una segunda parte de Configuración y Tuning de Directorio Activo, no os defraudara. Saludos a todos.

Ampliar el Esquema de AD de forma segura

Mientras voy terminando la segunda parte del articulo de Configuración y Tuning de Active Directory, he pensado que para no relajarnos puede venir bien este pequeño articulo de como ampliar de forma limpia y segura el esquema de nuestro Active Directory.

Existen multitud de aplicaciones y servicios que para poder ser instalados y puestos en producción requieren que previamente se realice una ampliación de nuestro Active Directory. Exchange, SMS y Office Communicator Server son algunos de los servicios que requieren la ampliación del esquema de nuestro Active Directory. También cuando migramos un dominio de Windows 2000 Server a Windows Server 2003 es necesario modificar el esquema, incluso cuando se va a agregar un servidor con Windows Server 2003 R2 como controlador de dominio cuando los demás servidores son anteriores a R2, hay que realizar esta operación.

Cuando solo tenemos un controlador de dominio la única opción que tenemos es, realizar un backup completo del servidor, seguir el procedimiento de ampliación de esquema según el producto que vayamos a instalar y rezar para que no falle y tengamos que restaurar a partir de la copia de seguridad que acabamos de hacer. Cuando tenemos varios controladores de dominio Microsoft hace una recomendación muy importante, aislar el controlador de dominio donde se va a realizar la operación.

Aquí me gustaría hacer una observación, para aislar un DC y que este no replique contra el resto ni el resto contra el, no es necesario apagar los demás DCs ni desconectar este de la red. Si, como lo estáis leyendo, hay gente que hace esto. Bueno de esta forma estamos seguros que este DC queda aislado, pero hay que preocuparse de demasiadas cosas que pueden provocar el error, que este DC sea DNS, Schema Master etc. Desde mi punto de vista esto es matar moscas a cañonazos.

Bien, ¿cómo ampliamos nuestro esquema de una forma limpia y sencilla?, vamos a ello. Accedemos al servidor que es Schema Master, este tiene que tener instaladas las support tools. Nuestro usuario ha de ser Administrador de Dominio y Administrador de Esquema y una vez allí, pasamos a deshabilitar la replicación entrante y saliente con el siguiente comando:

REPADMIN /OPTIONS SERVERNAME +DISABLE_INBOUND_REPL -> Detiene la replicación Entrante
REPADMIN /OPTIONS SERVERNAME +DISABLE_OUTBOUND_REPL -> Detiene la replicación Saliente

Una vez hecho esto nuestro servidor dejara de replicar contra el resto de DCs y el resto dejara de replicar contra él, es posible que veamos en algún visor de eventos errores de replicación, pero evidentemente tenemos que tomarlo como algo normal. Una vez hecho esto ya podemos ampliar el esquema por el procedimiento que indique el producto y realizando las pruebas pertinentes . Yo lo que suelo hacer es, dejar deshabilitada la replicación durante un tiempo razonable y comprobar que el DC continua dando servicio sin que aparezcan errores graves en el visor de eventos. Una vez que todo esta correcto volvemos a activar la replicación con el siguiente comando:

REPADMIN /OPTIONS SERVERNAME -DISABLE_INBOUND_REPL -> Activa la replicación Entrante
REPADMIN /OPTIONS SERVERNAME -DISABLE_OUTBOUND_REPL -> Activa la replicación Saliente

A continuación comprobamos que el servidor replica de forma correcta, cuando esto ocurra ya podremos respirar tranquilos. De esta forma nos aseguramos que si algo sale mal, no será replicado a los demás DCs y no necesitamos apagar servidores ni desconectar nada de la red, el servidor sigue trabajando de forma normal pero ni envía datos ni los recibe. ¿Y que hacemos si algo sale mal?, bueno, podemos reinstalar la máquina una vez que la desconectamos de la red y hacer un restore del backup previo. Yo personalmente, prefiero desconectar el servidor, reisntalar y en lugar de recuperar el restore, elimino el objeto de servidor del dominio con ntds util y lo promociono desde cero. Con esto nos aseguramos de que el Controlador de Dominio está limpio, no olvideis que antes hemos tenido que asumir el rol de Schema Master en otro DC.

Creo que este procedimiento es el más limpio de todos y el más seguro, dejo para otras ocasiones el como eliminar objetos con ntds util y algún otro punto de este articulo que he pasado por encima pero, el objetivo era indicar como detener la replicación de un DC si afectar a su funcionamiento. Espero que os sea de utilidad y como siempre espero vuestros comentarios.

Configuración y Tuning de Active Directory (Parte I)

Hola a todos, como lo prometido es deuda, voy con un pequeño artículo de tuning de Active Directoy, aunque sobre este tema se podrían escribir páginas y páginas enteras, voy a intentar resaltar algunos ejemplos importantes con los que me he encontrado.

Para comenzar, creo que es bueno recordar algunos puntos de configuración básicos que, aunque de seguro muchos de vosotros ya sabréis, es importante mencionarlos pues no en pocos sitios me he encontrado que estas reglas no se siguen como se debe.

Versión de Sistema Operativo

En primer lugar una de las más importantes recomendaciones que hace Microsoft es que todos los controladores de dominio sean la misma versión de sistema operativo y que todos estén al mismo nivel de parcheado, como todos sabréis la única versión en la que no podréis instalar un controlador de dominio es en un Windows 2003 Server Web Edition. No sería la primera vez que encontramos problemas diversos porque un servidor tiene una versión de SP diferente a la de sus compañeros de replicación.

Configuración de DNS

Otro de los puntos importantes que hay que tener en cuenta a la hora de configurar nuestro dominio es la configuración de los DNS, no solamente en los servidores, también en los clientes. En muchas redes pequeñas con uno o dos controladores de dominio, nos hemos encontrado que los PC’s no aplican bien las políticas o aparecen errores a la hora de acceder a los recursos. Lo ideal en este caso es que, si tenemos un solo controlador de dominio, en este tiene que estar montado el servicio DNS, en la configuración de red del servidor hay que configurar su propia IP como primer servidor DNS y dentro de la consola del servicio DNS, configurar en los reenviadores los servidores DNS del proveedor de servicios de internet. Es importante que esto este así, ya que nos podría dar muchos problemas a la hora de aplicar políticas entre otras cosas.

Los clientes deben tener en su configuración de red como servidores DNS primario y secundario los Controladores de Dominio que ejerzan esta función, nunca y en ningún caso los servidores DNS del proveedor de servicios de internet, estos estarán configurados en los reenviadores de los DNS como ya he mencionado. Si un usuario tiene que salir a internet, la secuencia será la siguiente, el usuario del dominio empresa.local quiere visitar la web www.heroescertificados.com, este preguntara a su DNS, que es el Controlador de Dominio, como este será incapaz de resolver este nombre, utilizara las direcciones colocadas en los reenviadores para intentar resolverlo y hará la petición a los DNS del proveedor. Una de las ventajas que aportó Windows 2003 Server en su momento con respecto al 2000 es el reenvío condicional.

Para todos aquellos que trabajéis en un dominio en Windows 2000 o que por motivos concretos tengáis que montarlo tenéis que tener muy presente que en el DNS hay que eliminar la zona punto. Esto es muy importante ya que si no lo hacéis, este será un servidor DNS Raíz, por lo cual no se puede configurar los reenviadores y si este servidor no conoce un nombre, contestara de forma autoritativa que ese nombre no existe.

Maestro de Infraestructuras y Catálogo global

Como ya sabréis en un dominio existen cinco roles FSMO, estos son el Maestro de Esquema y el Maestro de nombres de dominio, este ultimo debería estar en un Controlador de Dominio que sea catálogo global y ambos son únicos en el bosque. Aquellos que son únicos en cada dominio son el Maestro de Identificadores Relativos (RID Master), emulador de PDC y maestro de infraestructuras. Cada uno tiene una función importantísima y tienen que estar presentes.

Lo que yo sabía desde Windows 2000 Server, es que tenias que configurar un catálogo global por site y solo en el caso en el que haya un solo DC no han de coincidir en un mismo servidor un catálogo global y el maestro de infraestructura. Hasta aquí, en Windows Server 2003 ocurre lo mismo, el maestro de infraestructura no ha de coincidir con un catálogo global ya que si esto es así, este rol no funcionaria. Algo que me llamo mucho la atención en una de las revisiones de Active Directory en las que participé, es que Microsoft nos recomendó que colocáramos todos los Controladores de Dominio excepto el maestro de infraestructura como catálogo global. Si os soy sincero, no dieron muchas explicaciones, la pregunta que rápidamente se me ocurrió fue, ¿y esto porque?, su respuesta fue rotunda, ¿y porque no?.

Como mi memoria en ciertos casos es algo limitada, acudí a mi compañero Jesús M. Nacimiento, la explicación tiene toda la lógica del mundo. El catálogo global está diseñado para responder al usuario y a las preguntas de programa, sobre los objetos situados en cualquier lugar del árbol de dominio o bosque a la mayor brevedad posible. Si tenemos recursos suficientes entre los controladores de dominio y la replicación no es una carga para nuestro ancho de banda, ¿para qué voy a preguntar algo a un DC que no tendrá esta información, cuando puedo tener todos mis DCs con la respuesta correcta?. Esto ya es algo que tendréis que determinar vosotros y saber cuándo vuestro ancho de banda puede soportar la carga de replicación que esto puede generar.

Exclusiones en el análisis del antivirus

Otro error muy típico es instalar nuestro antivirus y no realizar ningún tipo de ajuste a su funcionamiento. Existen una serie de ficheros en un controlador de dominio que no deberían ser revisados por el antivirus ya que no tienen riesgo de infección y su análisis podría causar problemas por bloqueo de los mismos.

Los ficheros a excluir correspondientes a un DC son los siguientes:

• Ficheros de la BBDD NTDS, su ubicación está definida en la clave de registro HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\DSA Database File, su ubicación por defecto es %windir%\ntds y se han excluir los ficheros ntds.dit y ntds.pat.

• Ficheros de la carpeta NTDS Working, su ubicación está definida en la clave de registro HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\DSA Working Directory, en esta ubicación hay que excluir los ficheros temp.edb y edb.chk.

• Ficheros del registro de transacciones de Active Directory, su ubicación está definida en la clave de registro HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\Database Log Files Path, su ubicación por defecto es %windir%\ntds y hay que excluir los ficheros Res1.log, Res2.log, ntds.pat y EDB*.log (este asterisco hay que usarlo ya que puede haber más de un fichero). Windows 2003 Server ya no usa el fichero ntds.pat.

• Fichero de la carpeta de trabajo del servicio de replicación de ficheros (FRS), su ubicación está definida en la clave de registro HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Working Directory, en esta ubicación hay que excluir los ficheros ubicación\jet\sys\edb.chk, ubicación\jet\sys\ntfrs.jdb y ubicación\jet\sys\log\*.log.

• Ficheros de registro de la BBDD de FRS, su ubicación está definida en la clave de registro HKEY_LOCAL_MACHINE\system\currentcontrolset\services\NtFrs\Parameters\DB Log File Directory su ubicación por defecto es %windir%\ntfrs, si esta clave de registro no estuviese establecida se excluirían todos los ficheros *.log de la carpeta de trabajo del servicio de replicación de ficheros.

• Ficheros y subcarpetas de la carpeta staging, su ubicación está definida en la clave de registro HKEY_LOCAL_MACHINE\system\currentcontrolset\services\NtFrs\Parameters\Replica Sets\GUID\Replica Set Stage, la ubicación por defecto de esta carpeta %systemroot%\sysvol\staging areas. También es necesario excluir la carpeta SYSVOL, su ubicación por defecto es %systemroot%\sysvol\sysvol. Es importante mencionar que SI se han de escanear dentro de SYSVOL las siguientes ubicaciones, %systemroot%\sysvol\domain, %systemroot%\sysvol\domain\Policies y %systemroot%\sysvol\domain\Scripts.

• Ficheros y subcarpetas de la carpeta FRS Preinstall que están es la siguiente ubicación raízDeRéplica\DO_NOT_REMOVE_NtFrs_PreInstall_Directory.

Configuración de Hora

Otro tema importante es la sincronización de hora, en un dominio, los controladores de dominio han de sincronizar la hora contra el DC que tenga el ROL de PDC Emulator. A su vez, todos los clientes y servidores del dominio han de sincronizar su hora contra su LOGONSERVER ya que como sabréis, si hay un desfase superior a X segundos no se producirá la validación. Por defecto este valor está establecido en 300 segundos. Para que se cumpla esta jerarquía, todos los DCs del dominio tienen que tener establecido el método de sincronización como NT5DS excepto el servidor con el rol de PDC Emulator que tiene que estar en NTP. Para poder cambiar este valor tenemos que acudir a las siguientes claves de registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\

Para el DC que es PDC Emulator

Type = NTP, NtpServer = A.B.C.D,0x8 (dirección IP del servidor para la sincronización de hora, actualmente creo recordar que se puede sincronizar contra los servidores NTP de la red iris hora.rediris.es )

Para el resto de DCs

Type = NT5DS,

Estas son algunas recomendaciones, intentare recopilar las KBs donde podreis encontrar algo más de información sobre lo que os acabo de contar. Por el momento lo voy a dejar aquí, en breve os incluiré más cosas interesantes de cara a depurar el rendimiento de nuestro directorio activo. Espero que os sea de utilidad. Gracias a todos y espero vuestros comentarios.

Cisco Certified Entry Network Technician (CCENT)

Hola de nuevo, aquí os dejo un artículo que me pidieron que escribiera para la revista que CICE lanzo estas navidades. Simplemente es una opinión de cómo encaja la nueva certificación CCENT dentro del perfil de alumnos que tiene el programa CNAP. Espero que os guste.

CCNA EXPLORATION

Hace algunos meses leí un artículo que me llamó mucho la atención, parece ser que desde que estalló la burbuja tecnológica las empresas del sector se empiezan a recuperar con fuerza, lo que ha permitido superar los 100.000 empleados y volver a las cifras que tenían en el año 2000. Esta es una gran ventaja para todos aquellos que vivimos de este sector, ya que puede ser una oportunidad de evolucionar para muchos de nosotros e incluso para aquellas personas que se quieran iniciar en este mundo.

Durante el tiempo que llevo impartiendo cursos de Cisco, me he encontrado diferentes perfiles de alumnos. Están aquellos que proceden de empresas con grandes dispositivos y están acostumbrados a lidiar día a día con maquinas de este tipo, la intención de estos alumnos es clara, acceder a las certificaciones de Cisco a través del CCNA. Luego están aquellos que se dedican a dar soporte al usuario y pretenden evolucionar en esta dirección, y por último están los alumnos que no tienen que ver con el mundo del Networking y pretenden iniciarse en el.

Nuestro objetivo cada vez que un curso inicia, es tratar de nivelar el grupo de tal forma que el alumno que comienza en esta rama no se agobie y el alumno experto en redes no se aburra, os aseguro que no es una tarea fácil. Cisco mediante el Networking Academy Program, ha puesto en marcha una nueva certificación denominada Cisco Certified Entry Network Technician (CCENT), esta certificación permite agrupar los niveles de los alumnos de una forma mucho más acertada desde mi punto de vista.

Esta certificación está especialmente diseñada para aquellas personas que no tienen experiencia en el mundo de las redes, o aquellos que trabajan en entornos pequeños y los contenidos del CCNA son excesivos. El CCENT no solo trabaja términos básicos de Networking, también trabaja en soporte a puestos de trabajo, sistemas operativos, conceptos básicos de seguridad y pequeñas redes Wireless. Este tipo de curso es idóneo para que, aquellas personas que han decidido iniciarse en el mundo de las redes no se sientan atropelladas por el torrente de información que contiene el CCNA.

Aun así el CCENT deja una puerta entreabierta a entornos mucho más empresariales, y no deja de lado la evolución del alumno hacia este tipo de entornos, mostrando desde los tipos de dispositivos que se pueden encontrar en estas grandes redes, hasta la documentación que sería necesaria. Por otro lado la certificación CCNA continúa en la misma línea pero actualizando sus contenidos como ya ocurrió en otras ocasiones. En mi opinión, esta nueva puerta permite que cada perfil de alumno reciba los conocimientos adecuados y evitará que muchos de estos en ciertas ocasiones se sientan desbordados de información o desmotivados por temas aburridos y de sobra conocidos para ellos.

Javier CAZALLAS
Instructor Certificado Cisco

Ordenando Cuentas de Máquina en Grupos de Directorio Activo

A la hora de administrar un entorno de un número importante de PCs hay que tener siempre presente dos cosas.

La primera es el orden que tenemos que llevar a la hora de realizar ciertas tareas. Cuando trabajamos con un alto número de máquinas el desorden puede hacer que al cabo del tiempo nos podamos encontrar envueltos en una gran tela de araña de la cual no podamos escapar. La segunda es clara, para trabajar ya están las máquinas, porqué tenemos que hacer una serie de tareas repetitivas si puede hacerlo la máquina por nosotros.

El script que os muestro a continuación nos ayuda a asignar cuentas de máquina a una serie de grupos de forma equilibrada, supongamos que configuramos los PCs para conectarse a la red usando 802.1x y validación contra un IAS, hay motivos por los cuales configurar 802.1x, el principal el securizar el acceso a la red. También hay varios motivos para configurar un IAS, este en concreto es para comprobar que la cuenta de máquina pertenece a un grupo determinado y en función de esto le enviara el ID de VLAN al que va a pertenecer.

Para poneros en situación el caso es el siguiente, tenemos un edificio con 2500 PCs, para este edificio tengo 25 VLAN's por lo cual tendré un máximo de 100 máquinas por VLAN. En este articulo no quiero abordar ni la configuración del servicio IAS ni la configuración de 802.1x, nos vamos a ir directamente al problema y este es que tengo que asignar un grupo a mis máquinas para que el IAS les asigne un ID de VLAN.

El script asignara un grupo de Directorio Activo a cada una de las máquinas donde se ejecute y se asegurará que los grupos tengan el mismo numero de miembros. Para que el script funcione tenemos que tener en cuenta varias cosas:

• El nombre de los grupos de VLAN ha de terminar en un numero, un ejemplo puede ser VLAN001, VLAN002, etc.
• El usuario que ejecute el script tiene que tener permisos de "Leer todas las propiedades" y "Escribir todas las propiedades" sobre las cuentas de máquina, sobre los grupos de VLAN o sobre las OUs que los contienen.

Bien pues vamos al tajo, en primer lugar vamos a crear los objetos necesarios, creamos una instancia del del objeto ADSystemInfo, esto nos será de gran utilidad ya que podremos extraer bastante información sobre el usuario que inicio sesión o la máquina local para ser exactos vamos a obtener el distinguishedName de la máquina local con objADInfo.ComputerName.

Set objShell = CreateObject("WScript.Shell") Set objADInfo = CreateObject("ADSystemInfo") Set objMachine = GetObject("LDAP://" & objADInfo.ComputerName)

Se ha definido una función que comprueba la pertenencia a un grupo de Directorio Activo, esto nos servirá para comprobar si la máquina pertenece a algún grupo de VLAN, nos devolverá 1 si es miembro y 0 si no lo es. A la función le insertamos dos parámetros, el objeto máquina y el grupo que queremos comprobar. Se comprueba con la función isEmpty si la máquina es miembro de algún grupo, si no es así, la función devolverá 0 y no hará ningún tipo de comprobación. Se colocan los miembros en un array, y este array se convierte en una cadena separada por puntos y coma con la función Join(amembers,";") y se para a mayúsculas. A continuación se utiliza la función InStr(members, UCase(strTgtGroup)) para saber si el grupo objetivo esta en la cadena, si es así la función devolverá 1.

Function bMiembro (ByVal objMachine, ByVal strTgtGroup) bMiembro = 0 If Not IsEmpty(objMachine.memberof) Then    aMembers=objMachine.GetEx("memberOf")    members=UCase(Join(amembers,";"))    If InStr(members, UCase(strTgtGroup)) > 0 Then       bMiembro = 1    End If End If End Function

Bien, una vez hecho esto comenzamos con el script que añadirá la máquina a alguno de los grupos de VLAN, siempre y cuando esta no sea miembro de alguno de ellos. Creamos las variables iniciales que vamos a necesitar, son las siguientes:

• strMaquina, almacena la variable de entorno COMPUTERNAME, usamos esto ya que objADInfo.ComputerName nos devuelve el distinguishedName y solo necesitamos el nombre de la máquina.
• intContador, el contador que nos ayudara a recorrer los grupos de VLAN.
• strPeqVlan, almacenara el nombre del grupo de VLAN con menos miembros.

strMaquina= objShell.ExpandEnvironmentStrings("%COMPUTERNAME%") intContador=1 strPeqVlan=""

El resto del script se mueve dentro de un bucle donde realizaremos varias acciones, el bucle utiliza el contador para recorrer el total de grupos de VLAN que tengamos.

do    acciones Loop Until intContador = 25

A continuación y ya dentro del bucle utilizaremos una variable strGrupo para almacenar el nombre de cada uno de los grupos de VLAN, como veis se ha utilizado un pequeño if para ajustar el nombre del grupo de VLAN ya que el contador no permite ceros a la izquierda. Una vez que se ha conformado el nombre del grupo uniendo la cadena al contador podemos incrementar este. Si el contador es 5, la cadena resultante ser VLAN005, si este es 15 el resultado será VLAN015.

Dentro del bucle If intContador<10 Then    strGrupo = "VLAN00" Else    strGrupo = "VLAN0" End If strGrupo= strGrupo & intContador intContador = intContador + 1

Comprobamos la si la máquina pertenece al grupo de VLAN que hay en la variable strGrupo y si es así, finalizamos la ejecución del script mostrando un mensaje de aviso.

Dentro del bucle If bMiembro(objMachine, strGrupo) Then    MsgBox("La máquina esta en el grupo " & strGrupo & ", no se realizara ninguna acción")    WScript.Quit End If

Ahora vamos a contar los miembros del Grupo de VLAN en el que nos encontramos ubicados dentro del bucle, colocamos todos los miembros de ese grupo en un array y los contamos con intMiembros, esta variable es la que va a contener el numero de miembros total del grupo.

Dentro del bucle Set objGroup = GetObject ("LDAP://CN=" & strGrupo & ",OU=Grupos de VLAN,DC=dominio,DC=local") objGroup.GetInfo arrMemberOf = objGroup.GetEx("member") intMiembros = "0" For Each strMember in arrMemberOf    intMiembros = intMiembros + 1 Next

La ultima acción dentro del bucle será almacenar en dos variables el nombre del grupo de VLAN que tiene el menor numero de miembros (strPeqVlan) y este numero (intPeqVlan). Al finalizar el bucle, estas variables indicaran el Grupo al que se ha de añadir la máquina en el caso de ser necesario.

Dentro del bucle If strPeqVlan = "" Then    strPeqVlan = strGrupo    intPeqVlan = intMiembros Else    If intMiembros < intPeqVlan Then       strPeqVlan = strGrupo       intPeqVlan = intMiembros    End If End If

Ya sabemos cual es el grupo al que se ha de agregar la máquina por lo cual vamos a ello. Tenemos que indicar la ruta completa de la OU donde esta el grupo y utilizar la variable strPeqVlan para establecer el grupo elegido.

Const ADS_PROPERTY_APPEND = 3 Set objGroup = GetObject ("LDAP://CN=" & strPeqVlan & ",OU=Grupos de VLAN,DC=dominio,DC=local") objGroup.PutEx ADS_PROPERTY_APPEND, "member", Array(objADInfo.ComputerName) objGroup.SetInfo

Por ultimo para finalizar es script se realiza un pequeño control de errores, personalmente creo que esta parte es mejorable ya que en el inicio del script he usado un On Error Resume Next y esto no es muy recomendado. Lo suyo seria utilizar On Error GoTo ETIQUETA. El control de errores simplemente chequea si se ha producido algún error, si es así mostrara un mensaje indicando cual fue el error, si no, indicara que la máquina se ha agregado al grupo y cual es el numero de miembros de este.

If Err.Number <> 0 Then    MsgBox("No se ha agregado la Máquina al grupo porque se genero el siguiente error: " & Err.Description) Else    MsgBox("El equipo " & strMaquina & " se agrego al grupo " & strPeqVlan & " con " & intPeqVlan & " intMiembros") End If

Bueno, pues creo que ha sido suficiente por hoy, seguramente sea mejorable pero personalmente me ha sido muy practico, se podría añadir un control de numero máximo de usuarios por grupo, lo cual seria muy útil para no agotar el ámbito DHCP asignado a cada VLAN y seguramente alguna cosa mas.

Espero que os sea de utilidad. Como siempre se agradecerá cualquier tipo de comentario que queráis hacer.

A ver que tal...

Hola a todos, después de darle muchas vueltas he decidido tirarme a la piscina. Antes de comenzar tengo que darle las gracias a David Carrasco, el ha sido el empujón que me faltaba para empezar a escribir y para empezar a compartir con vosotros aquellas anécdotas del día a día. El fin de este blog es sencillo, analizar problemas y compartir sus soluciones, soluciones que han sido probadas en entornos en los que he participado y diseños de ciertos servicios que yo mismo he desarrollado.

Evidentemente en este mundo en el que trabajamos hay algo fundamental que no debemos olvidar, uno solo nunca llegará a ninguna parte y el trabajo en equipo es muy importante. Por la parte que me toca he tenido la gran suerte de rodearme siempre de grandes profesionales y amigos, veréis que en muchos casos nombraré a Fede, Emilio, Jesús, David Carrasco, Maestro Andrés y otros muchos, estos simplemente son algunos de los grandes profesionales que me han rodeado y que de seguro sin ellos no hubiera llegado a ninguna parte. El dicho es cierto, piensan mejor dos cabezas y ven mejor cuatro ojos que dos.

Intentare ser regular escribiendo cosas y dando toda la información que pueda, perdonarme si a veces soy parco en palabras, esto de escribir no se me da muy bien. Usare mi experiencia en Microsoft y Cisco para dar toda la información que me sea posible y espero que os sea de gran utilidad.




Estaremos en contacto.