Blog dedicado a Servicios de directorio y otros temas relacionados : Windows Server

Active Directory – File Replication Service - Análisis de problemas de Journal_Wrap

Marcelo P. di Iorio — Sat, 18 Jul 2009 07:59:10 GMT

Este tipo de problemas se puede presentar típicamente cuando ocurren una cantidad determinada de cambios tal que FRS no puede almacenar por diferentes razones, o también mientras FRS está detenido.

Cuando se presenta esta condición, y con el fin de prevenir inconsistencias, FRS entra en el estado Journal_Wrap.

Como recuperarse de este estado:

Primero, se debe detectar la presencia del evento con ID 13568 en el log de FRS. Lo más frecuente es que llevando a cabo un restore del tipo D2 en el Domain Controller afectado, solucionemos el problema, sin embargo no nos debemos conformar con mitigar el problema sino además tratar de encontrar los motivos por los cuales se presenta esta situación.

¿Que significa llevar a cabo un D2 en el Domain Controller afectado?, significa llevar a cabo un restore no autoritativo, tomando como referencia un inbound partner, lo cual puede llevar más o menos tiempo dependiendo del tamaño del replica set a restaurar. En situaciones típicas, no debemos preocuparnos por seleccionar un inbound partner, sin embargo, si esta situación se llegara a presentar en todos los Domain Controllers del dominio, deberemos llevar a cabo primero un restore autoritativo (D4) de un replica set, y luego llevar a cabo los posteriores D2 en cada uno de los Domain Controllers restantes.

Pasos generales para llevar a cabo un D2 en un escenario en el cual tenemos uno o más Domain Controllers en estado Journal_Wrap, pero contando con al menos una réplica saludable:

Detener el servicio FRS en los Domain Controllers afectados.
Configurar la clave correspondiente a BURFLAG = D2 (http://support.microsoft.com/kb/290762/en-us).
Iniciar nuevamente el servicio FRS.
Verificar la existencia posterior de eventos 13516, que indican que FRS se encuentra operacional nuevamente.

¿Qué ocurre si todos los Domain Controllers se encuentran en estado Journal_Wrap?

Detener el servicio FRS en todos los Domain Controllers.
Configurar la clave de registro BURFLAG = D2.
Restaurar autoritativamente una copia saludable de SYSVOL mediante NT Backup, marcando dicha restauración como autoritativa en Directory Services Restore Mode).
Configurar el valor de BURFLAG del Domain Controller seleccionado como autoritativo, en D4.
Iniciar el servicio FRS en el Domain Controller seleccionado anteriormente.
Iniciar gradualmente el servicio FRS en el resto de los Domain Controllers, verificando la existencia del evento 13516.

Causas más comunes, las cuales pueden encontrarse en cualquier evento 13568:

[1] Volume "\\.\C:" has been formatted.
[2] The NTFS USN journal on volume "\\.\C:" has been deleted.
[3] The NTFS USN journal on volume "\\.\C:" has been truncated. Chkdsk can truncate the Journal if it finds corrupt entries at the end of the journal.
[4] File Replication Service was not running on this computer for a long time.
[5] File Replication Service could not keep up with the rate of Disk IO activity on "\\.\C:".
Setting the "Enable Journal Wrap Automatic Restore" registry parameter to 1 will cause the following recovery steps to be taken to automatically recover from this error state.
[1] At the first poll, which will occur in 5 minutes, this computer will be deleted from the replica set. If you do not want to wait 5 minutes, then run "net stop ntfrs" followed by "net start ntfrs" to restart the File Replication Service.
[2] At the poll following the deletion this computer will be re-added to the replica set. The re-addition will trigger a full tree sync for the replica set.

Debido a que existe mucha información y detalle sobre este problema en particular, posteriormente estaré publicando otras notas relacionadas.

Saludos.

Marcelo.

Strict Name Checking y Alias de nombres de servidores

Marcelo P. di Iorio — Sun, 17 May 2009 01:10:53 GMT

Por defecto, en Windows Server solamente se puede acceder a un recurso compartido en la forma \\nombre_real\share y no \\alias\share. Deshabilitando Strict Name Checking permitirá usar el segundo ejemplo, teniendo en cuenta los riesgos de seguridad que esto representa (ej. un usuario malintencionado puede crear un registro que apunte a un servidor dummy idéntico al original y si por ejemplo se tratara de un File Server, puede robar información).

