Error al ejecutar Netdom.exe - The procedure entry point I_NetNameValidate could not be located

El día de hoy me encontrado con el siguiente mensaje de error al tratar de ejecutar el comando Netdom.exe

"The procedure entry point I_NetNameValidate could not be located in the dynamic link library NETAPI32.dll."

Después de investigar un poco, noté que se encontraban instaladas las Support Tools de Windows, y en ellas se encuentra también el comando Netdiag el cual ya no se encuentra disponible en Windows Server 2008, al intentar ejecutarlo desde la línea de comando se obtiene el siguiente error:

"The procedure entry point I_NetNameValidate could not be located in the dynamic link library NETAPI32.dll"

Muy parecido al arrojado por Netdom verdad?, entonces al mirar la variable de entorno que se utiliza para la ejecución de comandos se observa el valor que hace referencia a las support tools, como se muestra en la siguiente imagen:

Entonces, borré lo que se encuentra encerrado en rojo "C:\Program Files(x86)\Support Tools;", quedando de la siguiente manera:

Al terminar de realizar este ajuste, volví a la línea de comandos a digitar nuevamente el comando Netdom y efectivamente en esta ocasión si funcionó sin arrojar el error:

Cómo exportar permisos NTFS de carpetas con PowerShell

En esta ocasión veremos el código necesario en PowerShell para exportar a un archivo CSV los permisos de una carpeta y todas sus subcarpetas, lo cual puede llegar a ser de utilidad para ustedes en cualquier momento.

Voy a exportar los permisos en una estructura que he creado en mi disco C:\ y es la siguiente: 

Ahora, abrimos una consola de PowerShell y escribimos lo siguiente:

Get-Childitem -path "C:\Folder" -recurse | Where-Object {$_.PSIsContainer} | Get-ACL| Select-Object Path -ExpandProperty Access | Export-CSV "C:\Folder\ntfs_permisos_folder.csv" -NoTypeInformation

Lo que aparece en negrilla debe reemplazarlo por sus propias rutas.

Lo anterior, generará un archivo csv llamado ntfs_permisos_folder.csv en la ruta C:\Folder, el archivo contiene los permisos de la carpeta Folder incluyendo las subcarpetas subfolder1 y subfolder2 mostradas en la primer imagen.

Espero esta información les sea de utilidad.

Comando dfsrdiag no reconocido en Windows Server 2012 R2

Al intentar utilizar el comando dfsrdiag.exe en Windows Server 2012, es posible encontrar que el comando no se es reconocido.

Esto sucede debido a que en Windows Server 2012 la herramienta no está instalada de manera predeterminada, para instalar debemos hacer lo siguiente:

1. Abrir Server Manager

2. En el menú Administrar seleccionar Agregar Roles y Características

3. Seleccionar la opción de Características y expandir

 Remote Server Administrtion Tools\Role Administration Tools\File Services Tools\DFS Management Tools

Activamos la característica DFS Management Tools y hacemos clic en Install

Una vez termine el proceso de instalación, volvemos a digitar el comando dfsrdiag desde la consola de comandos y de este modo ya podemos disponer de él.

¿Qué es AdminSDHolder en Active Directory?

El propósito del objeto AdminSDHolder es proporcionar una "plantilla" de permisos para las cuentas y grupos protegidos en un dominio de Active Directory, AdminSDHolder es creado de manera automática como un objeto del contenedor System en cada dominio, su ruta es: CN=AdminSDHolder,CN=System,DC=,DC=

Al contrario de muchos objetos en Active Directory cuyo propietario es el grupo Administradores, AdminSDHolder tiene como propietario el grupo Domain Admins, de manera predeterminada los miembros del grupoEnterprise Admins pueden hacer cambios en el objeto AdminSDHolder, sin embargo aunque el propietario de este objeto es el grupo Domain Admins, los miembros del grupo Administrators y Enterprise Admins pueden tomar propiedad de este objeto.

Pero, mejor de manera gráfica veamos cómo funciona este objeto, si se compara la lista de control de acceso (ACL) de un grupo protegido, por ejemplo Domain Admins con la del objeto AdminSDHolder se puede apreciar que son exactamente iguales.

