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.
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.
En la segunda parte vimos todo lo referido a la configuración de Terminal Server, TS Gateway y distribución de aplicaciones remotas a usuarios. En esta tercer entrega vamos a tratar los siguientes temas:
-
Acceso a aplicaciones remotas desde Internet.
-
Probando el acceso al sitio TS Web Access.
-
Otros métodos de distribución de aplicaciones remotas.
-
Lo que se viene.
Acceso a aplicaciones remotas desde Internet
El acceso a las aplicaciones remotas desde Internet se lleva a cabo mediante el uso en conjunto con TS Gateway. Mediante esto, es posible brindar acceso seguro sin necesidad de tener que establecer previamente una conexión VPN, por ejemplo. Por supuesto que sigue siendo un escenario válido la implementación de TS Remote App y VPN en conjunto, sin la utilización de TS Gateway.
Dependiendo del método de implementación que se seleccione, los usuarios podrán acceder a las aplicaciones mediante un archivo .rdp, un acceso directo a un archivo .MSI, o el tipo de acceso a tratar en esta nota, mediante TS Web Access.
Para esto se debe tener en cuenta lo siguiente:
La configuración recomendada en estos casos es colocar tanto el TS Gateway como el TS Web Access en la red perimetral, y el Terminal Server que contiene a las aplicaciones remotas, detrás de un firewall interno.
Alternativamente, se puede implementar TS Web Access en la red interna, y luego configurar el acceso al sitio publicándolo mediante ISA Server, por ejemplo.
Más información al respecto en: http://go.microsoft.com/fwlink/?LinkId=86359
Si se implementa TS Web Access en la red perimetral, se debe definir en el firewall que se permita el tráfico WMI del TS Web Access al Terminal Server que contenga a las aplicaciones.
Además, el sitio de TS Web Access debe configurarse para que utilice Windows Authentication, la cual está seteada por defecto.
Probando el acceso al sitio TS Web Access
Una vez completada la implementación, probar el acceso es bastante simple.
En primer lugar, accedemos a la url http://TS_Web_Access_Server/ts, donde en primer lugar tendremos que ingresar las credenciales correspondientes, pudiendo posteriormente ver una interfaz similar a la siguiente:
Podemos verificar que funciona correctamente accediendo a cualquiera de las aplicaciones publicadas. Al acceder, se nos preguntará que recursos locales queremos mapear:
Por supuesto, esto depende de los requerimientos de cada aplicación, por lo que queda a criterio de cada uno seleccionar cualquiera de las siguientes categorías.
Luego, accederemos a la aplicación seleccionada.
Como se puede observar, no existen a simple vista indicios de que estamos ejecutando la aplicación de manera remota.
Otros métodos de distribución de aplicaciones remotas
Existen otros métodos de distribución de acceso a aplicaciones remotas, los cuales en esta oportunidad solamente voy a mencionar, y posteriormente en otras notas a explicar. Algunos de estos son:
Lo que se viene
La idea es cubrir la mayor cantidad de componentes y funcionalidades de Terminal Services en Windows 2008. TS Web Access me pareció una funcionalidad muy importante y amplia, de la que vimos desde lo más general hasta algunos puntos en particular más a fondo. Es por esto que posteriormente iré agregando nuevas notas relacionadas a componentes adicionales como TS Session Broker, gestión del look-and-feel de TS Web Access, Seguridad, distribución de aplicaciones mediante archivos .rdp y Windows Installer, y más.
Espero que esto les resulte útil, y sin tienen dudas o comentarios, no tienen más que hacérmelos llegar.
Saludos!
Marcelo.
En la 1era parte, vimos como instalar los servicios de Terminal Services, aplicaciones, y preparar las mismas para que se encuentren disponibles mediante Web Access.
Vamos a seguir ahora adelante con la 2da parte, que incluye:
- Configuración de Terminal Server.
- Configuración de TS Gateway.
- Distribución de aplicaciones remotas a usuarios.
Configuración de Opciones de Terminal Server
1. En Actions, dentro de TS RemoteApp Manager, seleccionar Terminal Server Settings.
2. En el tab Terminal Server, Connection settings, configurar el nombre de la granja, el puerto RDP, y las opciones de autenticación.
3. Si el checkbox Require server authentication está seleccionado, se debe tener en cuenta que:
- 3.1. Para equipos con Windows Server 2003 SP1 o XP SP2, se deberá configurar Terminal Server para que utilice SSL.
- 3.2. En el caso de aplicaciones para intranet, y los clientes son Windows Server 2008 o Vista, en lugar de utilizar SSL, se utilizará Network Level Authentication.
4. Para proveer un link al escritorio completo del TS, en Remote Desktop Access, se deberá seleccionar Show a remote desktop connection to this terminal server in TS Web Access.
5. En Access to unlisted programs, seleccionar alguna de las siguientes opciones:
- 5.1. Do not allow users to start unlisted program on initial connection(Recommended). Si bien es una buena alternativa, no previene que, por ejemplo, si un documento Word contiene un hyperlink, este pueda abrirse mediante el Internet Explorer.
- 5.2. Allow users to start both listed and unlisted programs on initial connection. Desde ya es opción es bastante descriptiva y deja en claro los riesgos que implica.
6. Al finalizar, seleccionar OK.
Configuración de TS Gateway
Básicamente en esta sección definimos si los usuarios se conectarán a través de un Firewall por TS Gateway. Para mayor información: TS Gateway Step-by-Step Guide.
Configuración de opciones de TS Gateway
1. En Actions, dentro de TS RemoteApp Manager, seleccionar TS Gateway Settings.
2. En el tab TS Gateway, Configurar las opciones de comportamiento deseadas, entre ellas:
- 2.1. Detectar automáticamente la configuración del servidor TS Gateway. (Esto provoca que los clientes intenten utilizar la configuración por Group Policies para determinar el comportamiento).
- 2.2. Utilizar las opciones de configuración especificadas.
- 2.3. No utilizar un servidor TS Gateway.
3. Si se selecciona Use these TS Gateway server settings:
- 3.1. Se debe configurar el nombre del servidor TS Gateway, y el método de logon.
- 3.2. Si se quiere utilizar las miasm credenciales de TS Gateway en Terminal Server, seleccionar Use the same user credentials for TS Gateway and terminal server.
4. Si lo que se quiere es que los clientes detecten automáticamente cuando TS Gateway es requerido, seleccionar Bypass TS Gateway server for local addresses (Lo cual optimiza el rendimiento de los clientes).
5. Para utilizar siempre TS Gateway, deseleccionar Bypass TS Gateway server for local addresses.
6. Al finalizar, seleccionar OK.
Distribución de aplicaciones remotas a usuarios
Los puntos principales (y los que se tratarán) para llevar a cabo la distribución son los siguientes:
1. Instalación de TS Web Access.
2. Asignaciones al Security Group TS Web Access Computers.
3. Especificar el servidor desde el cual se completará la lista de aplicaciones remotas que se mostrarán en el sitio web de TS Web Access.
Instalación de TS Web Access
Algunas aclaraciones previas:
- Al instalarlo, se instalará tambien IIS 7.0.
- No es necesario que el servidor cumpla el rol de Terminal Server.
1. En la consola Server Manager, seleccionar Add Roles.
2. En el wizard de instalación, en la ventana Before you begin, seleccionar Next.
3. En la ventana Select Server Roles, seleccionar Terminal Services, y luego Next.
4. En la ventana Terminal Services, seleccionar Next.
5. En la ventana Select Role Services, seleccionar TS Web Access, y luego, en la ventana emergente, seleccionar Add Required Role Services. Por último, Next.
6. En la ventana Web Server (IIS), seleccionar Next.
7. En la ventana Select Role Services, dejar los elementos seleccionados por defecto (ya no es el objetivo de esta nota entrar en detalle sobre los diferentes tipos de autenticación, diagnóstico, y demás prestaciones). Luego, seleccionar Next.
8. En la ventana Confirm Installation Selections, verificar que todo coincida con nuestra selección, y luego seleccionar Install.
9. Una vez finalizada la instalación, podremos ver el informe que muestra el resultado de la misma. Luego de esto, seleccionar Close.
Con esto finalizamos la instalación del rol TS Web Access.
Asignaciones al security group TS Web Access Computers
En el caso de que TS Web Access y el Terminal Server que contiene las aplicaciones se encuentren separados, se deberá agregar la cuenta de equipo del TS Web Access al Security Group TS Web Access Computers del Terminal Server.
Para esto, se deben seguir los siguientes pasos:
1. Seleccionar Start, Administrative Tools, y luego Computer Management.
2. Expandir Local Users and Groups, y luego seleccionar Groups.
3. Seleccionar TS Web Access Computers.
4. En TS Web Access Computers Properties seleccionar Add.
5. En Select Users, Computers, or Groups, seleccionar Object Types.
6. En Object Types, seleccionar Computers, y luego OK.
7. En el campo Enter the object names to select, especificar la cuenta de equipo del TS Web Access, y luego OK.
8. Seleccionar OK para cerrar las propiedades.
Especificación de servidor para la obtención de lista de aplicaciones remotas
Por defecto, TS Web Access completa la lista de aplicaciones remotas de un solo Terminal Server. En este caso veremos como obtener la lista de aplicaciones remotas.
Especificar que Terminal Server se utilizará como source
1. Conectarse al sitio web de TS Web Access, pudiendo hacerlo de las siguientes formas:
- Seleccionando Start, Administrative Tools, Terminal Services, y luego TS Web Access Administration.
- Utilizando Internet Explorer, accediendo a la ruta por defecto: http://server_name/ts
2. Iniciar sesión con la cuenta de Administrador Local, o una cuenta miembro del grupo TS Web Access Administrators group.
3. Seleccionar el tab Configuration.
4. En Editor Zone, en el campo Terminal server name, ingresar el nombre del Terminal Server que se desea utilizar como Data Source.
5. Seleccionar Apply para aplicar los cambios.
Esto es todo por ahora, muy pronto estaré posteando la 3era parte de Aplicaciones Remotas via Terminal Services.
Saludos.
Marcelo.
Hace un tiempo les mostré como instalar y configurar Terminal Services en Windows Server 2008, y algunos de sus componentes en general. En esta oportunidad les voy a presentar la instalación y configuración de los componentes necesarios para brindar acceso remoto a aplicaciones.
Instalación de Terminal Services:
Como dije al comienzo de la nota, ya fue explicado aquí.
Aplicaciones:
Simplemente consiste en instalar todas las aplicaciones que se deseen distribuir a través de TS Web Access, en el servidor.
Tengan en cuenta ejecutar el comando "change user /install", antes de instalar una aplicación, y "change user /execute", luego de haber finalizado.
Conexiones remotas:
Por defecto, las conexiones remotas se encuentran habilitadas luego de instalar el rol Terminal Server. Sin embargo, en los siguientes pasos veremos como personalizar esta configuración para ajustarla a los requerimientos particulares.
1. Seleccionar Start, Run, e ingresar control system luego, seleccionar OK.
2. En Tasks, seleccionar Remote settings.
3. En System Properties, en el tab Remote, verificar que los parámetros de configuración de Remote Desktop están configurados de acuerdo al entorno particular, pudiendo elegir alguna de las siguientes opciones:
- 3.1. Allow connections from computers running any version of Remote Desktop (less secure).
- 3.2. Allow connections only from computers running Remote Desktop with Network Level Authentication (more secure).
4. Agregar a los usuarios que se consideren necesarios para acceder remotamente.
Nota: Los miembros del grupo local Administrators pueden conectarse sin necesidad de estar listados.
5. Al finalizar, seleccionar OK.
Agregar aplicaciones a la lista de aplicaciones de RemoteApp
1. Seleccionar Start, Administrative Tools, Terminal Services, y luego TS RemoteApp Manager.
2. En Actions, seleccionar Add RemoteApp Programs.
3. En la ventana Welcome to the RemoteApp Wizard, seleccionar Next.
4. En la ventana Choose programs to add to the RemoteApp Programs list, selecccionar el check box correspondiente a cada aplicación que se desee mostrar en el listado de aplicaciones disponibles de RemoteApp Programs.
Nota: Generalmente no debería suceder ya que los programas listados son los que se encuentran en All Users, pero si no se llega a encontrar la aplicación deseada, se deberá seleccionar manualmente a través de browse, como en nuestro caso, en el cual seleccionamos adicionalmente Internet Explorer.
5. Para configurar las propiedades de cualquier aplicación, seleccionar la aplicación y luego Properties. Pudiendo configurar:
- Nombre.
- Ubicación.
- Alias.
- Disponible o no a través de TS Web Access.
- Ícono.
- Parámetros adicionales de ejecución, y si estos se habilitan.
6. Al finalizar, seleccionar OK, y luego Next.
7. En la ventana Review Settings, verificar que todo sea tal cual se requiere, y luego seleccionar Finish.
Luego de haber seguido los pasos anteriormente mencionados, logramos que las aplicaciones aparezcan listadas.
Con esto completamos la primer entrega correspondiente a la distribución de aplicaciones mediante Terminal Services Web Access.
En los próximos días estaré posteando la segunda parte.
Saludos.
Marcelo.
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.
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.
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.
¿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.
For those interested in the exam that have not taken yet, you must know that nowadays is still possible to take it for free using a promotion code.
Useful information:
Promo Code: MDOP.
Preparation Guide
Registration link
And finally but not less important, the Cleber Marques's Blog, who developed some interesting documents which can be useful as a study material for the exam. The only problem is that they are all in portuguese, but if you speak or at least understand spanish, you can try using them.
There isn't excuses!
Regards.
Marcelo.
Para aquellos interesados en el examen que aún no lo hayan tomado, les comento que aún pueden hacer uso de un Promo Code, el cual les permitirá hacerlo de forma gratuita.
Información útil:
Promo Code: MDOP.
Guía de preparación
Link para registrarse
Y por último pero no menos importante, el Blog de Cleber Marques, quien desarrolló unos documentos interesantes que pueden servirles como material de estudio para el examen. El único problema es que está en portugués, pero se entiende.
No hay excusas!
Saludos.
Marcelo.
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.
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.
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.
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.
