Cerrar
InicioAzureBuenas Prácticas: Usuarios deshabilitados y sincronizados con O365

Buenas Prácticas: Usuarios deshabilitados y sincronizados con O365

Voy a comentar lo que yo suelo configurar (de forma sencilla) para automatizar la gestión de usuarios deshabilitados en ADDS y lo beneficios que obtenemos en entornos con Azure AD Connect, algo que a veces veo que no se tiene presente en muchas organizaciones. Hay muchas razones por las que debemos gestionar las bajas en nuestro ADDS, fuera de las que ya no voy a nombrar porque me parece muy obvias. Si además, tenemos nuestro ADDS sincronizado con AzureAD entonces tenemos muchas más razones para tramitar de forma más meticulosa nuestras bajas.

Algunas de las razones por las que debemos tener un buen proceso de baja de usuarios, son las siguientes:

  • Distinguir los usuarios que están de baja en nuestro ADDS pero que han tenido licencia de O365
  • Ocultar los usuarios deshabilitados en la GAL (Global Address List)
  • Limpiar atributos personales (Empresa, Puesto, Responsable, Teléfonos, Dirección, etc..)
  • Quitar foto de usuario
  • Quitar a los usuarios de los grupos de Teams
  • Convertir los buzones de correo en buzones compartidos
  • Almacenar su información de OneDrive

Estos son, entre otros, algunas de las razones por las que deberíamos aplicar algo de mimo (y automatismo) al proceso de baja. No debe ser un simple proceso de deshabilitar el usuario, quitar la licencia y .. listo.

Este artículo, voy a mostraros un pequeño script (súper sencillo) que “automatizará” la baja de usuarios, retirar sus atributos (en On-Premises) y luego tareas en O365 (Exchange y Teams), pero antes, aquí  os dejo un esquema gráfico de mi propuesta de buenas prácticas:

Cuando tenemos un entorno sincronizado con O365 es muy importante que tengamos una buena higiene de nuestros usuarios de ADDS, desde sus atributos hasta los grupos de seguridad los que pertenece. Si somos muy pro atributos, seguro que estamos cubriendo muy bien la ficha de nuestros usuarios:

  • Nombre
  • Apellidos
  • Nombre para mostrar
  • Oficina
  • Teléfono(s)
  • E-mail
  • Empresa
  • Departamento
  • Manager (organigrama en Teams)
  • extensionAttribute1-15 (si tenemos extendido nuestro esquema con un Exchange On-Premises)
  • Etc..

Todos estos atributos los cubrimos para tener una ficha de usuario con información muy útil visible en las aplicaciones de O365 como Exchange, Teams, Outlook [tarjeta], etc… pero si tenemos datos incorrectos desde luego es un caos y estamos dando información al resto de usuarios incorrecta e incoherente. Para ello, cuando demos un usuario de baja, debemos borrar todos los atributos que consideremos oportuno, además de otras tareas relacionadas con O365:

  • Retirar licencia de O365
  • Guardar su información de OneDrive
  • Guardar su buzón de correo
  • Borrar foto de usuario
  • Quitar usuario de los Teams a los que pertenecía

Esto que a mi personalmente me parece obvio, hay empresas que ni se lo plantean y luego así hay un desgobierno importante en todos los ambientes (On-Premises y Cloud). Yo me voy a centrar en mostrar como podemos automatizar varias cosas:

  • Borrar atributos  de nuestros usuarios deshabilitados [script de PowerShell en On-Premises]
  • Quitar membresías locales [script de PowerShell en On-Premises]
  • Ocultar en la GAL [script de PowerShell en On-Premises]
  • Retirar foto de usuarios [script de PowerShell en Azure]
  • Guardar su buzón de correo [script de PowerShell en Azure]
  • Retirar licencia [pertenencia a grupos de AzureAD dinámicos mediante la limpieza de atributos]
  • Guardar información de OneDrive [configuración a nivel de tenant]
  • Quitar sus pertenencias de grupos de O365 utilizados por Teams [script de PowerShell en Azure]

Como algunas cosas ya las tengo documentadas, simplemente os voy a dejar los enlaces a dichos artículos:

Con esto tendríamos a todos los usuarios deshabilitados y sincronizados en AzureAD fuera de los grupos de Teams [evitamos ver miembros de Teams deshabilitados], además de retirar la foto de dicho usuarios. Ahora nos quedaría el retirar los diferentes atributos, los cuales voy a comentar los que tienen vital importancia en las aplicaciones de O365:

  • Ocultar en la GAL: que mostremos usuarios deshabilitados en la GAL de Exchange, no tiene sentido y además que podemos llevar a cierta confusión de los usuarios
  • Atributo Manager: sabemos que desde Teams tenemos una opción para ver el organigrama de la empresa, algo súper útil y que se forma con el atributo de manager configurado en los usuarios. No tiene sentido ver un organigrama con cientos de usuarios deshabilitados, mejor limpiamos el atributo y lo dejamos súper limpio.
  • Atributos extendidos: los podemos utilizar para muchas cosas, pero entre ellas la de utilizarse grupos dinámicos en AzureAD para asignar licencias [+info grupo dinámico en Azure Active Directory]

