En muchas ocasiones recibimos consultas sobre cómo realizar la copia o migración de GPOs de un bosque a otro diferente. Hoy vamos a tratar este tema.
Como sabéis, a través de GPOs podemos desplegar muchos tipos de configuraciones. Con frecuencia, estas configuraciones contienen información específica que pertenece al propio dominio o a objetos en él. Es por esto que, si se importan las GPOs de un entorno directamente en otro con la GPMC (Group Policy Management Console – gpmc.msc) va a haber una serie de rutas, objetos y/o “SIDs” que el dominio destino no va a poder traducir, al tratarse de rutas o SIDs pertenecientes a otro entorno que desconoce y que no existen en él.
Será necesario que la configuración se “traduzca” para que los datos referenciados tengan “sentido” en el nuevo entorno. En el ejemplo mostrado en el siguiente dibujo, queremos migrar la GPO X del dominio B de nuestro bosque de pruebas al dominio E de nuestro bosque de producción. En este proceso necesitamos traducir la configuración del derecho de usuario “Log on locally” configurado en la GPO para reflejar los nuevos grupos/usuarios del bosque de producción, en lugar de referenciar a los de nuestro bosque de pruebas.
Por lo tanto, si lleváramos a cabo esta importación, el mecanismo para conseguir que las GPOs hagan referencia a objetos del dominio local sería llevar a cabo una modificación manual de la configuración de las GPOs, lo cual podría convertirse en una tarea muy tediosa y susceptible a fallos.
No obstante, existe la posibilidad de llevar a cabo la migración ayudándonos de “tablas de migración” a la hora de importar las GPOs. Con estas tablas vamos a poder especificar la correspondencia entre rutas/objetos del dominio origen y rutas/objetos del dominio destino, tal y como se indica en los siguientes artículos:
When using import to transfer GPO settings to a GPO in a different domain or different forest, you may want to use a migration table in conjunction with the import operation. A migration table allows you to facilitate the transfer of references to security groups, users, computers, and UNC paths in the source GPO to new values in the destination GPO.
To transfer the settings in GPO X from domain B in the test forest to a GPO in domain E in the production forest, the administrator must use an import operation and a migration table because trust does not exist between domain B and domain E. If trust did exist, it would also be possible to do this with a copy operation. When you use a migration table together with the import or copy operation, the Group Policy Management Console (GPMC) enables the administrator to update the settings in the destination GPO to the new values that are appropriate for the destination domain.
Con la ayuda de estas “tablas de migración” se va a facilitar el proceso de importar las GPOs en el dominio destino, ya que nos va a ayudar a realizar la traducción de lo que especifiquemos en dichas tablas en la GPO importada automáticamente.
Por ejemplo, las siguientes configuraciones contienen Security Principals y pueden ser modificados durante una importación utilizando una “tabla de migración”:
Las siguientes configuraciones pueden contener rutas UNC que puede ser necesario actualizar a nuevos valores durante la migración:
Hay otras configuraciones que pueden referenciar tanto a Security Principals como rutas UNC en otras políticas, como en algunas Plantillas Administrativas. Estas configuraciones no se pueden mapear con la información de la “tabla de migración”, por lo que se copiarán tal cual.
Las “tablas de migración” se implementan como ficheros XML con la extensión “.migtable”, pero no os preocupéis porque no tendréis que lidiar con los tags ni con la estructura de estos ficheros si no queréis, ya que la GPMC incorpora un “Editor de tablas de migración”, que podéis encontrar en %programfiles%\gpmc\mtedit.exe. También podéis acceder al editor desde el menú contextual (click derecho) del nodo Domains o Group Policy Objects de la GPMC y seleccionando Open Migration Table Editor.
Podéis ver un ejemplo de “tabla de migración” en %programfiles%\GPMC\scripts\SampleMigrationTable.migtable.
En el siguiente enlace podéis obtener un documento que constituye una guía detallada de migración de GPOs de un dominio a otro con ejemplos, explicaciones detalladas de las tablas de migración y sus opciones de mapeo, etc.:
Aunque en el documento podéis encontrar los pasos de migración en detalle, os indico a continuación los pasos generales que tendríais que realizar para que veáis en qué consiste y el trabajo de búsqueda y traducción que os vais a evitar utilizando “tablas de migración”:
En los siguientes enlaces podréis encontrar más información sobre las “Tablas de migración” y el “Editor de tablas de migración” incluido en la GPMC, así como ejemplos de uso:
Si vais a realizar una migración de este tipo, es importante que reviséis el siguiente artículo ya que incluye un fix que solventa algunos problemas, por ejemplo con las políticas de 802.1x:
Espero que esta información os resulte útil a la hora de crear y probar vuestras GPOs y migrarlas al entorno de producción.
- Paula Tomás Galed
Hoy vamos a ver cómo poder crear nuestras zonas con caracteres como la Ñ o vocales con tilde. Desde hace algunos años, Red.es nos permite registrar este tipo de dominios DNS bajo el dominio “.es”. Una vez registrado el nombre que queremos tenemos que crear una zona DNS para servir las peticiones DNS correspondientes a los nombres del mencionado dominio.
Pongamos que ya hemos registrado nuestro dominio mizonaconeñe.es. Ahora creamos el dominio en nuestro servidor DNS y creamos un registro de tipo A para nuestro servidor web:
Nuestro siguiente paso sería probar, desde un navegador Web, que podemos acceder a nuestro servidor Web, así que intentamos acceder a www.mizonaconeñe.es y obtenemos el siguiente resultado:
Tras varios reintentos, obtenemos el mismo resultado, por lo que el siguiente paso es obtener unas trazas de red para ver lo que está pasando, y vemos la siguiente consulta DNS en el tráfico capturado:
Si nos fijamos bien, el nombre DNS por el que hacemos la consulta DNS, al igual que el que aparece en el TextBox para la URL, no es el mismo que nosotros hemos indicado (www.mizonaconeñe.es), sino www.xn--mizonaconee-beb.es.
IDN se describe en el RFC RFC3490 y nos permite utilizar caracteres no-ASCII en aplicaciones, en este caso en nuestro navegador Web, codificando dichos caracteres en un formato conocido como ACE (ASCII Compatible Encoding), concretamente Punycode. Por lo tanto, IDN nos da la posibilidad de tener nombres de dominios DNS con caracteres específicos al idioma español, francés, etc. de tal manera que sea más sencillo para los usuarios acceder, por ejemplo, a páginas web creadas con dichos caracteres. A la hora de hacer la traducción a Punycode obtendremos una cadena ASCII con el prefijo ACE xn--, por lo que no está permitido crear nombres de dominio que comiencen con los 4 caracteres de los que se compone el prefijo.
Los navegadores web deben “traducir” los nombres IDN a nombres con codificación ACE. Es importante que el navegador Web que utilicemos sea compatible con este tipo de nombres. Esto se traduce en que intentar acceder a www.mizonaconeñe.es desde el navegador Web genera una consulta DNS para el nombre www.xn--mizonaconee-beb.es. En nuestro caso, por ejemplo, Internet Explorer desde su versión 7 es compatible con los nombres de dominio en formato IDN.
Por lo tanto, para poder servir nombres de nuestro dominio DNS IDN deberemos crear una zona DNS en formato ACE en nuestro servidor DNS. En el ejemplo que estamos tratando, tendremos que crear la zona DNS xn--mizonaconee-beb.es. De esta manera, cuando el navegador Web recibe nuestra solicitud para acceder a www.mizonaconeñe.es, lo traduce a la cadena ASCII correspondiente (www.xn--mizonaconee-beb.es) y solicita la resolución del nombre DNS correspondiente a esta cadena.
Podéis encontrar más información acerca de dominios IDN en los siguientes enlaces:
Espero que esta información os resulte útil y os ahorre tiempo a la hora de crear vuestras zonas DNS “en EspaÑol” .
- Paula Tomas Galed
Muchos de vosotros nos preguntáis por el funcionamiento y gestión de la contraseña de los equipos que pertenecen a Directorio Activo. En el siguiente post vamos a destacar los puntos más importantes del proceso del cambio de contraseña, dónde se almacena, cómo se puede cambiar y diversos parámetros de configuración que nos ayudarán en su gestión.
Los equipos que pertenecen al dominio establecen una contraseña para la cuenta de máquina. Esta información se almacena tanto en local, en el propio equipo (SAM), como en la cuenta de máquina en Directorio Activo. Cuando el equipo inicia, la información de la contraseña es utilizada para establecer el canal seguro del equipo y, por lo tanto, se comprueba que la contraseña almacenada y enviada por el equipo coincide con la existente en la base de datos de DA.
Los equipos almacenan la información de la contraseña de máquina en HKLM\SECURITY\Policy\Secrets\$machine.ACC . La contraseña actual y la previa se almacenan en las claves CurrVal y OldVal, respectivamente. En Directorio Activo, la contraseña se almacena en unicodepwd y en lmPwdHistory. Además, también se guarda el “timestamp” en el atributo pwdLastSet.
En principio, el cambio de contraseña se realiza cada 30 días por defecto, aunque esta configuración puede modificarse y establecerse según las necesidades de cada entorno. Este valor puede configurarse mediante GPOs en el siguiente valor:
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Domain member: Maximum machine account password age
Es importante destacar que las contraseñas de máquina no caducan, y por lo tanto si un equipo lleva sin iniciarse más de 30 días, la última contraseña utilizada es válida para iniciar sesión. Si la contraseña proporcionada por el equipo en algún caso, no coincide con la del Directorio Activo, el equipo envía la N-1 y, si ésta es reconocida como válida por el DC, se permitirá el establecimiento del canal seguro. En otro caso, este intento fallará y será necesario volver a establecer la contraseña. Para volver a establecer la contraseña de la máquina podemos ejecutar nltest /SC_CHANGE_PWD:<DomainName> con un usuario con privilegios para realizar el cambio.
El proceso de cambio de contraseña de la máquina, o bien, porque se haya cumplido el tiempo estipulado en la configuración del entorno (por defecto 30 días), o bien, porque forzamos el establecimiento de una nueva contraseña mediante nltest, es iniciado por el proceso NetLogon del equipo cliente y nunca por el/los DCs del dominio. Este cambio debe llevarse a cabo tanto en el equipo local (SAM) como en AD de manera controlada y debe ser un cambio atómico. Cuando el equipo, envía la nueva información al DC, este indica si el cambio se ha aceptado y se ha realizado, para escribirse el cambio en ambos sitios.
Es posible modificar el comportamiento del cambio de contraseña de los equipos cliente en caso de considerarse necesario, por ejemplo, modificar el intervalo de cambio de contraseña, deshabilitar el cambio de contraseña, etc.
Los parámetros más importantes que se pueden configurar al respecto en el equipo cliente son los siguientes:
A continuación detallamos cada uno de los parámetros:
· DisablePasswordChange: Evita que el equipo cliente lleve a cabo el cambio de contraseña.
154501 How to disable automatic machine account password changes
“Warning If you disable machine account password changes, there are security risks because the security channel is used for pass-through authentication. If someone discovers a password, he or she can potentially perform pass-through authentication to the domain controller.”
Este comportamiento puede ser configurado por clave de registro o mediante GPOs:
Key = HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters Value = DisablePasswordChange Type= REG_DWORD Default = 0 Computer Configuration\windows Settings\Security settings\Local Policies\Security Options\Domain member: Disable machine account Password changes
Key = HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters Value = DisablePasswordChange
Type= REG_DWORD Default = 0 Computer Configuration\windows Settings\Security settings\Local Policies\Security Options\Domain member: Disable machine account Password changes
· ScavengeInterval: Establece la frecuencia con la que el servicio NetLogon comprueba si es necesario realizar el cambio de contraseña.
HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters Value: ScavengeInterval Type= REG_DWORD Default= 900 (15 minutes) Range= 60 to 172800 Seconds (48 hours)
HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters Value: ScavengeInterval
Type= REG_DWORD Default= 900 (15 minutes) Range= 60 to 172800 Seconds (48 hours)
· MaximumPasswordAge: Indica cuando se debe cambiar la contraseña de la máquina.
Key = HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters Value = MaximumPasswordAge
Type= REG_DWORD Default = 30 Range = 1 to 1,000,000 (in days)
Computer Configuration\windows Settings\Security settings\Local Policies\Security Options\Domain member: Maximum machine account Password age
También existe la posibilidad de configurar los DCs de manera que no acepten los cambios de contraseña de los equipos. Para ello es necesario habilitar la siguiente opción:
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Domain controller: Refuse machine account password changes
Esta configuración es equivalente a la siguiente clave de registro:
Key=HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Value=RefusePasswordChange Default=0
Esperamos que esta información os sirva de ayuda para entender mejor los cambios de contraseña de los equipos Windows.
- Yolanda Muñoz Muñoz && Paula Tomás Galed