Si revisamos la ACL de cualquier cuenta o grupo protegido podemos ver que tiene siempre la misma ACL y esta ACL es simplemente un reflejo de la ACL del objeto AdminSDHolder, pero dónde encontramos dicho objeto?

En la consola Usuarios y Equipos de Active Directory podemos ver el contenedor System y al expandirlo veremos el objeto AdminSDHolder

Simplemente hacemos clic derecho sobre el objeto, propiedades, y seleccionamos la pestaña Seguridad para ver la ACL que se propaga sobre las cuentas y grupos protegidos.

Ahora, hagamos una prueba, utilicemos una cuenta protegida y modifiquemos su ACL, agreguemos un usuario llamado John Smith y otorgemosle control total sobre la cuenta protegida Usuario1

Bien, hasta este momento el usuario John Smith tiene control sobre la cuenta protegida Usuario1, de igual modo pudo haber modificado la ACL de un grupo protegido, por ejemplo Domain Admins, es en este momento que entra en acción el objeto AdminSDHolder y "protegerá" la ACL del objeto modificado, en este caso la cuenta Usuario1, y la tarea es sencilla, simplemente remplazar la ACL del objeto modificado por la ACL del objeto AdminSDHolder.

Como podemos apreciar, en la ACL de Usuario1 ya no se encuentra la entrada para el usuario John Smith que se agregó en el paso anterior, esto debido a que el proceso automático se encargó de establecer la ACL de la cuenta protegida.

En resumen, el objeto AdminSDHolder contiene los permisos predeterminados de todas las cuentas y grupos protegidos, si no sabes cuáles son puedes revisar este artículo, si una ACL de cualquiera de los objetos protegidos es modificada, ésta será restablecida tomando como base la ACL definida en el objeto AdminSDHolder.

¿Qué es SDProp en Active Directory?

SDProp (Security Descriptor Propagator), es un proceso que se ejecuta cada 60 minutos por defecto,en el controlador de dominio que tiene el rol de emulador PDC. SDProp compara los permisos del objetoAdminSDHolder con los permisos de cuentas y grupos protegidos en el dominio, si los permisos de alguna cuenta o grupo protegido no coinciden con los que contiene el objeto AdminSDHolder, los permisos establecidos en las cuentas o grupos protegidos son restablecidos de tal forma que coincidan con los definidos en el objeto AdminSDHolder.

Adicional a lo anterior, la herencia será deshabilitada en las cuentas y grupos protegidos, lo cual significa que si alguno de estos objetos es movido a una ubicación diferente en el directorio, éste no heredará los permisos de los objetos padre en la nueva ubicación. la herencia es deshabilitada en el objeto AdminSDHolder, con lo cual cualquier cambio en la herencia del objeto padre no afectará lo establecido en el objetoAdminSDHolder.

Caso de la vida real: Muchas veces me he encontrado con administradores que no se explican porqué la herencia en un usuario o grupo está deshabilitada y a pesar de que se habilite vuelve a su estado después de un momento (ese momento son los 60 minutos que tarda en ejecutarse el SDProp), así que usted ya sabe que si esto ocurre es un proceso normal dado que se trata de una cuenta o grupo protegido.

¿Porqué se deshabilita la herencia?...usted ya lo sabe :-)

Cambiar el intervalo del SDProp en Active Directory

De manera predeterminada el proceso SDProp se ejecuta cada 60 minutos, normalmente usted no necesita cambiar este intervalo de tiempo, a menos que lo desee hacer con propósitos de prueba, si usted necesita cambiar este intervalo debe hacerlo sobre el controlador de dominio que tiene el rol emulador PDC, modificando el valor de registro AdminSDProtectFrequency que se encuentra en la siguiente rama:

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

El rango de valores está dado en segundos, desde 60 hasta 7200 (un minuto a dos horas). Para reversar los cambios hechos en el registro basta con eliminar la llave AdminSDProtectFrequency, esto causará que el tiempo de ejecución del SDProp se restablezca a su valor por defecto (60 minutos).

Generalmente usted no debería reducir el intervalo de tiempo por defecto en un ambiente de producción, ya que esto puede incrementar la carga de procesamiento de LSASS en el controlador de dominio, el impacto puede variar dependiendo del número de objetos protegidos existentes en el dominio. Veamos el paso a paso.