Dicho esto, vamos a centrarnos en el proceso de baja de nuestros usuarios. Voy a un escenario concreto pero se puede aplicar en cualquier entorno de O365, pero en algunos tiene más cabida que en otros. Si tenemos un entorno donde tenemos configurado OneDrive para hacer “backup” de Escritorio, Mis Documentos y Mis Imágenes, seguro que queremos guardar esa información de nuestros usuarios deshabilitados. Mucha gente se los descarga y los guarda en otros almacenamientos (USB, Cloud, etc..), pero .. ¿sabéis que MSFT tiene la posibilidad de configurar que no se borre el site de OneDrive de los usuarios por 10 años? Pues eso, podemos configurar a nivel de tenant desde el Centro de Administración de SharePoint:

Con esto, durante 10 años no nos tenemos que preocupar por descargar la información de nuestros usuarios deshabilitados. Otra cosa, si el usuario tiene buzón de correo .. pues lo podemos convertir a buzón compartido (además de ocultarlo en la GAL) y ya podemos retirar la licencia del usuario y tenemos su buzón intacto, otra vez ya no tenemos que hacer nada con su buzón (exportaciones, etc…).

¿Qué nos queda ahora? Pues el script que quite todos los atributos de los usuarios deshabilitados, esto que permiten además de conocer información profesional del usuario (Nombre, Apellidos, Oficina, etc..) la que se utiliza para las listas dinámicas de Exchange, AzureAD, etc… si borramos datos de los atributos, automáticamente desparecerán de estas listas y por lo tanto, otro nivel de higiene cumplido. Pero antes de mostraros el script, cuya ejecución la haremos desde un servidor unido al dominio de On-Premises (evitemos configurarlo en los DC), veremos que necesitamos:

  1. Cuenta de usuarios sin privilegios administrativos
  2. Como mínimo un grupo de seguridad con delegación de tareas administrativas sobre las OU donde tenemos nuestros usuarios deshabilitados
  3. GPO para configurar Inicio de sesión por lotes para conceder al usuario ejecutor de la tarea automatizada que pueda hacerlo sin ser administrador local

Voy a dejaros un ejemplo de cada requisito comentado, luego cada uno que lo adapte o configure como considere oportuno. Para la ejecución de la tarea programada necesitamos una cuenta de usuario, la cual, no queremos [no lo necesitamos] que sea administrador ni nada parecido, pero esté configurada con cierto mimo. Aquí os dejo mi propuesta:

La cuenta tendrá la siguiente nomenclatura:

  • Prefijo: svc
  • Proceso: Task
  • Servicio: Adds
  • Objeto: .usr/.cmp

El nombre de usuario será el utilizado con el atributo SamAccountName, y siempre que sea posible sin el dominio enrutado en internet: svcTaskAdds.usr@dominio.local. El usuario solo pertenecerá a los grupos creados para delegarle las tareas administrativas, además de las siguientes características:

  • El usuario se creará en la OU de Identidades Especiales/Usuarios/Servicios/Adds
  • La contraseña cuanto más compleja, mejor
  • La contraseña nunca expira
  • EL usuario no puede cambiar la contraseña
  • La cuenta es importante y no se puede delegar
  • Iniciar sesión en: se especificará el equipo(s) en los cuales el usuario podrá iniciar sesión.

Ahora necesitamos que el usuario tenga permisos sobre nuestras OU donde tenemos los usuarios deshabilitados, aquí va mi propuesta de grupos:

Para delegar los permisos necesarios para la cuenta de ejecución de la tarea, podemos crear los siguientes grupos de seguridad de dominio local:

  • Acl Adds OU Nombre-OU-Grupos Grupos svcTask
    • Ámbito: Dominio local
    • Tipo: Seguridad
    • Descripción: Usuarios de servicio con permiso de modificación de las membresías de los usuarios deshabilitados
    • Permiso delegado: Modificar la membresía de un grupo
  • Acl Adds OU Nombre-OU-Usuarios UsuariosDesh svcTask
    • Ámbito: Dominio local
    • Tipo: Seguridad
    • Descripción: Usuarios de servicio con permiso de modificación de las membresías de los usuarios deshabilitados
    • Permiso delegado: Crear, borrar y administrador cuentas de usuarios

