Category: Active Directory


La Sincronización de tiempo es un aspecto importante para todos los equipos de la red . De forma predeterminada , los equipos cliente obtienen su hora desde un controlador de dominio y el controlador de dominio obtiene su tiempo de operación de maestro PDC del dominio.  Una recomendacion es sincronizar el PDC con una fuente externa . Yo suelo usar los servidores que aparecen en el sitio web de Project Pool NTP. Recuerden que para que esto funciona es necesario  abrir el puerto 123 UDP por defecto ( entrada y salida) en el Firewall

  1. Saber cual es el PDC , correr el siguiente comando en un Domain controller:   netdom /query fsmo
  2. Logearse al Domain Controller que es PDC.
  3. Stopear el servicio   net stop w32time
  4. Configurar la fuente externa  w32tm /config /syncfromflags:manual /manualpeerlist:0.uk.pool.ntp.org,1.uk.pool.ntp.org /update /reliable:yes
  5. Configurar disponibilidad: w32tm /config /reliable:yes
  6. Prender el servicio nuevamente: net start w32time
  7. Chequear configuracion:  w32tm /query /configuration

En este post veremos como con un entorno de Windows 2008 R2, poder unir una computadora al dominio sin conexión. Es decir no es necesario que exista conectividad entre el equipo y el Domain Controller .  Esto es ideal, cuando por ejemplo instalamos computadoras que luego seran enviadas a otra sucursal, site….

Este procedimiento puede ser llevado a cabo entre equipos con: Windows 7 y Windows 2008 R2, para poder realizarlos con DC anteriores a Windows Server 2008 R2  debe usarce el siguiente parámetro : /downlevel

1- EN el DC, deberemos crear la cuenta, con el siguiente comando:

djoin /provision /domain <domain_name> /machine <destination computer> /savefile <filename.txt> [/machineou <OU name>] [/dcname <name of domain controller>] [/reuse] [/downlevel] [/defpwd] [/nosearch] [/printblob]

Luego debemos copiar el archivo TXT , generado en el paso anterior, al equipo con Windows 7.

Y por ultimo ejecutar en WIndows 7 el siguiente comando:

djoin /requestODJ /loadfile blob.txt /windowspath %SystemRoot% /localos

En este post veremos los aspectos y planeacion que hay que tener en cuenta para la Virtualizacion de Domain COntrollers.

Mas de 1 Domain Controller.

Se Debe intentar evitar la creación de posibles puntos únicos de falla al planear la implementación del controlador de dominio virtual, creando mas de un Domain Contoller:

  1. Ejecutar al menos dos controladores de dominio virtualizados por dominio en hosts de virtualización diferentes, lo que reduce el riesgo de perder todos los controladores de dominio, si un host de virtualización única falla.
  2. Recomendado para otras tecnologías, diversificar el hardware (utilizando diferentes procesadores, motherboards, adaptadores de red u otro hardware) en el que están ejecutando los controladores de dominio. Diversificación de hardware limita el daño que podría ser causado por un fallo que es específico para una configuración de proveedor, un controlador o una sola pieza o tipo de hardware.
  3. Si es posible, los controladores de dominio se deben ejecutar en el hardware que se encuentra en diferentes regiones del mundo. Esto ayuda a reducir el impacto de un desastre o falla que afecta a un sitio en el que están alojados los controladores de dominio.
  4. Mantener los controladores de dominio físico en cada uno de sus dominios. Esto reduce el riesgo de un fallo de la plataforma de virtualización que afecta a todos los sistemas de host que utilizan esa plataforma.

Consideraciones de seguridad

El equipo de host en el que se ejecutan los controladores de dominio virtual debe administrarse cuidadosamente como un controlador de dominio de escritura, incluso si ese equipo es sólo un equipo se unió el dominio o grupo de trabajo. Se trata de una consideración de seguridad importante. Un host mal administrado es vulnerable a un ataque de elevación de privilegios, que se produce cuando un usuario malintencionado obtiene acceso y privilegios del sistema que no fueron autorizados o legítimamente asignados. Un usuario malintencionado puede usar este tipo de ataque en peligro todas las máquinas virtuales, dominios y los bosques que los hosts de este equipo.

Asegúrese de tener las siguientes consideraciones de seguridad en cuenta cuando se planea virtualizar los controladores de dominio:

  • El administrador local del equipo que aloja el dominio virtual, se puede escribir controladores deben considerarse equivalentes en las credenciales del administrador de dominio predeterminado de todos los dominios y los bosques que pertenecen esos controladores de dominio.
  • La configuración recomendada para evitar problemas de seguridad y el rendimiento es un host que ejecuta una instalación Server Core de Windows Server 2008, con ninguna aplicación distinta de Hyper-V. Esta configuración limita el número de aplicaciones y servicios que están instalados en el servidor, que debe conducir a un mayor rendimiento y menos aplicaciones y servicios que podrían aprovecharse malintencionadamente para atacar el equipo o la red. El efecto de este tipo de configuración se conoce como una superficie de ataque reducida. En una sucursal o en otros lugares que no pueden ser garantizados satisfactoriamente, se recomienda un controlador de dominio de sólo lectura (RODC). Si existe una red de administración separada, recomendamos que el host se conecta sólo a la red de gestión.

Límites de seguridad

Uso de máquinas virtuales hace posible tener muchas configuraciones diferentes controladores de dominio. Debe prestarse especial atención a la forma en que las máquinas virtuales afectan a límites y confía en su topología de Active Directory. Configuraciones posibles para un controlador de dominio de Active Directory y el host (servidor de Hyper-V) y sus equipos invitados (máquinas virtuales que se ejecutan en el servidor de Hyper-V) se describen en la tabla siguiente.

Máquina Configuración 1 Configuración 2

Host

Grupo de trabajo o miembros de equipo

Grupo de trabajo o miembros de equipo

Invitado

Controlador de dominio

Grupo de trabajo o miembros de equipo

Domain Controllers running on Hyper-V server

  • El administrador en el equipo host tiene el mismo acceso como administrador de dominio en los huéspedes de controlador de dominio de escritura y debe ser tratado como tal. En el caso de un invitado RODC, el administrador del equipo host tiene el mismo acceso como administrador local en el huésped RODC.
  • Un controlador de dominio en una máquina virtual tiene derechos administrativos en el host, si el host está unido al mismo dominio. Hay una oportunidad para que un usuario malintencionado poner en peligro todas las máquinas virtuales, si el usuario malintencionado primero obtiene acceso a la máquina Virtual 1. Esto se conoce como un vector de ataque. Si hay controladores de dominio para varios dominios o bosques, estos dominios deben tener una administración centralizada en la que el administrador de un dominio es de confianza en todos los dominios.
  • La posibilidad de ataque de la máquina Virtual 1 existe incluso si está instalada la máquina Virtual 1 como un RODC. Aunque un administrador de un RODC explícitamente no tienen derechos de administrador de dominio, el RODC puede utilizarse para enviar las políticas para el equipo host. Estas políticas pueden incluir scripts de inicio. Si esta operación se realiza correctamente, el equipo host puede estar en peligro y, a continuación, puede utilizarse para poner en peligro las otras máquinas virtuales en el equipo host.

Seguridad de los archivos VHD

Un archivo VHD de un controlador de dominio virtual es equivalente a la unidad de disco duro física de un controlador de dominio físico. Como tal, debe ser protegido con la misma cantidad de atención que se dedica a proteger el disco duro de un controlador de dominio físico. Asegúrese de que sólo los administradores de confianza pueden acceder a los archivos VHD del controlador de dominio.

RODC

