Configuración de Windows 2008 Server Core (Básica)

Lo único que voy a suponer es que recién lo hemos instalado y solamente hemos puesto una contraseña a la cuenta Administrator, y por lo tanto hemos iniciado sesión.
Lo único a tener en cuenta es que como es normal en Windows 2008, la contraseña debe tener por los menos siete caracteres, no incluir parte o nombre del propio usuario y contener tres clases de caracteres (entre mayúsculas, minúsculas, números y simbolos).

¿Y ahora? Hay que reconocerlo muchos administradores de red actualmente no están a manejarse a través de la línea de comandos, y por las dudas para el que todavía no lo tenga claro, eso NO ES DOS J

La configuración inicial de Core Server es un equipo con un nombre generado aleatoriamente, configuración de TCP/IP a través de DHCP, y como si fuera poco con el Firewall activo. Podemos ver esto haciendo:

IPCONFIG /ALL

Las configuraciones que haremos en este caso son:

· Asignarle una dirección IP y parámetros adecuados a nuestra red

· Le cambiaremos el nombre para que se ajuste a nuestra conveniencia

· La uniremos a nuestro dominio existente

· Firewall……………

· La administraremos remotamente

· Instalaremos roles que luego administraremos remotamente

Una aclaración, aunque es lo mismo que si estuviéramos con un Windows Server normal, para cambiar la contraseña del usuario, pulsamos CTRL+ALT+SUP y tenemos la opción. También debemos recordar que en Server 2008 la contraseña de la cuenta Administrator caduca como la de cualquier usuario.
Con la misma combinación para Apagar (Shutdown) o Reiniciar (Restart).

Configuración de Red con TCP/IPv4

Una forma más ordenada de observar la configuración de IPv4 lo podemos hacer con:

NETSH INTERFACE IPV4 SHOW CONFIG

En este caso la configuración a asignar será:

· Dirección IP: 192.168.222.101

· Máscara de Subred: 255.255.255.0

· Puerta de Enlace: 192.168.222.1

Entonces ejecutamos:
NETSH INTERFACE IPV4 SET ADDRESS NAME=”Local Area Connection” SOURCE=STATIC 192.168.222.101 255.255.255.0 192.168.222.1

Que podemos verificar con:
NETSH INTERFACE IPV4 SHOW CONFIG

Configuración de Nombre de Máquina

En este caso renombraremos a la máquina a CS-01, por Core Server número 01, utilizando el comando:

NETDOM RENAMECOMPUTER %COMPUTERNAME% /NEWNAME:CS-01

Nos pedirá confirmación con advertencia de dependencias, y que es necesario reiniciar; por lo tanto reinciaremos la máquina con cualquiera de estos métodos:

· CTRL+ALT+SUP y el botón para reiniciar

· O si nos vamos acostumbrando al símbolo del sistema:
SHUTDONW /T 0 /R (/T 0 (cero) para que no espere, y /R para reinicio

Unir la Máquina al Dominio

Para poder unir el equipo al dominio primero debemos configurarla para que use el servidor DNS adecuado, en nuestro caso será 192.168.222.200

NETSH INTERFACE IPV4 ADD DNSSERVER NAME=”Local Area Connection” ADDRESS=192.168.222.200 INDEX=1

Que por supuesto podemos verificar con:

NETSH INTERFACE IPV4 SHOW CONFIG

Ahora ya está todo dispuesto para unir la máquina al dominio “guille.ad” con:

NETDOM JOIN CS-01 /DOMAIN:GUILLE.AD /USERD:ADMINISTRATOR /PASSWORDD:*

Y reiniciamos el equipo.

Ya podemos iniciar sesión con el administrador del dominio

Configuraciones Adicionales

Configurando fecha, hora, zona horaria, formatos numéricos y teclado:

CONTROL INTL.CPL

Como se puede ver, no todo es línea de comandos, hay algunas interfases gráficas, luego veremos más.

Habilitar Actualizaciones Automáticas

Debemos cambiarnos a la carpeta \Windows\System32 y ejecutar:

CSCRIPT SCREGEDIT.WSF /AU 4

Con “/AU 1” las deshabilitamos

Debemos tener en cuenta que en algunos lugares la única forma de salir a Internet es a través de un Proxy Server. Para esto tenemos dos noticias, una buena y otra mala.
La buena es que es posible configurar el proxy a usar con:

NETSH WINHTTP SET PROXY <proxyserver:port>

La mala es que no es posible configuar autenticación

Activando la Instalación

Para ver la información actual de licenciamiento:

CSCRIPT SLMGR.VBS /DLI

Para ver cuánto tiempo queda antes de la expiración:
CSCRIPT SLMGRV.VBS /XPR

Si están por expirar los 30 días, pero queremos prolongar su uso, lo podemos hacer hasta tres veces usando:
CSCRIPT SLMGR.VBS /REARM

Para introducir nuestro Product Key:
CSCRIPT SLMGR.VBS /IPK <Product Key>

Finalmente para activar el producto a través de web:
CSCRIPT SLMGR.VBS /ATO

Administrando el Firewall Remotamente

Una de las opciones que seguramente interferirá en el futuro con la configuración de los servicios que luego instalaremos es el Firewall, así que primero vamos a hacer que el cortafuegos pueda ser administrado remotamente.

A partir del comando anterior, ya podremos configurar el Firewall remotamente desde otro equipo, cargando una consola (MMC.EXE) y agregando el snap-in del Firewall. De esta forma es mucho más sencillo y claro de administrarlo.

Modificando el Registro (Registry)

Una de las interfaces gráficas que está aunque estemos con Core Server, es la que permite editar el registro:

REGEDIT.EXE

Por ejemplo, usando el regedit.exe, entre otras cosas podemos por ejemplo:

Modificar la resolución de pantalla:

Puede cambiar el GUID, pero tienen el camino en la barra de status del regedit.

Protector de Pantalla y Otras Configuraciones por Usuario

Todos conocemos el impacto que pueden tener las aplicaciones antivirus en el rendimiento del sistema; inclusive también se conocen efectos no deseados provocados por no permitir en algunos casos el acceso exclusivo a determinados archivos.

Pocos conocen que existe un artículo en la Base de Conocimientos de Microsoft con las recomendaciones sobre qué carpetas y archivos se pueden excluir en forma segura, no provocar problemas de acceso y afectar lo menos posible el rendimiento del sistema.

Virus scanning recommendations for computers that are running Windows Server 2003, Windows 2000, Windows XP, or Windows Vista:
http://support.microsoft.com/kb/822158/en-us

Ha llegado a mis manos el Resource Kit (Kit de Recursos) de Windows Vista editado por MS-Press y aunque recién lo estoy revisando veo con muy buena expectativa sus 1693 páginas. Si, es evidente y por mi parte muy complacido de encontrar tanta cantidad de información técnica dispuesta en forma ordenada; incluyendo las actualizaciones del Service Pack 1

Pienso que contiene información sumamente importante, no sólo para los "nuevos", sino que es una herramienta muy interesante para los que con más o menos fuerza nos opusimos al cambio, ya que tiene algunas opciones interesantes que no son evidentes en el producto, y aclarar algunas "intuiciones no tan intuitivas"

La información está agrupada en 6 Partes con 33 Capítulos y 3 Apéndices adicionales, realmente algo muy completo que abarca un amplio temario que trataré de describir muy brevemente. No era mi idea original, pero para mi sorpresa no veo en MS-Press el índice temas del libro, por lo que aunque pueda parecerles largo voy a tratar de resumirlo

Parte I – Overview

1. Overview of Windows Vista Improvements
2. Security en Windows Vista

Parte II – Deployment

1. Deployment Platform: Terminología, componentes, escenarios, comprendiendo la instalación MDT
2. Planning Deployment: Planificación, Microsoft Deployment Toolkit, Deployment Workbench
3. Testing Application Compatibility: Elección de la herramienta adecuada, Application Compatibility Toolkit (ACT)
4. Developing Disk Images: Captura de Imágenes, Distribución, Lab, LTI y ZTI, personalización
5. Migrating User State Data: Windows Easy Transfer y USMT
6. Deploying Applications: Planificación, automatización, aplicaciones "legacy", inclusión en imágenes
7. Preparing Windows PE: Inicio, trabajo y automatización con WinPE
8. Configuring Windows Deployment Services: Configuración, preparación de imágenes, captura de imágenes, instalación
9. Using Volume Activation: Las tres variantes OEM, MAK y KMS
10. Deploying with Microsoft Deployment Toolkit: MDT con LTI y ZTI (SMS-2003 y SCCM-2007)

Parte III – Desktop Management

1. Managing the Desktop Environment: Group Policies
2. Managing Users and User Data: Perfiles de usuarios locales y móviles, archivos sin conexión
3. Managing Disk and File Systems: Fragmentación, copia y restauración, ReadyBoost, Bitlocker, EFS, Symbolic Liks, Quotas
4. Managing Devices and Services: Dispositivos, administración de energía y comprendiendo los servicios
5. Managing Sharing: compartido de archivos y carpetas
6. Managing Windows Meeting Space: comprensión, implementación y uso
7. Managing Printing: Mejoras, comprensión uso con Group Policies, administración, migración
8. Managing Search: cómo trabaja, administración y uso
9. Managing Internet Explorer: Mejoras de seguridad y de no-seguridad, administración mediante GPOs, IEAK

Parte IV – Desktop Maintenance

1. Maintaining Desktop Help: confiabilidad y rendimiento (Reliability and Performance), eventos, reporte de errores
2. Supporting Users Using Remote Assistance: comprensión e implementación
3. Managing Software Updates: diferentes métodos manuales y automáticos, BITS, GPOs
4. Managing Client Protection: User Account Control, certificados,Windows Defender, Network Access Protection, Forefront

Parte V – Networking

1. Configuring Windows Networking: Mejoras, Wireless, cómo conectar a Dominio
2. Configuring Windows Firewall and IPSec: comprensión y administración del cortafuegos
3. Connecting Remote Users and Networks: accesos VPN y discado, GPOs, escritorio remoto
4. Deploying IPv6: comprensión, mejoras, migración

Parte VI – Troubleshooting

1. Configuring Startup and Troubleshooting Startup Issues: nueva forma de inicio, archivos de inicio, resolución de posibles problemas
2. Troubleshooting Hardware, Driver, and Disk Issues: resolución de problemas en disco, drivers, USB y Bluetooth, diagnóstico y herramientas
3. Troubleshooting Network Issues: herramientas para resolución de problemas
4. Troubleshooting Stop Messages: BSOD (Blue Screens) errores comunes, volcados de memoria, problemas de hardware

Aunque este listado está resumido es fácil ver la amplitud de temas abarcados.

Es muy importante destacar que el manual es de fácil consulta o aprendizaje, ya que tiene gráficos en todos los casos necesarios, notas recuadradras con los elementos más importantes, y un par de elementos que destaco especialmente:

• How It Works
• Direct From the Source

El primero explicando el detalle, y el segundo con información directa de los del equipo de desarrollo del producto.

Se incluye además enlaces a recursos adicionales en la web, y en el propio CD que acompaña al libro

Resumiendo: altamente recomendable para todo aquel que tenga que instalar, mantener y dar soporte a equipos con Windows Vista. Sirve tanto como material de consulta sobre temas específicos como para comprender el funcionamiento.

A veces puede suceder, los administradores suelen tener "dedos rápidos"  y borrar accidentalmente un usuario y responder en la misma operacióna la confirmación no es algo inusual. Lo que sí seguramente sigue es un "Huuuuuuuu"

Vamos a ver un poco cómo podemos recuperarlo, lo que sí y lo queno podremos recuperar, y de paso aprovecharemos para meternos un poco accediendo a Active Directory directamente.

Doy por conocido por todos, que cuando se crea un usuario, al mismo se le asigna un SID (Security IDentifier) que es un número único, no reutilizable, por lo que no vale volverlo a crear con el mismo nombre. Aunque se llame igual será otro diferente.

Lo importante será recuperarlo con el mismo SID, aunque lamentablemente, algunas propiedades no se podrán recuperar, o mejor, digamos qué es lo que se conserva cuando borramos una cuenta: SID, ObjectGUID,LastKnownParent y SAMAccountName.

Para demostrarlo he creado sobre Windows 2003R2-SP2 un dominio llamado "test1.msft" donde crearé una Unidad Organizativa llamada "test" dentro de la cual crearé un usuario "Usuario Uno". Esta cuenta será borrada y luego recuperada.

Para poder hacer el siguiente procedimiento, debemos tener instaladas las "Support Tools". Estas se pueden descargar del sitio de MS, debiendo cuidar que sean las que corresonden a nuestro sistema operativo y service pack.

Ahora borramos la cuenta de "User Uno", y paso siguiente comenzamos la "Support Tools" LDP.EXE

Hacemos Connection / Connect… (no hace falta ingresar el servidor, ya que por omisión tomará el en que estamos ejectuando

Ahora Connection / Bind e ingresamos las credenciales de un administrador.
Confirmemos que en el panel derecho aparezca: Authenticated as dn:'administrator'.

Seguimos con: Options / Controls y en Load Predefined, seleccionamos Return Deleted Objects

En Control Type, elegimos Server, y OK

View / Tree escribimos cn=deleted Objects,dc=test1,dc=msft

Vamos abriendo "deleted Objects" y veremos la cuenta borrada, inclusive haciendo un doble-click sobre la misma podemos ver los detalles en el panel derecho

Ahora vamos a recuperarlo. Para eso click-derecho sobre el usuario y elegimos Modify

1. En Edit Entry Attribute, ingresar isDeleted
   Dejar Value en blanco
2. Click en opción Delete, y ahora click Enter
   IMPORTANTE NO hacer Run
3. En Attribute, ingresar distinguishedName
4. En Values, ingresar el DN: cn=user uno,ou=Test,dc=test1,dc=msft
5. En Operation, click en REPLACE
6. Enter
7. Verificar que esté seleccionado Synchronous
8. Marcamos Extended
9. Y ahora sí, hacemos Run

Ya podemos ir y ver que la cuenta ha sido recuperada exitosamente.

Lamentablemente se ha perdido mucha información, debemos asignarle una contraseña y volverlo a incluir en los grupos a los que pertenecía antes de la eliminación.

Personalmente no es para mí muy cómodo el acceso para desconectar un dispositivo USB accediendolo desde el área de notificación.

En forma muy sencilla podemos crear un atajo (shortcut) sobre el escritorio
C:\Windows\System32\rundll32.exe shell32.dll,Control_RunDLL hotplug.dll

¿No les resulta molesta esa costumbre de Windows que cuando creamos un "Acceso Directo o Shortcut" lo pone en el título? A mi sí me molesta y mucho.

Se nota que a la gente de Microsoft no les alcanza, con agregar la flecha en el icono.

Se puede eliminar fácilmente, usando el registro (REGEDIT.EXE), y modificamos el valor:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\link
Cambiamos el valor original "1e 00 00 00", por "00 00 00 00"

En una red con Windows y TCP/IP, cada máquina tiene en realidad dos nombres: uno llamado "Nombre NetBIOS" y otro llamado "Hostname". Estos nombres son asignados a los equipos durante la instalación, y son usados tanto por las aplicaciones como por los que usamos los equipos y recursos de la red.

En sistemas Pre-Windows 2000, el nombre que se le asigna a una máquina es el "Nombre NetBIOS", este tiene una longitud máxima de 16 caracteres, aunque sólo son utilizables 15, pues el dieciseisavo tiene uso reservado. Admite algunos símbolos (por ejemplo "_"). Pero si vamos a las propiedades de TCP/IP vemos que también tiene asignado un "hostname" que por omisión el sistema trata que sea igual al "Nombre NetBIOS".

A partir de Windows 2000, en cambio, el nombre asignado durante la instalación es el "hostname" que puede tener hasta 255 caracteres, pero que es mucho más restrictivo ya que sólo puede contener letras, números y el signo "-". En estos sistemas si miramos en el lugar donde se cambia el nombre, notaremos que también existe un "Nombre NetBIOS" pero que no podemos cambiar separadamente del "hostname".

De cualquier forma, y esto es importante, en una red TCP/IP siempre que nos referimos a un equipo usando alguno de estos nombres, el sistema necesita obtener qué dirección IP corresponde a dicho nombre. A este proceso se lo llama Resolución de Nombres.

Existen métodos para resolver "Nombre NetBIOS" y métodos diferentes para resolver "hostname". Si no tiene muy claro el concepto es interesante que vea Resolución de Nombres de Máquina (DNS, WINS, HOSTS, LMHOSTS, y etcéteras)

En esta nota trataré de ver con cierto nivel de detalle la resolución de "hostname" lo cual nos lleva indefectiblemente a cómo trabaja el servicio DNS.

¿Lo hacemos como un cuento para que sea más ameno? J Bien, si nadie dice nada lo haré así J. Había una vez… un grupo de gente muy estudiosa trabajando con las primeras redes TCP/IP que cuando necesitaban acceder a otro equipo lo identificaban directamente escribiendo la correspondiente dirección IP, y eso funcionaba perfectamente.

Si, funcionó perfectamente hasta que se fueron agregando más y más máquinas y ya era difícil recordar esos números (dirección IP) para cada uno de los equipos. A partir de eso se buscó algo que fuera más fácil de recordar: un "alias" o "apodo" para cada máquina ya que eso es mucho más fácil para que un humano lo recuerde. Y así nació el hostname

Luego en cada máquina se debía tener un archivo de texto que especificara qué dirección IP correspondía a cada alias (hostname). Esto es el archivo HOSTS. Este es un método muy eficiente para resolver nombres, pero tiene el inconveniente que hay que mantenerlo y actualizarlo en cada máquina.

Mientras Internet, o en ese entonces Arpanet, eran pocos equipos y con muy poca variación esto fue una solución. Según se cuenta en el MIT (Massachusetts Institute of Technology) se mantenía el archivo HOSTS central. Bastaba que cuando se agregaba o cambiaba un equipo se avisara, y que periódicamente una se trajera una copia actualizada y la distribuyera entre sus equipos. Supongo que a esa altura la NASA debía tener como cinco computadoras J

Esto era muy bueno, pero a medida que siguió creciendo, se fue poniendo cada vez más difícil el mantenimiento del HOSTS central por su tamaño, y como si fuera poco comenzaron los problemas por la colisión de nombres, no podía haber dos máquinas con el mismo hostname.

Cómo se solucionó esto. La solución pasó por dos puntos fundamentales:

• Descentralizar la administración
• Armar una estructura jerárquica que solucionara las colisiones de nombres

Así nació DNS (Domain Name System o Domain Name Server)

En ese momento ya habían varias empresas comerciales incorporadas, como así también agencias gubernamentales, universidades, etc. Por lo tanto se convino en que cada una de ellas debía mantener un servidor de nombres (Name Server) que "resolviera" sus propios nombres.

Luego los clientes tenían configurado que cuando tuvieran que "resolver un nombre" le preguntaran a su servidor de nombres (Name Server). Mientras el administrador local se ocupara de mantener manualmente sus propios "mapeos de nombre" todo funcionaba perfectamente dentro de la propia organización . Esta base de datos donde se anotan los nombres y su correspondiente dirección IP, se llama ZONA.

Hasta acá todo bien, pero sólo se resuelve dentro de la propia organización, pero ¿cómo se hace cuando se quiere acceder a un equipo que esté en otra empresa u organización? Bien, para resolver esto se dispuso poner un servidor de nombres que se encargara de resolver *solamente* los servidores de nombres de cada organización. Y estos últimos debían conocer a este "servidor de nombres padre".

Entonces funcionaría de esta forma, cuando un cliente tiene que resolver un nombre, se lo pregunta a su servidor de nombres, si éste lo puede resolver utilizando su propia ZONA, responde según se dice en forma Autoritaria o Autoritativa, pues tiene los datos localmente. Pero si no tuviera los datos localmente entonces le preguntará al "servidor de nombres padre" para saber qué servidor de nombres en particular le puede dar la respuesta.

Así como está planteado hasta ahora, todo funcionaría, pero por variadas razones se hizo un poco más complejo, no mucho no asustarse. En lugar que todo el mundo tuviera un único "servidor padre" se agruparon por rubro. Es de decir el que resolvía quienes podían resolver nombres comerciales se agruparon en uno, los gubernamentales en otro, los educativos en otro, etc. etc. Arriba de todos estos, si había un "único padre".

Con un poco de imaginación de parte de los lectores, y porque es complicado ponerme a dibujar ahora ;-) vemos que estamos construyendo un árbol, o más precisamente las raíces de un árbol. Todos las organizaciones comerciales "colgando" de un servidor de nombres que "maneja los COMerciales", y otras organizaciones gubernamentales"colgando" del que "maneja los GOVernamentales", y educativas "colgando" del que "maneja los EDUcativos". Y por arriba de todo, o sea el que conoce quienes son los que manejan a los COMerciales, GOVernamentales, EDUcativos, etc. hay un servidor de nombres que sabe quiénes son estos últimos.

Bueno, a esta altura paremos con los cuentos y vamos a cosas más reales. Cada "nudo" de este árbol invertido que estamos haciendo se llama Dominio de DNS o Dominio de Internet.

En la parte inferior tenemos los dominios, por ejemplo: hp, microsoft, ibm, etc. que "cuelgan" del dominio "com"; nasa, whitehouse, etc. que "cuelgan" del "gov"; purdue, mit, etc. que "cuelgan" de "edu"; y podemos seguir con los diferentes grupos, que cada uno ya se imagina: org, net,mil y el que cada país tiene a este nivel (ar, es, mx, etc.)

Arriba de cada uno de esos dominios de primer nivel hay otro servidor de nombres que sólo conoce quienes son los servidores de com, gov, edu, etc. Lo que tuvieron problemas es para designar el nombre de este dominio raíz, no hubo forma de ponerse de acuerdo, por lo que quedó sin nombre (un poco de humor). Es verdad se llama con el carácter nulo, pero como los humanos no lo podemos representar y no lo podemos ver se lo representa por un punto (.)

¿Ya se armó cada uno el "arbolito"? si no pudo en la cabeza tome lápiz y papel J

Hasta ahora vimos como se distribuyó el trabajo, vamos ahora a ver cómo se evitan las colisiones de nombres.

Cada máquina (usemos la palabra host para ser más técnicos) necesita identificarse dentro de este árbol en una forma única (unívoca). Y esto se logra mediante el "camino" que va desde el propio host hasta el dominio raíz. Así por ejemplo un host que está en el sitio de hp y tiene hostname server1 se identifica como: server1.hp.com. (si, con punto al final) y otro que también se llame server1 pero que esté en el MIT, se llamará server1.mit.edu.

Este nombre que identifica unívocamente cada host en el árbol se llama FQDN (Fully Qualified Domain Name) que todos los usamos cuando escribimos un URL de Internet, aunque no sepamos que esa parte se llame así J

Aunque nadie pone el punto final de un FQDN, todas las aplicaciones lo dan por descartado y funciona bien.

Llegó el momento de poner las cosas en su lugar y ver cómo funciona esto. Vamos a suponer que en este momento se pone todo en funcionamiento, o sea que no hay ninguna información almacenada en memoria de ningún equipo salvo lo que tenga en su propia zona.

Cada servidor de una organización conoce solamente los nombres de su propia organización, y la dirección IP del (los en realidad) servidores del dominio raíz.
El (los) servidor del domino raíz conoce sólo los DNS que tiene justo "abajo", o sea primer nivel (.com, .edu, .mil, .ar, .mx, etc.)
Y los servidores de primer nivel sólo conocen a los DNS de cada organización.

En la situación anterior, un usuario en, supongamos, hp quiere acceder a server1.microsoft.com. Por lo tanto en el equipo cliente un componente software llamado Resolver se encarga de preguntar al DNS que tenga configurado para que le diga qué dirección IP tiene dicho host. Los Resolvers suelen ser de mal carácter (humor) así que la pregunta es algo así como: "decime que IP tiene server1.microsoft.com o decime que no sabes, no acepto referencias o medias respuestas) A esto tipo de pregunta se la llama Recursive Query, exige respuesta concreta por sí o por no.

Como el servidor DNS de hp no tiene localmente en su propia zona nada de microsoft.com sale a buscar en el único externo que conoce, el DNS del dominio raíz. Este le va a responder con una referencia, que es lo más que puede; algo así como "preguntale al servidor de com", por lo tanto el servidor DNS de hp ahora le pregunta al de "com" quien le dirá que pregunte al de microsoft que finalmente dará la respuesta solicitada, al servidor DNS de hp, que devolverá el dato correspondiente al cliente que originó todo, y que finalmente podrá hacer la conexión correspondiente. Estas "preguntas" entre servidores DNS se llaman Iterative Query, pues admiten referencias o respuestas parciales.

Cada pregunta que hizo el servidor DNS para resolver el pedido del cliente, recibió conjuntamente con la respuesta, un parámetro denominado TTL (Time To Live) que corresponde a cuánto tiempo puede tener la información en memoria y considerarla válida (cachear que le decimos J).

Si estamos dentro del tiempo de los TTLs, si otro cliente repite la pregunta, el DNS devolverá la información correcta sin necesidad de ir a buscar afuera. O inclusive si le preguntaran por serve1.microsoft.com podría preguntar directamente al DNS de microsoft.com. O inclusive si le preguntaran por server.ibm.com no comenzaría por el raíz, sino directamente por el DNS de com.

Esto ya está demasiado largo, así que quedará para otra nota, un poco más de DNS, específicamente los temas de zonas primarias y secundarias, tipos de registros SOA, NS, A, etc. y supongo que para una tercera parte, la integración de DNS con Active Directory.

En redes pequeñas es muy común contar con un único Controlador de Domino (Domain Controller) y muchas veces he escuchado esta pregunta: se necesita reemplazar un controlador de dominio por otro con componentes (Hardware) más nuevo o potente.

Por supuesto que se puede hacer con Copia de Seguridad y Restauración (Backup y Restore), pero no siempre es un proceso fácil ni rápido.

Otro procedimiento que se puede hacer, que es sencillo y tiene pocos riesgos es el siguiente:

1. Instalar el sistema operativo en el nuevo hardware y revisar que esté todo bien
2. Usado como DNS al anterior Controlador de Dominio, lo promovemos como Controlador de Dominio Adicional en un Dominio Existente
3. Esperamos que replique toda la información de Active Directory
4. Luego instalamos en el nuevo el servicio DNS, y controlamos que replique todas las zonas integradas en Active Directory
5. A partir de esto último ya lo podemos poner que use como DNS a sí mismo
6. Lo hacemos Catálogo Global (Global Catalog) y esperamos hasta ver en el DNS sus registraciones en la zona _msdcs…..gc…
7. Transpasamos los 5 FSMO Roles (*)
8. Nos aseguramos que todos los clientes estén usando como DNS al nuevo servidor, ya sea que manualmente o por DHCP tomen la dirección del nuevo DNS
9. Ya está todo casi listo, pero por precaución nos conviene apagar el Controlador de Dominio original por un tiempo prudencia, y ver que todo funcione correctamente
10. Si todo está bien, recién en ese caso ya podemos despromover al Controlador de Dominio original

(*)How to view and transfer FSMO roles in Windows Server 2003:
http://support.microsoft.com/kb/324801

Mover una instalación de Windows a otra máquina con diferente hardware siempre ha sido un problema, pero que tiene una explicación válida. Plug'nPlay ayuda a instalar los nuevos controladores, pero el problema reside en que para que esto suceda el sistema debe primero funcionar, aunque sea limitadamente.

Para que suceda esto, el sistema se tiene que poder comunicar con los componentes básicos del equipo, que para simplificar diremos que son: los discos rígidos y la placa base (motherboard) y esto depende de dos componentes, los drivers de la controladora de disco, y la HAL.DLL (Hardware Abstraction Layer)

Vemos primero soluciones "extraoficiales" no soportadas, pero que según mi experiencia funcionan en muchos casos

Si fuéramos a cambiar la controladora de disco, porejemplo IDE por SCSI o viceversa, bastará con que antes de apagar el equipo origen agreguemos manualmete la controladora del nuevo equipo.

Aún siendo IDE a IDE, no todas las controladoras son iguales, así que podemos también aplicar el procedimiento descripto en:
You receive a Stop 0x0000007B error after you move the Windows XP system disk to another computer:
http://support.microsoft.com/kb/314082

Para la HAL.DLL el problema es mucho más complicado, depende mucho de la que esté instalada en el sistema origen, pero en general podemos decir que la HAL.DLL correspondiente a NO-ACPI multiprocessor, arrancará casi cualquier equipo. No así a la inversa, un ACPI a NO-ACPI no funcionará L

De todas formas Microsoft documenta un proceso, que aunque no sea muy sencillo puede ayudar y justifica en muchas ocasiones:
How to move a Windows installation to different hardware:
http://support.microsoft.com/kb/249694

No debería suceder nunca, pero a veces pasa J. Un controlador de dominio tiene problemas y no hay forma de repararlo ni de despromoverlo en Active Directory.

Lo recomendable es que siempre que se vaya a sacar un Controlador de Dominio del Dominio, primero sea despromovido correctamente, pero no siempre es el caso. Vamos a ver qué opciones tenemos para dejar nuestro Active Directory correcto.

La primera, y mejor opción, es tratar de despromoverlo correctamente con DCPROMO.EXE. Si así funcionara entonces queda todo bien.

Si se negara a despromoverse, podemos forzar la despromoción con DCPROMO.EXE /FORCEREMOVAL. Los pasos están detallados en:
Domain controllers do not demote gracefully when you use the Active Directory Installation Wizard to force demotion in Windows Server 2003 and in Windows 2000 Server: http://support.microsoft.com/kb/332199/en-us
Aunque esto nos traerá como inconveniente que sus datos, quedarán en Active Directory, y el resto de los Controladores de Dominio seguirá intentando comunicarse con este equipo que ya no estará.

Para solucionar esto debemos hacer un proceso de limpieza de Active Directory, según el procedimiento detallado en:
How to remove data in Active Directory after an unsuccessful domain controller demotion:
http://support.microsoft.com/kb/216498/en-us

Y si la desaparición de este Controlador de Dominio, implicara que ya no existirá más un Subdominio (Child Domain) entonces debemos eliminar también sus correspondientes datos. Para eso utilizaremos:
How to remove orphaned domains from Active Directory:
http://support.microsoft.com/kb/230306/en-us

Mediante Group Policies (GPO) y Grupos Restrictivos (Restricted Groups) es fácil automatizar el proceso de hacer que un grupo de Help Desk esté dentro del grupo local Administradores (Administrators) de ciertas máquinas.

How to Configure a Global Group to Be a Member of the Administrators Group on all Workstations:
http://support.microsoft.com/kb/320065

Cuidado con la traducción al español que es automática

El artículo ser refiere a Windows 2000 pero es exactamente igual para 2003.

Además el título no es correcto pues basta aplicar la GPO a la Unidad Organizativa (Organizational Unit) donde están las máquinas donde queremos aplicar la configuración, que no necesariamente son todas (all) como refiere el título.

How to replace the motherboard on a computer that is running Windows Server 2003, Windows XP, or Windows 2000:
http://support.microsoft.com/kb/824125

Cómo sustituir la placa base de un equipo que está ejecutando Windows Server 2003, Windows XP o Windows 2000:
http://support.microsoft.com/kb/824125/es

Aunque es un truco que ya tiene varios años de antigüedad, no es muy conocido y aprovechado.

Si observamos con el complemento (snap-in) el Esquema (Schema) podremos ver varias cosas interesantes. Para nombrar solamente una, un objeto de clase usuario tiene muchos más atributos que los que nos muestra la aplicación Usuarios y Equipos de Active Directory (Active Directory Users and Computers).

Un atributo que puede ser útil en muchas empresas es poder disponer en Active Directory de un "Identificador de Empleado" llamado también en algunos casos como "Número de Legajo". Para esto podemos usar el atributo EmployeeID que ya está presente, sólo que no es mostrado.

El procedimiento es simple, sólo necesitaremos tener instaladas las Support Tools correspondientes al sistema operativo y service pack que tiene el controlador de dominio, alcanza con hacer una búsqueda en www.microsoft.com/downloads y luego instalarlo.

Creamos una MMC cargando el complemento ADSIEdit, y vamos a user-Display object (en CN=409, CN=DisplaySpecifiers, CN=Configuration). Con botón derecho elegimos propiedades y agregamos "2, Employee &ID, c:\windows\system32\employeeid.vbs" (Sin comillas). Es importante no remover entradas existentes, o si el número 2 ya estuviera, elegir el siguiente valor libre.

Lo que nos falta ahora es poner el script EmployeeID.vbs en c:\windows\system32

Acá transcribo un script que funciona:

____________

' -------------------------------------------------------------------------
'       Script by Sakari Kouti (see http://www.kouti.com)
' You have a royalty-free right to use, modify, reproduce and distribute
' this script (and/or any modified version) in any way you find useful,
' provided that you agree that Addison-Wesley or Sakari Kouti has no
' warranty, obligations or liability for the script. If you modify
' the script, you must retain this copyright notice.
' -------------------------------------------------------------------------
Option Explicit
Dim wshArguments, objUser, objSchemaEmployeeID, strCurrentID, strEmployeeID, intMaxLen

On Error Resume Next

Set wshArguments = WScript.Arguments
Set objUser = GetObject(wshArguments(0))
Set objSchemaEmployeeID = GetObject("LDAP://schema/employeeID")

intMaxLen = objSchemaEmployeeID.MaxRange

If objUser.employeeID <> "" Then
    strCurrentID = objUser.employeeID
Else
    strCurrentID = "empty"
End If

strEmployeeID = InputBox( _
    "The current Employee ID is " & strCurrentID & vbCrLf & _
    vbCrLf & _
    "Enter the new Employee ID (1 through " & intMaxLen & " chars)", _
    Right(objUser.Name, Len(objUser.Name) - 3) & " Employee ID", _
    objUser.employeeID)

If strEmployeeID = "" Then WScript.Quit   'User clicked Cancel

If Len(strEmployeeID) > intMaxLen Then
    MsgBox "The new Employee ID was too long and it was not saved.", _
        vbCritical, "Error Occurred"
Else
    Err.Clear
    objUser.employeeID = strEmployeeID
    objUser.SetInfo
    If Err Then MsgBox "The new Employee ID was not saved.", _
        vbCritical, "Error Occurred"
End If

____________

Solamente queda ir a Usuarios y Equipos de Active Directory (Active Directory Users and Computers) y hacer botón derecho sobre un usuario.

Una de las cosas que hace más interesante todavía esto, es que entrando en las opciones de búsqueda avanzada de Active Directory se puede buscar por este campo.

Hay disponible una herramienta gratis de Microsoft que permite crear en forma automática diagramas en Visio de la estructura de Active Directory, incluyendo sitios, dominio y unidades organizativas, o Exchange 2000x

ADTD (Active Directory Topology Diagrammer) se puede descargar desde: Microsoft Active Directory Topology Diagrammer

Aunque no han habido "grandes cambios" si hay "importantes cambios" varios de los cuales, pueden tener gran influencia en el diseño de Active Directory.

Entre otros podemos mencionar:

• Read-Only Domain Controllers (RODCs)
• Active Directory Domain Services Auditing
• Fine-Grained Password Policies
• Restartable Active Directory Services
• Database Mounting Tool and Snapshoots

Read-Only Domain Controllers (RODCs)

¿Una regresión a NT4? podemos pensar que casi es así, pero igual tiene gran importancia cuando se hace el diseño de Active Directory. Específicamente cuando tenemos sitios remotos donde no contamos con la seguridad física adecuada sobre los controladores de dominio, pero donde debemos tener controladores de dominio por la criticidad de la validación aún cuando el sitio esté desconectado de la red central.

Se da en muchas ocasiones que en un sitio remoto es estrictamente necesario que los usuarios puedan validarse aún estando el enlace caído. Esta consideración nos obliga a poner un Controlador de Dominio en dicho sitio.
Sin embargo la preocupación del diseñador es que va a poner en un sitio con poca seguridad física un servidor que tiene uno de los elementos más valiosos: una copia de todas sus cuentas de usuarios (y sus correspondientes contraseñas ). En estos casos el servidor puede estar sujeto a hurto, ataques por acceso directo, etc. Es un problema.

Para solucionar este problema, a partir de Windows Server 2008, podemos contar con RODCs (Read-Only Domain Controllers) que tiene varias características que lo hacen apropiado para escenarios como el nombrado.

La primera de las ventajas lo dice su nombre, su base de Active Directory, sólo se puede leer y no escribir, con lo cual mitigamos cualquier tipo de ataque que efectúe cambios en NTDS.DIT de este servidor. Igualmente, y para mayor seguridad, si de alguna forma se consiguieran hacer cambios, no hay que preocuparse pues este servidor no hacia otros Controladores de Dominio.

Pero la característica que pienso es la más importante está basada en que aunque este RODC tiene una copia completa de los objetos del Active Directory, se puede controlar fácilmente cuáles son las contraseñas que se replicarán desde el sitio central protegido.

A partir de lo anterior, se puede hacer que se repliquen al RODC sólo las contraseñas de las cuentas usadas en el sitio remoto, lo que haría que en el peor de los casos, las cuentas afectadas por un ataque serían solamente algunas y el daño es parcial.

Se debe tener en cuenta que si cuando el RODC necesita validar una cuenta cuya contraseña no está local, debe obligatoriamente contactar a un Controlador de Dominio que si la tenga.

Active Directory Domain Services Auditing

Ya en Windows 2003 se puede hacer auditoría de seguridad de Active Directory, pero sus posibilidades son limitadas. Esto traía como consecuencia que los administradores dudaran en delegar tareas administrativas, pues perdían parte del control. Los delegados estaban acotados a las tareas otorgadas, pero la auditoría era limitada, básicamente "creó - borró" "pudo - intentó". Pero si había cambiado algún dato ¿qué fue? ¿cuál era el valor anterior y cuál el actual?

Ahora la auditoría de seguridad puede auditar los cambios, informando del valor que fue modificado: anterior-actual. Así mismo la creación u operación de mover cuentas, también el "casi desconocido UNDO" para recuperar cuentas eliminadas accidentalmente.

Además se agregan otras categorías de auditoría que permiten auditar la replicación entre Controladores de Dominio.

Fine-Grained Password Policies

Si, al fin se pueden tener diferentes directivas de contraseñas de cuentas en un único dominio que regulan todas las características de las mismas (longitud, complejidad, duración, bloqueo, etc.)

No es quizás un proceso tan sencillo ni intuitivo, pero tampoco es demasiado complejo. Básicamente esto se debe al uso de una herramienta no muy familiar a la mayoría como es el ADSIEdit, con el cual se creará un Password Setting Object (PSO) con los atriibutos específicos, y que luego se asignará a usuarios o grupos.

Restartable Active Directory Services

En sistemas anteriores a Windows Server 2008, hay operaciones sobre la base de Active Directory que requieren que el Controlador de Dominio fuera reiniciado en Directory Service Restore Mode (DSRM). Y esto no era sólo para hacer una recuperación de Active Directory, sino que también es necesario para hacer una defragmentación "offline" de la base, corrección de posibles errores semánticos, cambio de carpeta de los archivos de la base y logs.

A partir de Windows Server 2008, Active Directory se comporta como "un servicio más", o sea que lo podemos detener como cualquier otro servicio, a fin de efectuar operaciones que así lo requieran.

Database Mounting Tool and Snapshoots

En este caso primero describiremos la tarea para luego ver su utilidad. Con la utilidad NTDSUTIL.EXE podemos tomar "snapshots" de la base de Active Directory, inclusive podemos hacerlo programándolo como tarea.
Luego con la utilidad DSAMAIN.EXE podemos listar dichos "snapshots" que no son otra cosa que "estados congelados" de nuestro Active Directory como si fuera un LDAP Server. También lo podemos hacer sobre copias de seguridad de Active Directory. Luego podemos "montar" esos estados anteriores con herramientas como LDP.EXE o aún con Usuarios y Equipos de Active Directory (Active Directory Users and Computers).

Bien ¿qué utilidades le encontramos a esto? va en la creativdad de cada uno, pero son varias, desde la reconstrucción de un domino/bosque hasta una auditoría de cambios, comparar copias de seguridad, etc.

Continuando con el tema seguridad, en esta nota veremos algunas de las propiedades más importantes de seguridad, desarrollaremos el concepto de encriptación o cifrado y luego algunos conceptos de firma digital. Esto permitirá que a continuación desarrollemos el tema de infraestructura de clave pública, su funcionamiento básico y el concepto de certificados.

La criptografía está fundamentalmente basada en funciones matemáticas y su estudio profundo nos llevaría directamente a investigación matemática, que no es el objetivo en este momento.

Los métodos criptográficos están basados en algoritmos matemáticos (funciones) tales que aplicados sobre ciertos datos (la información) más un argumento variable producen un determinado resultado no legible (Texto Cifrado).

En general se usan los términos Texto Plano (la información en forma legible), Clave (el argumento variable) y Texto Cifrado (la información encriptada). Lo que podemos ver como:

La criptografía es uno de los métodos para proteger información confidencial. En esta nota la definiremos como un conjunto de técnicas matemáticas para proteger la información mediante ciertas propiedades, de las cuales definiremos las más importantes.

Debemos tener en cuenta que algunas de ellas están provistas por medios criptográficos y/o no criptográficos.

Propiedades

Confidencialidad: implica que la información esté oculta para cualquiera que no sean las partes autorizadas a verla. Para proveer confidencialidad a la información la misma debe ser encriptada (cifrada).

Es importante tener en cuenta que las claves deben ser cambiadas periódicamente para mejorar la seguridad, y además que deben estar debidamente protegidas. Tomemos dos casos una transmisión de datos usando IPSec, y la utilización de EFS (Encrypted File System).

Integridad: implica que la información no sea alterada por partes no autorizadas, tanto durante la transmisión como durante el almacenamiento.

No-Repudio: implica que el emisor no pueda falsamente negar la emisión del mensaje. Implica también que el receptor tampoco pueda falsamente negar la recepción.

No-Reenvío: implica que una información o mensaje no pueda ser reenviado por alguien que ha capturado una transacción legal.

Autenticación: implica probar la identidad de una parte a otra. Esta provee que alguien no pueda falsear su propia identidad, y permite que el receptor determine fehacientemente la identidad del emisor.

Funciones Criptográficas

Los algoritmos matemáticos (funciones) usados en criptografía cumplen con ciertas condiciones, entre ellas la fundamental implica que es sencillo computarla en un sentido, y prácticamente imposible en sentido inverso, sin conocer algún dato.

Aclaremos esto: con el Texto Plano + Algoritmo + Clave es fácil obtener el Texto Cifrado. Pero conociendo el Texto Cifrado + Algoritmo, es casi imposible obtener el Texto Plano, sin conocer la Clave. Los algoritmos utilizados son conocidos públicamente, la dificultad consiste en no conocer la clave.

Funciones de Hashing

Intervienen también funciones de Hash. Estas funciones toman una entrada de largo variable (Texto Plano) y producen una salida de largo fijo (Hash). Tienen como prioridad que un "pequeño" cambio en la entrada producen un "gran" cambio en la salida.

De todas formas debemos tener en cuenta que al "reducir" la entrada a una salida de largo fijo, y más corta generalmente, siempre es posible que diferentes entradas produzcan el mismo resultado, esto se llama colisión. Cumplen con la condición que en caso de producirse una colisión las entradas son tan diferentes que es fácil darse cuenta que no corresponden.

Encriptado (Cifrado)

El encriptado de información se puede efectuar mediante dos técnicas:

• Encriptado por Clave Simétrica o Secreto Compartido
• Encriptado por Clave Asimétrica o esquema de Clave Pública

Encriptado por Clave Simétrica

Si se utiliza un esquema de Clave Simétrica, también llamado método de Secreto Compartido, se utiliza la misma Clave para encriptar y desencriptar la información

El concepto fundamental a tener en cuenta es que la clave utilizada para encriptar, es la misma utilizada para desencriptar, por lo tanto los algoritmos usados son complementarios.

Este esquema tiene ventajas e inconvenientes. Entre las ventajas podemos nombrar la facilidad de implementación, y entre los inconvenientes que si alguien accediera a la Clave, en cualquiera de los extremos, obtiene la posibilidad de encriptar y desencriptar.

Encriptado por Clave Asimétrica

El esquema de Clave Asimétrica mejora notablemente la seguridad del caso anterior pero su implementación es más compleja.

El esquema de Clave Pública está basado en que cada ente posee dos claves que cumplen con las siguientes condiciones:

• Las claves son diferentes
• Las claves son complementarias: si se utiliza una para encriptar, es necesaria la otra para desencriptar

Cada poseedor de estas claves denomina a una como Pública, y la da a conocer públicamente, y a la otra como Privada la cual mantiene secreta y protegida.

Ejemplo de utilización

Veamos un ejemplo para aclarar el uso, como puede ser un el envío de un mensaje.

a) Esquema de Clave Simétrica o Secreto Compartido