Cómo deshabilitar Strict Name Checking:

Ya sea tanto para Windows 2000 Server como así también Windows Server 2003, se deben seguir los pasos descriptos en este artículo.

La clave de registro descripta en el artículo sirve también para Windows Server 2008, sin embargo solo aplicará si se utiliza SMB v1.

Para un detalle completo de esta funcionalidad, pueden visitar el artículo mencionado anteriormente.

Saludos.

Marcelo.

File Replication Service - Excessive Replication

Marcelo P. di Iorio — Sat, 24 Jan 2009 09:55:32 GMT

Excessive Replication, es un problema que se presenta cuando FRS detecta 15 o más actualizaciones idénticas en archivos replicados durante un período de una hora, siempre y cuando esto ocurra durante 3 hs. consecutivas. Los cambios duplicados pueden ocurrir en un único archivo 15 veces, o en 15 archivos por única vez, o cualquier combinatoria de estas.

Yendo más a fondo, las actualizaciones duplicadas son detectadas cuando el checksum MD5 del último cambio es idéntico al anterior en el caso de un mismo archivo. Esto puede ocurrir generalmente ya sea por que se llevan a cabo cambios de manera manual, o mediante una determinada aplicación lleva a cabo cambios reiterados sobre archivos replicados mediante FRS, generando de esta forma inconsistencia entre los distintos Replication Partners. Estas son algunas de las posibles causas, ya que podemos encontrar otras más como por ejemplo Antivirus que modifican los descriptores de seguridad, en cuyo caso por supuesto debemos generar las exclusiones correspondientes, el uso de herramientas de optimización de discos, defragmentación de directorios que replican mediante FRS, copiado manual de archivos, etc.

A partir del SP3 de Windows 2000, cuando se presenta este caso, se genera el evento 13567.

Si bien la mejor forma de solucionar este tipo de problemas es identificar la fuente y mitigarla, en la nota http://support.microsoft.com/kb/315045/en-us se explica como activar la supresión, pero tengan en cuenta que la supresión no aplica para carpetas.

Esto es solamente un breve resumen de un tema mucho más amplio, que espero que les sirva.

Saludos.

Marcelo.

Windows Server 2003 - DCPROMO - Install From Media

Marcelo P. di Iorio — Sat, 24 Jan 2009 09:52:43 GMT

Introducción

Install From Media (IFM) es una característica incorporada en Windows Server 2003, que básicamente facilita, entre otras cosas, el promover un Domain Controller usando un backup de otro Domain Controller.

Funcionamiento

La herramienta se encuentra disponible al ejecutar DCPROMO /ADV. Lo que se tiene que hacer, basicamente, es llevar a cabo un backup del System State de un Domain Controller activo, restaurarlo en el futuro Domain Controller, y utilizar el comando DCPROMO /ADV, indicando como fuente un medio local, y no de red.

Aún mejor, es el aprovechamiento de esta utilidad para llevar a cabo un Backup y Restore de un Domain Controller que a la vez sea Global Catalog.

Es importante aclarar que esta funcionalidad no reemplaza la replicación por red, ya que lo que se está haciendo es utilizar un backup de un Domain Controller existente, para evitar así la primer replicación Full ocurra a través de la red, reduciendo tiempo y utilización de recursos.

Limitaciones

Básicas, pero no poco importantes:

IFM solo puede ser utilizado entre Domain Controllers del mismo dominio.
Un backup del System State solo puede utilizarse dentro de un período de 60 días, que es el tiempo de vida Tombstone por defecto (90 días a partir del Service Pack 1). De otra forma, utilizar un backup de más de 60 días puede ocasionar que se reactiven objetos borrados, al igual que todas las inconsistencias que eso implica.

Backup del System State de un Domain Controller existente

1. Seleccionar Start\All Programs\Accessories\System Tools\Backup.

2. Seleccionar el tab Backup.

3. Seleccionar System State, y cambiar la ubicación destino de almacenamiento del backup, en Backup media of filename.

4. Seleccionar Start Backup.

5. En la ventana Backup job information, verificar las opciones y modificarlas en caso de ser necesario. Luego, seleccionar Start Backup.

6. Esperar a que finalice el backup. Luego, si todo salió bien, seleccionar Close.

Restore del System State en un futuro Domain Controller

1. Copiar el backup del System State al servidor destino.

2. Ejecutar la herramienta NTBackup, seleccionando el tab Restore and Manage Media, y luego seleccionar el checkbox System State.

