Reenviadores en DNS Server

JediEsta semana hemos estado montando un servidor de Directorio Activo, para un nuevo dominio en una red. Tecnología punta: Windows 2000 server.

Durante la instalación de Directorio Activo, se nos da la posibilidad de instalar también el servicio de Servidor DNS en la misma máquina, que es lo habitual, y es lo que hemos hecho.

Sin embargo, al acabar las instalaciones y empezar con las configuraciones, hemos querido añadir un reenviador al servidor DNS, para que pueda resolver cualquier dirección de Internet, y que no sólo se encargue de la resolución de nombres de la red local (léase, de los nombres definidos dentro de la zona o zonas configuradas en el servidor DNS).

El problema, es que nos hemos encontrado, tanto la sección de reenviadores, como la sección de «root hints», deshabilitadas, puesto que además de la zona con el dominio definido, aparecía la zona raíz (.) en el propio servidor DNS. Básicamente, esto ocurre cuando al instalar un servidor DNS, éste no encuentra ningún otro servidor DNS. En ese caso, se configura a sí mismo como servidor raíz.

Símplemente eliminando la zona raíz (.), y refrescando (F5), se consigue habilitar la sección de reenviadores, y además se listan de forma automática los «root hints».

Fuente: http://www.petri.co.il/no_forwarding_or_root_hints_on_dns_server.htm

Flickr! Foto por PhillipWest

Mensaje de bienvenida

Portal

Esto, más que una entrada, es un recordatorio, de cómo he conseguido configurar el mensaje de bienvenida a una máquina de test desde Directorio Activo en Windows 2000 Server. Dudo que a estas alturas le pueda ser útil a alguien, pero si es así, mejor que mejor.

Este es el proceso que podríamos seguir:

  1. Abrimos la consola de «Usuarios y Equipos de Directorio Activo»
  2. Seleccionamos la OU a la que queremos aplicarle el mensaje de bienvenida > click derecho > propiedades.
  3. Desde la pestaña «Group Policy», creamos una nueva GPO (o editamos una existente).
  4. En la nueva GPO, expandimos Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options.
  5. Aquí, encontraremos las dos directivas que necesitaremos configurar para establecer el mensaje de bienvenida:
    • Message text for users attempting to log on
    • Message title for users attempting to log on
  6. Introduciendo el texto correspondiente en las directivas anteriores, quedará configurado el mensaje.
  7. Una vez configurados, moveremos la máquina en la que queremos mostrar el mensaje de bienvenida, a la OU en la que hemos configurado la GPO.
  8. Para forzar la aplicación de la directiva, desde el mismo servidor de AD podremos ir a inicio > ejecutar e introducir el comando anterior al «gpupdate» de 2003 Server:
    • secedit /refreshpolicy machine_policy /enforce (Fuente)
  9. Finalmente, deberemos reiniciar la máquina donde se desea ver el mensaje de bienvenida, para que pueda aplicar la nueva directiva.

Notas rápidas del MCSA

Nerd
Bueno, después de más de cuatro meses asistiendo a clases para la certificación MCSA de Microsoft, he decidido compartir algunas anotaciones interesantes que se han visto durante el curso, aunque no entran en el temario del mismo. Así que prepararos para una entrada bastante técnica, pero muy útil (o eso espero) para la gente de sistemas:

  • Servidor de ficheros: una buena idea es tener discos «hot swap», para poder reemplazarlos sin necesidad de parar el servicio, en caso de necesidad. Esto no nos sirve, si lo que falla es el disco donde tenemos el sistema operativo; para ello, usaremos 2 discos en espejo.
  • Discos duros: básicamente hablamos de discos SATA y discos SCSI (llamados SAS actualmente). Estos últimos son los recomendados siempre en entornos de empresa, puesto que el rendimiento es mucho mejor a pesar de que el pico de rendimiento puede ser mayor en discos SATA, aunque únicamente en picos puntuales.
  • DMZ: nunca se deberían facilitar accesos directos al exterior desde la red interna. Para ello, usaremos máquinas que harán de intermediarios para los servicios requeridos (como DNS, correo, web, etc.) que se ubicarán en esta DMZ. Estas máquinas perimetrales, no deberían ser miembros del dominio, por temas de seguridad.
  • Servidor Radius/IAS: Montaremos un servidor Radius cuando 1) queramos centralizar ahí las directivas de acceso remoto o 2) queramos autentificar equipos contra servidores que no estén en Directorio Activo
  • NAS vs SAN: entre otras, la diferencia principal es que NAS tiene un sistema operativo que hace toda la gestión, mientras que SAN únicamente comparte disco.
  • Siempre que podamos, intentaremos deshabilitar (no quitar) los componentes no estrictamente necesarios (USB, CD, ciertos tipos de archivo anexos en correos electrónicos, etc.)
  • NetBios: hoy en día, si podemos, deshabilitaremos Netbios en nuestra red. Con ello, deshabilitaremos también la función «Mis sitios de red», ya que únicamente se verá nuestro propio equipo. Los usuarios, por tanto, tendrá que usar la búsqueda por Directorio Activo para encontrar recursos compartidos, impresoras, usuarios, etc. Esto lo haremos, puesto que si tenemos muchos equipos, NetBios puede llegar a colapsar la red.
  • Directorio Activo: agarraos …
    • No montaremos un árbol de dominios con más de 3 niveles de profundidad, puesto que más niveles hacen inviable su gestión.
    • Montaremos un mínimo de 2 Controladores de Dominio por dominio.
    • Antes de montar Directorio Activo, deberemos tener muy claro para qué lo queremos, y siempre, primero se hará la estructura sobre papel.
    • Las cuentas de los usuarios que dejan la empresa, no deberán borrarse en los siguientes 5 años, por temas legales.
    • Los permisos se darán siempre a nivel de grupo.
  • Alto rendimiento: para alto rendimiento, usaremos (si el bolsillo lo permite) una cabina de discos, y montaremos el RAID por hardware que nos permita la cabina.
  • Además, usaremos fibra para la conexión gigabyte, o en su defecto, iSCSI.
  • Auditoría: la auditoría ha de habilitarse para empezar a registrar eventos. Lo que se ha hecho antes de habilitar la auditoría no se podrá auditar. En cualquier caso, para auditar necesitaremos:
    • Directivas: habilitar la directiva de auditoría necesaria, y
    • Recurso: habilitar el recurso que quiero auditar e indicar qué se quiere auditar.
  • Clústers: siempre que podamos, montaremos Clústers con Windows 2008 en lugar de con Windows 2003, por temas de compatibilidad.
  • Tarjetas de red TEAM: este tipo de tarjetas que soportan TEAM, permiten funcionar juntas como una sola (una máquina puede tener por ejemplo 4 tarjetas TEAM a 1 GB cada una, funcionando como una única tarjeta). Ésto nos permitirá usar cada tarjeta para una comunicación. Así, si por ejemplo estamos trabajando con una única comunicación por ejemplo copiando una ISO de 8GB, únicamente estaremos usando una de las tarjetas (a 1GB máximo). Sacaremos provecho al TEAM cuando estemos usando varias comunicaciones de forma simultánea.

¡Espero que os sea de utilidad!

Flickr! Foto por elvissa

Integrándonos con Active Directory

GPOHace unas semanas, realicé un pequeño curso de administración de Directorio Activo en Windows 2003 Server, de forma totalmente gratuita aunque incompleta, ya que se trataba de una formación de 12h, de las 24 totales que duraba el curso. En cualquier caso me sirvió para aprender los conceptos básicos de DA e ir un poco más allá.

La cuestión es que este curso ha despertado en mi, simpatía e interés por los programas que tienen algún tipo de integración con DA. Curiosamente, vengo de pasar unos días en Peterborough (un pueblecito muy al norte de Londres), dónde he asistido a unas jornadas técnicas de unos productos que comercializamos, y me ha sorprendido ver como uno de ellos tiene implementada una muy buena integración con DA. Se trata de un programa de control remoto, cuya integración con DA va más allá de permitir que un determinado grupo o unidad organizativa tenga permisos para iniciar conexiones remotas con determinados usuarios, y por tanto decidir qué usuarios de DA pueden usar control remoto. Concretamente, lo novedoso (para mi) es que permite importarse en el DA a través de unos templates (ADM) que describen las políticas de configuración del programa, para poderse administrar todo directamente desde el propio DA.

Esto sin duda, facilita la vida a los administradores de sistemas, que pueden escoger si prefieren integrar la herramienta con su DA, manteniendo así de forma centralizada la administración de la seguridad de la empresa, o si por el contrario estiman mejor usar la propia interfaz de configuración del programa. Se trata, a mi entender, de una opción muy interesante a tener en cuenta.