RBAC (Role Based Access Control) nos permite asignar usuarios, roles y permisos para el control de nuestro entorno XenServer. Esta funcionalidad no es nueva de 6.5.
RBAC depende de Directorio Activo para la authenticacion de los usuarios. Xenserver extrae la lista basada en el directorio de usuarios de AD, y Grupos a las cuales asignará los permisos necesarios. Por ello, es necesario que el pool sea integrado en el dominio. (más…)
En este post vamos a explicar como desplegar un nuevo dominio de active directory desde PowerShell.
Lo primero de todo, es tener en cuenta una serie de pre-requisitos antes de realizar la instalación.
Lo primero que debemos tener configurado es la directiva de seguridad para la ejecución de scripts de powerShell, el conocido Execution-Policy.
Ejemplo: Set-ExecutionPolicy remotesigned –force
El comando debe ser ejecutado con un usuarios con derechos de administrador. Una vez establecida la directiva de ejecución, vamos a ver los pre-requisitos.
* Asegurar antes de nada el nombre del servidor.
* Establecer una IP estática para nuestro controlador
* Disponer de un DNS. **
* Disponer de las herramientas de administración.
Estas herramientas son instaladas desde ServerManager o desde el cmdlet de PowerShell Add-WindowsFeature. Vamos a generar un script de PowerShell, basado en los requisitos necesarios, creado por Sciptingui, para la configuración previa necesaria de nuestro entorno.
#Establecer IP Estatica
# Se definen variables/datos
$ipaddress = «192.168.1.10»
$ipprefix = «24»
$ipgw = «192.168.1.1»
$ipdns1 = «192.168.1.1»
$ipdns2 = «192.168.1.10»
$ipif = (Get-NetAdapter).ifIndex
# Se configura la tarjeta de red.
New-NetIPAddress -IPAddress $ipaddress -PrefixLength $ipprefix -InterfaceIndex $ipif -DefaultGateway $ipgw
Set-DnsClientServerAddress -InterfaceIndex $ipif -ServerAddresses (“$ipdns1”,”$ipdns2”)
#Establecer nombre de equipo
# Se define variables/datos
$dcname = «dc00»
Rename-Computer -NewName $dcname –force
#Instalación de herramientas
#Se establece fichero log para comprobaciones
$featureLogPath = «c:\tmp\installfeatureLog.txt»
New-Item $featureLogPath -ItemType file -Force
# Definimos variable con la caracteristica que incluye las tools
$addsTools = «RSAT-AD-Tools»
#Se procede a la instalacion de las Tools y se genera Log
Add-WindowsFeature $addsTools
Get-WindowsFeature | Where installed >>$featureLogPath
# Reinicio de máquina
Restart-Computer
Con la ejecución de este Script de PowerShell, dispondremos todo lo necesario en nuestra maquina para la instalación de un nuevo bosque.
Una vez finalize y reinicie la maquina, podemos comprobar que los cambios han sido aplicados correctamente.
Toca el momento de instalar el Controlador de dominio. Creemos un nuevo script. En este punto es necesario utilizar el cmdlet Add-WindowsFeature el cual nos permitira instalar roles y caracterísitcas en nuestro Server 2012 (tal como hicimos anteriormente con las RSAT). Adicionalmente, haremos uso del cmdlet Wait-Job, el cual pausara la ejecución hasta que el comando add-windowsfeature haya terminado.
#Instalamos los roles AD DS, DNS y GPMC
# Definimos log
$featureLogPath = «c:\tmp\featurelog.txt»
# Arrancamos los cmdlets desde start-job para poder pausar
start-job -Name addFeature -ScriptBlock {
# Añadimos el rol de controlador de dominio
Add-WindowsFeature -Name «ad-domain-services» -IncludeAllSubFeature -IncludeManagementTools
# Añadirmos el servicio de DNS
Add-WindowsFeature -Name «dns» -IncludeAllSubFeature -IncludeManagementTools
# Añadimos las consolas de gestion
Add-WindowsFeature -Name «gpmc» -IncludeAllSubFeature -IncludeManagementTools }
# Esperamos a su finalización
Wait-Job -Name addFeature
Get-WindowsFeature | Where installed >>$featureLogPath
Este script instalará los roles y consolas necesarias pero no realizara la instalación del bosque. Para ello, seguiremos con un nuevo script. Con este, vamos a crear el dominio CTXDOM.COM
# Creación del Bosque y añadir controlador de dominio
$domainname = «ctxdom.local»
$netbiosName = «CTXDOM»
Import-Module ADDSDeployment
Install-ADDSForest -CreateDnsDelegation:$false
-DatabasePath "C:\Windows\NTDS"
-DomainMode «Win2012»
-DomainName $domainname
-DomainNetbiosName $netbiosName
-ForestMode "Win2012"
-InstallDns:$true
-LogPath "C:\Windows\NTDS"
-NoRebootOnCompletion:$false
-SysvolPath "C:\Windows\SYSVOL"
-Force:$true
Cuando se ejecute, se nos preguntara el password de Administrador, para el SafeMode. 
Para posteriormente, empezar el proceso de configuración del dominio.
Terminará el proceso con un reinicio de la VM: 
Y veremos que ya podemos logar como administrador del dominio.
Notas:
* El artículo no es original y esta basado en el artículo de Ed Wilson de Microsoft Scripting Guy.
* Los Scrips han sido probados y testeados en un servidor virtual 2012R2.
Recursos:
* Fuente Original:
* CMDLET for Check FSMO-Roles:
http://gallery.technet.microsoft.com/scriptcenter/PowerShell-Function-to-bec6c607
Alguna vez nos habremos (o no) preguntado como hace nuestro sistema para actualizar las directivas de nuestras maquinas y aplicar los cambios. Lejos de comparar claves con claves para detectar cambios en las mismas, Microsoft utiliza un sistema de versionado para detectar cambios en las directivas de nuestro entorno.
Verificar versión:
Podemos verificar la versión de las directivas desde :
HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\
En este punto disponemos de una serie de claves {XXX}, cada una de ellas corresponde a una extensión documentada en:
http://bit.ly/14GoMce
Por ejemplo, la extensión {25537BA6-77A8-11D2-9B6C-0000F8080861} corresponde a directivas de FolderRedirection. Dentro observaremos las directivas aplicadas que contienen configuraciones de FolderRedirection.
En la clave GPONAME podremos observar el ID de la directiva en cuestión, la cual corresponde con el ID del Sysvol (podemos ver este ID, en la consola de gestión de directivas – gpmc.msc , campo DETALLES de la directiva en cuestión).
En esta, observamos también la VERSION de la directiva; el valor que actualmente nos interesa.
Versión: 3080239
Entendiendo la versión
Veamos de donde sale este número. Una directiva de grupo dispone de dos partes, directiva de maquina y directiva de usuario. Con el fin de verificar y rastrear cambios en la configuración, la GPO rastrea el número de versión en busca de cambios.
Este número se divide en dos partes, una primera para la configuración de maquina y una segunda para configuración de usuario, divididos en forma de 16bits.
En el caso ejemplo, disponemos del siguiente número:
3080239 teniendo en cuenta que la composición de una versión se compone de: [User versión 16Bits][Computer Versin 16Bits]
Realizamos conversión a hexadecimal, para ello podemos utilizar la propia calculadora de Windows la cual nos facilitará la tarea: 2F002F
Realizamos la separación del hexadecimal en dos bloques de 16 bits, el cual nos da el siguiente resultado:
0x00010021 : [002F] User Version [002F] Computer versión
Así disponemos de una versión 47 para la gpo de usuario y una 47 para la gpo de máquina.
Cualquier modificación en la directiva, modificara la versión para la GPO y en el proceso de verificación de directivas se compara la versión. En caso de que la versión no coincida, se reaplicarán cambios de la directiva, en caso que la versión sea igual, se informa que no existen cambios y la directiva no será re-aplicada.
La versión de la directiva, es posible visualizar-la desde la pestaña de DETALLES en la consola de administración de directivas de grupo (gpmc.msc)
Si navegáis un poco por esta sección del registro observareis mas detalles interesantes. Os dejo literatura al respecto para aquellos que queráis profundizar mas.
Habilitar GPSvcDebugLevel para Troubleshooting de GPOs (2008)
Para habilitar el debug en 2008, realizaremos lo siguiente:
Troubleshooting e información ampliada en el procesamiento de directivas
– Abrir regedit
– Situarnos en HKLM\Software\Microsoft\Windows NT\CurrentVersion
– Crear una nueva clave llamada “Diagnostics”
– Generar un DWORD con nombre “GPSvcDebugLevel” e incluir el valor hexadecimal 0x30002
– Crear el directorio %systemroot%\Debug\Usermode
– Realizar un gpupdate /force
A partir de este momento, los logons de usuario generarán un fichero gpsvc.log en la ruta creada, dónde podremos verificar que esta ocurriendo durante la aplicación de directivas.
Troubleshooting y errores durante en el uso directivas.
– Abrir regedit
– Situarnos en HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}
– Generar un DWORD con nombre “ExtensionDebugLevel” e incluir el valor decimal 2.
– Reiniciar la maquina.
El fichero winlogon.log es creado en %systermroot% \Security\Logs para su revisión.
Recursos adicionales:
Computer Policy for Client-side Extensions: http://technet.microsoft.com/en-us/library/cc978265.aspx
Client-side Extension Preferences: http://technet.microsoft.com/en-us/library/cc978250.aspx
Group Policy Client Side Extension List: http://blogs.technet.com/b/mempson/archive/2010/12/01/group-policy-client-side-extension-list.aspx
Understanding the domain-based GPO version number: http://blogs.technet.com/b/grouppolicy/archive/2008/01/08/understanding-the-domain-based-gpo-version-number-scripts-included.aspx
Best Practices: http://technet.microsoft.com/en-us/library/cc961688.aspx
The Basics of Group Policies: http://blogs.technet.com/b/askperf/archive/2007/06/05/the-basics-of-group-policies.aspx
Group Policy Site: http://technet.microsoft.com/en-us/windowsserver/bb310732.aspx
Using Log files for Troubleshooting GPOs: http://technet.microsoft.com/en-us/library/cc775423%28v=WS.10%29.aspx
How Administrative Templates Extension Works: http://technet.microsoft.com/en-us/library/cc758189%28v=WS.10%29.aspx
Durante la integración y/o administración de una plataforma pueden aparecer necesidades constantes de actualizar GPOs en los servidores.
Modificar una GPO y realizar un gpupdate en los servidores no es una tarea complicada, pero cuando son unos cuantos los servidores a actualizar, puede ser un poco tedioso.
Las pruebas se realizarán sobre un servidor donde validaremos su correcto funcionamiento, pero confirmado el proceso, si queremos aplicar de forma inmediata estos cambios al resto de servidores, no nos quedará mas remedio que ir conectando uno por uno para forzar el update o esperar a que estas sean aplicadas de forma automática.
PowerShell permite a los administradores Windows automatizar tareas que solemos utilizar o que es necesario realizar de forma común o repetitiva.
Este pequeño script en PowerShell se encargará de actualizar mediante gpupdate una lista de servidores concreto. Para ello, nos son necesarias 3 cosas.
El primer punto se solventa con un fichero .txt en el cual incluimos el nombre de maquina (fqdn). Ejecutar el comando en mas o menos servidores, implica únicamente modificar el fichero con mas o menos servidores a actualizar.
Para el segundo punto, busque la solución mas rápida. Y esta vino de Sysinternals con “psexec.exe” el cual nos posibilita la ejecución de comandos de forma remota.
Por último, solo quedaba generar el script. Y este es sin duda el punto mas sencillo 😉 Ahí os dejo el código:
$ListComputers = gc .\Servers.list.txt
# Creamos variable $ListComputers con el contenido del fichero servers.list.txt
Foreach ($strComputer in $ListComputers)
# Por cada elemento, asignar valor a la variable $strComputer y realizar:
{.\psexec.exe \\$strComputer gpupdate.exe /target:computer /force}
#Ejecuta de forma remota mediate psexec.exe sobre la maquina $strComputer, un gputdate.exe y actualiza las GPOs de maquina.
Modificando el target por :user las gpo de usuario serán actualizadas, pero tened en cuenta que las directivas de usuario en algunos casos requieren de un logoff de usuario. Para forzar este logoff utilizaríamos el modificador /Logoff.
$ListComputers = gc .\Servers.list.txt
Foreach ($strComputer in $ListComputers)
{.\psexec.exe \\$strComputer gpupdate.exe /target:user /forcé /Logoff}
Recursos:
Psexec: http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx
Gpupdate: http://technet.microsoft.com/en-us/library/cc739112%28v=ws.10%29.aspx
En este artículo vamos a explicar como migrar vuestro controlador de dominio de 2008/2008R2 al reciente 2012. Recordad que también es posible realizar un Upgrade del DC tras elevar el nivel funcional del dominio, pero… ¿de verdad vamos a realizar upgrade en entornos productivos? … 😛
Requisitos previos
Es esencial para seguir este manual…
– Un Controlador de dominio en 2008/2008R2
– Un Servidor 2012 Server
Para su migración podemos seguir los siguientes pasos:
DCPROMO no existe en 2012. Para ello, existen dos posible nuevos caminos.
Vamos a usar el método 1 por ser un poco mas ágil inicialmente, aunque no durante todo el proceso; para simplificar-lo, para hacer-lo mas accesible a todo el publico, realizaremos y completaremos la migración desde la GUI.
Para ello, empezamos instalando el rol de AD desde powershell con un simple comando:
Add-WindowsFeature -name ad-domain-services -IncludeManagementTools
Si queremos asegurarnos de que el esquema del bosque y de AD han sido actualizados, en el CD de 2012, dentro de la carpeta Support, disponemos de las herramientas de ADPREP para tal efecto.
Adprep.exe /forestprep
Adprep.exe /domainprep /gpprep
Tras ello, seguimos tal y como indicamos a continuación:
En las notificaciones de administración de servidor podemos observar un icono de Advertencia.
Seleccionamos, “promover el Servidor”.
Seleccionamos “Agregar el controlador al dominio existente”
Especificamos los roles para el controlador.
Especificamos opciones adicionales.
Confirmamos rutas de acceso y confirmamos el resumen de cambios a realizar y tras ello, se procede con la instalación. Tras ello, el sistema se reinicia.
Una vez finalizado y reiniciado el sistema.
