La delegación de grupos es algo bastante frecuente en un entorno de Exchange. Esta delegación en general la encontramos de 2 formas; una donde el usuario final (por ejemplo jefe de proyecto o departamento) maneja la membresía de algún grupo en particular, otra donde usuarios de soporte administran la membresía de múltiples grupos. En este artículo nos vamos a enfocar en el caso del usuario final.
Situación de ejemplo:
Luego de migrar a Exchange 2010 o Exchange 2013 algunos usuarios reportan que antes podían modificar la membresía de “x” grupo y ahora reciben errores relacionados a permisos.
En Outlook se presenta el siguiente “error” al modificar la membresía de un grupo:
Changes to the distribution list membership cannot be saved. You do not have sufficient permission to perform this operation on this object.
En español:
No se pueden guardar los cambios en la pertenencia a listas de distribución. No tiene permisos suficientes para realizar esta operación en este objeto.
Digo “error” porque en realidad no es un error, sino que Exchange esta haciendo efectivamente lo que tiene que hacer (aunque no sea de lo más intuitivo).
Causas comunes:
-
El grupo que se intenta administrar a través del Outlook no es universal. Hay que tener en cuenta que en Exchange 2010 todos los grupos asociados a correo deben ser universales (sea seguridad o distribución), la excepción es cuando hay coexistencia con por ejemplo Exchange 2003.
-
La delegación de la administración de la membresía fue realizada originalmente a un grupo y no a un usuario individual (o a varios). En Exchange 2010 no es posible utilizar un grupo en el “managedby”, debo listar cuentas individuales.
-
No se cuenta con permisos a nivel de RBAC (Role Based Access Control) independientemente de ser el propietario o no del grupo.
Actualización 11/7/14: A partir de Exchange 2013 SP1 (cu4) es posible utilizar un grupo universal de seguridad en el campo de ManagedBy
Algunos conceptos sobre permisos en Exchange…
A partir de Exchange 2010, el modelo de permisos se basa en RBAC a diferencia de versiones anteriores que utilizaban ACLs (Access Control Lists, permisos tradicionales). Sin entrar en mucho detalle acerca de RBAC, este modelo es muy superior al anterior en muchos aspectos, por ejemplo desde el punto de vista de la granularidad de la delegación. Con RBAC se puede llegar al punto de delegar el uso de un comando (cmdlet en el shell) y un solo parámetro. Por ejemplo que un grupo de soporte pueda únicamente utilizar el comando Set-Mailbox con los parámetros que habilitan a manejar la cuota de un buzón (esto aplica mientras se use una herramienta administrativa soportada).
De un modo muy simplificado y como para entender algunas básicas de RBAC podríamos decir que para definir qué permisos tiene un usuario final en relación a su cuenta utilizamos lo que se denominan “Role Assignment Policies” (“User Roles” en el ECP) y para delegar permisos a usuarios de soporte utilizamos “Management Roles» (roles de administración que agrupan comandos y parámetros) asignados a “Role Groups” (grupos universales de seguridad con roles de administración asignados).
De forma predeterminada todo usuario con buzón tiene asignada una política denominada “Default Role Assignment Policy”. Esta política en adición a definir que permisos tiene el usuario sobre su cuenta podría incluir también la posibilidad de crear, remover y modificar grupos de distribución entre otros elementos. Por ejemplo la política asignada podría habilitar o no a configurar un OOF (fuera de oficina), modificar información de contacto, membresía de grupos, etc.
Para visualizar esta política debemos utilizar el EMS (Exchange Management Shell) o el ECP (Exchange Control Panel), lo más sencillo en este caso sería utilizar el ECP (en Exchange 2013 la interfaz es distinta pero el concepto es el mismo):
Si la editamos con la finalidad de ver que habilita a realizar encontramos una sección dedicada a los grupos de distribución:
Como se puede ver en la imagen anterior, la opción “MyDistributionGroups” se encuentra desmarcada. Esta opción habilita a modificar la membresía de un grupo en adición a la creación o remoción de estos. Si bien en casos específicos esta podría ser la opción que buscamos no es algo que quisiéramos habilitar para todos los usuarios de la organización. Debido a esto, la “solución” no sería marcar esta opción en la política predeterminada.
Dado que a este nivel el ECP expone más información que el Outlook, veamos como se ve en el caso de un usuario final sin esta opción seleccionada (esto sería lo predeterminado):
A continuación como prueba marcamos la opción para ver que cambia en el ECP:
Ahora vemos que tenemos una opción adicional para visualizar grupos de los cuales sea el propietario, también que habilita una opción para crear y otra para eliminar (la cruz en gris se habilita cuando seleccionamos un grupo). Estas ultimas opciones son las que en general no son deseables para el caso de un usuario final.
Suponiendo que un usuario reporte el problema de permisos, algo sencillo que se puede hacer para estar seguro de lo que estaría faltando es pedirle que entre al ECP y que se fije si tiene la opción de “Public Groups I Own”, si no la tiene, lo que le esta faltando es tener una política asignada que le habilite esto, si tiene la opción pero no aparece el grupo sobre el cual reporta el error de permisos lo más probable es que o no sea propietario del grupo o este no sea universal.
Solución:
Ahora analicemos un poco la situación, si agrego la opción de “MyDistributionGroups” a la política asignada de forma predeterminada (Default Role Assignment Policy) estaría habilitando a todos los usuarios de la organización entre otras cosas a crear grupos. Una alternativa podría ser crear una nueva política y asignársela a cada usuario que tenga como requerimiento manejar grupos pero aun así estaría dando mucha libertad al usuario.
Si bien tenemos varias formas de lograr el requerimiento, la más sencilla y flexible sería asignar a la política predeterminada únicamente la posibilidad de modificar la membresía de los grupos que el usuario sea propietario.
Para manejar esto del modo más simple posible el equipo de producto de Exchange desarrolló un script muy fácil de utilizar denominado Manage-GroupManagementRole.ps1. El script esta disponible para su descarga en el script repository de Microsoft.
Para ver cómo utilizar el script lo ejecutamos sin parámetros:
Como se puede ver en la imagen, el script básicamente lo que hace es crear un management role que permite la modificación pero no la creación o eliminación de grupos (derivado del builtin “MyDistributionGroups”). Lo otro a tener en cuenta es que como se indica, el usuario en cuestión debe ser propietario del grupo.
Si en nuestra organización estamos utilizando la política predeterminada (sin modificaciones), ejecutamos el script del siguiente modo:
Manage-GroupManagementRole –CreateGroup –RemoveGroup
Si por algún motivo se quiere aplicar este cambio a una política que no sea la default, se debe especificar el nombre con el parámetro “-policy”:
Manage-GroupManagementRole –CreateGroup –RemoveGroup –Policy “Nombre”
Para validar que realizó los cambios que esperábamos podemos ir a la sección de grupos en el ECP (la alternativa detallada es mediante el EMS):
Como se ve en la imagen, ya no aparecen las opciones de crear o remover.
Listo!, los usuarios con permisos ya podrían hacer las modificaciones utilizando directamente el Outlook.
Con esto concluimos la parte 1 del artículo, en la parte 2 vamos a ver cómo manejar la situación donde se cuenta con múltiples grupos y se desea delegar la administración de estos a varios usuarios en base a la membresía. En adición, cómo mantener la delegación de una forma automatizada.
Por último, dejo un par de links con información adicional:
Deja una respuesta