Category: Domain controller


En este Post veremos Un VB Script, el cual deben guardarlo como *.vbs, deben colocarlo por gpo como logon Script. El mismo permite,
• Mapear la home folder de cada usuario,
•Mapear una carpeta publica
•Dependiendo a que grupo pertenezca le creara una unidad de red. Por ejemplo si un usuario pertenece al grupo ventas, le mapeara una unidad de red definida en el Script
•Segun el grupo de Pertenencia le mapeara una Impresora.

—————————————————————————————————————————————————–

' Se debe cambiar cn=ventas por el grupo de AD al que pertenece el usuario.

' Obtener informacion del usario:

Set ADSysInfo = CreateObject("ADSystemInfo")

Set CurrentUser = GetObject("LDAP://" & ADSysInfo.UserName)

strGroups = LCase(Join(CurrentUser.MemberOf))

' Mapear la Home folder de cada usuario.

Set wshNetwork = CreateObject("WScript.Network")

wshNetwork.MapNetworkDrive "H:", "\\servidor\homefolders\" & wshNetwork.UserName

'Mapeo de Share publico:

wshNetwork.RemoveNetworkDrive "P:"

wshNetwork.MapNetworkDrive "P:", \\servidor\Public

'Mapeo segun Grupo de pertenencia

If InStr(strGroups, "cn=Ventas,") Then

wshNetwork.MapNetworkDrive "V:", \\servdidor\ventas

End if

If InStr(strGroups, "cn=rrhh,") Then

wshNetwork.MapNetworkDrive "R:", \\servidor\RRHH

End if

'Mapeo de Impresora segun grupo de pertenencia mapea y pone 'como impresora por default la printer1

If InStr(strGroups, ventas) Then

wshNetwork.AddWindowsPrinterConnection "\\printserver\printer1"

wshNetWork.SetDefaultPrinter "\\printserver\printer1"

End if

 

Si les da el siguiente error, cuando intentan mapear una unidad de red que ya esta en uso:

The local device name is already in use.

Se debe utilizar la siguiente condicion:

Dim objFSO, strDrive, strShare
Set objFSO = CreateObject(“Scripting.FileSystemObject”)
strDrive = “H:”
strShare = “\\fileserver\novellmain”
If objFSO.DriveExists(strDrive) = True Then
objNetwork.RemoveNetworkDrive strDrive
End If
objNetwork.MapNetworkDrive strDrive, strShare

 

En este post veremos, como redireccionar a una especifica OU, a las nuevas computadoras incorporadas al dominio.

Esto es  de gran utilidad, ya que  en el contenedor de default, no se pueden linkear group policies. Con este metodo , toda nueva computadora ,podra tener una gpo basica, hasta que se lo redirrecione (o no) a una OU definida.

Laboratorio:

DC: Windows Server 2008 R2

DOminio: morettimaxi.local

  1. Lo primero que tenemos que hacer es crear una OU,
  2. Luego saber el Distingueshed Name, el mismo lo encontramos en el “atribute Editor”

Luego abrimos un CMD, y colocamos la siguiente linea:

redircmp.exe “OU=Computers,OU=morettimaxi,DC=morettimaxi,DC=local”

De esta manera, todas las computadoras que agreguemos iran a la OU predefinida, donde por GPO, cumplira con los requisitos de seguridad de la empresa.

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

¿Estan Replicando mis Controladores de Dominio?

¿Se puedo saber si los DC está replicando correctamente? ¿Cuándo fue la última vez que replicaron ?. Para ayudarnos, utilizaremos la herramienta repadmin disponible en las Support Tools de Windows 2003.

El comando a ejecutar para determinar el estado de la replicación de AD es:

repadmin /replsummary /bysrc /bydest /sort:delta

La salida queda dividida en dos tablas:

  • Cada DC cuando es origen de replicación – tabla Source
  • Cada DC cuando es destino de replicación – tabla Destination

También podremos encontrar los DCs que no pudieron ser contactados en la parte final.

La columna Largest Delta muestra el máximo tiempo sin replicar satisfactoriamente alguna partición (naming context) entre todos los partners de replicación de un controlador de dominio particular. Las tablas se encuentran ordenadas por esta columna de mayor a menor. La columna Total muestra el número de enlaces de replicación (1 por DC por naming context) y la columna Fails (fallos) muestra el número de enlaces que han reportado error y el tipo del mismo.

Un ejemplo de la salida mencionada se encuentra en la siguiente tabla:

clip_image002

La salida de repdmin /showrepl nos muestra que el equipo HALEDC02 está replicando correctamente las particiones indicadas con su partner de replicación, HALEDC01 y no así con GUPTADC01.

La ultima replicación correcta para HALEDC01, tuvo lugar a las 8:56:57 del día 1 de Diciembre de 2009 para la partición de Schema y a las 9:43.21 del mismo día para la partición del dominio haledomain.com.

Entendemos que este resultado es lógico para el resto de particiones ya que al encontrarse todos los DCs en el mismo Site donde la replicación de AD funciona mediante notificaciones cuando se realiza un cambio para que la sincronización sea prácticamente inmediata. En caso de no existir ningún cambio en la partición la replicación respetará el intervalo configurado en el Site para la misma, por defecto una hora.

Sin embargo, la replicación con el partner GPTADC01 no está funcionando adecuadamente. En la salida se observa que la última replicación satisfactoria tuvo lugar el día 30 de Noviembre de 2009 a las 11:06:32 Posteriormente todos los intentos de replicación (574 intentos) han fallado con el error 1722 (RPC Unavailable).

El ejemplo de la salida mencionada se encuentra en la siguiente tabla:

clip_image004

Espero que esta información os sirva para monitorizar regularmente la replicación de vuestros DCs y para detectar problemas existentes antes de que sea tarde.

Antes de instalar el primer servidor de Windows 2008 R2 controlador de dominio (DC) en una existente de Windows 2000, Windows Server 2003 o dominio de WindowsServer 2008, se debe preparar el Forest y el dominio de AD. Se hace mediante la ejecución de una herramienta llamada ADPREP.

DPREP extiendiende el esquema del Active Directory y  realiza updates en los  permisos  necesarios para preparar el forest y el domain para agregar el  domain controller que correra en un Windows Server 2008 R2 o

Nota: Recuerda que ADPREP debe ser usado cuando el DC actual esta corriendo en un Windows Server 2003, Windows Server 2003 R2 and Windows Server 2008.

¿Qué es ADPREP ? ADPREP tiene parámetros que llevan a cabo una serie de operaciones que ayudan a preparar a una ya existente entorno de Active Directory para un controlador de dominio que ejecuta Windows Server 2008 R2No todas las versiones de ADPREP realizar las mismas operacionespero en general los diferentes tipos de operaciones que ADPREP puede realizar son las siguientes:

  • Updating the Active Directory schema
  • Updating security descriptors
  • Modifying access control lists (ACLs) on Active Directory objects and on files in the SYSVOL shared folder
  • Creating new objects, as needed
  • Creating new containers, as needed

para preparar debes realizar lo siguiente:

En primer lugar, debe revisar y entender los cambios de esquema y otros cambios que ADPREP hace como parte del proceso de gestión de esquema en Active DirectoryDomain Services (AD DS). Debe probar el esquema ADPREP actualizaciones en un entorno de laboratorio para asegurarse de que no entre en conflicto con las aplicaciones que se ejecutan en su entorno.

Además, asegúreta de iniciar sesión en el sistema con una cuenta que tiene credenciales suficientes para ejecutar adprep / forestprep. Debe ser un miembro del grupo Administradores

A continuacióninserte el de Windows Server 2008 R2 DVD en la unidad de DVD.Tenga en cuenta que si  no tiene los medios de comunicación útil, puede utilizar la versión de evaluación que está disponible para descarga desde el sitio web deMicrosoftTambién se puede utilizar una de MSDN o TechNet imagen ISO, si tenes una suscripción

Windows Server 2008 Trial Software:
http://www.microsoft.com/windowsserver2008/en/us/trial-software.aspx