3. En Restore Files to:, seleccionar Alterate Location. En Alternate Location:, ingresar la ubicación destino del Restore, por ejemplo C:\SystemStateRestoredFiles. Luego, seleccionar Start Restore.

4. Esperar a que finalice el Restore. Luego, seleccionar Close y cerrar la herramienta de Backup.

Creación de un Domain Controller adicional

1. Seleccionar Start\Run, y ejecutar el comando DCPROMO /ADV, para abrir el wizard de instalación de Active Directory con la opción de crear un Domain Controller desde un System State restaurado.

2. En el Wizard de instalación, seleccion Next.

3. En la ventana de Compatibilidad, seleccionar Next nuevamente.

4. En la ventana Domain Controller Type, seleccionar Additional domain controller for an existing domain.

5. En la ventana Copying Domain Information, seleccionar, From these restored backup files:, especificando además, la ubicación en la cual restauramos el backup anteriormente realizado. Luego, seleccionar Next.

6. En la ventana Global Catalog, seleccionar Yes o No, dependiendo de lo que se requiera. En este caso, vamos a seleccionar Yes. Luego, seleccionar Next.

7. En la ventana Network Credentials, ingresar las credenciales válidas para promover el equipo a Domain Controller. Luego, seleccionar Next.

8. En la ventana Database and Log Folders, seleccionar Next, excepto que se deseen almacenar en otra ubicación.

9. En la ventana Shared System Volume, aplicar la misma metodología que el paso anterior.

10. En la ventana Directory Services Restore Mode Administrator Password, ingresar la contraseña correspondiente, y luego seleccionar Next.

11. En la ventana Summary, revisar la información, y luego seleccionar Next.

12. Esperar a que finalice la configuración del Domain Controller. Luego, seleccionar Finish, y reiniciar el equipo.

13. Y si les queda alguna duda:

Más información:

Installing a Domain Controller in an Existing Domain Using Restored Backup Media

Saludos.

Marcelo.

Question of the Day - AdminSDHolder

Marcelo P. di Iorio — Tue, 06 Jan 2009 04:44:00 GMT

Which is the purpose of the AdminSDHolder object?

Ensures that the objects like groups and users, to which applies administratives roles (those assigned through task delegation), have no more than the necessary permissions over accounts and protected groups.
Prevents rights elevation over accounts and protected groups.
Maintains the integrity of the permissions applied when delegating a specific tasks.
1 and 2.
There is no such object.

I will publish the answer in the next days.

Regards.

Marcelo.

La Pregunta del día - AdminSDHolder

Marcelo P. di Iorio — Mon, 05 Jan 2009 14:49:00 GMT

¿Cuál es el propósito del objeto AdminSDHolder?

Asegura que los objetos como grupos y usuarios, a los cuales se les aplican roles administrativos (los que se asignan mediante delegación de tareas), no tengan más permisos de los que deberían tener sobre las cuentas y grupos protegidos.
Previene la elevación de privilegios sobre las cuentas y grupos protegidos.
Mantiene la integridad de los permisos aplicados al delegar una tarea determinada.
1 y 2.
No existe tal objeto.

La respuesta la tendrán en los próximos días.

Saludos.

Marcelo.

how to configure Active Directory to store BitLocker and TPM recovery information (Part I)

Marcelo P. di Iorio — Mon, 08 Dec 2008 09:53:00 GMT

Store recovery passwords for a BitLocker protected volume permit autorized users to recover it if it's protected by this technology. This grants of course, that the encrypted information who belongs to the company always can be accesed by at least someone which may be autorized.

Storing the TPM information of a computer is very useful because for example, if the owner of the computer is sacked and you wish to get access to the content of his hard disk, which is protected with BitLocker.

To be able to store this kind of information in Active Directory, you need Windows Server 2003 with SP1 domain controllers, at least, or Windows Server 2008.

Pre-requisites:

In addition to the above regarding the operating system, the schema must be extended, adding the corresponding extensions for BitLocker. Without this, if BitLocker is enabled before preparing the schema, any kind of recover information will be saved in Active Directory. The name of the BitLocker recovery object adds a GUID and information of date and time with a length of 63 characters:

The common name (cn) for the BitLocker recovery object is ms-FVE-RecoveryInformation. Each of this objects contains the following attributes:

ms-FVE-RecoveryPassword.
ms-FVE-RecoveryGuid.
ms-FVE-VolumeGrid.
ms-FVE-KeyPackage.
GUID added to the global catalog in order to simplify forest-wide searches (isMemberOfPartialAttributeSet).
A bit to confidential use for the GUID attributes (bit 128 of searchFlags).
Size of each attribute restricted to minimize the replication times in case of a flood attack to the Active Directory database (rangeUpper).
Descriptions of attributes updated for clarity (adminDescription).
additional bit defined setted to store values when creates copies of objects ( bit 16 of searchFlags).
An addition bit defined to create indexes per-container of GUID attributes (bit 2 of searchFlags).

Store of recovery information of TPM in Active Directory

Only one TPM recovery password exists per computer. When TPM initializes or the password is changed, a backup of the hash of the TPM ownership password is maded, as an attribute of the computer object.

The cn of this attribute is ms-TPM-OwnerInformation.

In the next part we will see the required steps to make the configuration of Active Directory in order to be able to use BitLocker and TPM. Also, I will continue with the Authotitative Restore in Active Directory post.

More information:

Configuring Active Directory to Back up Windows BitLocker Drive Encryption and Trusted Platform Module Recovery Information (document that I'm using to write this article) .

Regards.

Marcelo.

Como configurar Active Directory para almacenar información de recuperación de Bitlocker y TPM (Parte I)

Marcelo P. di Iorio — Sat, 06 Dec 2008 21:22:00 GMT

Almacenar recovery passwords para un volumen protegido con BitLocker permite a aquellos usuarios autorizados a recuperar el volumen si está protegido por esta tecnología. Esto permite por supuesto que la información encriptada que pertenezca a la empresa siempre pueda ser accedida por al menos alguna persona autorizada.

Almacenar la información de TPM de un equipo es de suma utilidad por ejemplo si se despide a un empleado y se desea acceder al contenido de su disco que se encuentra encriptado con BitLocker.

Para poder almacenar este tipo de información en Active Directory, es necesario que los controladores de dominio sean Windows Server 2003 con SP1 al menos, o Windows Server 2008.

Pre requisitos:

Ademas del anteriormente mencionado con respecto al sistema operativo, se debe extender el schema agregando las extensiones correspondientes para BitLocker. Sin esto, si se habilita BitLocker en en equipo antes de preparar el Schema, no se almacenará ningún tipo de información de recuperación en Active Directory.

La información de recuperación se almacena en un child object del computer object. Esto significa que el computer object es el contenedor del BitLocker Recovery Object. Vale la pena aclarar que puede existir más de un Recovery Object por Computer Object, ya que puede haber más de una contraseña de recuperación asociada con un volumen BitLocker.

El nombre del BitLocker recovery object incorpora un GUID e información de fecha y hora, con una longitud de 63 caracteres:

<Object Creation Date and Time><Recovery GUID>

El common name (cn) para el BitLocker recovery object es ms-FVE-RecoveryInformation. Cada uno de estos objetos contiene los siguientes atributos:

ms-FVE-RecoveryPassword.
ms-FVE-RecoveryGuid.
ms-FVE-VolumeGrid.
ms-FVE-KeyPackage.
GUID agregado al global catalog para facilitar búsquedas forest-wide (isMemberOfPartialAttributeSet).
Un bit para uso confidencial para los atributos GUID (bit 128 de searchFlags).
Tamaño de cada atributo restringido para minimizar los tiempos de replicación en el caso de un ataque del tipo flood a la base de Active Directory (rangeUpper).
Descripciones de atributos actualizadas para claridad (adminDescription).
Un bit adicional definido seteado para almacenar valores cuando se crean copias de objetos (bit 16 de searchFlags).
Un bit adicional definido para crear índices per-container de atributos GUID (bit 2 de searchFlags).

Almacenamiento de la información de recuperación de TPM en Active Directory

Solo existe una contraseña de recuperación TPM por equipo. Cuando se inicializa TPM o cuando la contraseña es cambiada, se lleva a cabo un backup del hash de la TPM ownership password, como atributo del computer object.

El cn de este atributo es ms-TPM-OwnerInformation.

En la próxima parte veremos concretamente los pasos necesarios para llevar a cabo la configuración de Active Directory para poder utilizar BitLocker y TPM. Además, seguiré adelante con lo que respecta a Authoritative Restore en Active Directory.

Más información:

Configuring Active Directory to Back up Windows BitLocker Drive Encryption and Trusted Platform Module Recovery Information (documento sobre el cual me estoy basando para desarrollar el artículo).

Saludos.

Marcelo.

Windows Server 2008 - Active Directory - Authoritative Restore (Part 1)

Marcelo P. di Iorio — Fri, 21 Nov 2008 05:57:00 GMT

While it is a task without major complications, this is not something we do every day, so in this article I will first describe the news about the authoritative restore process in Active Directory on Windows Server 2008 domains, and then the main considerations and things to take into account in this process.

First, as most of you already know, the Windows Server 2008 Domain Controllers bring the possibility to stop and/or restart exclusively the AD DS (Active Directory Domain Services service; this makes that nobody can temporarily logon on the Domain Controller on which we are working, ideal option for companies that occasionally bring another services in the Domain Controller affected. Of course, being a recommended action or not, this is not an issue that we will address at this time.

First, let's talk in general about the global steps necessaries to handle this task on a Windows Server 2008 Domain Controller:

The Active Directory Domain Services has to be stopped (net stop ntds).
Restore a valid System State.
Run the ntdsutil authoritative restore command.
Mark as authoritatives the objects to be restored.
Start the service again (net start ntds) when we have completed the restoration.

Some points to take into account:

Always try to mark objects as Authoritatives as precisely as possible. This means that if we must restore a specified quantity of user accounts, for example, we doesn't have to restore the whole OU, because it would affect many other objects that maybe doesn't have to be restored, and using this example, it have to be taken into account that when restoring an object also implies restore all the attributes, for example group memberships, password, etc.
The Schema can't be authoritatively restored. It's important test in a lab in a precisely manner any task that implies extend the schema.
Precisely, mark an object as authoritative implies that the version increases by default (100.000 * age of backup (in days)).

In the next part, I will continue talking about different features and considerations of the authoritative restore process, in addition to another examples.

Regards.

Marcelo.

Windows Server 2008 - Active Directory - Restore autoritativo (Parte 1)

Marcelo P. di Iorio — Fri, 21 Nov 2008 04:00:00 GMT

Si bien es un proceso dentro de todo sin mayores complicaciones, no es algo que llevemos a cabo todos los días, por lo tanto en este artículo voy a describir en primer lugar las novedades en cuanto al proceso de restore autoritativo en Active Directory en dominios Windows Server 2008, y luego las principales consideraciones y puntos a tener en cuenta en cuanto a este proceso.

En primer lugar, como muchos de ustedes ya sabrán, los controladores de dominio Windows Server 2008 ofrecen la posibilidad de detener y/o reiniciar exclusivamente el servicio AD DS (Active Directory Domain Services); esto provoca que temporalmente nadie se pueda validar en el controlador de dominio en el cual estemos trabajando, opción ideal para aquellas empresas que ocasionalmente presten otro tipo de servicios en el controlador de dominio afectado. Por supuesto, que esto sea o no una acción recomendada es un tema que no se tratará en esta oportunidad.

En primer lugar, tratemos en líneas generales los pasos a grandes rasgos para llevar a cabo esta tarea en un controlador de dominio Windows Server 2008:

Se debe detener el servicio Active Directory Domain Services (net stop ntds).
Restaurar un System State válido.
Ejecutar el comando ntdsutil authoritative restore.
Marcar los objetos a restaurar como Autoritativos.
Iniciar el servicio (net start ntds) cuando hayamos completado la restauración.

Algunos puntos a tener en cuenta:

Siempre se debe tratar de marcar como autoritativos de la manera más precisa posible. Esto significa que si debemos restaurar una cantidad determinada de cuentas de usuario, por ejemplo, no restauremos toda la OU, ya que estaríamos afectando a muchos otros objetos que quizás no debieran ser restaurados, y aprovechando el ejemplo, se debe tener en cuenta que al restaurar un objeto se restauran también todos sus atributos, entre ellos grupos a los cuales pertenezca, contraseña al momento del backup, etc.
El Schema no se puede restaurar autoritativamente. Es importante probar en laboratorio de manera precisa cualquier tarea que implique extender el esquema.
Concretamente, marcar un objeto como autoritativo implica que la versión del objeto afectado se incrementa por defecto (100.000 * cantidad de días de antigüedad del backup).

En la próxima parte seguiré mencionando distintas características y consideraciones del proceso de restore autoritativo, además de algunos ejemplos concretos.

Saludos.

Marcelo.