1. Abra el editor de registro y expanda la siguiente rama: HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

2. En un área vacía de la parte derecha del editor haga clic derecho, en el menú Nuevo seleccione DWORD

3. Escriba el siguiente nombre para la llave: AdminSDProtectFrequency

4. Establezca el nuevo valor en segundos entre 60 y 7200 y haga clic en OK

De esto modo tenemos un nuevo intervalo de ejecución para el proceso SDProp

Ejecutar proceso SDProp manualmente en Active Directory

El proceso SDProp se ejecuta automáticamente cada 60 minutos, este intervalo de tiempo puede ser cambiado y puede definirse entre 60 y 7200 segundos (vea aquí cómo hacerlo), pero también podemos manualmente generar la ejecución del mismo, revisemos cómo.

Es importante tener en cuenta que este proceso es ligeramente diferente en Windows Server 2008 y Windows Server 2012, así que antes de ejecutarlo tenga en cuenta su versión de Windows.

Ejecutar SDProp manualmente en Windows Server 2008 y anteriores

1. En ejecutar escriba ldp y presione Enter

2. En la ventana ldp haga clic en Connection y luego en Connect

3. En el cuadro de diálogo Connect escriba el nombre del controlador de dominio que tiene el rol emulador PDC y haga clic en OK

4. Una vez conectado, haga clic en Connection/Bind

5. En el cuadro de diálogo Bind escriba las credenciales de una cuenta de usuario que tenga privilegios para modificar el objeto rootDSE, si ya está logueado con un usuario que posea estos permisos, simplemente haga clic en Bind as currently logged on user y haga clic en OK

6. Luego, hacemos clic en Browse y clic en Modify 

7. En el cuadro de diálogo Modify, deje en blanco el campo DN. En el campo Edit Entry Attribute digite FixUpInheritance, y en el campo Values escriba Yes, luego haga clic en Enter para poblar el campo Entry List y haga clic en Run

Por último verifique que efectivamente los permisos definidos en el objeto AdminSDHolder han sido aplicados en la ACL de la cuenta o grupo protegido.

Ejecutar SDProp manualmente en Windows Server 2012 o Windows Server 2008 R2.

1. En ejecutar escriba ldp y presione Enter

2. En la ventana ldp haga clic en Connection y luego en Connect

3. En el cuadro de diálogo Connect escriba el nombre del controlador de dominio que tiene el rol emulador PDC y haga clic en OK

4. Una vez conectado, haga clic en Connection/Bind

5. En el cuadro de diálogo Bind escriba las credenciales de una cuenta de usuario que tenga privilegios para modificar el objeto rootDSE, si ya está logueado con un usuario que posea estos permisos, simplemente haga clic en Bind as currently logged on user y haga clic en OK

6. Luego, hacemos clic en Browse y clic en Modify 

7. En el cuadro de diálogo Modify, deje en blanco el campo DN. En el campo Edit Entry Attribute digite RunProtectAdminGroupsTask, y en el campo Values escriba 1, luego haga clic en Enter para poblar el campo Entry List y haga clic en Run

Por último verifique que efectivamente los permisos definidos en el objeto AdminSDHolder han sido aplicados en la ACL de la cuenta o grupo protegido, como se puede apreciar la diferencia entre las versiones de Windows se enccuentra en este último paso.

Cuentas y grupos protegidos en Active Directory

En Active Directory existe un conjunto de cuentas y grupos que son considerados "protegidos", generalmente si tenemos administradores designados estos mismos pueden cambiar y asignar permisos incluso pueden agregarse como miembros a cualquier grupo.

Con cuentas y grupos protegidos, los permisos de los objetos son establecidos de manera forzosa a través de un proceso automático que asegura que los permisos en los objetos permanezcan estables, incluso si el objeto es movido dentro del directorio, lo cual significa que si alguien (por ejemplo un administrador designado) cambia de manera manual los permisos de un objeto protegido en Active Directory éstos retornarán a su estado original o "por defecto" de manera automática.

Los siguientes son los grupos protegidos en un controlador de dominio:

• Administrators
• Domain Admins
• Enterprise Admins
• Schema Admins

Ahora bien, algo importante a considerar es que las cuentas pertenecientes a un grupo protegido automáticamente se convertirán en cuentas protegidas.

Para identificar una cuenta o grupo protegido, basta con revisar las propiedades del objeto y revisar el valor del atributo adminCount si está establecido en 1 significa que se trata de una cuenta o grupo protegido, de lo contrario este valor no estará establecido, veámos un ejemplo.

Revisemos el atributo adminCount de la cuenta Administrator.

Como podemos apreciar el valor efectivamente es 1, si no puedes ver la pestaña Attribube Editor ó Editor de Atributos de la cuenta, basta con hacer clic en el menú Ver y activar la opción Características avanzadas, de esta forma aparecerá la pestaña.

Ahora examinemos el mismo atributo pero en una cuenta normal llamada Usuario1

Como se puede apreciar su valor no está establecido, por lo cual se trata de una cuenta NO protegida.

Bien, ahora agreguemos a un grupo protegido, por ejemplo Domain Admins al usuario Usuario1

Después de agregarlo, ahora vamos a revisar sus atributos nuevamente.

Ahora ya vemos como el atributo adminCount ha sido establecido a 1, con lo cual podemos comprobar que cualquier cuenta vinculada a un grupo protegido automáticamente la cuenta quedará protegida, con ello su lista de control de acceso ACL se restablecerá cada 60 minutos a través de un proceso automático, esto previene la modificación o alteración de la lista de control de acceso de grupos o cuentas  sensibles por parte de administradores delegados por ejemplo.

Solucionar problemas de replicación de SYSVOL

En este artículo veremos cómo solucionar problemas de replicación del volumen del sistema o SYSVOL, este tipo de errores pueden detectarse de la siguiente forma:

Al realizar un gpupdate desde alguna estación cliente podemos recibir un mensaje de error que indica que ha fallado el procesamiento de la directiva de grupo:

"The processing of Group Policy failed. Windows attempted to read the file from a domain controller and was not successful."

Esta es una forma de detectar el error, la otra puede ser realizando un simple ejercicio, y se trata de observar el contenido de la carpeta SYSVOL en dos controladores de dominio, con lo cual se puede apreciar la existencia de diferencias, de igual forma si copiamos por ejemplo un archivo de texto en Servidor 1, podemos notar que no será replicado a Servidor 2

Si el contenido de la carpeta SYSVOL no se está replicando se experimentarán problemas con la aplicación de las directivas configuradas.

Antes de intentar corregir este inconveniente con la carpeta SYSVOL es recomendable realizar antes un análisis de la replicación en general entre los controladores de dominio para descartar que el problema solamente es a nivel de replicación de SYSVOL.

Lo primero que debemos hacer, es verificar los registros de eventos asociados a File Replication Service

Y allí debemos buscar con los eventos con ID 13568:

The file replication service has detected that the replica set is in jrnl_wrap_error

This indicates that the service is in a journal wrap state. Once you identify the DC that is in journal wrap condition, we must re-initializing SYSVOL replication. Before we start, we need to determine whether replication is being done by FRS (also known as NTFRS) or DFS-R.

El error básicamente lo que está indicando es que el servidor ha caido en un estado "journal wrap",  y en esencia cuando habla de journal se está refiriendo más exactamente al sistema de archivos, es decir a NTFS, y más específicamente a una característica de este sistema llamada NTFS Journal ó USN Journal, que de forma muy resumida se encarga de llevar un registro de los cambios hechos en un volumen con formato NTFS, y pues la replicación se basa en estos registros para saber qué información debe enviar al otro servidor (hablando en términos de SYSVOL), entonces al encontrarnos con este estado significa que hay inconsistencias entre el contenido del registro de un servidor con respecto al otro, las posibles causas de esto son las siguientes:

• Se ha formateado el volumen
• Se ha eliminado el registro NTFS USN journal del volumen o se ha truncado mediante una aplicación del comando chkdsk (el cual pudo encontrar entradas corruptas al final del journal).
• El servicio de replicación se ha detenido por un período de tiempo prolongado.