Cuando A va enviar un mensaje a B, primero debe encriptar el mensaje utilizando un algoritmo que ambos conocen, alimentado por la Clave (el secreto compartido). Luego de lo cual lo envía. Cuando B recibe el mensaje, conociendo el algoritmo utilizado y la Clave puede desencriptar el mensaje.
Se debe mencionar que este mecanismo tiene la dificultad de cómo compartir la clave, sin que un tercero la sepa.

b) Esquema de Clave Asimétrica o Pública

Cuando A va a enviar un mensaje a B, lo debe encriptar utilizando la clave Pública de B. Recordar que B da a conocer esta última a quien la requiera. Luego lo envía. Cuando B recibe el mensaje, utilizando su clave Privada y el algoritmo utilizado puede desencriptar el mensaje.
Se debe notar que previamente A debe conocer la clave Pública de B.

Firma Digital

El proceso de Firma Digital tiene como función principal asegurarse la Integridad de la información, pudiendo proveer también No-Repudio y Autenticación.

El proceso de Firma Digital se usa generalmente en combinación con un esquema de Clave Pública, de forma de encriptar el Hash. Si esto último no sucediera, sería fácil para alguien interceptar el mensaje alterar el contenido y calcular el nuevo Hash.

Es de notar que la firma digital no provee encriptación, si fuera necesario esto último se debe combinar con una técnica de encriptación.

Si A desea enviar un mensaje firmado digitalmente a B efectúa los siguientes pasos: primero calcula el hash de la información, a este dato lo encripta con su clave privada (la de A) y el resultado se acompaña con el mensaje enviado. Cuando B recibe el mensaje, utilizando su conocimiento de la clave pública de A, desencripta el hash, y luego hace su propio calculo del hash del mensaje recibido. Si el mensaje no fue alterado desde su envío estos valores deben coincidir. Además por el hecho de poder desencriptarlo utilizando la clave pública de A, le asegura que éste fue realmente el emisor.

Combinaciones

Todos estos elementos que hemos nombrado en general se utilizan en forma combinada. Es habitual que un mensaje encriptado esté además firmado digitalmente.

Dado el alto consumo de recursos que implicaría encriptar transmisiones usando únicamente clave pública, generalmente se utiliza el esquema de clave pública para intercambiar información que permite la generación de las claves simétricas que luego se utilizarán en la transmisión de datos. IPSec utiliza esta técnica.

Infraestructura de Clave Pública

Vamos a nombrar a continuación los componentes principales de la infraestructura de clave pública, y describiremos brevemente sus funciones.

Autoridad Certificadora (CA = Certificate Authority)

Es la encargada de, luego de verificar la identidad del requirente, crear el certificado solicitado.

Certificado Digital

Aunque luego profundizaremos más, en primera instancia podemos afirmar que un certificado es una prueba de la correspondencia entre el requirente y clave pública. Podemos corresponderlo a un documento de identidad.

Punto de Publicación de Certificados (CPP = Certificate Publication Point)

Es el lugar donde la autoridad certificadora deposita los certificados que fueron requeridos y otorgados.

Lista de Certificados Revocados (CRL = Certificate Revocation List)

Aunque los certificados tienen un período de validez, los mismos pueden ser revocados antes de su vencimiento. Esto puede ser a causa, de dejar de ser confiable, compromiso de seguridad del requirente o de la autoridad certificadora, cambio de condiciones, etc.

Aplicaciones para manejo de Certificados

A los efectos de poder pedir, otorgar e instalar certificados, debemos disponer de aplicaciones que permitan efectuar estas tareas.

Aplicaciones diseñadas para usar Certificados

El uso de encriptación y firma digital requiere que la aplicación esté diseñada especialmente para su uso. Por ejemplo, es fácil ver que podemos encriptar y firmar mensajes con Outlook, pero no lo podemos hacer con Word.

Funcionamiento de la Infraestructura de Clave Pública

Uno de los componentes fundamentales del esquema de clave pública es el certificado. El certificado es una forma fehaciente de verificar la correspondencia entre un nombre y su correspondiente clave pública. Aunque contiene muchos más datos, en primera instancia podemos decir que un certificado dice algo así como:

• Nombre: A
• Clave Pública de A

¿Cómo nos aseguramos que el certificado es válido? es decir que es verdad que esa clave pública corresponde realmente a A. Esto lo podemos verificar pues viene firmado digitalmente por la autoridad certificadora emisora.

¿Y cómo nos aseguramos que esa firma digital es válida? Lo podemos verificar mediante el conocimiento de la clave pública de la autoridad certificadora.

¿Y cómo obtenemos la clave pública de la autoridad certificadora? Obteniendo e instalando el certificado de la autoridad certificadora.

¿Y quien asegura que ese certificado es válido? Generalmente otra autoridad certificadora.

¿Y a esta autoridad certificadora? otra autoridad certificadora. Pero tenemos que ponerle un tope a esto. En última instancia existen autoridades certificadoras que se certifican a sí mismas. Es decir tienen un certificado otorgado a ellas y firmado por sí mismas. Son las llamadas autoridades certificadoras raíz.

Vamos a poner todos estos conocimientos en funcionamiento con un ejemplo de correo electrónico. Partimos que existen dos usuarios: A y B. Y una autoridad Certificadora CA.

La autoridad certificadora CA, es de tipo raíz y por lo tanto se otorga un certificado a sí misma.

El usuario A debe primero instalar el certificado de la CA. Esto es que va a confiar en todos los certificados otorgados por esta CA

Luego A solicita un certificado para sí mismo, cumpliendo con las condiciones que exige la CA para otorgar los certificados.

Suponiendo que la CA otorga su certificado procede a instalarlo.

El usuario B procede de la misma forma: instala el certificado de la CA, solicita un certificado para sí mismo, que es otorgado e instalado.

Hasta este momento tenemos tres certificados: el de la CA, el de A y el de B. Cada usuario tiene instalado el de la CA y el propio.

Si A envía un mensaje a B, firmado digitalmente, esto es encriptando el hash con su clave privada, debe enviarle también su clave pública. Y esto lo hace adjuntando su propio certificado (que contiene la clave pública).

Cuando B recibe el mensaje, obtiene del certificado la clave pública que le permite verificar la firma digital. Si B agrega a A a su lista de contactos además está instalando el certificado de A.

Luego B debe proceder igual que A, enviado un mensaje firmado digitalmente, con lo cual A procediendo en forma análoga, instala el certificado de B.

A partir que A y B poseen tanto su propio par de claves, como la pública del otro pueden intercambiar mensajes encriptados (y por supuesto también firmados)

Obtención de un certificado

Una de las formas más comunes de solicitud de certificados es a través de HTTP con el IIS de Windows 2000 e Internet Explorer, aunque también puede ser por Active Directory

El requirente, es quien genera su propio par de claves. La privada queda guardada localmente, y la pública es enviada cuando contacta a la CA para solicitar el certificado, proveyendo además toda la información requerida.

Luego del análisis de toda la información, y contando que la misma sea adecuada, la CA otorgará el certificado que quedará disponible.

El requirente debe contactar a la CA, para verificar el estado de su pedido, y en caso de ser otorgado, instalará su propio certificado. En este momento su clave privada es agregada a su perfil de usuario, y ya está en condiciones de utilizar ambas.

Contenido del Certificado

El contenido de un certificado en forma detallada está fuera del alcance de esta nota, pero veremos algunos de los datos importantes que contiene. Recordemos que el uso principal es verificar la correspondencia entre el nombre de a quien fue otorgado y su correspondiente clave pública.

Algunos de los campos que contiene son:

• Subject: a quien fue otorgado
• Subject Public Key: clave pública correspondiente
• Issuer: quien otorgó el certificado
• Serial: número de control de la autoridad certificadora
• Not Before: no válido antes de determinada fecha
• Not After: no válido después de determinada fecha
• Signed: firma digital de la autoridad certificadora.

Nota Final

Los conceptos de encriptación, firma digital e infraestructura de clave pública involucran temas complejos, desde la teoría matemática subyacente, pasando por la adecuada planificación y finalmente las dificultades de implementación. El propósito de esta nota ha sido efectuar una introducción a los conceptos fundamentales de funcionamiento. Para profundizar estos conocimientos hay disponible una amplia bibliografía, cursos generales de seguridad y capacitación específica sobre cada una de las plataformas disponibles.

La propuesta de esta nota es aclarar conceptos tan importantes como son: autenticación y autorización, las diferencias entre grupos de trabajo y dominio, que no son claras para todos, y cómo se producen los procesos de autenticación y autorización, en cada caso y para los diferentes tipos de dominio y clientes

Conceptos: Autenticación y Autorización

La diferencia entre estos dos conceptos es muy importante para tener en claro tanto desde el punto de vista seguridad, como para resolución de problemas y administración de la red.

Cuando iniciamos sesión en un equipo que forma parte de una red normalmente se ejecutan estos dos procesos en forma sucesiva automáticamente previo a que veamos la familiar apariencia de nuestro escritorio de Windows. Lo mismo ocurre cuando vamos a acceder a un recurso compartido de red. El hecho que se ejecuten en forma automática sucesivamente hace que pensemos que en realidad se trata de un solo proceso, pero en realidad son dos procesos sumamente diferentes.

La autenticación es el proceso con el que demostramos ser quienes decimos ser. Esto es, decimos ser determinado Usuario y lo demostramos introduciendo la contraseña del mismo. El sistema verificará que la contraseña sea la correcta, lo cual le probará que somos quien decimos ser pues “conocemos el secreto”

La mayoría de los sistemas de autenticación están basados en una técnica conocida como “Secreto-Compartido” y se explica de la siguiente forma: si sólo dos conocemos un secreto y yo soy uno, el que me demuestre que conoce el secreto tiene que ser el otro”. Llevado a términos de inicio de sesión: Si el Controlador de Dominio conoce la contraseña del usuario “Usuario1”, quien diga ser “Usuario1” y conozca la contraseña correspondiente, debe ser el usuario “Usuario1”.

Mediante esta técnica se produce el proceso de Autenticación, la verificación de identidad, que no es lo mismo que la autorización para acceder a un recurso. Debemos tener en cuenta que un equipo también es un recurso.

Durante el inicio de sesión interactiva, la autorización es el permiso de acceso a la máquina local; cuando se accede a un recurso compartido es el permiso de acceso al recurso.

A partir que se ha autenticado a la cuenta, comienza la segunda parte, verificar que el usuario tenga los privilegios necesarios para acceder al recurso y en la forma solicitada. Si inicia sesión, verifica si tiene el derecho de “Inicio de sesión interactivo”; y si intenta abrir un archivo, con acceso de lectura-escritura por ejemplo, si tiene los permisos necesarios.

Recién cuando el sistema ha verificado que la cuenta está Autorizada para hacer lo que intenta, le da acceso.

Cuando iniciamos sesión, verifica identidad (Autenticación), luego controla si tenemos derecho de inicio de sesión interactivo (Autorización), y finalmente arma el escritorio de Windows.

Cuando nos conectamos a un recurso remoto, también verifica la identidad primero (Autentica), y luego controla si tenemos los permisos requeridos para acceder al recurso. La diferencia con el caso anterior es que estos procesos los ejecuta el equipo remoto al que estamos intentando acceder.

Es fácil ver que son dos procesos distintos: podemos verificar la identidad (Usuario-Contraseña) correcta, pero no estar autorizados para ejecutar determinada acción. Iniciamos sesión, pero recibimos acceso denegado sobre una carpeta por ejemplo.

Grupo de Trabajo y Dominio ¿quién cumple qué funciones?

Desarrollaremos primero las importantes diferencias entre grupo de trabajo (Workgroup) y dominio, ya que tanto la autenticación como la autorización se desarrollan de formas diferentes en cada caso.

Grupo de Trabajo

En un grupo de trabajo toda la seguridad se maneja localmente en cada equipo. Cada máquina tiene localmente su lista de usuarios autorizados con las contraseñas correspondientes. Es decir, tanto la autenticación como la autorización se ejecutan localmente en cada máquina.

Debemos tener en cuenta que el equipo en sí mismo también es un recurso de red. Cuando iniciamos sesión nos Autentica y nos Autoriza a utilizarlo. Luego cuando vamos a acceder a un recurso local, como ya estamos autenticados, solamente verifica si estamos autorizados para acceder al mencionado recurso.

En cambio cuando vamos a acceder a un recurso remoto, este equipo remoto debe previamente autenticarnos para poder evaluar si estamos autorizados a acceder al recurso compartido.

Las soluciones en un grupo de trabajo son dos: duplicar la cuenta de usuario en ambos equipos, o elegir conectarse como otro usuario, especificando un Usuario-Contraseña válidos en el equipo remoto. Es recomendable la segunda.

El esquema de grupo de trabajo tiene ventajas: no se necesitan “servers” que en general son mucho más caros y la administración es relativamente sencilla. Pero también surgen inconvenientes: cuando aumenta el número de equipos se incrementa la tarea de administración ya que cada cambio hay que efectuarlo en todos y cada uno de los equipos. Además no se puede manejar en forma centralizada, ya que por definición de grupo de trabajo cada equipo es “independiente”. Cuando aumenta el número de máquinas o cuando se requiere administración centralizada o cuando la seguridad pasa a ser un tema importante, la solución es un ambiente de dominio.

Dominio

En un ambiente de dominio, hay uno o más “servers” que cumplen la función de Controladores de Dominio, una de cuyas funciones principales es Autenticar.

Vamos a ver primero el proceso con clientes Windows NT, Windows 2000 y Windows XP, ya que con Windows 9x el proceso es distinto. Algo que habrán notado seguramente, es que con estos sistemas operativos como clientes, hay que crear una cuenta de máquina en el dominio, inclusive con los servidores miembros. El equipo tiene cuenta en el dominio, se autentica durante el proceso de inicio, a partir de lo cual se arma un canal seguro de comunicación que servirá para el transporte de las credenciales de autenticación de los usuarios que accedan a los recursos del mismo. Si observamos el tráfico de red generado en el arranque de una máquina, veremos que sucede un proceso de autenticación muy similar al de un usuario. En lenguaje humano diríamos que luego de la autenticación del equipo, sucede un diálogo similar a “¿Puedo enviar a autenticar usuarios del dominio?” seguido por “Si mandámelos a mí, que yo verifico autenticidad”

A partir de esto cuando un equipo necesita autenticar usuarios del dominio envía las credenciales suministradas por el usuario al controlador de dominio quien verifica la autenticidad de las mismas y devuelve una confirmación de la autenticación e información adicional tal como pertenencia a grupos del dominio y derechos específicos del dominio.

Cuando esta información es recibida por el cliente se construye localmente una credencial de autenticación (Access Token) donde consta quién es, a qué grupos pertenece y los derechos que tiene. Esta credencial es usada localmente para el proceso de Autorización previo al acceso a recursos.

Cuando este usuario que ya inició sesión (ya fue autorizado al inicio de sesión interactivo local) se va a conectar a un recurso remoto tiene que probar su identidad. Dependiendo del tipo de autenticación que se utilice (NTLM o Kerberos) este proceso es diferente.

Si se está usando un dominio NT4, el cliente reenvía las credenciales del usuario (Usuario-Contraseña) al server remoto, quien repite el proceso de Autenticación ante el controlador de dominio seguido de la Autorización local. Bien, a decir verdad, no se envía la contraseña sino que se produce un mecanismo llamado Challenge-Response donde se prueba que conoce la contraseña sin necesidad de enviarla. Hay que recalcar que el server remoto es quien con la información enviada desde el cliente, contacta al controlador de dominio para que haga la autenticación, a partir de lo cual el propio server autoriza o no la conexión. Este proceso de autenticación se produce una sola vez por cada server, no importando a cuántos recursos del mismo se conecte el usuario, y dura hasta terminar la sesión (aprox. 15 minutos después de desconectarse o inmediatamente forzando desde el server). Es decir hay una sola sesión entre un determinado cliente y un server, no se puede conectar a un server en forma simultánea con dos cuentas diferentes.

En caso de dominio Windows 2000, el método de autenticación es Kerberos y la diferencia fundamental es que es el propio cliente quien recurre al servicio de Kerberos para obtener una pieza de información (Ticket) que será presentada al server remoto. Con esta información (Ticket) el server puede verificar la autenticidad del usuario sin contactar a un controlador de dominio. Vale lo mismo que en el caso anterior: no se puede tener simultáneamente dos sesiones con diferente usuario entre los mismos cliente-server.

Si los clientes son Windows 9x o Windows ME, no tienen cuenta de máquina en el dominio. El tema es que estos sistemas operativos no manejan autenticación a nivel de usuario, por lo que lo único que se les configura es a quién le envían la información para que haga la autenticación; esto puede ser a un dominio o simplemente a otro equipo que pueda autenticar usuarios (Windows 2000 Professional o XP por ejemplo). Localmente no existe, salvo una excepción, el proceso de autorización ya que estando los recursos locales sobre FAT no se maneja seguridad a nivel de usuario. La excepción es si hay carpetas o impresoras compartidas que fueron configuradas con seguridad a nivel de usuario. Vale siempre lo mismo que en los casos anteriores: no se puede tener simultáneamente dos sesiones con diferente usuario entre los mismos cliente-server.

Resumiendo

En un grupo de trabajo la autenticación y autorización se produce y se administra localmente en cada equipo. En un ambiente de domino, la autenticación la hace un controlador de dominio, en el server que tiene el recurso se produce sólo la autorización.

Muchas veces he visto en foros y listas preguntas que no aclaran si están en dominio o grupo de trabajo, que no especifican el tipo de dominio (NT4 o W2k y posteriores), o ni siquiera el tipo de cliente. Esto hace que sea imposible responder muchas de las preguntas. O inclusive es común ver errores conceptuales importantes como que estando en un ambiente de dominio se habla de “el logon al server…” ¿a qué llama logon? ¿autenticación o autorización? ¿pide o rechaza Usuario-Contraseña? ¿niega el acceso?

Es importante tener en cuenta que aunque puedo haber iniciado sesión en un equipo con un usuario, puedo tener varias conexiones simultáneas con diferentes equipos remotos, usando una cuenta de usuario diferente para cada uno de ellos. Lo que no se puede hacer son dos sesiones simultáneas con el mismo equipo y distinta cuenta, o lo que algunos han querido hacer que es iniciar sesión simultáneamente en dos dominios diferentes. La solución a todo esto se llama Relaciones de Confianza entre Dominios que seguramente trataremos en otra nota

Primero vamos a definir exactamente qué significa esta expresión “Resolución de Nombres”. Cuando tenemos un grupo de PCs conectadas en red es porque deseamos compartir recursos. Esto es, desde un equipo poder acceder a los recursos que tenemos en otro. Esto se hace a través del correspondiente cableado que interconecta las placas de red que tenemos instaladas en los equipos, donde lo único que se transmiten son señales eléctricas.

Esto viene a que hay diferentes niveles a los que podemos mirar nuestra red. A los humanos nos resulta mucho más fácil referirnos a los equipos por el nombre que le hallamos asignado, pero este nombre debe ser resuelto en los niveles más bajos de forma de alcanzar el equipo destino. Por ejemplo: si en el browser escribimos http://support.microsoft.com o hacemos un acceso directo a \\server\compartida estamos usando nombres de máquina de alto nivel, pero esto hay que resolverlo primero a una dirección de equipo que entienda el protocolo de red que estemos utilizando (TCP/IP, IPX/SPX, AppleTalk, etc.). Y todavía falta algo más, esta dirección usada por el protocolo se deber resolver a una dirección única que tiene cada placa de red (MAC Address = Media Access Control Address).

En esta nota acotaré el problema a la resolución de nombres de equipo a la dirección de protocolo de red TCP/IP, en el caso de tráfico tipo unicast.

Vamos aclarando, existen tres tipos de tráfico en una red IPv4:

• Broadcast: desde uno a todos los demás equipos
• Multicast: desde uno a un grupo de equipos, no a todos, sino a los que se suscribieron a un determinado grupo de multicast
• Unicast: desde un equipo a otro (1 a 1)

En una red con medio compartido como en el caso más común de Ethernet, aunque el tráfico esté dirigido a un equipo en particular, todos los que estén en el mismo medio “escuchan” la transmisión. Sólo el equipo destino toma la información, los demás la descartan al ver que no está dirigido a ellos.

Entonces estamos ya acotados a una red con protocolo de red TCP/IP v4 y veremos cómo a partir de un nombre de máquina se puede obtener (resolver) la dirección IP correspondiente para poder direccionar la información a nivel de protocolo de red.

Nombres NetBIOS y Hostnames

A todos los Windows cuando se los instala en red hay que asignarle un nombre de equipo. Previo a Windows 2000 este nombre corresponde a lo que se conoce como Nombre NetBIOS del equipo y es utilizado para la comunicación entre los mismos. Aunque la longitud máxima es de 16 caracteres, el sistema permite usar sólo 15 porque el último es utilizado para funciones reservadas al sistema.

Cuando tenemos instalado TCP/IP, en las propiedades del mismo se puede ver que existe también un campo llamado Hostname. Es también un nombre de equipo y por omisión es igual al nombre NetBIOS, y conviene que así sea. Pero este Hostname podría ser diferente y tiene características sintácticas muy distintas: puede tener hasta 63 caracteres y sólo están permitidos letras, números y el signo menos (-); a diferencia del nombre NetBIOS que permite la utilización de algunos símbolos.

A partir de Windows 2000, el nombre que colocamos al equipo es el Hostname, no el nombre NetBIOS. Este último es igual al hostname y a diferencia de los casos anteriores no se puede hacer diferente. Windows 2000 y posteriores siguen utilizando el nombre NetBIOS por compatibilidad con los anteriores sistemas operativos y aplicaciones basadas en NetBIOS.

Cuando se utiliza cada uno

Una de las preguntas más frecuentes es ¿cuándo se utiliza el Hostname y cuándo el nombre NetBIOS? Esto depende de la aplicación o sintaxis que usemos, pero en general podemos decir que siempre que utilicemos \\server, el sistema interpreta que “server” es el nombre NetBIOS del equipo; y siempre que utilicemos utilitarios de TCP/IP (ftp, telnet, ping, etc.), por ejemplo “ping host” el sistema interpreta que “host” es el hostname.

Para qué toda esta disquisición, porque existen diferentes métodos para resolver nombres NetBIOS y Hostnames. Una de las ventajas de la implementación que hace Microsoft es que si el sistema tiene que resolver un nombre NetBIOS, primero prueba por los métodos específicos, pero si no pudiera, trata por los métodos de resolución de hostname. Si ambos son iguales, que es el valor por omisión, tiene más chances. Y la inversa también es verdad, si no puede resolver un hostname por los métodos propios trata de resolver con los métodos de NetBIOS.

Esto tiene una ventaja y un inconveniente. La ventaja: si no implementamos adecuadamente el sistema de resolución de nombres, igual funciona. La desventaja: ¿por qué demora tanto? porque está probando con varios métodos hasta encontrar uno que haga la resolución. Todo esto funciona si Nombre NetBIOS es igual a Hostname.

Un error muy común es confundir la resolución de nombres con el servicio de Browser (Examinador) que arma el Entorno de Red donde puedo observar los equipos que comparten recursos. Son dos cosas totalmente diferentes e independientes. Puede resolverse el nombre correctamente y sin embargo no ver el equipo en el Entorno de Red; o ver el equipo en el entorno de red y no poder resolver la dirección de red. Por eso cuando queremos ver si podemos acceder a un equipo la mejor forma es tratar de accederlo desde Inicio\Ejecutar (Start\Run) y \\nombre o con el comando “ping nombre”. Tener en cuenta que el comando ping admite dos sintaxis: “ping hostname” y “ping dir_IP”. Si es de interés en una nota posterior veremos el servicio de Browser.

Métodos de Resolución de Nombres NetBIOS

Los Windows utilizan los métodos de resolución normalizados y uno propio de Microsoft.

Los métodos normalizados son:

• NetBIOS Name Cache
  Si en algún momento se resuelve una dirección, permanece durante un cierto tiempo el mapeo en memoria
• Broadcast
  Se envía información en la red, dirigida a todas los equipos, que contiene algo así como “¿Qué dirección IP tiene el equipo que se llama Server?” Todos los equipos lo escuchan, pero contesta sólo el que se llama Server, informando su dirección IP
• NBNS (NetBIOS Name Server). Microsoft lo implementa como WINS (Windows Internet Name Server)
  Un server con el servicio WINS instalado y los clientes configurados para usarlo. Para explicarlo en forma sencilla: cuando los clientes inicializan registran con el servidor WINS su nombre y su dirección IP. Con esta información el server construye una base de datos dinámica que incluye todos los clientes que se registraron. Luego cuando los clientes tienen que resolver una dirección IP le preguntan al servidor WINS que si puede responde adecuadamente.

Microsoft implementa un método propio que es una adaptación del método del archivo Hosts de Hostnames:

• Archivo LMHOSTS
  Es un archivo de texto, donde cada renglón corresponde a un registro e incluye la dirección IP seguida de por lo menos un espacio y el Nombre NetBIOS correspondiente. Este archivo debe estar disponible y mantenerse individualmente en cada PC.

Seguramente lo que todos están esperando es ¿en qué orden los utiliza? Para eso debo explicar un parámetro adicional de TCP/IP que controla parte del orden: Tipo de Nodo. Este parámetro está en el Registro (Registry) y normalmente el sistema se ocupa de mantenerlo, aunque en algunos casos haya que modificarlo manualmente.

Tipo de Nodo

Este parámetro puede tener cuatro valores que identifican cada uno de los tipos de nodo y afectan la utilización de Broadcast y/o WINS:

• B = Broadcast
  Cuando tiene que resolver nombres usa Broadcast, no WINS
• P = Peer
  Cuando tiene que resolver nombres usa WINS, no Broadcast
• H = Hybrid
  Cuando tiene que resolver nombres utiliza primero WINS. Si no resuelve prueba Broadcast
• M = Mixed
  Cuando tiene que resolver nombres utiliza primero Broadcast. Si no resuelve prueba WINS

Si el equipo no tiene configurado servidor WINS utiliza nodo tipo B por omisión. Al asignarle manualmente la dirección de un servidor WINS, cambia automáticamente a tipo H. Si la dirección del servidor de WINS la obtiene por DHCP, el servidor DHCP debe cambiarle el tipo de nodo. En algunos casos puede ser necesario configurarlo a mano, por ejemplo cuando queremos que sea tipo M o P, y no lo hacemos a través de DHCP.

Orden de resolución de Nombres NetBIOS

Suponiendo un cliente configurado con dirección de servidor WINS y nodo tipo H, que es el más común, cuando tiene que resolver un nombre NetBIOS utiliza el siguiente orden:

1. NetBIOS Cache
2. Servidor WINS
3. Broadcast
4. Archivo LMHOSTS
5. Si con ninguno de los anteriores pudo resolver, y va a probar con los métodos de resolución de Hostnames

Métodos de Resolución de Hostnames

Los métodos de resolución de Hostnames están normalizados y son:

• Archivo Hosts
  Similar al archivo LMHOSTS visto antes, sólo que en este caso se incluyen los hostnames en lugar de los nombres NetBIOS
• DNS (Domain Name Server)
  Un server con el servicio de DNS instalado y configurado. La construcción de la base con los registros puede ser hecha manualmente o en forma dinámica, de acuerdo a la versión utilizada. Windows 2000 utiliza protocolo DDNS (Dynamic DNS) y los clientes Windows 2000 se registran automáticamente. Windows NT 4.0 no soporta DNS dinámico, ni como cliente ni como servidor. La solución pasa por dos métodos: el primero consiste en dar manualmente de alta estos registros en el servidor DNS, la segunda es utilizar para estos clientes un DHCP server Windows 2000, y configurarlo para que cuando asigne direcciones IP, también haga la registración en el servidor DNS de las mismas
• Hostname Cache
  A partir de Windows 2000, cuando resuelven un nombre a una dirección IP, esta información permanece almacenada en memoria durante un tiempo

Orden de resolución de Hostnames

Suponiendo un cliente Windows 2000 con dirección de servidor DNS configurado. Si no fuera Windows 2000 o posterior el cache no está disponible. Cuando tiene que resolver un Hostname usa el siguiente orden:

1. Hostname Cache
2. Archivo Hosts
3. Servidor DNS
4. Si con ninguno de los anteriores pudo resolver, y está configurado, va a probar por los métodos de resolución de nombres NetBIOS

NOTA: A partir de Windows 2003, el archivo Hosts está siempre contenido en el Hostname Cache

Optimización

Cuando vemos que el tiempo para acceder a un determinado equipo es muy lento, pero luego el servicio se presta normalmente, lo más probable es que estemos ante un problema de resolución de nombres. Debemos asegurarnos que el tipo de resolución que requiera el acceso esté entre los primeros en probar, y no que utilice primero otros que no resultarán.

Microsoft ha ido, en las últimas versiones, haciendo mejoras en los algoritmos de resolución. Por ejemplo: si el nombre comienza con “\\” se supone que lo que sigue es un nombre NetBIOS, pero si este es de más de 15 caracteres y/o contiene puntos “.” se da cuenta que no es nombre NetBIOS y prueba directamente por los métodos de Hostnames. Si incluye puntos estamos ante un FQDN (Fully Qualified Domain Name) en el cual la primera parte corresponde al Hostname o a un Alias: “host.dominio.com” por ejemplo.
En algunos casos se da también que inicia el segundo método sin esperar respuesta del primero. Es interesante, para el que quiera hilar fino, hacer pruebas utilizando un analizador de protocolo (Sniffer)

Resumiendo

Existen en una instalación Windows con TCP/IP dos nombres de equipo: el nombre NetBIOS y el Hostname. Dependiendo la aplicación o el comando que utilicemos se usa uno u otro. El sistema debería poder resolver ambos, aunque hay algunos requerimientos:

• En ambiente de dominio NT4, es requerido resolver nombres NetBIOS. Es opcional la resolución de Hostnames, salvo que los necesite alguna aplicación.
• En ambiente de dominio Windows 2000 o posterior puro, es requerido resolver Hostnames y FQDNs. Es opcional la resolución de nombres NetBIOS, salvo que sea utilizado por aplicaciones
• En un ambiente de dominio Windows 2000 con clientes Pre-Windows 2000 se deben resolver ambos tipos de nombres, ya que los Controladores de Dominio y clientes Windows 2000 se encuentran a través de Hostnames, mientras que los Pre-Windows 2000 lo hacen a través de nombres NetBIOS.

Es muy recomendable, sobre todo para los "nuevos administradores" tener un dominio paralelo al productivo, a fin de poder probar configuraciones en ambiente de laboratorio antes de implementar en la realidad.

Hay varios elementos a considerar, pero lo principal es Hardware, Software y Active Directory.

Por el tema hardware, hay dos grandes posibilidades:

1. Tener el hardware necesario para cada equipo que necesitemos en laboratorio
2. Disponer de un equipo lo con suficientes recursos como para poder virtualizar el entorno necesario

En general, es mucho mejor la segunda opción ya que cuaquiera sea la aplicación de virtualización utilizada podremos fácilmente deshacer los cambios que no funcionan como queremos.

Hay productos gratis y de pago para todos los gustos. En el caso de Microsoft se dispone gratuitamente de VirtualPC y Virtual Server 2005 R2 y la nueva opción Hyper-V incluida en algunas versiones de Windows Server 2008.

Además hay otros productos también con opciones gratis y pagas. Para nombrar sólo una de ellas que en mi caso es muy importante vean VMware

Con las opciones de Microsoft, disponemos de "Undo disks" que nos permiten deshacer cambios y volver al estado inicial. Con VMware Workstation, podemos congelar diferentes estados (Snapshots) para luego volver a cada uno de ellos.

Voy a suponer que la mayoría (si yo lo hago así entonces todo los hacen así ) que vamos a utilizar un ambiente de pruebas virtualizado.

En mi caso, en este momento dispongo de un equipo "más o menos poderoso" con QuadCore 2.4 y 4GB RAM, pero también he hecho mucha de mi experiencia con un PIV 2.8 y 1GB RAM sin grandes problemas y un poco de paciencia.

Por la importancia que en mi trabajo diario tiene la virtualización uso más de un producto, tanto ambos de Microsoft, como VMware Workstation, dado que este último pude emular ambientes WAN de poca o mala conectividad.
Desarrollaré el tema con el producto de VMware y Snapshots, pero es fácilmente implementable también en los productos de Microsoft usando "Discos Diferenciales".

Primero que nada, si queremos ahorrarnos muuuuuuuucho tiempo, nos conviene tener "máquinas virtuales plantilla". De cada versión de sistema operativo que usemos crearnos una instalación básica, la configuramos como mejor nos parezca, pero MUY IMPORTANTE: le copiamos la utilidad Sysprep correspondiente a dicho sistema operativo, o en mi caso uso NewSID de las utilidades de Sysinternals (Ver Applicaciones Buenas, Baratas y Gratis). Copio a disco y hago un acceso directo sobre el escritorio. Recién entonces apago la máquina virtual.

Si es VirtualPC/Server será usada como Disco Master, si es VMware será una "Base" a partir de la cual haré los "Linked Clone".

A partir de esto, disponer de, por ejemplo, cinco instalaciones de Server 2003 puede llevar no más de 10 minutos. Simplemente se crean "Linked Clone", se arrancan, se configura la red, y se ejecuta NewSID para cambiar los identificadores únicos y en el mismo paso renombrarla. Vale el mismo proceso para otros sistemas operativos Windows.

Hasta ahora "solucionamos" el tema hardware y software, pero ¿cómo obtengo un dominio Active Directory de pruebas similar al productivo.

Tengo dos opciones en mente, la primera que realmente veo complicada sería instalar una virtual como Controlador de Dominio adicional al dominio, esperar que replique toda la info, luego aislarla en red virtual separada, cambiar DNS, tomar roles, GC, etc.. Y muy importante: borrar en el AD productivo este equipo con el NTDSUTIL. NO me gusta mucho "tocar" el ambiente productivo.

Si lo único que necesitamos son los usuarios, grupos y OUs entonces es mucho más fácil, ya que podemos usar LDIFDE.EXE para exportar todo a un archivo de texto y luego importarlo en nuestro AD de laboratorio

Vean estos enlaces

LDIFDE - Export / Import data from Active Directory:
http://support.microsoft.com/kb/555634/en-us

LDIFDE - Export / Import data from Active Directory - LDIFDE commands:
http://support.microsoft.com/kb/555636/en-us

LDIFDE - Export / Import data from Active Directory - LDIFDE commands 2 (AN: 555636):
http://support.microsoft.com/kb/555637/en-us

Bueno, ya podemos probar tranquilamente esas restricciones que nunca nos atrevimos, o esa GPO de la que siempre tuvimos dudas

Buenas

Baratas

WinPatrol

Controle el autoarranque, el Internet Explorer, las tareas programadas, los servicios, las cookies, los archivos ocultos y mucho más.

Hay versión gratis y de pago

WinPatrol

 

ImgBurn

Si necesita trabajar con ISOs y/o grabar CDs y DVDs. De lo mejorcito.

ImgBurn

  

nLite

Instalaciones personalizadas de XP y Server 2003. Graba o crea ISO personalizado con: integración de Service Packs, hotfixes, drivers, remoción de componentes personalización, tweaks y hasta inclusive instalaciones desatendidas.

nLite

Y como si fuera poco, también hay versión para Vista (vLite) aunque esta no la probé

vLite

 

TweakGDS

Google Desktop es un muy buen producto pero no ofrece casi personalización. Con TweakGDS se puede

TwekGDS

 

No te vayas a perder ninguna de estas