Como delegar la administracion de grupos en Exchange 2010/2013 – Parte 2

En la primer parte de este artículo vimos algunos conceptos básicos a nivel de delegación de permisos a usuarios finales, problemas comunes que nos podemos encontrar, muy brevemente tratamos RBAC y por último como realizar la delegación para que un usuario final que requiera administrar la membresía de un grupo lo pueda hacer sin darle permisos extras como por ejemplo la posibilidad de crear o remover grupos.

El paso a paso visto funciona muy bien y en organizaciones pequeñas quizás no haya mucho más que meditar pero que pasa si tengo muchos grupos y quiero delegar la administración a varios usuarios en base a su membresía? como vimos en la primer parte no es posible en Exchange 2010 / 2013 setear un grupo como propietario de otro grupo por lo que de algún modo tengo que ver como incluir las cuentas individuales en el atributo de “Managedby”.

Esto no sería todo, después tengo que ver como mantener esto, que pasa si un usuario ya no pertenece al grupo delegado? que pasa si un usuario nuevo se agrega a uno de estos grupos? el administrador tendría que revisar el campo de “managedby” de cada grupo que tenga delegado uno por uno y chequear que este actualizado respecto a la membresía de los grupos inicialmente utilizados para la delegación? Esto podría llevar mucho tiempo y sería muy difícil de mantener de forma manual, muy propenso a error.

Quienes trabajan con grupos delegados en versiones anteriores en general utilizan grupos y no tienen que preocuparse de listar de forma individual cada cuenta (como uno esperaría que fuese también en Exchange 2010 o 2013) pero a partir del cambio del modelo de seguridad a RBAC algunas cosas se podría decir que no acompañaron esta evolución y estamos frente a una de ellas, igualmente el workaround que vamos a ver para emular el comportamiento de versiones anteriores del producto funciona bien y conceptualmente lo puedo utilizar para realizar otro tipo de tareas.

Antes de ver la solución a este tema veamos que error nos podríamos encontrar si intentamos setear un grupo como propietario de otro, este caso el ejemplo fue tomado con Exchange 2013 pero sería similar en Exchange 2010:

Get-DistributionGroup “nombredegrupo” | set-DistributionGroup –ManagedBy “grupo de delegados”

Cannot process argument transformation on parameter ‘ManagedBy’. Cannot convert value “nombre de grupo” to type “Microsoft.Exchange.Data.MultiValuedPorperty”…..

Error: “Conversion from System.Management.Automation.PSObject to Microsoft.Exchange.Configuration.Tasks.GeneralRecipientIdParameter has not been implemented.” …

Solución:

Si bien esta situación agrega complejidad al tema, tampoco es necesario reinventar la rueda, afortunadamente el equipo de Exchange desarrolló un script denominado Set-DistributionGroupOwners.ps1 el cual puede ser descargado del script repository de Microsoft. Básicamente lo que hace este script es emular la utilización de un grupo en el campo de “Managedby”.

Resumiendo paso a paso como funciona:

1. Ejecutar el script con los parámetros que establecen que grupo de distribución queremos afectar y que grupo debe ser propietario de este:

Set-DistributionGroupOwners.ps1 –DistributionGroup “nombre de grupo” –GroupOwner “grupo que contiene a los delegados”

En este punto lo que hace el script es setear en el CustomAttribute5 el DN (Distinguished Name) del grupo que contendría a los propietarios. Para verificar esto ejecutar lo siguiente:

Get-DistributionGroup “nombre de grupo modificado” | FT CustomAttribute5

El script aun no modificó el atributo en cuestión, simplemente esta utilizando un campo auxiliar para a futuro expandir la membresía del grupo definido como propietario. Este paso es requerimiento para cada grupo que quiera administrar con este script.

2. Ejecutar el script con el parámetro que define el grupo de distribución a modificar:

Set-DistributionGroupOwners.ps1 –DistributionGroup “nombre de grupo”

En este punto el script lo que hace es expandir la membresía del grupo de delegados establecido en el CustomAttribute5 y setearlos de forma individual en el campo de “Managedby”.

Para validar esto ejecutar el siguiente comando:

Get-DistributionGroup “nombre de grupo modificado” | FL ManagedBy,CustomAttribute5

Bien, entonces definimos el grupo cuyos miembros queremos que sean propietarios del grupo a delegar, ejecutamos el script para que modifique el atributo “managedby” y validamos que se encuentren listadas las cuentas individuales, estaría funcionando, correcto?

Ahora el tema es el mantenimiento de este atributo en base a los cambios que eventualmente podría sufrir la membresía del grupo de los delegados en cuestión.

Para esto el script tiene otra función. Si lo ejecutamos sin incluir parámetros adicionales lo que hace es buscar los grupos de distribución en la organización con el custom attribute definido con un DN. En base a esto, actualiza el campo de ManagedBy con los miembros del grupo. En mi lab tengo 2 grupos con el customattribute5 con un DN, por lo que si corro el script sin parámetros devuelve lo siguiente:

En conclusión, una vez preparado el ambiente podría correr manualmente el script cuando hayan cambios de membresía o idealmente agendar la ejecución para que por ejemplo corra 2 veces al día de tal forma de automatizar el proceso de mantenimiento.

Por último les dejo el link al artículo del blog del equipo de Exchange con más info sobre el tema:

How to manage groups with groups in Exchange 2010

Related Articles:

• Como acceder al buzón de otro usuario en Exchange 2010 / 2013
• Como delegar la administracion de grupos en Exchange 2010/2013
• Evento 1053: Insuff_Access_Rights – Access is denied
• Grupos en Exchange 2013 – No tiene permisos suficientes para realizar esta operacion