Una ventaja de RODC es la capacidad para colocar en lugares donde garantizar la seguridad física no puede ser, tal como en las sucursales. Puede utilizar el cifrado de unidad de Windows ® BitLocker ™ para proteger los archivos VHD (no los sistemas de archivos en él) de que se vea comprometida en el host a través del robo del disco físico. Para obtener más información acerca de BitLocker en Hyper-V, consulte Windows Server 2008 Hyper-V y el cifrado de unidad BitLocker (http://go.microsoft.com/fwlink/?LinkID = 123534).

Consideraciones de implementación de controladores de dominio virtualizado

Esta sección describe algunas cosas a tener en cuenta al implementar controladores de dominio en máquinas virtuales. Hay varias prácticas comunes de máquina virtual que se deben evitar al implementar controladores de dominio. También hay consideraciones especiales para el almacenamiento y sincronización de tiempo. Las siguientes secciones describen estas consideraciones.

Prácticas de implementación de virtualización para evitar

Plataformas de virtualización, como Hyper-V, ofrecen una serie de características de conveniencia que administrar, mantener, realizar copias de seguridad y migrar equipos más fácil. Sin embargo, hay algunas características que no deben utilizarse los controladores de dominio virtual y prácticas comunes de implementación. La lista siguiente describe las prácticas para evitar al implementar controladores de dominio:

  • No aplicar los diferenciación disco discos duros virtuales (VHD) en una máquina virtual que está configurando como un controlador de dominio. Esto es demasiado fácil revertir a una versión anterior, y también disminuye el rendimiento. Para obtener más información acerca de los tipos VHD
  • No clonar la instalación de un sistema operativo sin necesidad de utilizar Sysprep.exe porque no se actualizará el identificador de seguridad (SID) del equipo. (http://go.microsoft.com/fwlink/?LinkId = 137100).
  • Para ayudar a prevenir una potencial situación de deshacer actualización secuencia número (USN), no utilice copias de un archivo VHD que representa un controlador de dominio ya desplegados para implementar controladores de dominio adicionales. Los siguientes tres elementos en esta lista también se recomiendan evitar la potencial reversión de USN.  USN y USN Rollback.
  • No utilice la función Hyper-V exportar para exportar una máquina virtual que se ejecuta en un controlador de dominio.

Consideraciones operacionales para controladores de dominio virtualizado

Los controladores de dominio que se ejecutan en máquinas virtuales tienen restricciones operacionales que no se aplican a los controladores de dominio que se ejecutan en máquinas físicas. Cuando se utiliza un controlador de dominio virtualizados, hay algunas funciones de software de virtualización y prácticas que no se deben utilizar:

  • No pausar, detener, o almacenar el estado guardado de un controlador de dominio en una máquina virtual para períodos de tiempo más largos que el desecho del bosque y luego reanudar desde el estado guardado o en pausa. Haciendo esto puede interferir con la replicación. Para aprender cómo determinar el desecho del bosque, vea determinar el desecho del bosque (http://go.microsoft.com/fwlink/?LinkId = 137177).
  • No copiar o clonar discos duros virtuales (VHD).
  • No tomar o utilizar una instantánea de un controlador de dominio virtual.
  • No utilice un disco VHD de diferenciación en una máquina virtual que está configurada como controlador de dominio. Esto hace que revertir a una versión anterior demasiado fácil y también disminuye el rendimiento.
  • No utilice la función de exportación en una máquina virtual que se ejecuta en un controlador de dominio.
  • No restaurar un controlador de dominio o intentar revertir el contenido de una base de datos de Active Directory por cualquier medio distinto utilizando una copia de seguridad compatible. Para obtener más información, vea copia de seguridad y restaurar las consideraciones para virtualizar los controladores de dominio.

Backup y Restore consideraciones para controladores de dominio virtualizado

La copia de seguridad de controladores de dominio es un requisito fundamental para cualquier entorno. Copias de seguridad protegen contra pérdida de datos en caso de fallo del controlador de dominio o error administrativo. Si se produce este evento, es necesario revertir el estado del sistema del controlador de dominio a un punto en el tiempo antes de la falla o error. El método admitido de restaurar un controlador de dominio a un Estado saludable es utilizar una aplicación de backup de Directory–compatible activo, como Windows Server Backup, para restaurar una copia de seguridad de estado de sistema que se originó a partir de la instalación actual del controlador de dominio. ¿Para obtener más información acerca de cómo utilizar copia de seguridad de Windows Server con servicios de dominio de Active Directory (AD DS), consulte la Guía de paso a paso de recuperación y Backup de AD DS (http://go.microsoft.com/fwlink/?LinkId = 138501).

Con la tecnología de máquina virtual, ciertos requisitos de Active Directory restauración operaciones toma mayor importancia. Por ejemplo, si restaurar un controlador de dominio mediante una copia del archivo de disco duro virtual (VHD), omita el paso crítico de la actualización de la versión de base de datos de un controlador de dominio después de que ha sido restaurada. Replicación procederá con números de seguimiento inadecuado, resultando en una base de datos inconsistente entre réplicas de controlador de dominio. En la mayoría de los casos, este problema va sin ser detectados por el sistema de replicación y no se informa de ningún error, a pesar de las inconsistencias entre los controladores de dominio.

Hay una forma compatible para realizar backup y restore de un controlador de dominio virtualizados:

  1. Ejecutar copias de seguridad de Windows Server en el sistema operativo huésped.

Prácticas de backup y restore para evitar

Como se mencionó, los controladores de dominio que se ejecutan en máquinas virtuales tienen restricciones que no se aplican a los controladores de dominio que se ejecutan en máquinas físicas. Al volver arriba o restaurar un controlador de dominio virtual, existen ciertas funciones de software de virtualización y prácticas que no se deben utilizar:

  • No copiar o clonar archivos VHD de controladores de dominio en lugar de realizar copias de seguridad periódicas. Si el archivo VHD de él es copiado o clonado, quede obsoleto. Entonces, si el VHD se inicia en modo normal, podría ser una divergencia de datos de replicación en el bosque. Debe realizar las operaciones de backup adecuadas que son compatibles con los servicios de dominio de Active Directory (AD DS), como el uso de la función de copia de seguridad de Windows Server.
  • No utilice la función de instantánea como una copia de seguridad para restaurar una máquina virtual que se ha configurado como controlador de dominio. Problemas se producen con la replicación cuando se volver la máquina virtual a un estado anterior. Para obtener más información, vea USN y USN Rollback. Aunque usando una instantánea para restaurar un controlador de dominio de sólo lectura (RODC) no causará problemas de replicación, no todavía se recomienda este método de restauración.

Restauracion

Utilizar el proceso en la siguiente ilustración para determinar la mejor manera de restaurar el controlador de dominio virtualizado.

Writeable domain controller restoration in Hyper-V

Mas info: http://technet.microsoft.com/en-us/library/virtual_active_directory_domain_controller_virtualization_hyperv(WS.10).aspx#operational_considerations_for_virtualized_domain_controllers

Les dejo un buen POST de como solucionar bloqueos inesperados de cuentas

 

Curiosamente, un 99% de las veces he encontrado la respuesta para el bloqueo de cuentas  en un mismo documento.
Cuando uno se introduce en la lectura del mismo, puede darse cuenta de porque es que tanta información es ignorada: se trata de un documento con 42 páginas. A partir de esto surgió la idea de  escribir un documento que resumiera los pasos para resolver casos de bloqueos de cuentas en dominios con Windows 2000 y Windows Server 2003, sin que éste se convierta en un sustituto, sino más bien una guía rápida para resolver casos de bloqueos de cuentas complementada por el documento de Account Passwords and Policieshttp://technet.microsoft.com/en-us/library/cc783860(WS.10).aspx

 

¿Por qué 10 intentos y no 3?

Si bien el dilema más común es el de por qué se debe de configurar la política de bloqueos de cuentas a utilizar a 10 intentos con contraseña incorrecta, cuando por lo general las auditorias de seguridad recomiendan el uso de únicamente 3; en éste documento no entraremos en demasiado detalles y únicamente remarcaremos que la recomendación de Microsoft no termina en utilizar 10 intentos con contraseña incorrecta, sino que es parte de una serie de recomendaciones como la complejidad de la contraseña, la ventana de observación, la duración del bloqueo, etc. los cuales hacen que las probabilidades de descifrar la contraseña sean mínimas. Así mismo, recordemos que muchas aplicaciones pueden tomar más de 3 intentos con la contraseña que se los provee, lo cual propiciará que los bloqueos sean más comunes aumentando por lo tanto los costos de operación tanto del help desk como del usuario, debido al tiempo que le tomará al personal de help desk el estar desbloqueando cuentas y el que le tomará a los usuarios el esperar hasta que ésta sea desbloqueada. Para más detalles utilizar el documento de Account Passwords and Policies

 

EL ABC.

La metodología para detectar la causa de un bloqueo de cuentas es tan simple que se puede resumir en 3 pasos:

 

a.              Activar auditoria y logging.

b.             Detectar la máquina causando los intentos con contraseña incorrecta.

c.              Detectar el servicio, aplicación o configuración culpable.

 

a. Activar auditoria y logging.

            El primer paso para detectar la causa de un bloqueo de cuenta inesperado consiste simplemente en configurar los controladores de dominio para capturar información que nos pueda guiar a encontrar desde dónde vienen los intentos con contraseña incorrecta, cuando estos ocurran nuevamente.
Contamos con dos tipos disponibles:

1.      Auditoria

2.      Log de Netlogon.

 

1.      Auditoria.

La activación de auditoria consiste de:
1.1 Editar la política de Default Domain policy.

1.2 Dentro de la política ir a Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy.

1.3 Activar las siguientes opciones:

  • Account Logon Events – Failure
  • Account Management – Success
  • Logon Events – Failure

Debido a que esta información aparecerá en el log de seguridad de todos los controladores de dominio, se recomienda cambiar estos para que el tamaño sea cuando menos 10,000KB y con la opción de “Overwrite events as needed”.

 

2.      Log de Netlogon.

Este se activa de la siguiente forma::

2.1  Ejecutar en una ventana de comandos:
nltest /dbflag:2080ffff

2.2  Reiniciar el servicio de netlogon:
net stop netlogon & net start netlogon

El log se generará en Systemroot\Debug\Netlogon.log en cada controlador de dominio.
Cuando netlogon.log alcanza 20 MB se renombra a netlogon.bak y un nuevo netlogon.log se generará. El tamaño máximo puede ser modificado en el registry cambiando el valor MaximumLogFileSize:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\netlogon\Parameters

Value: MaximumLogFileSize

Value Type: REG_DWORD

Value Data: 0 min, 0xffffffff max

Value Data Default: DEFAULT_MAXIMUM_LOGFILE_SIZE (~20 MB)

 

 

b. Detectar la máquina causando los intentos con contraseña incorrecta.

Una vez que se ha activado auditoria y logging, el siguiente paso es detectar desde qué máquina están viniendo los intentos con contraseña incorrecta, la cual llamaremos lamáquina culpable.
Esto se realiza a través del análisis del log de Seguridad de todos los controladores de dominio y/o del log de Netlogon de los mismos.
Antes de comenzar el análisis, hay que escoger una cuenta que haya presentado el bloqueo para enfocar el análisis hacia ella. Una vez que se determine la causa del bloqueo se puede emplear la misma solución a las demás máquinas, si alguna presenta nuevamente el bloqueo; se realizará el mismo procedimiento esta vez escogiendo esta nueva cuenta.

 

Si bien los logs de Seguridad resultan ser más sencillos de analizar que los logs de Netlogon, cualquiera de los dos métodos es útil.

El log de seguridad se puede analizar con eventcombmt.exe y el de netlogon con nlparse.exe, ambas herramientas incluidas en los Account Lockout Tools. En el caso de que uno no contenga la información, se puede intentar buscar en el otro.


Logs de seguridad.

Cómo se mencionó anteriormente, podemos usar eventcombmt.exe con la opción de Searches\Built In Searches\Account lockouts para analizar los logs de Seguridad. Esta opción automáticamente selecciona todos los controladores de dominio del dominio y busca por los event IDs 529, 644, 675, 676, y 681, los cuales están relacionados con bloqueos de cuentas. El Event ID 644 muestra que la cuenta ha sido bloqueada y los demás muestran intentos con contraseña incorrecta. Delimitemos la búsqueda a solamente la cuenta escogida, escribiendo el nombre en la sección de Text. Eventcombmt hará la búsqueda y creará un log por cada controlador de dominio que se haya revisado y que contenga eventos que cumplan con el criterio especificado. Estos eventos nos indicarán cuál es la máquina que está causando los intentos con contraseña incorrecta. Por lo general los intentos causados por un programa, script o servicio pueden ser identificados por presentar varios intentos dentro del mismo segundo. Un bloqueo causado por un usuario se verá separado por varios segundos.
Es importante entender que cada intento con contraseña incorrecta es verificado una vez por el controlador de dominio que recibió la solicitud y una vez más por el controlador de dominio con el rol de PDC Emulator, por lo que si el que log que estamos revisando es el del PDC Emulator y el intento refleja que el causante fue otro controlador de dominio, tendremos que verificar los logs de éste otro controlador de dominio a la misma hora. Si los eventos en éste controlador de dominio reflejan que el causante es otra máquina entonces habremos encontrado la máquina culpable.

 

Logs de Netlogon.

Para analizar los logs de Netlogon, hay que recolectar los logs de todos los controladores de dominio y después analizarlos con NLParse.exe o con findstr.
Cuando se utilice NLParse.exe seleccione las opciones 0xC000006A (intento con contraseña incorrecta y 0xC0000234 (Cuenta bloqueada) y después haga clic en Extract. En el resultado final hay que identificar aquellos intentos que sean con la cuenta que escogimos y detectar la máquina desde la cuál viene el intento.
Para analizar varios logs a la vez se puede utilizar findstr.exe, el cual viene incluido con Windows 2000, Windows XP y Windows Server 2003. Posteriormente hay que renombrar los logs de netlogon, ponerlos en un solo directorio y correr el siguiente comando:

FindStr /I User1 *netlogon*.log >c:\user1.txt

 

De los logs resultantes hay que analizar cuál es la máquina desde la cual provienen la mayoría de los intentos con contraseña incorrecta. La máquina culpable será la que presente un intento que no diga “via”, si dice que el logon fue “via” computername, entonces hay que analizar el netlogon.log de computername.

Si la máquina que dice “via” no es un controlador de dominio verifique que tipo de servicios provee, para que sepa que analizar en la máquina cliente. Por ejemplo, si se trata de un servidor de Exchange, entonces hay que analizar el Outlook de la máquina cliente.

 

c. Detectar el servicio, aplicación o configuración culpable.

Una vez que detectemos desde qué máquina vienen los intentos el siguiente paso es activar logging en la máquina culpable y esperar a que vuelvan a ocurrir intentos con contraseña incorrecta con la cuenta del usuario y desde esta máquina.

Dependiendo del tipo de máquina es el tipo de logging:

  • Estación de trabajo con Windows 2000 o Windows XP

o        Alockout.txt
– Registrar alockout.dll de los Account Lockout Tools:

1.      Copiar la versión correcta de alockout.dll a %systemroot%\System32

2.      Hacer doble clic al archivo appinit.reg

3.      Reiniciar la computadora.

Esto generará un archivo %systemroot%\Debug\alockout.txt

 

o        Logging de eventos de Kerberos.

o        Para activar  Logging de eventos de Kerberos en los clientes

3.1 Agregar el siguiente valor del registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

      • Registry value: LogLevel
      • Value type: REG_DWORD
      • Value data: 0x1

Nota: Si la llave de Parameters no existe; hay que crearla.

3.2 Reiniciar la computadora.

Para automatizar el proceso se puede usar EnableKerbLog.vbs el cual viene en los Account Lockout Tools.

o        Dejar capturando un Network trace con Network Monitor con un buffer amplio y detenerlo inmediatamente después de que se bloquee la cuenta.

Esto puede ser desde:

    • Una máquina dedicada. (Recomendado). Conectar una máquina dedicada a un puerto de un hub en el cual la máquina culpable se encuentra conectada o a un puerto del switch haciendo mirroring del puerto de la máquina culpable. Para más información ver el siguiente documento:

244209          How to Perform Network Tracing in a Switched Environment

http://support.microsoft.com/default.aspx?scid=kb;EN-US;244209

    • En el controlador de dominio del site que validó a la máquina (en el caso de que haya sólo un controlador de dominio en ese site),
    • En la misma máquina culpable. Sólo útil en el caso de que los intentos no ocurran al momento de logon.

Para más información de cómo capturar tráfico con Network Monitor:

812953     How to use Network Monitor to capture network traffic

http://support.microsoft.com/default.aspx?scid=kb;EN-US;812953

 

  • Servidor

o        Logging de eventos de Kerberos. Ver sección anterior.

Dejar capturando un Network trace utilizando los pasos listados anteriormente.

 

Cuando ocurra nuevamente el problema y se tenga todo el logging activado el proceso para detectar el servicio culpable es el siguiente:

  1. Encontrar en los eventos de seguridad o en los logs de netlogon la hora y fecha en que ocurrieron los intentos con contraseña incorrecta desde la máquina en donde se activó el alockout.txt, el kerberos logging y/o el network trace.
  2. Analizar el alockout.txt, el log de sistema por los eventos de kerberos y/o el network trace, buscando por eventos o paquetes correspondientes a la misma hora y fecha en que ocurrió el bloqueo. Estos deberían de proveernos con algún rastro del servicio causando el problema.
  3. Una alternativa en caso de que los logs no provean suficiente información es buscar por lo obvio en la máquina cliente culpable. Revisar lo recomendado en la sección de Common Causes for Account Lockouts del documento Account Passwords and Policies

Windows Server 2008 R2–Administración de Sites 

Dentro del Active directory, un Sitio define los límites de replicación interna y externa, ademas  ayuda a los usuarios a localizar el pool de servidores más cercanos para autentificarse y tener acceso a los recursos de red. También puede servir como límite administrativo, como delegar autoridad a un administrador local de su sitio AD.

Sitios

Un Sitio se compone de un nombre de sitio; subredes dentro del sitio; enlaces y puentes a otros sitios; políticas basadas en el sitio; y, claro está, los servidores, estaciones de trabajo y servicios proporcionados dentro de ese Sitio. Algunos de sus componentes, como servidores y estaciones, se configuran dinámicamente en el sitio basándose en su configuración de red. Los servicios de DC y las ubicaciones DFS también se localizan dentro de los sitios mediante la configuración de red del servidor en el que se ubican los recursos.

Los sitios de AD se pueden configurar para coincidir con una o varias ubicaciones que dispongan de conectividad de banda-ancha entre ellas. Éstas pueden optimizarse para la replicación y requiera poco ancho de banda. Después de definir un Sitio, los servidores y los equipos cliente usan la información almacenada en la configuración del sitio para localizar los más cercanos DC, Catálogos globales y los DFS. La configuración de un sitio puede ser una simple tarea, pero si la topología del sitio no está bien definida, la velocidad de acceso de la red puede sufrir ya que los servidores y usuarios pueden conectarse a los recursos mediante la WAN en lugar de usar los recursos locales. En la mayoría de las ocasiones definir y levantar un sitio tomará unas pocas horas. Después de dicha configuración, los sitios raramente necesitaran ser modificados, a no ser que se hayan hecho cambios en el direccionamiento de red, se hayan añadido o quitado DCs, se definan nuevos sitios o se quiten algunos antiguos.

Subredes

Las subredes marcan la frontera de un sitio y limitan el tráfico WAN permitiendo a los clientes encontrar servicios locales antes de buscar a través de un enlace WAN. Muchos administradores no definen subredes para  ubicaciones que no disponen de servidores locales, en su lugar, ellos relacionan las subredes del site sólo para la replicación de controlador de dominio de AD.

Si un usuario de una estación de trabajo de una subred no se encuentra definido dentro de AD, la estación de trabajo tomará aleatoriamente otro controlador de dominio. Este DC puede que sea uno de los que hay en su misma ubicación física o puede que sea cualquier otro accesible mediante los enlaces WAN. El usuario de la estación podrá autenticarse y descargar las políticas o ejecutar servicios desd un DC que no está conectado directamente a la LAN. Esto crea un tráfico innecesario y tiempos de respuesta inaceptables.

Al analizar la infraestructura de AD, podría parecer que las sucursales sin DC pueden simplemente agruparse con el Site de la central con añadir las subredes de la sucursal al Site principal. Esto ahorraría mucho tiempo de configuración necesario para crear estos Sites de sucursal.

Esto es algo obtuso o de vista corta, y que afectará al comportamiento de otras aplicaciones compatibles con AD. Así pues, es importante definir completamente la arquitectura de Sites en AD, incluyendo las subredes para reflejar la arquitectura WAN de la organización.

Todas las subredes deben definirse en Sites y Services de AD para asegurarse que el DC más próximo es el asignado a las estaciones de trabajo. Y todas las ubicaciones deben tener su propio Site y subred definidos, incluso si no hay DC actualmente en el lugar. Esto asegura que los recursos están localizados correctamente por AD y no sólo por los servicios de dominio, sino también por otros servicios.

Vínculos de Site

Los vínculos controlan la replicación de AD y conectan Sites individuales directamente entre ellos. Un vínculo de Sitio se configura para un tipo de protocolo en particular (a saber, IP o SMTP) y la frecuencia y la agenda de la replicación se configura dentro de éste vínculo. Los vínculos de sitio se utilizan por Active Directory Knowledge Consistency (KCC) para realizar las conexiones y asegurarse que la replicación tiene lugar de la manera más eficiente.

Una vez más, algunos administradores no definen completamente la arquitectura de Sites y no los crean para ubicaciones en las que no hay DC. El razonamiento es que los Sites los utiliza AD para la replicación y las ubicaciones a las que le falta DC no necesitan definir Site.

Al igual que con el diseño de subredes, esto también es de vista corta…  Los vínculos de Site también se usan por las aplicaciones compatibles con AD para entender la topología física y optimizar las comunicaciones WAN.

Así pues, sirva de repetición, es importante definir completamente la arquitectura de sitios de AD, incluyendo tanto las subredes como los vínculos de sitio para reflejar la arquitectura WAN de la organización.

Ejemplos de vínculos de Site incluyen un vínculo por lada enlace WAN, como el de la oficina principal a cada una de las sucursales.

Directivas de grupo de Site

Las directivas de Site permiten definir configuraciones de equipo y usuario, y permisos en una ubicación y aplicarse a todos los equipos y/o usuarios dentro de ese sitio. Ya que el ámbito de un Site puede abarcar todos los dominios y DCs en un bosque, las directivas de Site deben aplicarse con precaución. Debido a esto no suelen usarse excepto para definir los valores de seguridad de red para sitios con requerimientos altos o para delegación de derechos administrativos cuando la administración se lleva a cabo principalmente sobre una base geográfica.

*Ya que normalmente se definen los Sites de acuerdo con su conectividad de ancho de banda, hemos de tener en cuenta ciertos consejos cuando queremos definir las necesidades de un Site. Si es posible, los Sites deben contener servicios locales de red, como DC, Global Catalog, DNS, DHCP, WINS. De esta forma si la comunicación entre sitios se corta, el Site local seguirá funcionando a nivel de autenticación, resolución de nombres y identificación de recursos. Colocar servidores de archivos en el Site puede mejorarlo también, siempre que los archivos servidos no deban hallarse de forma central por otras razones.

Configurar  Windows Server 2008 Core

//

Se procedera a la instalacion de un server core, en el entorno ya se encontrara instlado un w08 el cual sera DC

Supongamos 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 acostumbrados 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 ejecutando:

IPCONFIG /ALL

Configuración de Red

En nuestro caso asignaré los siguientes parámetros:

Dirección IP: 192.168.1.101

Máscara de Subred: 255.255.255.0

DNS Server: 192.168.1.200

Puerta de Enlace: 192.168.1.1

Para eso ejecutaremos:

NETSH INTERFACE IPV4 SET ADDRESS NAME=”Local Area Connection” SOURCE=STATIC 192.168.1.101 255.255.255.0 192.168.1.1

NETSH INTERFACE IPV4 ADD DNSSERVER NAME=”Local Area Connection” ADDRESS=192.168.1.200

También lo podemos verificar con:

NETSH INTERFACE IPV4 SHOW CONFIG

Configuración de Nombre de Máquina

En este ejemplo, renombraré el equipo con el nombre: CS-01

NETDOM RENAMECOMPUTER %COMPUTERNAME% /NEWNAME:CS-01

Se observa que estoy aprovechando el uso de la variable de entorno %computername% para no tener que ingresar el nombre generado por la instalación

Para que el cambio surta efecto debemos reiniciar la máquina. Aunque se puede hacer pulsando CTRL+ALT+DEL y elegiendo reiniciar, para ir familiarizándonos con el intérprete de comandos lo haré con:

SHUTDWON /R /T 0

Configuración de Formato de Fecha y Hora

Esto lo haremos con:

CONTROL INTL.CPL

Configuración de Zona Horaria

Esto lo haremos con:

CONTROL TIMEDATE.CPL

Configuración de Windows Update

Para configurar Windows Update debemos ejecutar un script que está en \Windows\System32 así que opté por cambiarme a dicha carpeta con:

CD \WINDOWS\SYSTEM32

Y ejecutamos el script con:

CSCRIPT SCREGEDIT.WSF /AU 4

Con “/AU 1” se deshabilitan

Con esto podemos tener algún problema si para salir a Internet es obligatorio configurar la dirección de un Proxy.

Podemos solucionarlo, por lo menos en parte, ya que se puede asignar una dirección de Proxy, lo que no se puede es usar autenticación.

Para asignar un proxy ejecutaremos:

NETSH WINHTTP SET PROXY <proxyserver:port>

Activación de la Instalación

Como en todas las instalaciones de Windows Server 2008 disponemos inicialmente de un período de gracia para usar la instalación sin introducir la Clave de Activacion y sin activarlo.

Para ver y configurar estas opciones se utiliza el script SLMGR.VBS que si lo ejecutamos sin parámetros nos mostrará todas las opciones disponibles

Verificamos con: SLMGR.VBS -dlv o SLMGR.VBS -xpr

Introducimos la clave con: SLMGR.VBS –ipk <product-key>

Y activamos con: SLMGR.VBS -ato

Para prolongar la evaluación: SLMGR.VBS -rearm

Unir la Máquina al Dominio

Para esto debemos ejecutar:

NETDOM JOIN CS-01 /DOMAIN:CONTOSO.MSFT /USERD:ADMINISTRATOR /PASSWORDD:*

Y reiniciamos la máquina

Editar Archivos de Texto

El Notepad existe!!!

Modificando el Registro

Y también podemos modificar el Registro en forma gráfica, para todos los “trucos” que conozcamos

Para los que Desean Investigar

Para todo aquel que conozca y le guste ver qué se puede hacer desde línea de comando le sugiero moverse a la carpeta Windows y usando el conocido DIR, ver qué encuentran en busca de ejecutables y scripts. Por ejemplo:

DIR *.EXE /S /P

Configuración para Administración GráficaRemota

Como primera opción permitiremos la administración remota del Firewall (Cortafuegos) y luego la administración remota con Consola (MMC.EXE) ya que ambas serán necesarias ahora o a futuro.

De todas formas, como comenté algunas cosas las tendremos que hacer desde línea de comandos, como por ejemplo Agregar/Quitar Roles y Features, o promocionarlo a Controlador de Dominio.

Permitir Administración Remota del Firewall (Cortafuegos)

Para permitir la administración remota desde interfaz gráfica del Firewall debemos ejecutar:

NETSH ADVFIREWALL SET CURRENTPROFILE SETTINGS RemoteManagement ENABLE

Permitir Administración Remota Mediante Consolas

Para administración remota con consolas MMC, utilizamos:

NETSH ADVFIREWALL FIREWALL SET RULE GROUP=”Remote Administration” NEW ENABLE=YES

Administración Remota y Gráfica

Desde otra máquina del dominio he creado una consola MMC cargando dos Snap-In típicos, el que permite administración del Firewall y la administración de la máquina. Se pueden cargar los complementos que crean más convenientes para su situación.

Agregar/Quitar Roles y Features

Aunque tengamos la administración remota por consola MMC habilitada, aún hay configuraciones que se deben hacer desde línea de comandos.

Entre otras, lo que sea agregar o quitar Roles y Features lo debemos hacer por línea de comandos.

Un comando que nos resultará particularmente útil, aunque ahora no lo parezca es poder listar los Roles y Features instalados o no. Lo podemos hacer simplemente con:

OCLIST

Para agregar componentes alcanza con usar OCSETUP y el nombre de lo que deseamos agregar. Es importante tener en cuenta que el nombre del componente es sensible a mayúsculas-minúsculas, por lo que la salida del comando OCLIST tiene importancia.

OCSETUP <Componente-a-Agregar>

Para quitar un componente es:

OCSETUP <Componente-a-Quitar> /Uninstall

A partir de tener el componente instalado, podemos usar remotamente una consola MMC para hacer la administración del mismo.

Algunos Comandos Utiles

Revisar en cada caso: <comando> /?

Informativos del Sistema

SYSTEMINFO

MSINFO32

SET

WHOAMI

HOSTNAME

Administrar Grupos y Usuarios

NET GROUP

NET LOCALGROUP

NET ACCOUNTS

NET USER

Configuración de Servicios y Procesos

SC …

NET STOP

NET START

NET PAUSE

TASKLIST

TASKKILL

TASKMGR

Administración de Discos

DISKPART

FORMAT

DEFRAG

CONVERT

Manejo de Permisos

ICACLS

NET SHARE

TAKEOWN

Group Policies

GPUPDATE

GPRESULT

Llegados a este punto hemos podido hacer una configuración básica de Server Core, con la posibilidad de administrarlo remotamente con la conocida interfaz gráfica.

FUente: WindowServer

En este post  empezaremos a tratar  de explicar las consultasy modficiiones del Active Directorya traves de linea de comandos, de esta manera obtendriamos varias ventajas como  poder simplificar la administracion del mismo ademas de poder obtenerinformacion que no podriamos obtener del entorno grafico. Con este metodo hasta podriamos crear cientos de usuarios, con sus respectivos, permisos, contrasenas importandolas de un  Excel, realizar inventarios de las pcs en segundos, crear listas segun que sistema operativo tienen….entre muchisimas otras cosas…

.

Para comenzar un poquito de teoria

DSQUERY

Es una Consulta al AD mediante el uso de criterios de búsqueda . Cada uno de los comandos dsquery encuentra objetos de un tipo de objeto específico, con la excepción de dsquery *, que puede consultar cualquier tipo de objeto

Dsquery es una herramienta de línea de comandos que está integrado en Windows Server 2008. . Para utilizar dsquery, debe ejecutar el comando dsquery desde un símbolo del sistema con privilegios elevados. Para abrir un símbolo del sistema con privilegios elevados, haga clic en Inicio, haga clic en Símbolo del sistema y, a continuación, haga clic en Ejecutar como administrador.

.

REDIRECCION CON | (PIPE)
Puede redireccionarse el resultados de las  DSQUERY a por ejemplo DSMOD con el fin de modificar un objeto.

Veamos un ejemplo simple:

“‘C:\> dsquery computer -inactive 4″” Con este comando consultamos todas las pcs que estuvieron inactivas las ultimas 4 semanas

“‘C:\>dsmod computer * -disabled yes”” COn este comando reemplazando el * por el “”nombre” de una pc, podriamos desactivarla la computadora en cuestion.

Bueno ahora utilizaremos el | (pipe)

C:\> dsquery computer -inactive 4 | dsmod computer -disabled yes

Que estamos diciendo con este comando? Traeme todas las pcs que estuvieron inactivas en las ultimas semanas, el Pipe realiza la redireccion del ID de todas estas pcs al segundo comando que es dsmod (comando que sirve para modificar un atributo de obetos) y las deshabilita.

DSGET

Muestra las propiedades de un equipo en el directorio. Hay dos variaciones de esta orden. La primera variación se muestran las propiedades de varios equipos. La segunda variación muestra la información de la pertenencia a un solo equipo.

Ejemplo, poder ver la descripcion de todas las computadoas que comienzan con marketing de la ou ventas.

dsquery computer OU=ventas,DC=Argentina,DC=Com -name marketing* | dsget computer -desc

.

Bueno despues de la teoria seguimos con mas teoria 😦

Dsquery computer

Syntaxis
      DSQuery Computer [{StartNode | forestroot | domainroot}]
         [-o {dn | rdn | samid}]  [-scope {subtree | onelevel | base}]
            [-name Name] [-desc Description] [-samid SAMName] [-inactive NumberOfWeeks]
               [-stalepwd NumberOfDays] [-disabled]
                  [{-s Server | -d Domain}] [-u UserName] [-p {Password | *}]
                     [-q] [-r] [-gc] [-limit NumberOfObjects] [{-uc | -uco | -uci}]

Key
   StartNode | forestroot | domainroot  The node in the console tree where the search starts.
                                        forestroot = search using the global catalog. 

   -o           The format used to display the search results.
                dn = distinguished name.
                rdn = relative distinguished name.
                samid = Security Accounts Manager (SAM) account name.

   -scope       The scope of the search:
                subtree = subtree that is rooted at the start node in the console tree.
                onelevel = immediate children of the start node only.
                base = single object that the start node represents.
                If forestroot is the StartNode, then subtree is the only valid scope. 

   -name        Search for computer(s) whose name attribute(CN) matches Name.
                For example, "br*"

   -desc        Search for computer(s) whose description matches. For example, "dell*"

   -samid       Search for computer(s) whose SAM account names match SAMName

   -inactive    Search for computer(s) that have been inactive for N number of weeks

   -stalepwd    Search for computer(s) whose passwords have not changed for n number of days.

   -disabled    Search for computer(s) whose accounts are disabled.

   -s       Server to connect to (Default=the domain controller in the logon domain.)
   -d       Domain to connect to.

   -u       Username with which the user logs on to a remote server.
   -p       Password     (UserName or Domain\UserName or Username@domain.com)

   -q       Quiet, suppress all output
   -r       Recursive search (follow referrals)
   -gc      Use the AD global catalog during the search.
   -limit   The maximum number of objects to return, default=100.

   -uc      Unicode format
   -uco     Unicode format for output only
   -uci     Unicode format for input only

.

Bueno vayamos a la parte divertida

Ejemplos:

En contrar todas las pcs que comienzan con ventas, suponiendo que la tenemos nombradas por sector ventas01, ventas02…

C:\> dsquery computer -name ventas*

Encontras todas las computadoras de la ou(unidad organizativa) Mendoza.

.

C:\> dsquery computer ou=Mendoza,ou=Workstations,dc=argentina,dc=com

.

Encontrar pcs con 4 semanas de inactividad:

C:\> dsquery computer -inactive 4

.

Encontrar las pcs con 4 semanas de inactividad y deshabilitarlas:

C:\> dsquery computer -inactive 4 | dsmod computer -disabled yes

.

Estos comandos pueden sernos muy utiles para poder realizar inventarios, ahorrandonos muchisimo tiempo 🙂

.

dsquery computer -name * | dsget computer -samid

Que le esstmos pidiendo? Que nos traiga todas las pcs, no importa cual sea el nombre y que nos devuelva el samid (nombre en la sam, por ejemplo servidor1)

.

COmo podemos exportar esto a un Notepad, excel?

dsquery computer -name * | dsget computer -samid > c:\pclist.txt

Agregandoles “”> c:\*.txt” nos exporta el resultado a un archivo de texto. >)

.

Obtener un listado de las computadoras segun que sistema operativo tienen

dsquery * domainroot -filter “(&(objectCategory=computer)(operatingSystem=Windows Server*))” | dsget computer -samid

Donde dice windows server *, podemos cambiarlo por ”windows seven” o “”windows xp””

.

Bueno esto es todo por hoy, espero que les haya sido de utilidad,  se puede consutar casi cualquier cosa del AD, les dejo un enlace a microsoft para que sigan investigando:

http://technet.microsoft.com/en-us/library/cc754340%28WS.10%29.aspx

El uso adeacuado de las group policies esta sujeto  a que tan bueno es el diseño del Active Directory. Muchas veces nos encontramos el error de que estos estan diseñados siguiendo el ornanigrama de la empresa. La manera mas eficiente es armarlo a base del funcionamiento de la empresa.  Si ha impelentado los  sitios, dominios y unidades organizativas de la manera incorrecta, las directivas de grupo serán difíciles de utilizar y mucho mas poder  resolver problemas.  Por lo tanto el primer paso sera planificar el Active directory, no hay una modelo, esta sujeto al funcionamiento de la empresa en la cual se va a implementar. Algunas de las preguntas que deben hacerse son las suiguientes:  ¿Cuantos bosques/forest se va a implementar (uno o varios)? ¿Cuántos árboles de dominio? Habrá dominios secundarios? ¿Qué tipo de estructura de unidades organizativas tendra  cada dominio  Y así sucesivamente. Cada una de estas decisiones debe hacerse siempre por la pregunta: ¿Qué impacto tendrá mi decisión tiene sobre la directiva de grupo se lleva a cabo en mi empresa? Veamos algunas pautas que pueden ayudarle a diseñar Active Directory con eficacia en cuanto a la directiva de grupo se refiere

K.I.S.S. “Keep It Simple, Stupid ” 🙂

En el contexto de la planificación de directiva de grupo, esto significa dos cosas::

Si un dominio único se reunirán todas las necesidades de su empresa, a continuación, utilizar un solo dominio. La razón es simplemente que el número de objetos de directiva de grupo (GPO) que tendrá que crear es aproximadamente proporcional al número de dominios que tienen en el bosque. Para vincular un GPO mientras residen en un dominio a un contenedor (dominio, sitio o unidad organizativa) en un dominio diferente reduce el número total de GPO que necesita para implementar, puede tener un impacto en el rendimiento y por lo general no se debe hacer.

Mantener su estructura de unidades organizativas relativamente sencillas, por ejemplo dos o tres niveles de unidades organizativas en la mayoría. La razón es similar aquí por qué usted debe tener su número de dominios de lo más bajo posible: los gastos administrativos.
Así que vamos a decir de comenzar el diseño de Active Directory con la decisión que nos van a un único dominio (ver Figura 1) con dos o quizás tres niveles de unidades organizativas dentro de ella. Eso es un buen lugar para empezar. ¿Qué sigue?


OU servidor

Directiva de grupo no es sólo para la administración de escritorios, es también excelente para el bloqueo de los servidores para garantizar que son seguros y funcionan correctamente. Y por los servidores me refiero tanto a los servidores miembros (que incluyen los servidores de archivos, servidores de impresión, servidores web, servidores DHCP, etc) y los controladores de dominio. La mejor manera de bloquear los controladores de dominio es dejarlos en la unidad organizativa controladores de dominio predeterminada y configurar un GPO vinculado a esa unidad organizativa. Hay dos maneras para hacer esto:

  1. Configurar los ajustes en el controladores de dominio predeterminada.

Crear un nuevo GPO, vincularla a la unidad organizativa de controladores de dominio, y configurarlo.
¿Qué enfoque es mejor? Algunos expertos recomiendan dejar el GPO predeterminado tocar y el crear un nuevo GPO y moverlo a la parte superior de la orden de enlace para los GPO vinculados a la OU. De esta manera si algo sale mal después por lo menos tener la GPO predeterminado en su lugar y sin tocar. pero hay varias opciones

¿Qué pasa con los demas servidores ? El truco aquí es darse cuenta de que las funciones de miembro de diferentes servidores son, básicamente, de forma incremental diferente de una línea de base servidor miembro. Así que un buen enfoque es crear un alto nivel de unidad organizativa Servidores miembro y luego por debajo de él añadir las unidades organizativas adicionales para cada función


Figure 2: OU structure for member servers.

La ventaja de este enfoque es que ahora se puede crear una base de servidores miembro GPO que generalmente asegura cualquier servidor miembro y enlace a la unidad organizativa Servidores miembro. De esta forma todos los servidores miembro en unidades organizativas secundarias heredarán automáticamente esta política. A continuación, puede crear una impresión Servidores GPO y vincularlo a la unidad organizativa Servidores de impresión, servidores de un archivo de GPO y vincularlo a la unidad organizativa de servidores de archivos, y así sucesivamente. Estas diferentes GPO vinculados a unidades organizativas secundarias de la UO Servidor miembro se puede utilizar para endurecer la seguridad incremental para cada función de servidor en la base endurecimiento facilitada por los servidores de GPO.

Escritorio del usuario y las unidades organizativas

La estructura de unidades organizativas a planificarpuede depender de varias cosas incluyendo el organigrama de la empresa, sucursales, número de departamentos, y así sucesivamente. No hay un modelo de diseñar las unidades organizativas de un dominio, pero los siguientes consejos pueden ayudarle a evitar problemas en el futuro cuando se inicia la creación de GPO para bloquear los usuarios y sus computadoras de escritorio.

En primer lugar, sólo se debe crear una unidad organizativa, si hay alguna razón de peso para que exista. Por ejemplo, si los usuarios de las Ventas, Marketing, y los departamentos de referencia tienen necesidades similares en cuanto a la seguridad va, el grupo de sus cuentas en una única unidad organizativa en lugar de tres. Entonces, si los usuarios de ventas tienen algunas diferencias menores en los requisitos de seguridad de los otros dos departamentos, se puede crear y vincular otro GPO a la OU y el uso de filtrado de seguridad para garantizar sólo los miembros del grupo de ventas tienen que establecer GPO se aplica a ellos.

A continuación,se debe tratar de crear unidades organizativas a lo largo de las líneas departamentales en lugar de la ubicación geográfica. De esa manera se  puede hacer un uso más eficaz de la delegación cuando se necesita para usarlo. Si se debe tener las unidades organizativas geográfica, hacen de las unidades organizativas de nivel superior y luego crear unidades organizativas secundarias por debajo de ellos por cada división o departamento (Figura 3):

A continuación, crear unidades organizativas independientes para las cuentas de equipo y cuentas de usuario (Figura 4). De esta manera puede utilizar unidades organizativas independientes para bloquear los ajustes de la máquina y la configuración del usuario. Por supuesto, se puede lograr lo mismo por agrupar las cuentas de equipo y de usuario en una única unidad organizativa, que une dos GPO a la OU, y la desactivación de la configuración de la máquina en una unidad organizativa y la configuración del usuario en la OU otros. Sin embargo, mantener el equipo y las cuentas de usuario en unidades organizativas independientes, será más fácil para solucionar problemas de directiva de grupo

Figure 4: separadas ou para usuarios y computers

Además, trate de evitar el uso de bloqueo,” force Loopback” , y otras formas de modificar la directiva de grupo predeterminada para la herencia. Eso es porque el uso de estas características puede hacer que sea muy difícil de averiguar por qué la directiva de grupo no está haciendo lo que quieres que deberia . Ses absolutamente necesario utilizar estas características en el diseño de la directiva de grupo, es probable que no se haya diseñado una estructura de Active Directory de forma ordenada . La única excepción a esta regla es el filtrado de seguridad, que es una poderosa herramienta que puede ayudar a hacer una selección más precisa GPO sin complicar el diseño.

Por último, evitar hacer cambios en la directiva de dominio predeterminada. En su lugar, crear un nuevo GPO, vincularla con el dominio, y configurar sus parámetros, según sea necesario. Pero tenga mucho cuidado con lo que configurar en cualquier GPO vinculado a un dominio, ya que todos los ajustes que configure será heredado por todas las computadoras y cuentas de usuario en todas las unidades organizativas en el dominio. Siempre que sea posible configurar la política en el nivel de unidad organizativa y no en el nivel de dominio y uso de dominio GPO sólo para objetos del dominio.

Creación y Modificación de Usuarios de Active Directory con PowerShell (Bulk-Users)

Introducción

En este documento utilizaremos la nueva consola de comandos de Windows denominada PowerShell para crear y modificar usuarios en el Active Directory. Desde ella, podremos administrar desde un usuario hasta el número que necesiten. Existen muchos escenarios en los cuales debemos crear una gran cantidad de usuarios (nuevo dominio, nuevos empleados, etc), como así también podríamos necesitar modificar varios datos de usuarios ya existentes (modificación de teléfono, puesto, dirección, etc). En el ejemplo de ésta guía crearemos 13 usuarios de Active Directory y luego modificaremos ciertos datos para poder ejemplificar el script de modificación. Por último, activaremos el Mailbox de cada usuario en Microsoft Exchange 2007 SP1, por medio de PowerShell o bien por medio de la GUI.

Escenario

Nuestro escenario es muy simple, el cual consta de un servidor que es nuestro controlador de dominio principal, es DNS Server y posee Microsoft Exchange Server 2007 SP1 instalado. En nuestro caso tenemos instalado todo en un solo servidor debido a cuestiones prácticas de la guía. Recuerden que no es recomendable instalar el servidor de correo en el mismo servidor que es controlador de nuestro dominio.

clip_image001[4]

Requisitos

Nuestro controlador de dominio posee Microsoft Windows Server 2003 Standard Edition con Service Pack 2 y la actualización de R2 instalada, siendo ésta última no necesaria. Adicionalmente debemos tener las siguientes aplicaciones instaladas:

Powershell 1.0
http://www.microsoft.com/windowsserver2003/technologies/management/powershell/download.mspx

Microsoft Core XML Services (MSXML) 6.0
http://www.microsoft.com/downloads/details.aspx?FamilyID=993c0bcf-3bcf-4009-be21-27e85e1857b1&displaylang=en

PowerShell Commands for Active Directory (ActiveRoles Management Shell) by Quest Software
http://www.quest.com/powershell/activeroles-server.aspx

PowerShell Commands for Active Directory es un agregado para Microsoft PowerShell realizado por la firma Quest Software, el cual es gratuito y agrega comandos de PowerShell para administrar objetos de nuestro Active Directory.

Creando Bulk-Users en Active Directory con PowerShell

Lista de Usuarios

Una vez que dispongamos de nuestro servidor (Controlador de Dominio) instalado, procederemos a utilizar PowerShell para crear Usuarios de Active Directory a partir de una lista de usuarios, que en principio podríamos tener en Microsoft Excel pero que en definitiva debemos tenerla en un archivo CSV.

clip_image002
Figura 1. Lista completa de usuarios con datos adicionales

En la Figura 1 tenemos una lista completa de usuario con todos sus datos. En ella tenemos: nombre, apellido, nombre a mostrar, nombre de usuario, teléfono, area de trabajo, cargo laboral, empresa, dirección postal de trabajo, código postal y ciudad y password.
Una vez completada toda la lista la debemos guardar como CSV (archivo delimitado por coma), el cual utilizaremos en nuestro script de PowerShell.

Conociendo los cmdlets de Quest Software para PowerShell

Para crear usuarios debemos utilizar el cmdlet New-QADuser.

Sintaxis

La sintaxis que utilizaremos en el script de PowerShell para crear los usuarios es la siguiente:

New-QADUser [-Name] <String> -ParentContainer <IdentityParameter>

[-City <String>] [-Company <String>] [-Department <String>]

[-Fax <String>] [-FirstName <String>] [-HomePhone <String>]

[-Initials <String>] [-LastName <String>]

[-Manager<IdentityParameter>] [-MobilePhone <String>]

[-Notes <String>] [-Office <String>] [-Pager <String>]

[-PhoneNumber <String>] [-PostalCode <String>]

[-PostOfficeBox <String>] [-SamAccountName <String>]

[-StateOrProvince <String>] [-StreetAddress <String>]

[-Title <String>] [-UserPrincipalName <String>]

[-WebPage <String>] [-UserPassword <String>]

[-ObjectAttributes <ObjectAttributesParameter>]

[-Description <String>] [-DisplayName <String>]

[-ExcludedProperties <String[]>] [-IncludedProperties <String[]>]

[-DeserializeValues] [-UseDefaultExcludedProperties]

[-UseDefaultExcludedPropertiesExcept <String[]>] [-Proxy]

[-Service <String>] [-ConnectionAccount <String>]

[-ConnectionPassword <SecureString>] [-Credential <PSCredential>]

[-Connection <ArsConnection>] [-UseGlobalCatalog]

A continuación se listan los atributos/sintaxis posibles a usar con el cmdlet para modificar los atributos de los usuarios.

Atributo

Sintaxis

l

-City <String>

company

-Company <String>

description

-Description <String>

department

-Department <String>

displayName

-DisplayName <String>

facsimileTelephoneNumber

-Fax <String>

givenName

-FirstName <String>

homePhone

-HomePhone <String>

initials

-Initials <String>

sn

-LastName <String>

manager

-Manager <IdentityParameter>

mobile

-MobilePhone <String>

info

-Notes <String>

physicalDeliveryOfficeName

-Office <String>

pager

-Pager <String>

Parametro para setear la clave del usuario

-UserPassword <String>

telephoneNumber

-Phone <String>

postalCode

-PostalCode <String>

postOfficeBox

-PostOfficeBox <String>

samAccountName

-SamAccountName <String>

st

-StateOrProvince <String>

streetAddress

-StreetAddress <String>

title

-Title <String>

userPrincipalName

-UserPrincipalName <String>

wWWHomePage

-WebPage <String>

Creando la Unidad Organizacional

El siguiente paso comprende en crear una nueva Unidad Organizacional (OU) en nuestro dominio al cual denominaremos “UsuariosNuevos”, tal como podemos ver en la Figura 2.

clip_image002[5]

Figura 2. Aquí es donde estarán los nuevos usuarios que crearemos con PowerShell

Armando el script de creación de usuarios

Ahora solo nos queda por crear el script final acorde a nuestra lista de usuarios. Para ello, primero analizaremos el script y luego lo ejecutaremos.

Import-CSV c:\users.csv | ForEach-Object { New-QADUser -Name $_.display -SamAccountName $_.SamAccountName -UserPrincipalName $_.user1 -FirstName $_.first -LastName $_.last -DisplayName $_.display -Phone $_.phone -Department $_.departamento -Title $_.Title -Company $_.company -Streetaddress $_.street -PostalCode $_.zip -City $_.city -StateOrProvince $_.state -UserPassword $_.password -ParentContainer mazzite.com/UsuariosNuevos }

En este script utilizaremos el cmdlet “Import-CSV” para importar la lista de nuestros usuarios, la cual habíamos creado anteriormente, que tomará de la ubicación que le indiquemos. Luego por cada objeto de la lista se ejecutara el cmdlet “New-QADUser” seguido de los parámetros con sus variables correspondientes. El código resaltado en verde son los nombres que le hemos dado a cada columna de datos en nuestra lista de usuarios. Por último, el dato resaltado en rojo, es la OU en donde se crearan los nuevos usuarios. Cabe destacar que estamos utilizando solo algunos de los parámetros para modificar atributos. Si quisiéramos agregar algún otro dato, solo es cuestión de agregar la sintaxis según la tabla vista anteriormente y agregar la columna en nuestra lista de usuarios.

clip_image002[7]
Figura 3. Aquí vemos el nuestro script ejecutado desde la Quest Managemente Shell

clip_image002[11]
Figura 4. Como resultado vemos que se han creado los usuarios correspondientes.

Como hemos visto con éste script, crear grandes cantidades de usuarios toma tan solo pocos minutos. Lo más importante es tener la lista de usuarios completa y con todos los datos actualizados, aunque esto no sería un problema ya que existe otro cmdlet que nos permitirá realizar cambios en los atributos de cada usuario de una forma bastante similar a la que hemos utilizado para crear usuarios.

Crear Cuentas de E-Mail desde PowerShell

Como opcional, veremos cómo crear en forma muy sencilla una cuenta de e-mail por cada uno de los usuarios que hemos creado anteriormente.

clip_image002[13]
Figura 5. Management Console de Microsoft Exchange Server 2007. Tan solo vemos dos usuarios con cuenta de e-mail.

Para crear las cuentas de e-mail a cada usuario tan solo debemos correr el siguiente script luego de haber creado los usuarios:

Get-User –OrganizationalUnit “MAZZITE.COM/UsuariosNuevos” | Enable-Mailbox -Database “SRV1\Mailbox Database”

Es importante aclarar que el script para crear las cuentas de e-mail lo debemos ejecutar desde la consola de PoweShell de Microsoft Exchange Server 2007. Una vez que ejecutemos el script de PowerShell obtendremos algo similar como la Figura 6.

 

clip_image002[15]
Figura 6. Ahora los usuarios poseen cuenta de e-mail en nuestra empresa.

Si entramos nuevamente a la consola grafica de administración de Microsoft Exchange Server 2007 veremos que ahora vemos mas de dos cuentas de e-mail. Ahora se suman todos los usuarios que hay en la OU “UsuariosNuevos”.

clip_image004
Figura 7. Management Console de Microsoft Exchange Server 2007. Con tan solo un script hemos creado las cuentas de e-mail de todos los usuarios de una determinada OU.

Es importante aclarar que Microsoft Exchange Server 2007 permite crear cuentas de e-mail para usuarios existentes con muy pocos pasos, utilizando la selección múltiple a través de la consola gráfica desde Service Pack 1 de Exchange 2007. Sin Service Pack 1, solo hubiera sido posible a través de la GUI realizando la creación usuario por usuario.

Modificación de atributos en Active Directory con PowerShell (Bulk-Users)

Anteriormente hemos visto como crear usuarios con todos sus datos en nuestro Active Directory. Ahora veremos cómo podemos modificar atributos para grandes cantidades de usuarios en muy pocos pasos.

Modificando la lista de Usuarios

Existen muchos casos en el cual debamos modificar un mismo dato para todos los usuarios o bien para cierta cantidad de ellos. En nuestro caso veremos cómo agregar un dato y modificar otro dos datos para todos los usuarios que hemos creado. Este caso, ejemplifica la modificación de la dirección y código postal, ya que la empresa se ha mudado de oficina y se ha agrega una descripción a cada uno de los usuarios.

 clip_image002[18]
Figura 8
. En nuestra lista de usuarios debemos modificar los datos necesarios y agregar otra columna con los nuevos datos.

Tal como vemos en la Figura 8, hemos modificado la dirección de cada usuario, el código postal y al final hemos agregado la columna de “descripción”. Una vez finalizada la modificación volvemos a guardar el archivo como CSV.

Armando el script de modificación de  Usuarios

Ahora tan solo debemos crear y ejecutar el script de PowerShell para modificar los atributos de los usuarios en nuestro Active Directory.

Import-CSV c:\users.csv | ForEach-Object { Set-QADUser -Identity $_.SamAccountName  -Streetaddress $_.street -PostalCode $_.zip -description $_.descripcion }

Una vez ejecutado el script, veremos como resultado algo similar como vemos en las siguientes Figuras:

 

clip_image002
Figura 9
. Aquí vemos el script en acción.

 

clip_image004
Figura 10
. Active Directory Users and Computers: La descripción ha sido agregada a cada usuario


clip_image006
Figura 11
. La dirección y el código postal han sido modificados.

Resumen

A lo largo de ésta guía hemos visto el potencial de PowerShell para la administración de Active Directory y Microsoft Exchange Server 2007. Existen una gran cantidad de parámetros y opciones que en esta guía no hemos visto, por lo cual les recomiendo que revisen toda la documentación de Microsoft PowerShell y de Quest Software para que puedan adaptar y utilizar ésta fascinante herramienta que nos permitirá automatizar gran parte de nuestro trabajo.

Links y Referencias

Grupo Latinoamericano de Usuarios de Active Directory
http://www.msglad.org

Grupo Latinoamericano de Usuarios de Exchange Server
http://www.msglue.org

Blog del Team de Windows PowerShell
http://blogs.msdn.com/PowerShell

Download de Windows PowerShell
http://www.microsoft.com/windowsserver2003/technologies/management/powershell/download.mspx

Quest ActiveRoles Management Shell for Active Directory – Administrator’s Guide
http://info.quest.com/QuestWebMgmtShellForADAdminGuide

Quest Downloads
http://www.quest.com/powershell/activeroles-server.aspx


Documentodel equipo  MSGLAD – www.msglad.org

Hoy vamos a ver : Active Directory Topology Diagrammer la cual  es una herramienta que permite pasar fácilmente a Visio una estructura de Active Directory , con sus relaciones de confianza, sus Sites, OUs, y hasta aplicaciones que se integren con el, como es el caso de Exchange:

image image image image

image image image

Simplemente necesita instalarse sobre un equipo que tenga Visio instalado y nos solicitará que nos conectemos a un Global Catalog o a un FQDN (ojo con la resolución DNS) con las credenciales adecuadas.

Algunos resultados, para una estructura de AD bastante sencilla:

image image image image

Una posible aplicación de estos diagramas Visio es integrarlos total o parcialmente con la monitorización de System Center Operations Manager para construir cuadros de mandos que ofrezcan información en tiempo real de la infraestructura, de modo que podamos usarlos desde el propio cliente de Visio o desde los Visio Services de SharePoint 2010.

Los add-ins para Visio y MOSS y las guías paso a paso están aquí: