Consulta con el equipo de Windows : Directorio Activo

Cómo reconfigurar Windows Time en el antiguo PDC cuando transferimos el rol a otro DC

esplat — Wed, 25 Nov 2009 17:34:00 GMT

Hola a todos,

Como todos sabéis, los Controladores de Dominio de un dominio sincronizan su servicio de tiempos siguiendo la jerarquía del dominio. Generalmente, el PDC Emulator del dominio raíz del bosque se configura para que sincronice su hora con una fuente externa o con su propio reloj hardware, tal y como se indica en el artículo:

816042 How to configure an authoritative time server in Windows Server

Si el rol de PDC Emulator en el dominio raíz del forest se mueve a otro DC, además de configurar el nuevo PDC, también debe indicarse al PDC antiguo que ya no es una fuente de hora autoritativa en el entorno, ya que la operación de transferencia del rol no realiza esta operación sobre el servicio de tiempos.

Si no se realiza la operación, el antiguo PDC sigue anunciándose y actuando como fuente de tiempos autoritativa, lo que hace que el resto de DCs, si no tienen fallos al contactar con él o no realizan de nuevo el proceso selección de una nueva fuente de tiempos, sigan sincronizándose contra esta máquina.

El procedimiento que hay que llevar a cabo en el PDC antiguo se describe en el artículo Change the Windows Time service configuration on the previous PDC emulator y consiste en ejecutar los comandos que aparecen a continuación:

Ejecutar el siguiente comando para configurar el servicio de tiempos para que siga la jerarquía del dominio:

w32tm /config /syncfromflags:domhier /reliable:no /update

Parar y arrancar el servicio de tiempos (W32Time)

net stop w32time && net start w32time

Tras realizar esta modificación, el antiguo PDC deja de anunciarse como fuente de tiempos y, por lo tanto, el resto de los DCs procederán a buscar una nueva fuente de tiempos una vez agotados los tiempos de polling.

Espero que encontréis útil esta información.

Paula Tomás Galed

¿Por qué cuando un usuario se conecta a un servidor de Terminal Server el servidor de licencias registra un evento 4105 en el visor de sistema?

esplat — Wed, 25 Nov 2009 11:09:00 GMT

Hola a todos,

Recientemente nos hemos encontrado con un caso curioso, en el que hemos estado trabajando unas cuantas semanas, que implica tanto a la parte de Core como de Directorio Activo y queríamos comentároslo. Esperamos que os sea de utilidad :).

Cuando un usuario se conecta a un servidor de Terminal Server, el servidor de licencias registra el siguiente evento:

Event ID 4105

Source Microsoft-Windows-TerminalServices-Licensing

Type Warning

Description

The Terminal Services license server cannot update the license attributes for user "user" in the Active Directory Domain "domain". Ensure that the computer account for the license server is a member of Terminal Server License Servers group in Active Directory domain "domain".

If the license server is installed on a domain controller the Network Service account also needs to be a member of the Terminal Server License Servers group.

If the license server is installed on a domain controller after you have added the appropriate accounts to the Terminal Server License Servers group you must restart the Terminal Services Licensing service to track or report the usage of TS Per User CALs.

Win32 error code: 0x80070005

El error 4105 ocurre en los usuarios migrados desde un entorno NT/2000. Cuando se actualiza el esquema del dominio a 2003, los usuarios creados a partir de ese momento, incluyen permisos de lectura/escritura para el grupo Terminal Server License Servers en su security descriptor. Esto es debido a que el grupo Terminal Server License Servers se crea al ampliar el esquema a 2003 ya que en 2000 no existía y se modifica el defaultSecurityDescriptor de la clase user añadiendo la siguiente ACE:

(OA;;WPRP;6db69a1c-9422-11d1-aebd-0000f80367c1;;S-1-5-32-561)

Donde:

6db69a1c-9422-11d1-aebd-0000f80367c1 –> es la propiedad sobre la que damos los permisos (terminalserver)
WPRP –> Write/Read property
S-1-5-32-561 –> SID del grupo Terminal Server License Servers

Llegados a este punto tenemos dos posibilidades:

Aplicar la ACE para todos los objetos en el naming context de dominio.

Para ello, lo que tenemos que hacer es ejecutar el comando dsacls "dc=XXXX,dc=XXXX,dc=XXXX,dc=XXXX” /I:T /G "BUILTIN\Terminal Server License Servers”:WPRP;terminalServer”. Por ejemplo, si nuestro dominio se llamase contoso.com el comando sería:

dsacls "dc=contoso,dc=com” /I:T /G "BUILTIN\Terminal Server License Servers”:WPRP;terminalServer”

Dar permisos usuario a usuario utilizando el comando:

dsacls "CN=XXXX,OU=XXXX,OU=XXXX,OU=XXXX,DC=XXXX,DC=XXXX,DC=XXX" /G "BUILTIN\Terminal Server License Servers:WPRP;terminalServer"

Este comando lo que hace es precisamente dar permisos de lectura/escritura al grupo Terminal Server License Servers sobre la propiedad terminalServer de un usuario. Por tanto, lo que necesitamos para resolver el problema es identificar todos los usuarios creados antes de actualizar el esquema a 2003 (y que vayan a acceder a través de terminal server) y darle los permisos antes mencionados.

En este punto es necesario identificar los usuarios sobre los que necesitamos dar los permisos, basándonos en la pertenencia a un grupo o en la fecha de creación. Si os vais a basar en la pertenencia a grupos, os recomendamos seguir los pasos descritos en el siguiente post:

Diversas herramientas no muestran todos los miembros de un grupo en el Directorio Activo

De acuerdo con el post, un posible script sería como el siguiente:

Set objGroup = GetObject _

    ("LDAP://cn=XXXX, ou=XXXX, dc=XXXX, dc=XXXX”)

set objShell = WScript.CreateObject("WScript.Shell")

For Each strUser on objGroup.Member

        Wscript.Echo strUser

         set objExec = objShell.Exec("dsacls """ + strUser + """ /G ""BUILTIN\Terminal Server License Servers:WPRP;terminalServer""")

El anterior script daría permisos a 1000 usuarios pertenecientes a un grupo administrativo. Si el número de usuarios es mayor, habría que utilizar otro script.

Nuestros compañeros de desarrollo nos han comentado que el script se complicaría bastante por lo que os recomendamos abrir un caso con ellos para que os puedan guiar de la mejor manera. Asimismo, si lo que queremos es dar permisos a usuarios de una OU específica el script también sería diferente.

Por último, si os queréis basar en la fecha de creación de los usuarios también deberíamos utilizar un script diferente y bastante más complejo. Además, necesitaríamos utilizar un filtro para la query LDAP del tipo (&(objectclass=user)(whenCreated>=20010420235531.0Z)(whencreated<=20010420235531.0Z).

Un saludo,

Rafael Basterra Careaga y Yolanda Muñoz Muñoz

¿Por qué no puedo unir un servidor Win2008R2 a un dominio de Directorio Activo?

esplat — Mon, 23 Nov 2009 15:06:00 GMT

Hola a todos.

Recientemente se nos planteó un caso de este tipo en soporte. En este caso era debido a que los DCs Windows Server 2003 se estaban “comportando” como Windows NT. Aquí tenéis toda la histora:

Entorno:

Dominio con 3 DCs Windows Server 2003 (SP2) y múltiples BDCs Windows NT4.0
Modo functional Windows 2003 Interim

Servidores miembro Windows Server 2003

Problema:

No se podía unir equipos Windows Server 2008R2 al dominio como servidores miembro
Al intentar unirse especificando el nombre FQDN del dominio se recibía el error:

An Active Directory Domain Controller (AD DC) for the domain DOMINIO.COM could not be contacted. Ensure that the domain name is typed correctly

Al intentar unirse especificando el nombre NETBIOS del dominio se recibía el error:

The following error occurred attempting to join the domain DOMINIO: The specified domain either does not exist or could not be contacted

El problema se repetía al intentar unir equipos Windows Server 2003 al mismo dominio mediante el nombre FQDN, pero NO ASÍ por mediante el nombre NETBIOS donde SÍ lograban unirse correctamente al mismo dominio.

A su vez, determinamos que los mismos servidores Win2008R2 SÍ podían unirse correctamente utilizando el nombre FQDN a otros dominios del mismo entorno

Durante nuestra investigación obtuvimos y analizamos trazas de red del tráfico entro los equipos Win2008R2 y los DCs

Observamos que, en principio, los DCs respondían “correctamente” a las peticiones de los clientes (no había cortes de tráfico ni errores en las comunicaciones entre los prospectivos servidores miembros 2008R2 y los DCs). A pesar de ver que recibían “respuestas” por parte de los DCs, los equipos Win2008R2 persistían en repetir las mismas peticiones para localizar información del dominio al que se querían unir, hasta finalmente fallar con los errores ya citados

Investigación

El problema finalmente tenía 2 matices:

A pesar de ser Win2003, los 3 DCs del dominio, a ojos de los clientes “actuaban” como servidores Windows NT4.
Tenían configurados una clave de registro NT4Emulator, que existe (como medida temporal) para evitar que se sobrecarguen los nuevos DCs de tipo directorio activo durante la migración de un dominio de tipo Windows NT4 a directorio activo
La descripción y la funcionalidad de la clave de registro se encuentran en el siguiente artículo:

298713 How to prevent overloading on the first domain controller during domain upgrade

The NT4Emulator parameter specifies whether this domain controller will emulate the behavior of an Windows NT 4.0-based domain controller. By default, the domain controller does not emulate this behavior. Emulation of the Windows NT 4.0 behavior is desirable when the first domain controller that is running Windows 2000 or a later version of Windows is promoted to a primary domain controller in a Windows NT 4.0 domain that has many Windows 2000-based clients. Unless you emulate the Windows NT 4.0 behavior, all the Windows 2000-based clients will target the Windows-based domain controller and potentially overload it. This parameter is ignored on computers that are not domain controllers.

Respecto a este caso concreto, observamos los comportamientos descritos en rojo

If this parameter is set to TRUE, the following scenario occurs on a domain controller:

Incoming LDAP locator pings are ignored unless the ping comes from an admin computer. (See the "Neutralizing Windows NT 4.0 Emulation for Some Computers" section.)
The flags that are negotiated during the incoming security channel setup will be set to what an Windows NT 4.0-based domain controller can support unless the channel setup comes from an admin computer.

Ambos puntos explicaban por qué los clientes Win2008R2 repetían sus peticiones a pesar de recibir “respuesta”, tanto en los intentos de unirse al dominio mediante nombre FQDN como mediante nombre Netbios

A su vez el hecho de que los servidores Win2008R2 no se unieran al dominio pero los equipos Win2003 sí (a través de NETBIOS )se explica en el siguiente artículo:

940268 Error message when you try to join a Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2-based computer to a Windows NT 4.0 domain: "Logon failure: unknown user name or bad password"

En resumen, los DCs se comportaban como máquinas NT4, y Win7/Win2008R2 no pueden unirse a un dominio de tipo NT4.

Resolución

Pudimos unir los equipos Windows Server 2008R2 correctamente al dominio tras crear el valor de registro NeutralizeNT4Emulator que les permitía contactar con los DCs Windows Server 2003 y que éstos les respondiesen “correctamente”

Tolu Igbon

Monitorizando el tipo de consultas LDAP que llegan a nuestros DCs

esplat — Tue, 11 Aug 2009 23:25:00 GMT

Hola de nuevo. Volvemos a la “carga” con LDAP. Hoy vamos a hablar sobre cómo obtener un logging detallado de las consultas LDAP llevadas a cabo por un controlador de dominio. Esto puede resultarnos útil a la hora de comprobar el tipo de consultas LDAP que se efectúan, comprobar si están optimizadas en cuanto a objetos recorridos, etc.

Para qué nos sirve

Los datos obtenidos pueden ayudarnos a determinar, por ejemplo, si hay un cliente que está efectuando muchas consultas y que, en principio, no debería estar realizando, lo que puede indicar la presencia de alguna aplicación no deseada.

También puede ayudarnos a determinar si es necesario indexar algún atributo concreto para optimizar un tipo de búsqueda concreta que se realiza de forma frecuente y con un filtro que utiliza un atributo específico no indexado (lo que provoca recorrer innecesariamente múltiples objetos por cada búsqueda).

Es posible que estemos realizando la búsqueda en un scope o ámbito muy amplio y con un DN base muy general cuando podemos restringirla a una OU concreta y no a todo el sub-árbol del dominio: si buscamos usuarios de una oficina concreta que cumplen un requisito y sabemos que todos los usuarios de dicha oficina están en una OU específica, deberíamos utilizar dicha OU como DN base de la búsqueda y no todo el dominio.

Este logging de las consultas LDAP se realiza en el visor de sucesos en forma de eventos. Los eventos generados proporcionan, además de los datos del cliente y la propia consulta, información adicional como el tiempo empleado en las queries LDAP y los objetos recorridos.

Para leer información sobre cómo funcionan las búsquedas LDAP: How Active Directory Searches Work

Cómo configurar este nivel de logging

Para conseguir este nivel de logging, en los DCs hay que hacer varias modificaciones en el registro para:

Definir lo que consideramos una búsqueda LDAP costosa/ineficiente
Habilitar el log de eventos de diagnóstico de Directorio Activo para Field Engineering

En primer lugar hay que definir los límites a partir de los cuales se considera que una consulta es costosa/ineficiente. Estos límites se especifican en términos de objetos recorridos, y sólo se registrarán eventos que superen estos límites.

Una búsqueda costosa es aquella que visita un alto número de objetos. La eficiencia de una búsqueda se mide comparando el número de registros devueltos con respecto al número de registros visitados. Es decir, si la búsqueda devuelve 300 objetos después de recorrer 300 objetos, entonces estamos ante una búsqueda eficiente.

Los límites se especifican con creando o modificando los siguientes valores de la clave de registro que se proporciona a continuación (si se desea que se muestren todas las consultas LDAP, el valor de ambos límites deberá ser 1, aunque esto puede suponer un incremento no deseado de la carga de CPU del DC):

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Valor: Expensive Search Results Threshold

Tipo: DWORD

Datos: 10000 (Valor por defecto)

Valor: Inefficient Search Results Threshold

Tipo: DWORD

Datos: 1000 (Valor por defecto)

Con estos valores por defecto, una búsqueda se considerará costosa si el DC recorre más de 10000 objetos (Expensive Search Results Threshold). Una búsqueda se considerará ineficiente si recorre más de 1000 objetos (Inefficient Search Results Threshold) y se devuelve como resultado menos de un 10% de los objetos visitados.

Los valores de Expensive e Inefficient Search Results Threshold son valores subjetivos, por lo que habrá que adecuarlos al entorno y al tipo de consultas que se efectúen en los DCs.

Se puede encontrar más información sobre estos valores en el siguiente enlace:

Creating More Efficient Microsoft Active Directory-Enabled Applications

Hasta aquí ya hemos determinado nuestros valores límite de lo que consideramos una búsqueda costosa o ineficiente. Sin embargo, esto no es suficiente para generar los eventos.

Los eventos de log de actividad LDAP se generan en el visor de sucesos de Directorio Activo en la categoría de Field Engineering. Por lo tanto, tendremos que activar el log de diagnóstico de esta categoría en los DCs en los que queramos monitorizar la actividad LDAP.

Para ello es necesario modificar el siguiente valor de la clave de registro que se muestra a continuación:

HKLM\system\CCS\Services\NTDS\Diagnostics

Valor: 15 Field Engineering

Datos: 5

Nota: Para que los valores sean efectivos no es necesario reiniciar el DC en el que se modifiquen

A partir de dicho momento, por cada query LDAP costosa/ineficiente aparecerá en el Visor de Sucesos de Directory Services un evento 1644 de categoría Field Engineering con la información de la búsqueda, tipo, filtro, ámbito de búsqueda (scope), entradas recorridas, entradas encontradas, etc.:

Event Type: Information

Event Source: NTDS General

Event Category: Field Engineering

Event ID: 1644

Description:

Internal event: A client issued a search operation with the following options.

Client:

127.0.0.1

Starting node:

DC=dominio,DC=com

Filter:

(objectClass=computer)

Search scope:

subtree

Attribute selection:

[types_only]

Server controls:

Visited entries:

3448

Returned entries:

Otro tipo de log de diagnóstico que puede resultar útil es el siguiente, que nos permite obtener información sobre el tiempo empleado en las búsquedas:

Valor: 16 LDAP Interface Events

Datos: 3

Después de habilitarlo obtendremos un evento 1139 de LDAP Interface indicando el tiempo que ha costado realizar cada búsqueda:

Event Type:          Information

Event Source:      NTDS LDAP

Event Category:   LDAP Interface

Event ID:               1139

Description:
Internal event: Function ldap_search completed with an elapsed time of 30 ms.

Para revisar los eventos generados por los DCs y obtener, por ejemplo, todos los eventos con ID 1644 y fuente NTDS General de todos los DCs que estemos monitorizando, podemos usar una herramienta como EventCombMT. La herramienta EventCombMT se puede descargar desde el siguiente enlace:

También es recomendable que aumentemos el tamaño del log de Directory Services, ya que se van a generar varios eventos por cada consulta LDAP registrada, lo que podría provocar que dicho visor de sucesos llegara a su tamaño máximo.

Hasta la próxima.

Paula Tomás Galed

¿Por qué una consulta LDAP no devuelve todos los resultados y qué tiene que ver el valor MaxPageSize en ello?

esplat — Tue, 04 Aug 2009 20:30:00 GMT

Hola a todos. Soy Paula, del equipo de Directorio Activo. Hoy vamos a tratar un tema por el que nos preguntan en Soporte.

A veces, cuando se realizan consultas LDAP a Directorio Activo (utilizando alguna herramienta o programa a medida), no se devuelven todos los resultados que esperamos. Podemos, por ejemplo, solicitar todos los usuarios de una determinada Unidad Organizativa en la que sabemos que hay 3000 usuarios para luego realizar algunas modificaciones sobre ellos. Sin embargo, al ejecutar la consulta LDAP, AD sólo nos devuelve 1000 usuarios, con lo cual la búsqueda no nos sirve...

Este comportamiento se debe a que Directorio Activo devuelve por defecto un máximo número de objetos (1000) en una única búsqueda, aunque los objetos que cumplan los parámetros de búsqueda sean más de ese número por defecto. Este límite viene dado por el valor MaxPageSize de la política LDAP en Directorio Activo.

El valor puede ser modificado y adaptado a las necesidades concretas que tengamos. Para modificar dicho valor es necesario realizar la operación con un usuario con credenciales de Enterprise Admin.

No se recomienda cambiar su valor para recibir un mayor número de objetos en una única consulta LDAP, sino realizar búsquedas paginadas en el Directorio Activo. De esta manera se dividirá la búsqueda en varias búsquedas “más pequeñas” que cumplirán con el límite máximo establecido para cada una de ellas.

¿Por qué no se recomienda cambiar el valor de MaxPageSize?

Porque su modificación puede producir efectos negativos sobre el rendimiento de los DCs y el tráfico generado en la red.

Se puede encontrar más información sobre el valor MaxPageSize y cómo consultarlo y/o modificarlo con ntdsutil.exe en el siguiente enlace:

315071 How to view and set LDAP policy in Active Directory by using Ntdsutil.exe

“MaxPageSize - This value controls the maximum number of objects that are returned in a single search result, independent of how large each returned object is. To perform a search where the result might exceed this number of objects, the client must specify the paged search control. This is to group the returned results in groups that are no larger than the MaxPageSize value. To summarize, MaxPageSize controls the number of objects that are returned in a single search result.
Default value: 1,000”

Si se modifican los límites establecidos por defecto existe un problema potencial de rendimiento. Estos límites han sido probados y se seleccionaron por considerarse óptimos o recomendables. Para entornos específicos pueden ser modificados pero siempre teniendo en cuenta que pueden suponer un problema de rendimiento en el futuro. También hay que recordar que el valor se cambia a nivel general en la política LDAP de AD, por lo que afectará a todos los DCs.

¿Cómo resolver la situación sin modificar el valor de MaxPageSize?

La recomendación para realizar consultas LDAP es realizar dichas consultas de manera paginada (los diferentes lenguajes de programación a través de APIs para LDAP ofrecen mecanismos para llevar este tipo de búsquedas a cabo), con lo que se recibirían los datos de 1000 en 1000 (registros), en lugar de modificar el tamaño de la página que nos devuelve Directorio Activo. De hecho, aunque aumentemos el tamaño del valor MaxPageSize, es posible que tampoco sea suficiente y la búsqueda no devuelva todos los resultados esperados (el número de objetos puede crecer en el tiempo y superar el nuevo límite de MaxPageSize).

Se puede encontrar más información sobre las diferentes políticas LDAP, incluyendo MaxPageSize en el siguiente enlace:

3.1.1.3.4.6 LDAP Policies

Como ya se ha comentado, las políticas LDAP proporcionan límites operacionales para consultas/operaciones LDAP y deben ser configuradas de tal manera que garanticen un nivel de servicio aceptable sin impactar al rendimiento de los DCs y evitando así también ataques de denegación de servicio.

Información específica sobre las políticas LDAP en Windows Server 2008:

LDAP policies

“To ensure that domain controllers can support service level guarantees, you can specify operational limits for a number of Lightweight Directory Access Protocol (LDAP) operations. These limits prevent specific operations from adversely impacting the performance of the server and also make the server resilient to denial of service attacks.”

Más información sobre los límites administrativos de LDAP para AD en la información sobre la herramienta Microsoft Exchange Server Analyzer Tool que analiza configuraciones erróneas entre otros:

Microsoft Exchange Server Analyzer Tool – Active Directory settings
MaxPageSize is set too high

“The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the setting for the MaxPageSize value for the LDAPAdminLimits attribute of the Default Query Policy object in the Query-Policies container. If the Exchange Server Analyzer determines that the value for MaxPageSize is greater than 2,500, an error is displayed.

The Lightweight Directory Access Protocol (LDAP) administrative limits balance Active Directory operational capabilities and performance. These limits prevent specific operations from adversely affecting the performance of the server. The limits also make the server resilient to denial of service attacks. Increasing this setting beyond its default value could have an adverse impact on your Active Directory infrastructure.“

Información adicional sobre las búsquedas paginadas:

Espero que la información os resulte útil a la hora de realizar consultas LDAP en vuestro directorio.

Paula Tomás Galed

Diversas herramientas no muestran todos los miembros de un grupo en el Directorio Activo

esplat — Thu, 16 Apr 2009 12:59:05 GMT

Hola a todos.

En ocasiones, es posible que necesitemos inventariar los usuarios y/o grupos que tenemos en nuestro Directorio Activo.

En función del método que empleemos para extraer información, puede ser que los resultados obtenidos no sean los correctos o estén incompletos.

Sea, por ejemplo, el grupo big_group (un grupo Global de Seguridad en el dominio) que tiene unos 2000 miembros aproximadamente.

Si intentamos listar los miembros que tiene, obtenemos los siguientes resultados:

dsget group

En este caso, como podemos ver en la captura, la salida de la herramienta no nos devuelve resultados:

ldp.exe

La herramienta ldp.exe trunca los resultados obtenidos, no mostrando la totalidad de miembros del grupo:

Expanding base 'CN=big_group,CN=Users,DC=testdom,DC=local'...

Result <0>: (null)

Matched DNs:

Getting 1 entries:

>> Dn: CN=big_group,CN=Users,DC=testdom,DC=local

2> objectClass: top; group;

1> cn: big_group;

0> member:

1500> member;range=0-1499: CN=user1,CN=Users,DC=testdom,DC=local; CN=user2,CN=Users,DC=testdom,DC=local; CN=user3,CN=Users,DC=testdom,DC=local; CN=user4,CN=Users,DC=testdom,DC=local; CN=user5,CN=Users,DC=testdom,DC=local;...

A través de la herramienta ntdsutil, podemos controlar una serie de parámetros para las políticas LDAP de los DCs del dominio.

Entre otros, tenemos la posibilidad de alterar el valor del parámetro MaxValRange el cual controla el número de valores que se devuelve en una query para cualquier atributo de un objeto en el AD.

Sin embargo, hemos de tener en cuenta diversas consideraciones antes de realizar cualquier cambio en estas políticas:

· Las políticas de LDAP son comunes a todos los DCs del forest. No es posible tener distintos DCs con valores distintos para cada parámetro.

· El hecho de incrementar el número máximo de valores por atributo que nos devuelve un DC (MaxValRange), puede provocar un impacto en el rendimiento de los Controladores de Dominio.

Este valor tomará efecto para todos los atributos de todos los objetos del Directorio Activo, y no sólo para miembros de un grupo o para otro atributo concreto que nos interese.

Tenéis disponible más información sobre el tema aquí:

315071 - How to view and set LDAP policy in Active Directory by using Ntdsutil.exe

http://support.microsoft.com/kb/315071

[…]

• MaxValRange - This value controls the number of values that are returned for an attribute of an object, independent of how many attributes that object has, or of how many objects were in the search result. In Windows 2000, this control is "hard" coded at 1,000. If an attribute has more than the number of values that are specified by the MaxValRange value, you must use value range controls in LDAP to retrieve values that exceed the MaxValRange value. MaxValueRange controls the number of values that are returned on a single attribute on a single object.

Default value:

o Windows 2000 - 1,024

o Windows Server 2003 - 1,500

Como alternativa, y en caso de necesitar un listado de todos los miembros de un grupo (p.ej. de más de 1500 usuarios en Windows Server 2003), os proponemos el uso de scripts para realizar la tarea.

En el siguiente enlace podéis encontrar un ejemplo de implementación de esto:

Scripting Guy: List members of a group

http://www.microsoft.com/technet/scriptcenter/resources/qanda/apr05/hey0419.mspx

[…] It’s easy enough to list all the members of a group; for example, here’s a script that reports back all the members of the Finance Managers group:

Set objGroup = GetObject _
    ("LDAP://cn=Finance Managers, ou=Finance, dc=fabrikam, dc=com")

For Each strUser on objGroup.Member
        Wscript.Echo strUser
Next

Un saludo a todos,

Javier Rama

¿Cómo "esconder" tus Controladores de Dominio?

esplat — Mon, 09 Mar 2009 12:55:00 GMT

Hola, soy Yolanda Muñoz, del equipo de Directorio Activo. En algunas ocasiones, nos hemos encontrado con la necesidad de disminuir la carga de logon en determinados DCs o bien por ser el de menor recursos hardware del Site o porque se encuentre destinado a otro tipo de operaciones/aplicaciones. En estos casos sugerimos implementar las siguientes recomendaciones:

Quitar la opción de GC.
Ajustar el “weight” (peso) y la “priority” (prioridad) de los registros SRV en DNS para minimizar el número de peticiones de logon recibidas por los DCs.

Si lo que queremos conseguir es reducir proporcionalmente el número de peticiones clientes recibidas, ajustaremos el “weight”.
Sin embargo, si lo que queremos es minimizar al máximo el número de peticiones recibidas,ajustaremos la “priority”.

En esta ocasión nos detendremos a explicar la segunda de las recomendaciones:

El Directorio Activo asigna por defecto el valor de 100 para el “weight”. Si queremos reducir a la mitad el número de peticiones atendidas por el DC, crearemos la clave del registro que controla dicho valor y lo estableceremos a 50.

Como cambiar el “weight” de los registros SRV en DNS:

1. In the Run dialog box, type regedit, and then press ENTER.
2. In the registry editor, navigate to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
3. Click Edit, click New, and then click DWORD value.
4. For the new entry name, type LdapSrvWeight, and then press ENTER. (The value
name is not case sensitive.)
5. Double-click the entry name you just typed.
6. In the Edit DWORD Value dialog box, select Decimal as the Base option.
7. Enter a value between 0 and 65535 (the recommended value is 10), and then click OK.
8. Click File, and then click Exit to close the registry editor.

El Directorio Activo asigna por defecto el valor de 0 para la “priority” . Así, si creamos la clave del registro que controla dicho valor y lo establecemos a 200, las peticiones de autenticación de los clientes serán atendidas por los DCs cuya “priority” sea menor. De esta manera, el equipo configurado con mayor valor de “priority” no atenderá ninguna petición siempre que existan DCs disponibles con un valor de “priority” menor.

Cuando el valor de “priority” es el mismo para varios DCs, el valor especificado en “weight” determinará el orden en que los servidores van a ser contactados por los clientes.

Como cambiar la “priority” de los registros SRV en DNS:

1. In the Run dialog box, type regedit, and then press ENTER.
2. In the registry editor, navigate to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
3. Click Edit, click New, and then click DWORD value.
4. For the new entry name, type LdapSrvPriority, and then press ENTER.
5. Double-click the entry name that you just typed.
6. In the Edit DWORD Value dialog box, select Decimal as the Base option.
7. Enter a value between 0 and 65535 (the recommended value is 500), and then click OK.
8. Click File, and then click Exit to close the registry editor.

Para que los valores mencionados anteriormente sean efectivos, es necesario reiniciar el servicio de Netlogon (net stop netlogon && net start netlogon). El servicio al iniciar leerá la nueva configuración y actualizará los registros en DNS con los nuevos valores, siempre que las actualizaciones dinámicas estén permitidas en la zona.

Los nuevos valores quedan reflejados tanto en el archivo netlogon.dns (%Systemroot%\System32\config), como en el netlogon.log (%Systemroot%\debug) si el valor DBFlag está establecido a 0x2080FFFF.

- Yolanda Muñoz Muñoz

Error en la comprobación de revocación a la hora de arrancar una entidad certificadora

esplat — Mon, 23 Feb 2009 14:52:00 GMT

Hola a todos. Soy Tolu Igbon, del equipo de Directorio Activo.

Un caso común que tratamos en el área de soporte de Directory Services es el siguiente error al intentar arrancar una entidad certificadora (CA) subordinada:

The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613)

El comportamiento puede producirse nada más intentar arrancar la CA por primera vez, o pasado un tiempo (semanas, meses) tras haber estado funcionando con normalidad.

Antes de comenzar con el diagnóstico del error, vamos a comenzar por recordar algunos conceptos básicos sobre el funcionamiento de certificados:

Basic Certificate Validation:

For a certificate to function properly, the following items must validate correctly (at a minimum):

1. Subject name: The subject of the certificate must match the resource subject that is being used. For example, when using https the subject in the certificate being used on the web server must match the https URL that users will use to connect to the https website. Subject name is analogous to the name on a driver’s license.

2. Validity Period: The (Valid From) and (Valid To) must be within the time frame the certificate is planning on being used. This is much like the expiration of a driver’s license. Validity period is analogous to the expiration date on a driver’s license.

3. Trust: The certificate must be used by a trusted Certificate Authority. Trust is analogous to the State that issued a driver’s license. Because the State that issued the license is a member of the union that makes up the United States we trust the issuer of the license.

4. Chain Building: Chain building is the process of building a trust chain, or certification path, from the end certificate to a root CA that is trusted by the security principal. The chain-building process will validate the certification path by checking each certificate in the certification path from the end certificate to the root CA’s certificate.

5. Key Usage: To help control the usage of a certificate outside of its intended purpose, the optional Enhanced Key Usage extension can be included in the certificate by the CA. The Enhanced Key Usage extension contains a list of usages for which the certificate is valid. These usages, also known as intended purposes, are displayed on the General tab of the certificate dialog box. This is important when evaluating why a certificate may not be working correctly. Key Usage is analogous to driver’s license endorsements (types of vehicles that can be driven with this license).

6. Revocation Checking: Each certificate in the certificate chain is verified to ensure that none of the certificates are revoked. A certificate can be revoked prior to the expiration date to disavow the certificate. Revocation Checking is analogous to checking a driver’s license against a State database to verify that a driver’s license has not been revoked for a violation.

En el caso que nos interesa hoy, el punto clave es el 6, donde se habla sobre la comprobación de revocación.

El certificado de la CA subordinada, al igual que cualquier certificado de usuario/cliente, viene con un campo/atributo “CRL Distribution Points” (CDP) donde se especifican uno o varios

· Puntos de acceso al directorio activo (rutas LDAP),

· Servidores web (direcciones http/https) o

· Recursos compartidos de red.

En estos CDP el cliente puede encontrar una lista de certificados revocados firmada por su CA emisora y comprobar si su propio certificado es válido o no.

El error recibido en el caso que estamos tratando nos indica que no se puede comprobar el estado de revocación de nuestro certificado (el de la propia CA Subordinada) porque o bien el servidor de revocación (donde comprobamos la lista de certificados revocados) está fuera de línea (apagado) o no se puede acceder a él.

En este caso, esto impide que arranquen los servicios de la CA, mientras que en otros escenarios, como en el inicio de sesión a través de tarjetas inteligentes (SmartCard), podría implicar que el usuario no pueda iniciar sesión en el dominio.

Troubleshooting/Solución

En el escenario que tratamos hoy, tenemos varias opciones para el diagnóstico/resolución del problema, en función de cómo esté configurado nuestro entorno:

1. Podría ser que la CA raíz que actualiza las listas de revocación (CRLs) realmente esté “offline” (y que la CRL que tiene la CA subordinada esté caducada)

· Es una práctica común mantener una CA Raíz apagada e inaccesible por cuestiones de seguridad

· Para resolver el problema, debería ser suficiente con volver a arrancar la CA raíz y publicar una nueva CRL. Normalmente, la CA Raíz publicará su lista (de larga duración) en un servidor web que se mantendrá en línea para que los clientes (la CA subordinada) puedan verificar la CRL por HTTP.

2. La CA Raíz o, en su defecto, el servidor donde se publican las CRLs sí está en línea y tiene publicada una CRL actualizada pero nuestro cliente (la CA Subordinada) no puede acceder a ella

· Normalmente, para verificar si podemos acceder correctamente a un CDP por HTTP podemos:

o Intentar navegar a la URL en una ventana de Internet Explorer

P.ej http://ServidorWeb/Crl/Archivo.crl

o Utilizar la herramienta Certutil para comprobar si podemos acceder

P.ej certutil -URL [URL]

certutil -URL http://ServidorWeb/Crl/Archivo.crl

o O podemos exportar una copia del certificado cuya revocación queremos comprobar y ejecutar el comando

certutil -url <exportedcert.cer>

En el cuadro de dialogo “Verify and Retrieve”que nos aparece, seleccionamos “From CDP” y verificamos el resultado

En el 99% de los casos, nosotros (el usuario con el que hemos hecho las pruebas) podremos acceder correctamente a la CRL por los métodos anteriores.

Entonces, la pregunta sería: ¿por qué el mensaje de error indica que el servidor de revocación esta fuera de línea? La clave está en el contexto de seguridad con el que se intenta acceder al CDP.

La CA funciona bajo el contexto de la cuenta Local System, o dicho de otra manera, de la propia cuenta de máquina. Por lo tanto, deberemos verificar si la cuenta de maquina puede acceder a los CDP al igual que nuestro usuario puede hacerlo.

Esta vez, para realizar las comprobaciones anteriormente descritas, utilizaremos la herramienta AT.exe (el programador de tareas de Windows Server 2003) para poder ejecutar los comandos en el contexto de Local System.

(NOTA: La correcta ejecución de las pruebas con AT.exe depende de que el programador de tareas este configurado para ejecutarse bajo la cuenta Local System – configuración por defecto en Windows)

· Programamos una tarea para lanzar una ventana de comandos a las 15:00:

AT 15:00 /INTERACTIVE CMD.EXE

· A las 15:00 se lanza una ventana de comandos en el contexto de Local System

· Desde esta ventana de comandos lanzamos Internet Explorer (iexplore.exe) y ejecutamos Certutil de nuevo para comprobar si la cuenta de maquina puede acceder correctamente a los CDP por http

Bajo el supuesto que estamos tratando hoy, en la mayoría de los casos, Certutil fallará al intentar verificar la URL especificada, e Internet Explorer mostrará un error de acceso o un cuadro de diálogo solicitando credenciales para acceder a la URL a través del proxy.

En este punto, ya habríamos determinado el origen del problema: La CA Subordinada efectivamente no puede acceder a la información de revocación porque la cuenta de maquina no puede acceder a la URL a través del proxy.

La solución suele radicar en dar permisos a nivel de proxy para que la máquina pueda acceder correctamente, o modificar las opciones de Proxy en la configuración de Internet Explorer (en el contexto de Local System)

Una vez hechos los cambios pertinentes, podemos comprobar que la maquina ya accede correctamente al CDP, y la CA ya podrá arrancar correctamente.

Enlaces de interés:

· Certificate Revocation and Status Checking

· Basic CRL checking with Certutil

· Troubleshooting Certificate Status and Revocation

- Tolu Igbon

La importancia de instalar las actualizaciones de seguridad (MS 08-067 y el virus Conficker)

esplat — Thu, 22 Jan 2009 12:30:00 GMT

Hola de nuevo, somos Juan Arlandis (Sistema Operativo) y Javier Rama (Directorio Activo / Networking).

En esta ocasión, y sumándonos al mensaje que lanzan nuestros compañeros en LATAM, hablaremos sobre la reciente oleada de casos que hemos recibido con respecto al tema.

El pasado mes de Octubre, Microsoft publicó el siguiente boletín de seguridad (MS 08-067) que corrige una vulnerabilidad en el servicio Servidor.

En caso de no haberlo hecho ya, recomendamos encarecidamente proceder a instalar cuanto antes esta actualización en todos los equipos de vuestros entornos.

958644 MS08-067: Vulnerability in Server service could allow remote code execution

A partir de aquí, y explotando esta vulnerabilidad, han ido apareciendo multitud de virus/gusanos que pueden manifestarse de diversas maneras en el entorno.

Desde Soporte, los síntomas más comunes que hemos observado son:

· Parada de los servicios Server y Browser (casi siempre han sido asociados al virus Conficker.A)

Comportamientos tales como servicios no disponibles, recursos que han dejado de estar compartidos, etc. han sido el síntoma inicial.

Un estudio más en profundidad, suele revelar la existencia de un servicio (con nombres con letras aleatorias tales como qbmmf) extraño instalado en el servidor afectado.

· Bloqueo de múltiples cuentas del dominio (variante del anterior y comúnmente denominada Conficker.B)

Podemos consultar una descripción amplia de este virus, así como un procedimiento para determinar si una máquina está infectada, en el siguiente enlace:

http://www.microsoft.com/security/portal/Entry.aspx?Name=Worm%3aWin32%2fConficker.B

Ante una infección de nuestros sistemas, será necesario tanto proceder a instalar la actualización KB 958644 como eliminar el virus de todas las máquinas.

Para eliminar el virus de las máquinas, podemos utilizar cualquiera de los múltiples software de antivirus existentes en el mercado.

(teniendo el fichero de firmas correspondiente en su versión lo más actualizada posible)

En caso de no ser capaces de detectarlo con él, siempre tenemos disponible el scanner online One Care Live.

Para esta solución, el único requisito es que el equipo afectado tenga conexión a Internet.

Por último comentar que, muy posiblemente, estén surgiendo variantes nuevas de los virus mencionados más arriba.

Por ello, nuevamente advertiros sobre la importancia de mantener nuestros servidores actualizados.

Enlaces relacionados

Esperamos que esta información os haya servido de utilidad,

- Javier Rama del Castillo y Juan Arlandis Villarroya

Directorio Activo, RPC, puertos efímeros y firewalls

esplat — Fri, 28 Nov 2008 00:51:00 GMT

Hola de nuevo. Soy Paula del equipo de Directorio Activo.

Hoy hablaremos sobre el funcionamiento básico de RPC que afecta a diferentes operaciones de Directorio Activo. Como seguramente la mayor parte de vosotros ya sabe, la comunicación utilizada para múltiples operaciones en Directorio Activo es RPC. Estas operaciones incluyen, por ejemplo, la replicación de DA, la replicación FRS, la promoción de un nuevo Controlador de Dominio, etc. También realizan conexiones RPC a los DCs la ejecución del comando dcdiag /v o incluso consultar qué DCs son los maestros de operaciones (mediante el comando netdom query fsmo). También es muy común que tratemos casos con problemas de conectividad RPC en que la replicación de DA y/o FRS no se lleva a cabo de manera satisfactoria o incluso que la replicación de DA funcione perfectamente pero los Controladores de Domino no puedan replicar SysVol por FRS.

En una comunicación RPC, el cliente se conecta al puerto TCP 135 del servidor y solicita un puerto al End Point Mapper (EPM) para comenzar la conversación RPC. El EPM del servidor reserva un puerto (llamado puerto dinámico) para este cliente y se lo envía. A partir de este punto, el cliente abre una nueva conexión TCP a dicho puerto del servidor y comienza la comunicación.

Los puertos dinámicos RPC (o puertos efímeros) que puede utilizar el EPM de RPC (o RPCSS) van del 1025 hasta el 65535, aunque Windows 2000/XP/2003 por defecto utilizan puertos que están comprendidos en el rango 1025-5000 (en total 3976 puertos). En Windows Vista y Windows Server 2008, el rango de puertos por defecto es 49152-65535 (un total de 16384 puertos).

Puede encontrarse más información en el siguiente artículo (muy recomendable para identificar y entender los pasos a seguir cuando nos encontramos ante un problema con el RPC Endpoint Mapper):

839880 Troubleshooting RPC Endpoint Mapper errors using the Windows Server 2003 Support Tools from the product CD

Cuando no se puede establecer la conexión por estos puertos efímeros, al realizar las operaciones que hemos comentado anteriormente podemos recibir errores como el siguiente:

There are no more endpoints available from the endpoint mapper.

Vamos a ver unas trazas de red de ejemplo de un establecimiento de una comunicación RPC fallida debido a que el cliente no puede establecer la sesión al puerto dinámico que le indica el EPM del servidor.

Las trazas de red las podéis capturar con cualquier sniffer, por ejemplo en este caso nosotros hemos utilizado Microsoft Network Monitor 3.2.

Esta es la conversación inicial RPC entre un DC y una máquina desde la que se ejecuta la operación netdom query fsmo:

Fuente	Destino	Protocolo	Descripción
cliente	dc	TCP	TCP:Flags=......S., SrcPort=1687, DstPort=DCE endpoint resolution(135), PayloadLen=0, Seq=721180773, Ack=0, Win=65535 ( ) = 65535
dc	cliente	TCP	TCP:Flags=...A..S., SrcPort=DCE endpoint resolution(135), DstPort=1687, PayloadLen=0, Seq=3452375582, Ack=721180774, Win=16384 ( Scale factor not supported ) = 16384
cliente	dc	TCP	TCP: [Bad CheckSum]Flags=...A...., SrcPort=1687, DstPort=DCE endpoint resolution(135), PayloadLen=0, Seq=721180774, Ack=3452375583, Win=65535 (scale factor 0x0) = 65535
cliente	dc	MSRPC	MSRPC:c/o Bind: UUID{E1AF8308-5D1F-11C9-91A4-08002B14A0FA} EPT Call=0x1 Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0
dc	cliente	MSRPC	MSRPC:c/o Bind Ack: Call=0x1 Assoc Grp=0x14EE2 Xmit=0x16D0 Recv=0x16D0
cliente	dc	EPM	EPM:Request: ept_map: NDR, DRSR {E3514235-4B06-11D1-AB04-00C04FC2DCD2} v4.0, RPC v5, 0.0.0.0:135 (0x87) [DCE endpoint resolution(135)]
dc	cliente	EPM	EPM:Response: ept_map: NDR, DRSR {E3514235-4B06-11D1-AB04-00C04FC2DCD2} v4.0, RPC v5, 10.200.8.59:1025 (0x401) [*1025*]
cliente	dc	TCP	TCP: [Bad CheckSum]Flags=...A...F, SrcPort=1687, DstPort=DCE endpoint resolution(135), PayloadLen=0, Seq=721181002, Ack=3452375795, Win=65323 (scale factor 0x0) = 65323
dc	cliente	TCP	TCP:Flags=...A...., SrcPort=DCE endpoint resolution(135), DstPort=1687, PayloadLen=0, Seq=3452375795, Ack=721181003, Win=65307 (scale factor 0x0) = 65307
dc	cliente	TCP	TCP:Flags=...A...F, SrcPort=DCE endpoint resolution(135), DstPort=1687, PayloadLen=0, Seq=3452375795, Ack=721181003, Win=65307 (scale factor 0x0) = 65307
cliente	dc	TCP	TCP: [Bad CheckSum]Flags=...A...., SrcPort=1687, DstPort=DCE endpoint resolution(135), PayloadLen=0, Seq=721181003, Ack=3452375796, Win=65323 (scale factor 0x0) = 65323

En la respuesta del End Point Mapper (EPM) del DC ante la solicitud de conexión del cliente (trazas en rojo), el DC indica que van a continuar hablando por el puerto TCP 1025. Si filtramos el tráfico generado en el cliente con destino el DC y puerto 1025, vemos los siguientes intentos de conexión al mismo:

Fuente	Destino	Protocolo	Descripción
cliente	dc	TCP	TCP:Flags=......S., SrcPort=1688, DstPort=1025, PayloadLen=0, Seq=570735085, Ack=0, Win=65535 ( ) = 65535
cliente	dc	TCP	TCP:[SynReTransmit #63]Flags=......S., SrcPort=1688, DstPort=1025, PayloadLen=0, Seq=570735085, Ack=0, Win=65535 ( ) = 65535
cliente	dc	TCP	TCP:[SynReTransmit #63]Flags=......S., SrcPort=1688, DstPort=1025, PayloadLen=0, Seq=570735085, Ack=0, Win=65535 ( ) = 65535
cliente	dc	TCP	TCP:[SynReTransmit #63]Flags=......S., SrcPort=1688, DstPort=1025, PayloadLen=0, Seq=570735085, Ack=0, Win=65535 ( ) = 65535

Como podemos ver claramente en las trazas de red, el cliente trata de conectarse varias veces a dicho puerto en el DC y no recibe respuesta (ver retransmisiones). Si observamos unas trazas de red simultáneas a las anteriores pero obtenidas en el DC (capturar el tráfico en ambos extremos es muy recomendable en este tipo de situaciones), únicamente se observa la conversación inicialmente descrita en la primera tabla. Es decir, el DC no llega a recibir los paquetes que el cliente le envía por el puerto 1025.

Lo más probable en este caso es que haya un firewall que esté bloqueando las comunicaciones. Puede ser un firewall hardware/software, el firewall integrado de Windows o incluso un antivirus con funcionalidad de firewall. (Tened también en cuenta que no todos los problemas relacionados con conectividad RPC se deben a la configuración de los firewalls!!!)

Ante esta situación tenemos dos opciones para evitar el bloqueo:

Abrir los puertos comprendidos entre el 1025 y el 5000 en el firewall para permitir la negociación/tráfico RPC entre las máquinas implicadas
Configurar RPC en el DC para utilizar un rango de puertos específicos y abrir dichos puertos en el firewall para permitir la negociación/tráfico RPC entre dichas máquinas

La desventaja que hay que tener en cuenta es la posibilidad de que en determinados momentos no haya puertos disponibles al estar todos en uso, por lo que habrá que realizar pruebas y verificar cuál es el número de puertos adecuado para el entorno. Hay que tener en cuenta que los DCs utilizan RPC para multitud de funcionalidades, como puede ser la replicación de DA o FRS.
El mecanismo para Windows 2000/XP/2003 se define en el siguiente artículo: 154596 How to configure RPC dynamic port allocation to work with firewalls
El artículo anterior también apunta a mecanismos para configurar si se prefiere, por ejemplo, un único puerto concreto para la replicación FRS en lugar de un rango de puertos.
El mecanismo para Windows Vista/2008 se define en el siguiente artículo: 929851 The default dynamic port range for TCP/IP has changed in Windows Vista and in Windows Server 2008

Si queréis obtener una lista completa de los puertos necesarios para el correcto funcionamiento de un entorno de Directorio Activo, echadle un vistazo a los siguientes artículos:

Espero que esta información os sirva de utilidad, ya que es uno de los problemas que tratamos más frecuentemente y su detección es relativamente sencilla a partir de unas trazas de red.

- Paula Tomás Galed

Blogs recomendados sobre Directorio Activo

esplat — Tue, 11 Nov 2008 13:24:00 GMT

Hola. Soy Paula de nuevo. Hoy quería comentaros que nuestros compañeros de Soporte MS a Directorio Activo de Estados Unidos tienen blogs muy interesantes y de gran calidad que merece la pena leer y agregar a vuestros lectores RSS:

Ask the Directory Services Team: http://blogs.technet.com/askds
Tim Springston's Active Directory Blog: http://blogs.technet.com/ad/

Podéis encontrar un enlace a estos blogs también en la barra lateral de nuestro blog.

Como los blogs están en inglés, si tenéis algún problema, podéis usar el traductor online de Windows Live :):

- Paula Tomás Galed

Cómo añadir una capa de seguridad extra a las Relaciones de Confianza habilitando Autenticación Selectiva

esplat — Tue, 07 Oct 2008 20:01:00 GMT

Hola a todos. Soy Paula, del equipo de Directorio Activo. Hoy trataremos sobre cómo configurar una relación de confianza de tal manera que podamos restringir qué usuarios acceden a qué recursos.

La manera de restringir el acceso a recursos de un dominio a determinados usuarios de otro dominio con el que se tiene una relación de confianza externa (external trust) o de bosque (forest trust) es configurando dicha relación de confianza para que realice una Autenticación Selectiva. La siguiente imagen procedente de aqui muestra gráficamente la diferencia en el acceso a los recursos dependiendo del tipo de autenticación que se configure (en todo el dominio/bosque o selectiva):

Autenticación en todo el dominio/bosque:

Autenticación selectiva:

Sólo puede habilitarse este tipo de autenticación en relaciones de confianza de bosque o externas. En el caso de una relación de confianza de bosque, el bosque donde residen los recursos (trusting forest) debe tener el nivel funcional del bosque establecido a Windows Server 2003. Si la relación es externa, el dominio donde residen los recursos (trusting domain) debe tener el nivel funcional del dominio establecido a Windows Server 2000 nativo.

Para habilitar la Autenticación Selectiva pueden seguirse estos pasos con un usuario que sea miembro del grupo Domain Admins del dominio (del dominio root si es una relación de confianza de bosque) o Enterprise Admins:

Abrir la consola Dominios y Relaciones de confianza de Directorio Activo
Hacer click derecho sobre el nodo del dominio que tiene la relación de confianza (si es un forest trust, el nodo será el dominio raíz del bosque) y seleccionar Propiedades
En la pestaña Confía, seleccionar la relación de confianza que queramos configurar y hacer click sobre el botón Propiedades
En la pestaña Autenticación, seleccionar Autenticación Selectiva

Para que un usuario de un dominio en el que se confía (trusted) pueda acceder a los recursos del dominio que “confía” (trusting) con este tipo de autenticación es necesario dar permisos explícitos a los usuarios del dominio trusted en los recursos determinados del dominio trusting a los que se quiera dar acceso. Este permiso se configura en Directorio Activo en las propiedades del objeto Computer del servidor de recursos concreto y se denomina Allowed to Authenticate (Permitido Autenticarse).

Abrir la consola Usuarios y Equipos de Directorio Activo del dominio donde se encuentra la máquina con el recurso al que los usuarios del otro dominio deben acceder
Hacer click derecho sobre la cuenta de máquina y seleccionar Propiedades
En la pestaña Seguridad, otorgar el permiso de Permitido Autenticarse

Si la relación de confianza que se establece entre dos dominios es unidireccional, para poder agregar a los usuarios del dominio trusted a la seguridad de la cuenta de máquina del servidor a través de la consola de Usuarios y Equipos de Active Directory, se solicita un usuario con permisos para realizar consultas en el dominio trusted. El artículo KB 263956 (You cannot browse users in a trusted domain) describe este escenario y especifica que se necesita un usuario del otro dominio para poder realizar las búsquedas en el dominio trusted desde el dominio trusting cuando existe una relación de confianza de un solo sentido. Para esta operación es suficiente con un Domain User.

Los artículos que recopilan la información sobre Selective Authentication y el permiso Allowed to Authenticate que hay que darle a los usuarios del dominio en el que se confía son los siguientes:

Enable selective authentication over an external trust

Grant the Allowed to Authenticate permission on computers in the trusting domain or forest

Información interesante sobre consideraciones de seguridad a tener en cuenta a la hora de establecer una relación de confianza y sobre cómo funciona, cómo afecta a los DCs y qué ventajas presenta en cuanto a seguridad una Relación de Confianza con Autenticación Selectiva:

Security Considerations for Trusts

Más información sobre Relaciones de Confianza:

How Domain and Forest Trusts Work

Tener acceso a los recursos entre bosques

- Paula Tomás Galed

Cómo configurar el Firewall de Windows para el perfil de dominio excluyendo un interfaz de red

esplat — Fri, 26 Sep 2008 12:47:00 GMT

Hola, soy Javier Rama, del equipo de Directorio Activo / Networking. En algunas ocasiones hemos tenido casos en los que el cliente necesita configurar el Firewall de Windows a través de GPO en su dominio.

Como sabemos, tenemos multitud de settings para configurarlo desde la consola de edición de Políticas de Grupo en:

Computer Configuration\Administrative Templates\Network\Network Connections\Windows Firewall

Sin embargo, puede haber ocasiones en que necesitemos deshabilitar todas las reglas y excepciones que aplicamos en el Firewall para un interfaz de red concreto del equipo.

Esto no podemos conseguirlo directamente con el conjunto de parámetros que podemos configurar a través de GPO.

Para conseguirlo, debemos realizar los siguientes pasos:

1. Deshabilitar la siguiente política en el perfil de Dominio, Windows Firewall: Protect all network connections

Gracias a este setting , habilitamos o deshabilitamos el Firewall de Windows.

El inconveniente que nos encontramos estableciéndolo es que, además de habilitar el Firewall, también lo configuramos para que aplique todas las reglas en todos los interfaces de red disponibles en la máquina destino.

Por tanto, lo deshabilitaremos estableciéndolo a Disabled y ,como veremos a continuación, activaremos el Firewall gracias a la herramienta netsh.

2. A continuación, crearemos un script de inicio para el equipo con el siguiente contenido:

netsh firewall set opmode mode=enable profile=domain (Habilitar el Firewall de Windows para el perfil de dominio)

netsh firewall set opmode mode=enable interface=”Red” (Proteger este interfaz de red con el Firewall de Windows)

netsh firewall set opmode mode=disable interface=”Red Externa” (No aplicar las reglas del Firewall para este intefaz)

…

(Continuar con todos los dispositivos poniéndolos a enable o disable según nos interese)

Como vemos, es necesario especificarle el nombre completo de cada interfaz de red.

Tras la aplicación de este script, conseguiremos el siguiente efecto:

3. El resto de parámetros que queramos configurar, tales como reglas específicas o excepciones, podemos hacerlo normalmente a través de GPO.

- Javier Rama del Castillo

Ocultando ficheros y carpetas de un share con ABE en Windows Server 2003

esplat — Mon, 22 Sep 2008 17:50:00 GMT

Hola, soy Javier Rama, del equipo de Directorio Activo / Networking.

Hace algunos días, un cliente nos preguntaba cómo ocultar las carpetas y ficheros de un share a los usuarios que no tienen permisos para acceder a ellos.

Para acometer dicha tarea, tenemos disponible la tecnología ABE (Access Based Enumeration) gracias a la cual, el servidor de ficheros ocultará las carpetas y ficheros en función de los permisos del usuario que accede a dicho recurso.

ABE es una funcionalidad que está incluida en Windows Vista y en Windows Server 2008, pero además está disponible como descarga para Windows Server 2003 en el siguiente enlace:

Microsoft Download Center: Windows Server 2003 Access-based Enumeration

http://www.microsoft.com/downloads/details.aspx?FamilyId=04A563D9-78D9-4342-A485-B030AC442084&displaylang=en

Antes de habilitar ABE sobre cualquier recurso compartido, debemos tener en cuenta las siguientes consideraciones:

· ABE está pensada únicamente para shares de red, por ejemplo \\servidor\carpeta. Sin embargo, si accedemos a través del explorador (ruta C:\carpeta por ejemplo) esta tecnología no nos servirá.

· Además, también es oportuno apuntar que, habilitar ABE sobre una carpeta compartida añade una carga extra de CPU al servidor (el cual comprobará los permisos del usuario que intenta acceder con el contenido de la carpeta, y determinar así qué elementos mostrar). En escenarios en los que se produzcan muchos accesos a los recursos, será necesario tener en cuenta este punto.

CONFIGURANDO ABE

1- Una vez instalado ABE, será necesario habilitarlo en cada uno de los shares que deseemos. Para ello podemos proceder de dos maneras:

a) A través de la interfaz gráfica de usuario (Clic derecho sobre el share -> Propiedades -> Pestaña Access Based Enumeration -> Marcar checkbox Enable Access-based Enumeration in this shared folder ).

b) Desde línea de comando a través de la herramienta abecmd

Se puede encontrar información detallada sobre este comando en en siguiente enlace:

Windows Server 2003 Access-based Enumeration

http://www.microsoft.com/windowsserver2003/techinfo/overview/abe.mspx

2- Una vez habilitado ABE sobre un share y, habiendo configurado los permisos oportunos para los distintos usuarios, conseguiremos el efecto que aparece en las siguientes capturas (los ejemplos que aparecen a continuación corresponden al enlace anterior):

Figura 1 - Recurso compartido “Customer Accounts” con ABE deshabilitado.

Como vemos en la Figura 1, el usuario puede ver todo el contenido del share independientemente de tener permisos de acceso para cada elemento o no.

Con el checkbox Enable access-based enumeration on this folder habilitado desde las propiedades de la carpeta “Customer Accounts” , el usuario únicamente ve las carpetas a las cuales puede acceder (Figura 2).

Figura 2 - Recurso compartido “Customer Accounts” con ABE habilitado.

- Javier Rama del Castillo

Cómo auditar la creación y el borrado de zonas DNS integradas en DA

esplat — Thu, 18 Sep 2008 13:43:00 GMT

Hola, soy Paula, del equipo de Directorio Activo. Hoy vamos a hablar de cómo habilitar la auditoria para poder disponer de información en el caso de que se cree o elimine una zona DNS integrada en Directorio Activo.

Habilitar la auditoría va a conllevar que el log de eventos de Seguridad registre una cantidad mayor de eventos, con lo que requerirá mayor espacio en disco (para no perder eventos, se puede incrementar el tamaño del log).

Los pasos a seguir para habilitar la auditoría son los siguientes:

1. Habilitar la auditoría al acceso a los servicios de directorio (Directory Service Access):

a. Editar la política Default Domain Controllers Policy o crear una nueva GPO en la OU de los controladores de dominio. Si se tienen varios dominios y se desea auditar la actividad en todos dependiendo del tipo de replicación de la zona, habrá que habilitar la auditoría en todos ellos.

b. Habilitar Success (también se puede auditar Failure) en la siguiente ruta de la GPO:

Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy > Audit directory service access

2. Establecer la auditoría sobre el objeto de Directorio Activo que deseemos. Esta operación se puede realizar, por ejemplo, mediante ADSIEdit:

a. Acceder a la partición que se desee auditar (Botón derecho sobre la raíz "ADSI Edit" y seleccionar Connect to...). Como se comentó anteriormente aquí, las zonas DNS pueden albergarse bajo el contenedor MicrosoftDNS en tres particiones diferentes en Directorio Activo dependiendo de su configuración de replicación:

CN=MicrosoftDNS,CN=System,DC=domain,dc=com -> Partición del dominio: La zona está configurada para replicar a todos los DCs del dominio

CN=MicrosoftDNS,DC=DomainDNSZones,DC=domain,DC=com -> Partición de aplicación DomainDNSZones: La zona replica a todos los servidores DNS del dominio

CN=MicrosoftDNS,DC=ForestDNSZones,DC=domain,DC=com -> Partición de aplicación ForestDNSZones: La zona replica a todos los servidores DNS del bosque

b. Acceder a las propiedades de la partición ForestDNSZones (por ejemplo) > Seguridad > Avanzadas > Auditoría

Agregar al usuario Everyone (o al usuario/grupo que se desee auditar)

Aplicar a Container objects

Tipo de acceso Create dnsZone Objects y Delete dnsZone Objects

Una vez se habilite, esta configuración es homogénea para todo el dominio, es decir, todos los DCs van a auditar estos accesos. Siempre es recomendable que se realicen algunos tests en un entorno de pruebas para comprobar que la auditoria cumple los requisitos que se necesitan.

Un ejemplo del evento que se generan al crear una nueva zona:

Event Type: Success Audit

Event Source: Security

Event Category: Directory Service Access

Event ID: 566

Date: 9/18/2008

Time: 1:17:42 PM

User: HALEDOMAIN\paula

Computer: HALEDC01

Description:

Object Operation:

Object Server: DS

Operation Type: Object Access

Object Type: container

Object Name: CN=MicrosoftDNS,DC=ForestDnsZones,DC=haledomain,DC=com

Handle ID: -

Primary User Name: HALEDC01$

Primary Domain: HALEDOMAIN

Primary Logon ID: (0x0,0x3E7)

Client User Name: paula

Client Domain: HALEDOMAIN

Client Logon ID: (0x0,0x226DB)

Accesses: Create Child

Properties:

Create Child

dnsZone

Additional Info: DC=prueba.com,cn=MicrosoftDNS,DC=ForestDnsZones,DC=haledomain,DC=com

Additional Info2: DC=prueba.com,CN=MicrosoftDNS,DC=ForestDnsZones,DC=haledomain,DC=com

Access Mask: 0x1

Ejemplo de una eliminación:

Event Type: Success Audit

Event Source: Security

Event Category: Directory Service Access

Event ID: 566

Date: 9/18/2008

Time: 1:31:20 PM

User: HALEDOMAIN\paula

Computer: HALEDC01

Description:

Object Operation:

Object Server: DS

Operation Type: Object Access

Object Type: dnsZone

Object Name: DC=..Deleted-prueba.com\0ADEL:39fd87f0-46f8-4474-8a53-1392aaf34a95,CN=Deleted Objects,DC=ForestDnsZones,DC=haledomain,DC=com

Handle ID: -

Primary User Name: HALEDC01$

Primary Domain: HALEDOMAIN

Primary Logon ID: (0x0,0x3E7)

Client User Name: paula

Client Domain: HALEDOMAIN

Client Logon ID: (0x0,0x226DB)

Accesses: DELETE

Properties:

DELETE

dnsZone

Additional Info:

Additional Info2:

Access Mask: 0x10000

Esperamos que esta información os sirva en caso de que necesitéis auditar la creación/borrado de zonas DNS.

- Paula Tomás Galed