El error también indica que una vez identifiquemos el servidor que ha caído en este estado (evento 13568), debemos reinicializar la replicación SYSVOL, además indica que se debe identificar cuál mecanismo de replicación se está usando FRS ó DFSR, pues entonces antes de iniciar de reiniciar la replicación SYSVOL revisemos cuál de los dos métodos estamos usando, para evitar esta revisión puede tener en cuenta lo siguientes, si está usando una edición de Windows anterior a 2008, por ejemplo 2003, la replicación será FRS, si está usando 2008 o superior será DFSR, pero atención!!! si tiene Windows Server 2008 pero fue actualizado desde una versión 2003 la replicación será FRS, aunque se puede migrar a DFSR, pero esto no lo trataremos aquí, sin embargo iniciemos el proceso de revisión.

Debemos ingresar a la siguiente rama del registro: 

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalState

Si el valor de la llave LocalState es 3, se está usandeo DFSR, si la llave no existe o tiene un valor diferente a 3 se está usando FRS.

En este caso, podemos observar que el valor es 0, pero se trata de un 2008 que fue migrado desde 2003, lo cual tiene sentido, por lo cual el método de reinicialización de SYSVOL que usaremos será para FRS.

Antes de iniciar el proceso es importante  determinar las causas del problema, ya que de otra forma no servirá de mucho hacer la reparación ya que pronto se volverá a presentar, por ello es importante por lo menos tener en cuenta lo siguiente:

• Verificar que el servicio FRS ó DFSR según el caso, se encuentren corriendo.
• Verificar que hay conectividad entre los servidores, mediante ping a la IP y al FQDN
• Verificar que el servicio RPC esté arriba y que no exista un firewall bloquendo los puertos 135 y 445
• Verificar que no exista lentitud en el canal de comunicación.
• Verificar que no existan problemas físicos de disco duro o de memoria
• Garantizar que los DC no pierdan conexión entre sí por períodos prolongados de tiempo.

La necesidad de identificar si se trata de replicación FRS ó DFSR se debe a que el proceso de reinicialización es diferente para cada una, debido a que hemos identificado que la replicación es FRS iniciaremos con este proceso.

Reinicializar carpeta SYSVOL en sistema con replicación FRS

Para este caso tenemos dos tipo de replicación de SYSVOL autoritativa y no autoritativa.

Es recomendable siempre intentar la no autoritativa, para ello debemos garantizar conectividad con otro servidor que del cual deseamos replicar la información que necesitamos.

El primer paso es detener el servicio de replicación a través del comando net stop ntfrs

Luego abrir la siguiente rama desde el editor del registro.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup

Debemos modificar el valor de la llave BurFlags el cual se encuentra establecido en 0 a D2, con lo cual la llave queda de la siguiente manera:

Con esto le hemos indicando al sistema que se trata de una restauración no autoritativa de SYSVOL., en este artículo no se tratará la restauración autoritativa

Por último volvemos a iniciar el servicio de replicación con el comando net start ntfrs

Después de esto el proceso puede tardar varios minutos dependiendo de la cantidad de información a replicar, al finalizar se generará un evento 13516

De esta forma hemos terminado de restablecer la replicación SYSVOL con FRS

Reinicializar carpeta SYSVOL en sistema con replicación DFSR

Para este caso no he generado screenshots ya que el problema se presentó en un servidor con FRS, sin embargo pondré los pasos.

1. Debemos abrir la consola adsiedit.msc y navegar hasta la siguiente ruta en cada uno de los DC:

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=,OU=Domain Controllers,DC= 

establecer el siguiente valor msDFSR-Enabled=FALSE

2. Forzar la replicación a través de todo el dominio.

3. Ejecutar el siguiente comando en los servidores que semarcarán como no autoritativos: dfsrdiag polladd

4. Se generará un evento 4114 indicando que SYSVOL ni seguirá siendo replicado.

5. En la misma ruta del paso 1 volver a establecer el valor a true msDFSR-Enabled=TRUE

7. Volver a forzar la replicación a través de todo el dominio.

8. Se generará un evento 4614 indicando que la operación finalizó.

Importante: Los procesos descritos en este artículo tanto FRS como DFSR solo tratan la restauración no autoritativa de SYSVOL