Nota: no voy a mostrar como delegar tareas administrativas, pero aquí os dejo como podéis hacerlo: Delegar la administración mediante objetos de unidad organizativa. Por favor, siempre los permisos más restrictivos posible

La GPO que necesitamos esa para permitir el inicio de sesión por lotes en el equipo en el cual ejecutaremos la tarea programada, por defecto, esto solo lo pueden hacer los Administradores y Operadores de copia de seguridad y nuestro usuario no tiene que ser miembro de ninguno de estos grupos. Además, en la misma GPO quiero que copie el script que lo tengo compartido [protegido correspondientemente con una ACL] para que siempre se copie al servidor de destino, así si alguien actualiza el script el equipo siempre lo tendrá actualizado. A continuación, os muestro los pasos a seguir:

Se creará una GPO que configure la copia del script desde una ubicación de red hasta el servidor que ejecutará la tarea programada, y la política de Iniciar sesión como proceso por lotes.

En la política de Iniciar sesión como proceso por lotes debemos agregar a los siguientes grupos (los por defecto) y el usuario creado para la ejecución de la tarea programada:

  • Administradores
  • Operadores de copia de seguridad
  • svcTaskAdds.usr [o el usuario que hayáis creado]

En la misma GPO, configuraremos que el script [Update-Attrib-Usr.ps1] se copie desde la red \\dfs\xx\scriptsIT al servidor en la ubicación C:\Windows\Scripts.

La GPO se llamará Cmp Sec Logon On Batch Update-Users y se vinculará sobre un servidor de administración (bastión) [evitaremos esta configuración en los controladores de dominio]

Por último, debemos crear la tarea programada con la siguiente configuración:

La tarea programada se creará de forma manual con la siguiente configuración:

  • Nombre: Actualización Atributos Usuarios
  • Cuenta de ejecución: svcTaskAdds.usr
    • Ejecutar tanto si el usuario inició sesión como si no
    • Ejecutar con los privilegios más altos
  • Hora: la misma de la creación de la tarea
    • Repetir: cada 4 horas
  • Acción: ejecución del script con la siguiente configuración
    • Programa o script: exe
    • Argumentos: -ExecutePolicy Bypass -File C:\Windows\scripts\ Update-Attrib-Usr.ps1
  • Configuración: Permitir que la tarea se ejecute a petición

Ahora si, os voy a mostrar/comentar partes del script para que se pueda “entender fácilmente”, pero vamos, ya os digo que súper sencillo para que cualquier técnico pueda actualizarlo cómodamente. Lo primero que tenemos que definir, son las variables, yo tengo las siguientes:

  • # Raiz de la OU de usuarios deshabilitados
  • $OUUsuariosDesh = “OU=UsuariosDesh,OU=Empresa,DC=dominio,DC=local”
  • # OU de usuarios deshabilitados que necesitan mostrarse en la Gal
  • $OUUsuariosDeshGal = “OU=Gal,OU=UsuariosDesh,OU=Empresa,DC= dominio,DC=local”
  • # OU de usuarios deshabilitados que NO necesitan mostrarse en la Gal
  • $OUUsuariosDeshNoGal = “OU=NoGal,OU=UsuariosDesh,OU=Empresa,DC= dominio,DC=local”
  • # Prefijo para mostrar en el nombre para mostrar de los usuarios deshabilitados
  • $PrefijoBaja = “(Baja)”
  • #Ou de Grupos que queremos ocultar en la GAL
  • $GruposNoGal = “OU=Sm,OU=Locales,OU=Grupos,OU=Empresa,DC= dominio,DC=local”
  • #OU de todos los grupos globales corporativos
  • $Grupos = “OU=Grupos,OU= Empresa,DC=cunado,DC=local”
  • # Listado de usuarios deshabilitados en la raíz de la OU de usuarios Deshabilitados
  • $UsuariosDesh = Get-ADUser -SearchBase $OUUsuariosDesh -Filter {Enabled -eq $False} -Properties *
  • #OU de todos los usuarios de la empresa
  • $OUUsuarios = “OU=Usuarios,OU=Empresa,DC=dominio,DC=local”

Creo que los comentarios son bastante claros, eso si, tenéis que adaptarlo a vuestras configuraciones. Ahora, aquí va cada sección comentada del script:

# 1. Mover usuarios deshabilitados en la OU de usuarios a la OU de usuarios deshabilitados NOGal
Se moverán todos los usuarios deshabilitados de la OU de Usuarios a la OU NoGal de los usuarios deshabilitados, sobre la cual en los siguientes puntos del script se automatizará el resto del proceso.

# 2. Quitar atributos personales de los usuarios deshabilitados
Se limpiarán todos los atributos del usuario, los cuales se han cubierto en el momento del alta. Esto hará que, desde las diferentes aplicaciones que utilizan dichos atributos, los usuarios no vayan apareciendo.

