Los mismos permisos que...

Active directory no tiene una forma simple de copiar la membresía de grupos de un usuario a otro desde las herramientas administrativas. Si nos piden que un usuario tenga los mismos permisos que otro, podemos recurrir a PowerShell para realizar esta tarea.

El procedimiento es el siguiente:

1. Guardamos los grupos en una variable... $grupos=(Get-ADUser "Pires" -Properties Name,MemberOf).memberof
2. Enumeramos los grupos para comprobar el comando anterior... $grupos
3. Comprobamos los grupos actuales del usuario que recibirá las nuevas asignaciones... Get-ADUser KaraT -Properties * | fl Name, MemberOf
4. Agregamos las nuevas membresías pasando por todos los grupos guardados en la variable... foreach ($group in $grupos) {Add-ADGroupMember $group -Members "KaraT"}
5. Comprobamos los nuevos grupos... Get-ADUser KaraT -Properties * | fl Name, MemberOf

El único grupo que no se copia de esta manera es el grupo default del usuario, que generalmente es "Domain Users".

Como ejemplo, copiamos la membresía del usuario "Pires" al usuario "KaraT" (Figura 1).

Figura 1

Replicación AD Inter-Site ... pero ya!!!

Cuando Active Directory empezó a utilizarse en el año 2000, la conexión de red entre dos sitios de AD podía ser lenta o inestable. Por ese motivo la replicación entre ambos sites no puede ser menor a 15 minutos (Figura 1).

Figura 1

Hoy las conexiones son mucho mas rápidas y estables. Si queremos mantener la separación de nuestros sites, pero no queremos esperar 15 minutos para que comience la replicación, podemos configurar el Site Link que une los sites para que éste notifique cuando se produce un cambio.

En las propiedades del Site Link, dentro de la solapa Attribute Editor podemos buscar el atributo "options" (Figura 2) y darle el valor de "1" (Figura 3).

Figura 2

Figura 3

De esta forma nuestro Site Link usará notificaciones ante los cambios en el Active Directory sin esperar los 15 minutos mínimos requeridos en la configuración predeterminada.

Evento en el MUG - Active Directory de 0 a 100

Para los que estén por Buenos Aires, el Viernes 7 de Abril de 2017, de 9:30 a 18 hs, en el Auditorio del MUG, Rivadavia 1479 Primer Piso "A". 

Será una jornada intensiva para profesionales IT en la que veremos los conceptos fundamentales de infraestructura y realizaremos demos en nuestros servidores de Active Directory Domain Services.

La registración pueden hacerla por medio de este link.

Server Core en Windows Server 2016

Una nueva característica de Windows Server 2012 había sido la posibilidad de agregar o quitar la interface gráfica a un equipo.

Con Windows Server 2016 esta posibilidad fue removida. Por lo que debemos prestar atención al momento de instalación si vamos a utilizar un Server Core o un Server con GUI, ya que cambiar la interface del equipo implica reinstalar el servidor, al igual que sucedía con Windows Server 2008.

DCPromo.exe en Windows Server 2016 !!!

Ya desde Windows Server 2012 se viene anunciando que dcpromo.exe está desenfatizado para promover un nuevo DC en nuestro dominio. Igualmente con Windows Server 2016 aún tenemos posibilidad de utilizarlo. Desde la línea de comandos, con un archivo de respuesta desatendido podemos instalar un DC con dcpromo.exe en Windows Server 2016. La forma de hacerlo es igual que en la versión anterior de Windows Server y podemos leer cómo en un articulo anterior de este blog.

 

 

Adicionalmente, dcpromo.exe se puede utilizar para desinstalar los binarios de ADDS, crear o usar una cuenta de equipo para un RODC e incluso para forzar la desinstalación de ADDS en un DC.

User profile cannot be loaded

Hoy, uno de los administradores quiso autenticarse en un servidor y recibió un error (Figura 1).

Figura 1

El error me resultaba conocido, y está relacionado con la corrupción del perfil del usuario. Varios artículos indican que se debe entrar en el registro del equipo y borrar una clave que contiene el SID del usuario, la cual finaliza con ".BAK". Pero éste no era el caso, ya que para poder aplicar esa resolución, era necesario que el usuario se hubiera validado al menos una vez en el equipo, para que el perfil pudiera crearse y luego corromperse.

Buscando otra solución, revisé el Event Viewer y encontré un evento relacionado (Figura 2).

Figura 2

Al parecer un KB aplicado al equipo cambió los permisos en el archivo que se indica en el Event 1509. La resolución fue modificar los permisos en el archivo para que herede los mismos permisos que el directorio que lo contenía, para que la copia del perfil del nuevo usuario se complete con éxito.

Buscar permisos en AD

Buscar en Active Directory los permisos que se han asignado a diferentes objetos, es una tarea complicada. En AD existen varios tipos de objeto: OU, usuarios, grupos, cuentas de equipo, etc, y a veces necesitamos saber dónde fue delegada una cuenta.

Para facilitar la búsqueda, podemos utilizar PowerShell!

Como vamos a trabajar con Active Directory, lo primero es importar el modulo de AD (Figura 1) y cambiar la ubicación de trabajo desde el C:\ a AD (Figura 1)

Figura 1

Luego le asignamos a una variable, el valor de todos los objetos de AD (Figura 2).

Figura 2

Por último, para cada valor de la variable donde tenemos todos los objetos de AD, hacemos una búsqueda de los permisos en su Access Control List (ACL) y mostramos los resultados (Figura 3).

Figura 3

cmdlets:

Import-Module ActiveDirectory

 

Set-Location AD:

 

$allO=(Get-ADObject -Filter * -Properties DistinguishedName).distinguishedname

 

foreach ($one in $allO) {(get-acl $one).access |? {$_.IdentityReference -like "*deleo*" }| ft @{Expression={$one};label="Nombre"},IdentityReference,AccessControlType,@{Expression={(Get-ADObject $one).objectClass};label="Type"}}