Cambio de Aires

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)

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

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

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)

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…

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?

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)

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.