# 3. Añadir el texto $PrefijoBaja como prefijo en el nombre para mostrar de los usuarios deshabilitados
Se añadirá el prefijo especificado en la variable $PrefijoBaja, el cual se añadirá el atributo nombre para mostrar de los usuarios. Esto nos permite de forma rápida distinguir en AzureAD y O365 que el usuario está deshabilitado.

# 4. Quitar atributos extendidos
Si hemos utilizado los atributos extensionAttribute1-15, se borrará todo el contenido de cada atributo.

# 5. Ocultar usuarios deshabilitados en la GAL de la OU NoGal
Si tenemos el esquema del ADDS extendido con los atributos de Exchange, este proceso cambiará a True el atributo msExchHideFromAddressLists. Lo que permitirá mantener una GAL siempre lo más actualizada posible, evitando mostrar usuarios deshabilitados.

# 6. Mostrar usuarios deshabilitados en la GAL de la OU Gal
Si necesitamos mostrar usuarios deshabilitados en la GAL, debemos moverlos manualmente a la OU Gal dentro de la OU de los usuarios deshabilitados y se cambiará a False el atributo msExchHideFromAddressLists

# 7. Quitar las membresías de los usuarios deshabilitados con excepción de grupo Usuarios del dominio
Se quitarán todas las membresías de los usuarios deshabilitados, dejamos únicamente el grupo Usuarios del dominio. Si los grupos de seguridad están en inglés debemos cambiar la siguiente línea $grupos = Get-ADPrincipalGroupMembership $user.SamAccountName | Where-Object {$_.name -NotLike ‘*Usuarios del*’} por esta $grupos = Get-ADPrincipalGroupMembership $user.SamAccountName | Where-Object {$_.name -NotLike ‘*Domain User*’}

# 8. Ocultar grupos de seguridad en la GAL
Debemos ocultar todos los grupos de seguridad en la GAL que no sean necesario mostrarse, ejemplo: grupos de seguridad habilitados para correo para securizar el acceso a buzones compartidos, etc.

# 9. Quitar usuarios deshabilitados de grupos de seguridad [ejecución manual y controlada]
Este punto permite retirar lo miembros deshabilitados de todos los grupos de seguridad que se encuentre en la OU indicada en la variable. Debemos tener mucho cuidado con esto, ejecutarlo de forma controlada y manual. Esta sección la utilizo para limpiar todo los grupos de determinadas OU los cuales tienen miembros deshabilitados, así dejamos los grupos sólo con usuarios habilitados.

Notas sobre las OU:

  • NoGal: los usuarios que contenga esta OU no se mostrarán en la GAL [msExchHideFromAddressLists = False]
  • Gal: los usuarios que contenga esta OU se mostrarán en la GAL [msExchHideFromAddressLists = True]
  • PrefijoBaja: permite cambiar el nombre para mostrar de los usuarios y así podemos ponerle un prefijo que nos permita distinguirlos, por ejemplo cuando vemos un documento modificado en SharePoint y vemos el nombre del usuario. Ejemplo del nombre para mostrar de un usuario: [Baja] Juan Pérez.

Lo dicho, aquí cada uno sabrá que estructura de OU tiene y como debería organizarla. Yo es como lo configuro, cada uno es muy libre de hacerlo como desee. Mi script es súper sencillo y súper útil para mi, dejando siempre el ADDS bien cuidadito y lo que subamos a AzureAD súper higienizado.

Aquí os dejo mi script comprimido en zip:

GDE Error: Error al recuperar el fichero. Si es necesario, desactiva la comprobación de errores (404:Not Found)
y aquí una captura de pantalla para que tengáis una previsualización del código:

Espero que no me haya dejado muchas cosas atrás en la descripción, pero si es así o algo no se entiende, por favor, dejarlo en los comentarios e iré respondiendo a la mayor brevedad posible. Pero lo que sí espero, es que se haya captado la idea:

  • Automatizar la baja
  • Guardado de información [Exchange y OneDrive]
  • Higiene de información [Teams, Office Apps]
  • Ejecución con MPP [Mínimos Privilegios Posibles], que siempre se puede hacer mejor, pero lo normal es que la gente se vaya a lo fácil y se pongan a todas las cuentas como local admin y listo..

Como siempre, espero que os sea de utilidad y ahora os toca a vosotros darle una vuelta, mejorarlo y comentarlo por favor!!

Microsoft Azure: For
Azure AD: Entorno se
NO HAY COMENTARIOS

DEJA UN COMENTARIO

Este sitio web utiliza cookies. Si continúas navegando, consideramos que aceptas su uso. Puedes obtener más información en nuestra política de cookies. ACEPTAR

Aviso de cookies
Share This