Systems and Networks

Cambio de Aires

2011-09-02T11:25:00.001+02:00

Hola a todos, como sabéis, llevo escribiendo en este blog hace ya algún tiempo, cierto es que no he escrito todo lo que me hubiese gustado pero lo que he hecho lo hice con todo el mimo del mundo e intentando que todos lo entendierais de la mejor forma posible, espero que os haya gustado y pediros que perdonéis los errores que haya podido cometer.

Desde el pasado día 27 de Junio formo parte de una nueva familia, me incorporé a Microsoft como PFE de Plataforma y mi especialidad principal será Active Directory, es una gran oportunidad que se me ha brindado y creo que merece la pena emprender el viaje. La primera sensación que uno tiene allí es que es muy muy pequeño, estas rodeado por gente que sabe una barbaridad de lo suyo y es una fuente inagotable de sabiduría, en el poco tiempo que llevo allí me han tratado muy bien aunque sé que llegarán momentos duros.

Aunque este post suena a despedida no es así, simplemente os quiero trasladar que de momento estaré en un blog especifico que se ha creado para PFE’s como yo y en el cual estoy seguro que podréis aprender mucho sobre cualquiera de sus tecnologías ya que hay compañeros de AD, OCS y Lync, SQL y otras tecnologías Microsoft. No quiero dejar pasar la oportunidad para agradeceros profundamente vuestros comentarios y dar las gracias a todas y cada una de las personas que me han ayudado. Todos habéis aportado para que este blog que aunque pequeño, ha sido muy comentado. El blog quedará activo ya que desde aquí os iré colocando links para que veáis los sitios donde me podéis encontrar.

Por ultimo quiero dejar claro que todos los post escritos aquí han sido anteriores a mi incorporación en Microsoft.

Muchas gracias a todos.

Como Ofrecer Disco Compartido a Nuestro Cluster de Laboratorio (2/2)

2011-04-23T16:04:00.001+02:00

Hola a todos de nuevo, en este post vamos a terminar la configuración de nuestro software iSCSI Target que instalamos anteriormente y asignaremos como ejemplo un disco de 2GB para utilizarlo como disco de QUORUM en un cluster. Previamente a esta configuración tenemos que tener claros los puntos explicados en el post anterior relativos a la identificación del iSCSI Intiator del servidor y tener claro c0mo vamos a identificar a este en el Target. También tenemos que tener claro cuantos Targets vamos a crear y a cuantos servidores los vamos a presentar, para nuestro caso de ejemplo vamos a crear un Target con un disco de 2GB y se lo vamos a presentar a los dos servidores del cluster.

Ahora vamos a proceder a crear el Target, accedemos al software que está en Menú Inicio > Herramientas Administrativas > Microsoft iSCSI Software Target, una vez allí hacemos clic con el botón derecho sobre la opción iSCSI Targets y seleccionamos Create iSCSI Target.

El primer paso del asistente nos pedirá que le demos un nombre al Target y una descripción como se puede ver en la imagen siguiente.

En el siguiente paso del asistente se nos pedirá que introduzcamos el identificador del servidor que podrá acceder al Target, aquí es donde tendremos que elegir una del cuatro opciones anteriores, IQN, Nombre DNS, Dirección IP o Dirección MAC.

En el Botón Advanced… podemos seleccionar las diferentes opciones de identificación para el servidor al que queremos presentarle los discos, estos métodos son los antes mencionados.

Una vez hecho esto, solo quedará pulsar el botón Finish y el Target estará listo para crear los discos a presentar. Si queremos saber cual es el IQN de la maquina a la cual le queremos presentar los discos debemos ir al menú Herramientas Administrativas > iSCSI Initiator de la maquina en cuestión y dentro de la pestaña Configuration tenemos el Initiator Name tal y como se puede ver en la siguiente imagen.

Una vez hecho lo anterior, ahora toca crear o importar un disco VHD para presentar a los servidores, para este ejemplo crearemos un nuevo disco de 2GB que utilizaremos como QUORUM de un cluster. Seleccionamos la opción Create Virtual Disk.

Aparece el asistente para la nueva creación de disco virtual, seleccionamos la opción Next.

Ahora seleccionaremos la ubicación donde guardaremos el disco VHD que vamos a crear pinchando en Browse. Seleccionamos la carpeta de destino y lo completamos con el nombre del fichero y no debemos olvidar escribir la extensión VHD, una vez hecho esto seleccionamos el botón Next.

Establecemos el tamaño del disco y seleccionamos Next para poder escribir su descripción.

Una vez hecho esto, asociamos el disco a un target ya creado, marcamos el botón Add y seleccionamos el Target.

Una vez hecho esto, nos aparecerá un mensaje indicando que el asistente ha finalizado y se va a crear el disco.

Cuando hayamos terminado el asistente se habrá creado un disco VHD en la ubicación indicada y ya se podrá hacer uso del mismo en el Administrador de discos del servidor que se indicó.

Espero que esta información os sea de ayuda ya que este servidor puede ofrecer discos por iSCSI de forma totalmente valida para diferentes servidores y esto nos permitirá montar servicios que sin una cabina de discos no podríamos montar. Como siempre espero vuestros comentarios y nos leemos en breve.

Planificar el Despliegue de OCS 2007 R2

2011-03-24T11:42:00.002+01:00

Hola de nuevo, hace un año más o menos participé en un proyecto de despliegue de OCS 2007 R2, este proyecto inicialmente fue diseñado por consultores de Microsoft los cuales nos hicieron entrega de una documentación muy completa. La verdad es que cuando revisamos la documentación nos sorprendió el nivel de detalle de la misma, ciertamente era un buen trabajo y nos preguntábamos la cantidad de tiempo que podía llevar realizar dicha documentación. Cierto tiempo después me enviaron a un WorkShop de OCS R2 en Microsoft, estos cursos son impartidos por los propios técnicos de Microsoft expertos en el tema y allí descubrí una herramienta que me hizo entender el por qué del nivel de detalle de la documentación que había visto antes, esta herramienta se llama Planning Tool for Microsoft Office Communications Server 2007 R2 .

Con esta herramienta se puede realizar una planificación muy completa del despliegue de OCS, nos indica desde que máquinas necesitamos, cuales son los puertos a nivel de Firewall que necesitamos abrir, cual es el orden de instalación de roles en el despliegue y también nos permite acceder a la documentación oficial de Microsoft en el Technet. La herramienta nos hace un pequeño cuestionario en el que nos pregunta que roles queremos desplegar, cuantos usuarios tenemos en nuestra organización, si vamos a utilizar Enterprise Voice y en caso afirmativo cuantas llamadas por hora aproximadamente realizan los usuarios, en conclusión, pide información sobre el entorno en cuestión que queremos desplegar.

Una vez contestadas todas las preguntas sobre el entorno, la herramienta saca una un informe detallado con la arquitectura a desplegar y las características de las máquinas con los puertos requeridos tal y como se ve en las imágenes que hay a continuación:

La herramienta muestra tanto los pasos de planificación como el orden de los pasos del despliegue y si pinchamos cada uno de los enlaces nos lleva a la documentación de ese paso en el Technet.

La herramienta también puede exportar a Visio la topología generada o a Excel el listado de las características de servidor y los puertos necesarios. Este tipo de herramientas son muy prácticas y la verdad es que yo las hecho de menos para otros productos como Exchange o Active Directory. Espero que os sea de utilidad y como siempre espero vuestros comentarios.

SID History en Relaciones de Confianza de Bosque

2011-03-21T00:42:00.002+01:00

Hola a todos, mientras termino la segunda parte del artículo de Storage Server quería compartir con vosotros un problema que hemos padecido hace poco. Actualmente estamos inmersos en una migración de dominios “eterna”, el motivo por el cual esta migración de dominios es “eterna” es simplemente porque desde mi opinión personal el proyecto está mal definido desde el principio y se han pasado demasiadas cosas por alto. Pero esto es otra guerra y no hay tiempo para contarla ahora , a lo que voy es a que para poder realizar la migración inicialmente se ha tenido que establecer una relación de confianza y ejecutar cierta parametrización para que esto funcione.

En concreto se definió una relación de confianza Externa y se deshabilitó el SID Filtering como para cualquier otra migración. Para aquellos que no estéis familiarizados con esto, deciros que el filtrado de SID se encuentra habilitados en todas las relaciones de confianza que se establecen entre dominios, el filtrado de SID garantiza que el uso incorrecto del atributo SID History en las entidades de seguridad (incluida inetOrgPerson) en el bosque de confianza no supone una amenaza para la integridad del bosque que confía. El atributo SID History se utiliza en las migraciones entre dominios para que los usuarios migrados puedan acceder a recursos del dominio de origen sin tener que establecer nuevos permisos en el recurso.

Para poder visualizar este atributo necesitamos registrar una librería llamada acctinfo.dll y se encuentra en Account Lockout and Management tools que es descargable desde esta web:

http://www.microsoft.com/downloads/en/details.aspx?FamilyId=7AF2E69C-91F3-4E63-8629-B999ADDE0B9E&displaylang=en

Registramos la dll utilizando el comando regsvr32 acctinfo.dll, y una vez hecho esto aparecerá una pestaña nueva dentro de las propiedades del usuario llamada Additional Account Info y allí tenemos el botón SID History donde podemos ver este atributo del usuario en cuestión.

Como en las relaciones de confianza Externas no funcionan las autenticaciones Kerberos, tuvimos que reconfigurar varios servicios para que autenticaran por NTLM, esto nos provocó un error en varios de estos servicios, los servidores agotaban el numero de threads NTLM disponibles y dejaban de ver el dominio. Como no tenemos todos los usuarios migrados, para poder configurar la autenticación Kerberos en estos servicios teníamos que cambiar la relación de confianza a una relación de Bosque así que nos pusimos manos a la obra. Eliminamos la relación de confianza Externa y creamos una nueva relación de confianza de Bosque, como hacemos para todas las relaciones de confianza entre las que tenemos una migración, deshabilitamos el SID Filtering con el siguiente comando:

Netdom trust dominio1.origen /domain:dominio2.destino /quarantine:No /userD:UserAdminDom1 /passwordD:*

Una vez hecho esto, cuando el lunes llegaron los usuarios empezamos a encontrar incidencias de acceso denegado a ciertos recursos, comprobábamos que el atributo de SID History estaba en los usuarios pero no entendíamos por qué no se enviaba este SID para acceder al recurso del dominio origen. Después de varios intentos de resolver el problema, abrimos caso con Microsoft y todos andábamos un poco perdidos, hacíamos pruebas pero ninguno entendíamos por qué no se enviaba este atributo para acceder a los recursos del dominio Origen. A los días de tener el caso abierto, Microsoft nos hizo llegar el siguiente Link:

http://technet.microsoft.com/en-us/library/cc755321(WS.10).aspx

Este link, recoge un dato que desconocíamos, cuando se establece una relación de confianza de Bosque, no basta con deshabilitar el SID Filtering, también tenemos que especificar explícitamente que se envíe el SID History entre el dominio origen y el dominio de destino, esta operación no la realizamos en las relaciones de confianza de Externas por lo que entendimos que tampoco se debía realizar en la de Bosque, para indicar explícitamente que se envíe el SID History entre los dominios usamos el siguiente comando:

Netdom trust Dominio1.origen /domain:dominio2.destino /enablesidhistory:Yes /userD:UserAdminDom1 /passwordD:*

Una vez hecho esto se solucionó el problema y los usuarios pudieron trabajar sin ningún tipo de problema. Así que ya sabéis, si estáis inmersos en una migración y necesitáis una relación de confianza de Bosque, no basta con deshabilitar el SID Filtering, también tenéis que indicar que el atributo SID History se ha de intercambiar entre dominios. Espero que os sea de utilidad.

Como Ofrecer Disco Compartido a Nuestro Cluster de Laboratorio (1/2)

2011-03-15T23:57:00.002+01:00

Hace meses que no aparecía por aquí, muchos me preguntan si lo he dejado, si ya no escribo más, pero la verdad es que el problema que he tenido ha sido falta de tiempo y como éste es algo que no me sobra mucho últimamente, si me permitís, voy a ir directo al grano.

La cuestión está, en que hace poco se me planteó un problema de cara a ciertos laboratorios que montábamos para realizar prácticas o pruebas de cluster. Desde que empecé a utilizar VMWare para crear maquetas y laboratorios podía probar prácticamente de todo, el problema que me encontraba en el cluster era el almacenamiento compartido, ¿cómo podía ofrecer disco compartido a las máquinas virtuales?, como siempre, acudí a Google y allí encontré varios procedimientos de cómo hacer que un disco *.vmdk fuese accesible para dos máquinas virtuales, llamarme torpe si queréis, pero no conseguí que funcionase nunca. No sé si es porque no encontré el artículo adecuado o porque nunca vi lo suficientemente abajo como para que funcionase.

Al tiempo, mi amigo Emilio, me presentó OpenFiler; desde la propia página te puedes bajar una máquina virtual y empezar a ofrecer discos iSCSI a las máquinas virtuales con Sistema Windows Server 2003, descargas el iSCSI Initiator para el servidor y todo listo. Mi sorpresa llega cuando intentamos montar por el mismo procedimiento un cluster en 2008, lanzamos el test de validación del cluster y parece ser que OpenFiler no soporta SCSI-3 Persistent Reservation y esto es necesario para montar el cluster en 2008. A partir de ahí comenzamos a investigar buscando alternativas, Emilio ya me había hablado de Windows Storage Server 2003 pero no sabíamos ni como funcionaba ni como se montaba, al tirar del hilo encontré varios Links, el que me aclaró cómo montar Storage Server es el siguiente:

http://blogs.technet.com/b/josebda/archive/2010/09/27/windows-storage-server-2008-r2-and-the-microsoft-iscsi-software-target-3-3-are-available-on-msdn-technet-here-s-how-to-install-them.aspx

Este Link es el Blog de José Barreto y explica que contiene la ISO de Windows Storage Server 2008 R2 y que necesitas para montarlo, en primer lugar decir que Windows Storage Server 2008 R2 es descargable desde la Web del Technet y se monta sobre un Windows Server 2008 R2 tal y como muestra José en la imagen siguiente:

También recordar que hay una versión para la descarga en el Technet que es Windows Storage Server 2008 R2 Embedded que directamente monta el SO con todos los componentes instalados, si quieres montarlo desde cero la cuestión es la siguiente, coges un Windows Server 2008 R2 y a partir de ahí instalas lo que trae la imagen descargada del Technet de Windows Storage Server 2008 R2, a continuación voy a detallar como instalarlo y como crear un disco compartido que se usará de QUORUM para nuestro cluster. Tal y como indica la imagen extraemos el contenido de la ISO descargada del Technet, ésta contiene el fichero WSS2008R2+iSCSITarget33.exe, cuando lo lanzamos, descomprime el fichero Windows_Storage_Server_2008_R2.iso y el fichero iSCSI_Software_Target_33.iso, insertamos la primera ISO en nuestro servidor 2008 R2 y lanzamos la instalación como se ve a continuación:

Cuando montamos la ISO, accedemos a las carpetas que vemos en la imagen siguiente

Accedemos a la carpeta Windows Storage Server 2008 R2, y ejecutamos Windows6.1-KB982050-x64-EnterpriseBranding.MSU (Branding for the Enterprise Edition of Storage Server).
A continuación ejecutamos el fichero Windows6.1-KB976833-x64-SIS.msu (Single Instance Storage component) y el fichero Windows6.1-KB976836-x64-OOBE.msu (Out-Of-the-Box-Experience for Storage Server).
Una vez instalado hay que reiniciar el servidor, en ese momento veremos que ya ha cambiado el logotipo del mismo a Storage Server 2008 R2 como se ve en la imagen siguiente:

Una vez instalado lo anterior, tenemos que ejecutar las actualizaciones de sistema, se encuentran dentro de la carpeta OS Updates, son unas 54 actualizaciones y para ejecutarlas todas yo he creado un fichero llamado Actualizaciones.bat, este fichero contiene una llamada a todos los ficheros de la carpeta con los atributos /quiet y /norestart, esto instalará todas las actualizaciones que sean aplicables. Una vez finalizada la actualización se debe reiniciar el sistema.

Con esto habremos finalizado la instalación de Windows Storage Server 2008 R2 y ya tendremos nuestro NAS, ahora tenemos que instalar el Software de Target iSCSI que nos permitirá generar nuestra SAN iSCSI para ofrecer los discos para nuestro cluster. Insertamos la ISO iSCSI_Software_Target_33.iso, y accedemos a la página de inicio que trae el CD.

La página de inicio contiene un aparatado denominado Install the Software, allí ejecutamos la opción iSCSI Software Target (X64) para lanzar la instalación.

Una vez finalizada la instalación ya tendremos disponible el iSCSI software Target dentro de las herramientas administrativas y ya podremos ofrecer discos iSCSI a los servidores, lo único que quedaría es configurar los Targets y los discos VHD. Por internet hay diferentes Blogs con muchas recomendaciones, yo he anotado varios puntos que creo que son interesantes. Antes de empezar me gustaría indicar que no soy experto en almacenamiento por lo que las opiniones que voy a transmitir lo he obtenido gracias a búsquedas en páginas, documentación especifica de almacenamiento y mi propia experiencia, si alguien considera que hay algún dato incorrecto me gustaría que me lo notificara lo antes posible para corregirlo.

Para el tráfico de red iSCSI, utilizaremos un segmento de red Ethernet (VLAN) exclusivo e independiente de los segmentos de red utilizados para el tráfico de red normal. Es deseable utilizar adaptadores de red exclusivos para iSCSI, tanto en las máquinas físicas como en las máquinas virtuales.

Por norma general se suele crear un target para cada servidor al que queremos ofrecer disco, hay algunas excepciones como las que detallo a continuación.

Hay que tener en cuenta que cada Target tiene su propia cola de peticiones, por lo que si buscamos presentar varios discos a un servidor, una best practice sería crear un Target para cada disco. Esto haría que las colas de peticiones para cada disco fuesen de forma independiente y obtendríamos un mejor rendimiento.
Cuando vamos a crear un cluster como es el ejemplo de este artículo, necesitamos que varios servidores vean los mismos discos para que el cluster pueda funcionar, en ese caso asociaremos varios iniciadores iSCSI al Target para que nuestro cluster pueda manejar los discos. Esto sería una opción ya que el enfoque clásico de crear un Target para cada servidor y allí asignar los mismos discos también sería valido.

De cara a utilizar Microsoft iSCSI Software Target debemos saber lo siguiente, los Discos Virtuales que usa el software de Target toman forma de ficheros VHD, similares a los Discos Virtuales de Hyper-V, Virtual Server y Virtual PC, aunque con alguna peculiaridad. Sólo podremos crear Discos Virtuales de tamaño fijo y posteriormente podremos extender y realizar Snapshot de los mismos.

Debemos recordar que los equipos clientes de nuestro Storage, denominados iniciadores iSCSI (iSCSI initiators), pueden identificarse en el Target utilizando cuatro métodos diferentes:

iQN (iSCSI Qualified Name). Es el método preferido y el método por defecto para identificar a un iniciador iSCSI. En el caso de utilizar el software Microsoft iSCSI Initiator, se trata de una cadena que contiene el nombre DNS del equipo prefijado del siguiente texto "iqn.1991-05.com.microsoft:".
Nombre DNS.
Dirección IP.
Dirección MAC.

Bien, hasta aquí hemos realizado la instalación de nuestro software de Target, en la segunda parte del articulo que colgare en los próximos días explicaré como configurar este software para ofrecer los discos a nuestro cluster de laboratorio.

Algo de NAT…

2010-04-07T18:51:00.002+02:00

Hola a todos, en las últimas semanas y tras varios temas que he comentado en mi trabajo, hay varias personas que me han pedido que inserte un nuevo artículo en mi blog tratando el tema de NAT y PAT, tras los 8 años de experiencia que tengo como instructor en CISCO, voy a aportar información que se puede encontrar en el semestre 4 del curso de CCNA, también incluiré las sentencias de configuración para estos dispositivos al final de este articulo. Voy a intentar aportar toda la información que pueda para intentar que quede claro este tema, sobre todo la terminología ya que esta puede confundir un poco.

Hace algunos años, conectarse a Internet era un lujo solo al alcance de unos pocos, desde finales de los años 80 se ha venido experimentando un crecimiento exponencial de las maquinas que se conectan a internet. Hoy en día se conecta casi todo a internet, PCs, portátiles, móviles, videoconsolas, televisores, frigoríficos y hasta podríamos conectar bicicletas (ni que decir que esto último es exagerado hasta el día que se le ocurra a alguien :D). Cada dispositivo conectado a la red necesita una IP y con tantos dispositivos conectados, el direccionamiento se va agotando.

Como los problemas de agotamiento de direcciones empezaban a ser preocupantes se empezaron a tomar medidas, entre ellas, el direccionamiento público y privado. Las direcciones privadas son las que se muestran a continuación y también pueden ser utilizadas de forma libre:

Clase A: 10.0.0.0*

Clase B: 172.16.0.0 a 172.31.0.0*

Clase C: 192.168.0.0 a 192.168.255.0*

*NOTA: solo identifico la dirección de red de cada una de las redes.

También tenemos el direccionamiento público, este está controlado y ha de ser asignado por el ISP. Por cada continente existe una organización que se encarga de gestionar el direccionamiento público, en América del Norte es ARIN, en América del Sur y Centro América es LACNIC, en Asia y Oceanía es APNIC, en Europa es RIPE y en África es AfricNIC. A este proyecto se le llama RIR (Regional Internet Registry) y para obtener más información podéis visitar este enlace de CISCO (http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_4-4/regional_internet_registries.html).

En cada oficina privada, en cada casa o en cada ubicación que nos plazca podemos repetir direccionamiento 192.168.0.X ya que este es un direccionamiento privado, esto nos acarrea un pequeño “pero”. Pues bien, para saltar este escalón y otros (en los que no voy a entrar en este artículo), se diseño NAT. Tu puedes tener el direccionamiento privado que te plazca y de cara a internet se te vera con una dirección pública, NAT significa Network Address Traslation. Para empezar tenemos que tener claro los tipos de dirección que nos podemos encontrar, esto lo represento en la siguiente tabla:

Dirección Local Interna	Por norma general suele ser una dirección IP Privada de un dispositivo interno.
Dirección Global Interna	Esta dirección suele ser una dirección pública, es la dirección a la que se traduce la dirección Local Interna.
Dirección Global Externa	Es la dirección IP asignada a un host en la red externa. El dueño del host asigna esta dirección.
Dirección Local Externa	Es la dirección IP de un host externo, como la conocen los hosts en la red interna.

También es importante definir una zona (interfaz) como interna (inside) y otra como externa (outside) aunque esto no significa que en inside tengamos que utilizar una IP privada y en outside tengamos que usar una IP pública. Pero, ¿Cómo funciona NAT?, supongamos que tenemos el escenario que se puede ver a continuación:

Supongamos que tenemos un número de servidores X que están configurados con un direccionamiento privado, necesitamos que estos servidores se conecten a otro que está situado en internet o que estos sean accesibles desde el mismo sitio. Con el direccionamiento actual esto no es posible así que vamos a hacer que estos servidores se vean con el direccionamiento adecuado en internet. Lo primero que se debe hacer es obtener un pool de direcciones públicas del proveedor, en este caso valdría de la dirección 80.0.0.10 a la dirección 80.0.0.13, cuatro direcciones, una para cada servidor. Lo que pretendemos con esto es que cada dirección interna sea traducida a una externa y podemos hacer de dos maneras. De forma estática o dinámica, de forma estática cada dirección IP interna se traducirá siempre a la misma dirección externa, por ejemplo:

192.168.0.15 -> 80.0.0.10

192.168.0.16 -> 80.0.0.11

192.168.0.17 -> 80.0.0.12

192.168.0.18 -> 80.0.0.13

Esta traducción siempre será a la misma dirección mientras que de forma dinámica el primer paquete que llegue será traducido a la primera dirección del pool y así sucesivamente, por norma general en cualquier configuración hay una ACL que determina que IPs pueden ser traducidas y que IPs no podrán ser traducidas. La pasarela NAT se encarga de realizar esta traducción anotando todas las traducciones de IP en una tabla como se puede ver en los siguientes gráficos:

- El servidor de origen envía un paquete al servidor en internet, el paquete llega a la pasarela NAT.

- La Pasarela NAT chequea el pool disponible, anota la IP en la tabla y modifica el campo IP origen del paquete.

Cuando el paquete regresa, la pasarela NAT busca la dirección de destino de este en su tabla de traducciones, si esta aparece, sustituye el campo ID de destino por la IP indicada en la tabla.

A continuación adjunto un link de CISCO donde se puede ver todo esto.

http://www.cisco.com/warp/public/556/nat.swf

Cuando lo queremos acceder desde Internet a nuestra red interna, tenemos que tener identificadas las maquinas de esta red con una dirección IP publica en la pasarela NAT, también tenemos que publicar asociado a la IP un numero de puerto, en términos de ISA server a esto se le llama publicar un servicio. Cuando el paquete llega a la pasarela NAT, esta chequea su tabla de asignaciones cambia la IP y si es una publicación valida redirecciona al servidor apropiado y al puerto indicado.

La configuración de NAT en un dispositivo cisco es la que muestro a continuación:

NAT Dinámico

Router# configure terminal
Router(config)# interface Fastethernet 0/0 -> Determinamos que esta es la interfaz interna.
Router(config-if)# ip nat inside
Router(config-if)# interface Fastethernet 0/1 -> Determinamos que esta es la interfaz externa.
Router(config-if)# ip nat outside
Router(config)# exit
Router(config)# ip nat pool public_access 80.0.0.10 80.0.0.13 netmask 255.255.255.0 –> Identificamos el pool de direcciones.
Router(config)# access-list 1 permit 192.168.0.0 0.0.0.255 –> Identificamos las IPs que pueden ser traducidas.
Router(config)# ip nat inside source list 1 pool public_access -> Asociamos el pool a las IPs que pueden ser traducidas.

Configuración de Mapeo estático:

Con estas líneas asociamos una IP interna a una IP del pool.
Router(config)# ip nat inside source static 192.168.0.15 80.0.0.10
Router(config)# ip nat inside source static 192.168.0.16 80.0.0.11
Router(config)# ip nat inside source static 192.168.0.17 80.0.0.12
Router(config)# ip nat inside source static 192.168.0.18 80.0.0.13

Con esta configuración asignamos un pool de direcciones a nuestra red interna, supongamos que lo que quiero ahora es no contratar ese pool de direcciones o bien necesito que salgan a internet muchas direcciones IP, por ejemplo nuestros PCs. Para realizar esto utilizamos PAT, esto permite traducir múltiples IPs internas a una sola IP externa. La operación es similar a la de NAT, solo que todas la IPs se traducen a una misma dirección IP en el exterior, esta IP suele ser la IP del Router.

En esta ocasión, como todas las direcciones son traducidas a la misma IP, el Router forma una tabla en la que incluye el puerto de origen que está utilizando esa maquina para esa comunicación y crea una asociación entre los dos datos para así reconocer el paquete a su vuelta.

Cuando el paquete viene de vuelta, el Router tiene que tratar de devolverlo a la maquina correcta, como todas las maquinas fueron traducidas a la misma dirección, el Router comprueba el puerto de destino que tiene el paquete y lo coteja con su tabla. Una vez localizado ese puerto, el Router sabrá a que dirección corresponde ese paquete y hará la traducción correspondiente.

La configuración de PAT sería la siguiente:

Router# configure terminal
Router(config)# interface Fastethernet 0/0 -> Determinamos que esta es la interfaz interna.
Router(config-if)# ip nat inside
Router(config-if)# interface Fastethernet 0/1 -> Determinamos que esta es la interfaz externa.
Router(config-if)# ip nat outside
Router(config)# exit
Router(config)# access-list 1 permit 192.168.0.0 0.0.0.255 –> Identificamos las IPs que pueden ser traducidas.
Router(config)# ip nat inside source list 1 interface Fastethernet 0/1 overload-> Esta secuencia traducirá IPs a la dirección que tenga el Router en su interfaz Fastethernet 0/1 (80.0.0.1).

Espero haber dado algo mas de luz a este tema para aquellos que no lo conozcáis y como siempre espero vuestros comentarios, saludos a todos.

David,¿ahora vendes relojes?

2009-10-08T12:21:00.001+02:00

No, nuestro gran amigo David Carrasco no vende relojes, cuando yo entré en www.heroescertificados.com fue lo primero que pensé. Las noticias de David sobre las certificaciones pasan a www.heroescertificados.es, no le perdáis de vista.

Pinceladas de DNS en AD (La zona msdcs)

2009-04-08T00:32:00.002+02:00

Hola a tod@s, lo primero que quiero pedir son disculpas por no poder aparecer por aquí durante algún tiempo. Tengo que admitir que mi fuerte no es escribir, pero durante estos meses que he estado desaparecido han sido varias las personas que me han pedido añadir alguna cosilla en el blog. Me han animado y como siempre me han convencido, voy a hacer todo lo que pueda por seguir aportando información sobre Active Directory que es a lo que me dedico principalmente.

En este post mi intención es aportar algo de información sobre la integración entre DNS y AD, comentar algo sobre los tipos de registros que existen, las zonas, sobre todo una en concreto (msdcs) y me gustaría incluir algo de Troubleshooting. Sobre DNS y AD se podrían escribir muchas páginas pero como siempre intentaré ser escueto, ir al grano y dar todos los datos que pueda sin aburrir. Bien, en primer lugar retrocedamos un poco en la historia, cuando hablamos de Sistemas Operativos de Red, todos recordamos de forma algo gris NT, Windows NT utilizaba como mecanismo de comunicación principal de Red NetBIOS. Esto significa que antiguamente teníamos la necesidad de instalar un servidor WINS para nuestros dominios, los administradores de Red necesitaban mantener dos bases de datos de consultas, DNS para resolución de nombres y WINS para resolución de nombres NetBIOS. Con la aparición de Windows Server 2000 y Active Directory esto ya no es necesario y solo necesitamos mantener nuestros servidores WINS por compatibilidad con aplicaciones antiguas y no por su necesidad en Active Director ()y.

DNS es un protocolo de capa de aplicación de la pila de protocolos de TCP/IP y de la misma capa dentro del modelo OSI, trabaja por el puerto 53 tanto en TCP como en UDP y Active Directory se apoya en él. Inicialmente se publicaron las RFCs 882 y 883 que quedaron obsoletas con la publicación a partir de 1987 de las RFCs 1034, 1035, 1912, 1995, 1996 y 2181 recientemente, en ellas podéis encontrar toda la información del protocolo.

DNS se compone de ZONAS, las ZONAS son porciones del espacio de nombres de dominio que almacenan los datos. Cada zona de autoridad abarca al menos un dominio y posiblemente sus subdominios, si estos últimos no son delegados a otras zonas de autoridad. Las zonas contienen los registros que es la unidad de información de DNS, en la siguiente tabla podemos ver los tipos de registros que hay.

Tipo de Registro	Nombre	Descripción
A	Address	Mapea un hostname a una IPv4
AAAA	Address	Mapea un hostname a una IPv6
PTR	Pointer	Mapea una IPv4 a un hostname
CNAME	Alias	Mapea un Alias a un hostname
MX	Mail Exchanger	Especifica una ruta de correo para un dominio
NS	Name Server	Especifica un nombre de servidor para un dominio dado
SOA	Start of Authority	Contiene datos administrativos sobre una zona incluido el nombre de servidor primario.
SRV	Service	Mapea un servicio a varios hostnames

Los clientes siguen un proceso sencillo para localizar un controlador de dominio utilizando consultas DNS, en la KB247811 y KB314861 de Microsoft podemos ver como un cliente localiza un controlador de dominio. Durante esta búsqueda, el cliente realizará varias consultas al DNS para localizar cualquier DC del dominio o bien un DC perteneciente a su site, dependiendo si el cliente ha logado en alguna ocasión o no, se seguirá un orden en la búsqueda. Para ello el cliente utilizará registros de tipo SRV como los que vemos a continuación:

_ldap._tcp.<DnsDomainName>
_ldap._tcp.dc._msdcs.<DnsDomainName>
_ldap._tcp.<SiteName>._sites.<DnsDomainName>

NOTA: Para aquellos que no estéis familiarizados <DnsDomainName> es la zona con el nombre de vuestro dominio.

Bien, algunos de estos registros se encuentran en la zona msdcs, esta es una zona importantísima para muchas tareas de Active Directory, el primer ejemplo lo podéis ver en las KBs mencionadas, pero cuando un servidor de Exchange quiere localizar un Catálogo Global utiliza la zona msdcs, cuando un controlador de dominio quiere replicar contra otro usa la zona msdcs y para múltiples tareas más. Esta es una zona bastante crítica que casi nadie conoce. En Windows 2000 Server, msdcs estaba alojada dentro de la zona <DnsDomainName>, en Windows Server 2003, msdcs es una zona independiente de la zona <DnsDomainName> pero está delegada en todos los controladores de dominio, por eso aparece en gris en la siguiente imagen:

Otro punto importante del servicio es el DDNS (Dynamic DNS), está definido en la RFC 2136 y permite a los clientes añadir o eliminar registros en las zonas. Cuando un DC se agrega al dominio o arranca el servicio Netlogon se registra contra su DNS añadiendo una entrada con su nombre y su IP (host A), los controladores de dominio además de crear su registro A, también añaden los siguientes registros que tienen las funciones que detallo a continuación:

_ldap._tcp.<DnsDomainName>, permite a los clientes localizar un servidor que corra ldap en su dominio.
_ldap._tcp.<SiteName>._sites.<DnsDomainName>, permite a los clientes localizar un servidor que corra ldap en un site de un dominio especifico.
_ldap._tcp.dc._msdcs.<DnsDomainName>, permite al cliente localizar un DC en un dominio.
_ldap._tcp.<SiteName>._sites.dc._msdcs.<DnsDomainName>, permite al cliente localizar un DC en un site de un dominio especifico.
_ldap._tcp.pdc._msdcs.<DnsDomainName>, permite al cliente localizar el PDC emulator, este registro solo lo grabara el DC con dicho rol.
_ldap._tcp.gc._msdcs.<DnsDomainName>, permite al cliente localizar un Catálogo Global de su dominio, este registro sólo lo grabará el DC con dicho rol.
_ldap._tcp.<SiteName>._sites.gc._msdcs.<DnsDomainName>, permite al cliente localizar un Catálogo Global de un site especifico de su dominio, este registro sólo lo grabará el DC con dicho rol.
gc._tcp.<DnsDomainName>, permite al cliente localizar un Catálogo Global para este forest, este registro sólo lo grabará el DC con dicho rol.
D1539E64-58F8-4C7F-A97B-1582D0D5B348._msdcs.<DnsDomainName>, este registro es el GUID del DC y lo utilizarán otros DCs para la replicación.

Este último registro es un ALIAS y es de vital importancia para la replicación, veremos qué es lo que ocurre cuando este registro no está. En primer lugar encontraremos información sobre este tipo de registro en la consola de Sitios y Servicios de Active Directory, usando el botón derecho contra NTDS Settings de cada controlador de dominio como vemos en la siguientes imágenes:

En las siguientes imágenes se puede comprobar que si usamos un ping contra el registro, este es resuelto y el controlador de dominio responde a la prueba de conectividad, también podemos ver que este tipo de registros para todos los controladores de dominio están almacenados en la zona msdcs.

Bien, una vez que tenemos claro que son estos registros y donde están, supongamos que realizando una serie de tareas rutinarias en nuestro Active Directory, forzamos la replicación entre dos DCs después de hacer unos cambios y nos aparece el siguiente mensaje en pantalla.

Este no es un error muy común ya que tienen que unirse una serie de factores, pero si es uno de los errores que más quebraderos de cabeza os pueden dar ya que hay veces que el propio mensaje de advertencia nos puede confundir y hacernos creer que existe un error en el servidor DNS. Puesto que sospechamos que existe un problema DNS y este error nos ha cantado al forzar una replicación, ejecutaremos el comando dnslint con el argumento /ad que permite realizar el test sobre Active Directory, el comando a ejecutar sería el siguiente:

dnslint.exe /ad 100.1.0.254 /s 10.1.0.253 /v

Este comando nos emite un reporte en html que entre otras cosas mostrará la siguiente información:

Alias (CNAME) and glue (A) records for forest GUIDs from server:

Total number of CNAME records found on this server: 0

Total number of CNAME records missing on this server: 3

Total number of glue (A) records this server could not find: 0

CNAME records for forest GUIDs missing on server:
GUID: d1539e64-58f8-4c7f-a97b-1582d0d5b348._msdcs.contoso.com
DC: ROOTDC

GUID: e3415b00-f56f-405e-b851-ebfb00554a1a._msdcs.contoso.com
DC: CORPDC01

GUID: ed44cd9d-58c1-4300-8cb5-44acc61de1b9._msdcs.contoso.com
DC: CORPDC02

Este mensaje nos informa que este servidor tiene algún problema con los CNAME en la zona _msdcs.contoso.com por lo que vamos a comprobar esta zona y vemos lo siguiente:

Este forest está compuesto por dos dominios, contoso.com y su subdominio corp.contoso.com, si os fijáis en la imagen anterior hay tres registros de tipo NS y sólo dos de tipo CNAME, ¡Falta el CNAME del servidor corpdc01!. Parece que hemos encontrado la solución por lo que vamos a reiniciar el servicio NetLogon del DC para que este vuelva a registrar el CNAME. Una vez reiniciado el servicio comprobamos que nada ha cambiado por lo que vamos a extraer información de la zona con el comando dnscmd.exe /zoneinfo _msdcs.contoso.com, con este comando vemos lo siguiente:

Si repasamos todos los datos hay uno en especial que llama la atención, las zonas de DNS tienen tres opciones para las actualizaciones, 0-None, 1-Nonsecure and Secure y 2-Secure. En la imagen anterior la opción de update está en cero por lo cual eso significa que la zona no permite actualizaciones, este es el motivo por el cual el servidor no ha actualizado su registro CNAME. Cambiamos la opción como se puede ver en la siguiente imagen, reiniciamos el servicio NetLogon y comprobamos de nuevo la zona _msdcs.contoso.com y que el DC actualizó la información:

Como podemos comprobar en la imagen anterior el DC corpdc01 ya tiene su CNAME en la zona _msdcs.contoso.com y ya no existirá ningún tipo de problema a la hora de replicar contra el resto de controladores de dominio. Podría extenderme muchísimo más hablando de DNS y su integración con AD, mi intención con este post es dar un poco de luz a la zona _msdcs ya que esta es una zona poco conocida por los administradores. Como podéis comprobar su importancia es alta ya que son muchas las tareas para las cuales Active Directory necesita consultar esta zona. Espero que este post os sea de utilidad y como siempre espero vuestros comentarios, para mí es importante saber que os es útil todo el sermón que os he pegado :D, muchas gracias a todos.

Limite 48 Horas!!!!!

2008-10-30T23:59:00.002+01:00

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.

Feliz Verano a Todos

2008-08-07T13:10:00.002+02:00

Bueno, llegó la hora de las vacaciones, espero que podáis disfrutar todos de la playa, la montaña o lo que os apetezca. Nos leemos en Septiembre.

Soluciones con Etherchannel de Capa2

2008-07-30T11:27:00.002+02:00

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.

Suerte a los profesionales

2008-07-10T04:04:00.001+02:00

Aunque se que es tarde para avisar, hoy mis compañeros y amigos David Carrasco y Jesús M. Nacimiento darán una charla sobre Exchange en las instalaciones de Microsoft. Por motivos de trabajo no podré asistir, pero estoy seguro que merecerá la pena escucharles. Os iré informando de nuevos eventos ya que hay mucho que aprender de estos dos profesionales. Suerte a ambos.

"Prefiero ser el peor de los mejores que el mejor de los peores"

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

2008-07-10T03:52:00.002+02:00

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.

Campeones de Europa 2008!!!!!

2008-07-01T00:44:00.001+02:00

Ya se que esto no tiene nada que ver con el tema del blog, pero, 44 años después volvemos a ser campeones y no quería dejar pasar la ocasión para felicitar a todos los jugadores de nuestro combinado nacional. ESPAÑA, CAMPEONES DE EUROPA 2008.

Disculpad mi ausencia durante este tiempo pero por temas laborales me ha sido imposible escribir. Para finales de esta semana os dejaré la segunda parte de Configuración de Directorio Activo.

Información interesante sobre Cisco

2008-06-18T22:55:00.002+02:00

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

2008-06-13T23:44:00.002+02:00

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)

2008-06-11T00:05:00.002+02:00

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.

Continúo trabajando

2008-06-05T17:20:00.001+02:00

Hola a todos, disculpad que no haya aparecido por aquí en los últimos días, sigo trabajando en un pequeño documento de tuning de Directorio Activo que colgare en breve.
Gracias a todos.

Cisco Certified Entry Network Technician (CCENT)

2008-05-28T13:53:00.009+02:00

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

2008-05-28T01:42:00.008+02:00

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...

2008-05-23T22:35:00.001+02:00

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.