Revista Informática

Como delegar la administracion de grupos en Exchange 2010/2013

Publicado el 01 enero 2014 por Aprendiendoexchange
Facebook0LinkedIn0Google+1Twitter0

El delegar la administració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.

En la primer parte vamos a ver algunos cambios que hay en este sentido a partir de Exchange 2010, conceptos nuevos y como delegar efectivamente la administración de un grupo, en la segunda parte nos vamos a enfocar en como mantener esta delegación de un modo automatizado sin tener que estar chequeando manualmente cada caso puntual.

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.

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:

  1. El grupo que intento 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.
  2. 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 o posterior no es posible utilizar un grupo en el “managedby”, debo listar cuentas individuales.
  3. No tengo permisos a nivel de RBAC (Role Based Access Control) independientemente de ser el propietario o no del grupo.

Actualización 11/7/14: En Exchange 2013 SP1 (cu4) es posible utilizar un grupo universal de seguridad en el campo de ManagedBy

Algunos conceptos a manejar…

A partir de Exchange 2010, el modelo de permisos se basa en RBAC (Role Based Access Control) 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 pueden 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 no implica que lo que delego en Exchange 2010 o posterior debe ser manejado a través del shell, ya que independientemente de la herramienta de administración que utilice (EMS, EMC, ECP) siempre pasa por RBAC (siempre y cuando utilice un mecanismo soportado), el tema es que no siempre la interfaz gráfica tiene la opción que estoy buscando.

De un modo muy simplificado y como para entender algunas básicas de RBAC podríamos decir que para definir que 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):

Default Role Assignment Policy

Si la editamos con la finalidad de ver que habilita a realizar encontramos una sección dedicada a los grupos de distribución:

Default Role Assignment Policy

Como pueden 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):

ecpgrupossinmydistributiongroups

A continuación como prueba marcamos la opción para ver que cambia en el ECP:

MyDistributionGroups

MyDistributionGroups

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 me reporte el problema de permisos, algo sencillo que puedo hacer para estar seguro de lo que estaría faltando es pedirle que entre al ECP (esto si por algún motivo no tengo acceso a un equipo para ver que política tiene asignada) 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 (recuerden que un grupo como propietario no sirve en este caso) 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 como utilizar el script lo ejecutamos sin parámetros:

manage-groupmanagementrole.ps1

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

manage-groupmanagementrole.ps1

Si por algún motivo quieren 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”

manage-groupmanagementrole.ps1

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):

Public Groups I Own

Como ven 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 como manejar la situación donde cuento con múltiples grupos y quisiera delegar la administración de estos a varios usuarios en base a su membresía. En adición, como mantener la delegación de una forma automatizada.

Por último, les dejo un par de links con información adicional:

How to Manage Groups that I already own in Exchange 2010?to-manage-groups-that-i-already-own-in-exchange-2010.aspx

Can’t manage distribution group from Outlook with Exchange 2010 or Exchange 2013 mailbox

Facebook0LinkedIn0Google+1Twitter0
Volver a la Portada de Logo Paperblog