Busca en  X:\support\adprep , los archivos: adprep.exe or adprep

NotaADPREP está disponible en una versión de 32bits y una versión de 64 bits . La versión de 64 bits se ejecuta de forma predeterminada. Si necesita para ejecutar ADPREP en un equipo de 32 bits,ejecute la versión de 32 bits (adprep32.exe).

Abre un cmd

Arrastre el archivo adprep.exe desde la ventana del Explorador de Windows al CMD .O si lo desea, siempre puede escribir manualmente la ruta del archivo en la ventana del símbolo del sistema si eso te hace sentir mejor 

NotaDebe ejecutar adprep.exe desde un símbolo del sistema con privilegios elevadosPara abrir un símbolo elevado del sistemahaga clic en Iniciohaga clic en Símbolo del sistema y, a continuación, haga clic en Ejecutar como administrador.

adprep /forestprep

Tipee la letra “c” y ENTER.

ADPREP procedera por algunos minutos . Varios LDF files seran importados al AD Schema, y finalmente aprecera: . File sch47.

Cuando se complete recibira el siguiente mensaje:

Nota: Esta metodologia, ADPREP solo debe correrse si ya hay un DC  existente .Cuando se intenta correr desde un servidor que no es es DC, recibirás el siguiente error:

Adprep cannot run on this platform because it is not an Active Directory Domain
Controller.
[Status/Consequence]
Adprep stopped without making any changes.
[User Action]
Run Adprep on a Active Directory Domain Controller.

En la  Command Prompt window, Tipea:

adprep /domainprep

ADPREPsolo corre en Windows 2000 Native o supeiror .

Deje que la operación finalice y luego de los cambios ya se  preparara el esquema para agregar un controlador de dominio  que se ejecute en Windows Server 2008 R2.

Si está ejecutando un Windows 2008 de dominio de Active Directory, recuerde que esto no es necesario

Si está ejecutando Windows 2000 de dominio de Active Directory, debe también el siguiente comando:adprep /domainprep /gpprep

Si está ejecutando un Windows 2003 cd DC, No necesita tareas adicionales. Sin embargosi tienes  planeando ejecutarlo  como controlador de dominio de sólo lectura (RODC), también debe escribir el siguiente comando:

adprep / rodcprep


EL proceso se completara en unos segundos

Deje que la operación finalice y luego los cambios se replicaran en todo el Forest.

Para comprobar que los comandos adprep / forestprep se completó con éxito por favor, siga estos pasos:

1Inicie sesión en una estación de trabajo administrativo que ha instalado ADSIEdit.ADSIEdit se instala por defecto en los controladores de dominio que ejecutan Windows Server 2008 o Windows Server 2008 R2En Windows Server 2003 debe instalar el Kit de recursos de herramientas.

2Haga clic en InicioEjecutar, escriba Adsiedit.msc y, a continuación, haga clic en Aceptar.

3Haga clic en Acción y, a continuación, haga clic en Conectar con.

4Haga clic en Seleccionar un contexto de nomenclatura conocidoseleccione Configuración en la lista de contextos de nombres disponibles y, a continuación, haga clic en Aceptar.

5Haga doble clic en Configuración y, a continuación, haga doble clic en CN =Configuración DC = forest_root_domainwhere forest_root_domain es el nombre completo del dominio raíz del bosque.

6Haga doble clic en CN = ForestUpdates.

7Haga clic en CN = ActiveDirectoryUpdatea continuación, haga clic en Properties

8. If you ran adprep /forestprep for Windows Server 2008 R2, confirm that the Revisionattribute value is 5, and then click OK.

9. Click ADSI Edit, click Action, and click Connect to.

10. Click Select a Well known naming context, selecciona Schema en la lista y presiona OK

11. doble-click Schema.

12. Boton derecho CN=Schema,CN=Configuration,DC=forest_root_domain, y presiona propiedades

13. Si ha ejecutado adprep / forestprep de Windows Server 2008 R2confirme que el valorobjectVersionattribute se establece en 47y luego haga clic en Aceptar.