共用方式為

RBAC: Tutorial para la creación de un rol que pueda eliminar los dispositivos ActiveSync

  • 發行項

Artículo original publicado el miércoles, 12 de septiembre de 2012

Una pregunta que ha surgido varias veces en los últimos meses es la siguiente: ¿Cómo creo roles de RBAC que tengan funciones de administración de ActiveSync muy limitadas?

Antes de empezar a responder, veamos un breve resumen de lo que es el RBAC (control de acceso basado en roles).

Antes de Exchange 2010, los permisos se definían con herramientas como DSACLS y ADSIEdit. Esto le permitía especificar qué objetos podía tocar un usuario o grupo, así como lo que podían hacerle al objeto como conjunto. Si un usuario necesitaba acceso de escritura a una propiedad concreta de un objeto, pero no a las otras propiedades, no existía una forma sencilla de conseguirlo. El RBAC no define permisos en el objeto: lo que hace es definirlos en los cmdlets de PowerShell que pueden modificar el objeto. Los cmdlets de PowerShell se agregan a un rol, que se asigna a un usuario o grupo. Si el cmdlet y los parámetros que necesita forman parte de un rol en el que usted participa, podrá ejecutar el cmdlet.

En el Shell de administración de Exchange puede ejecutar (get-excommand).count para ver a cuántos cmdlets de Exchange tiene acceso actualmente. En el Panel de control de Exchange (ECP) y en la Consola de administración de Exchange, los cmdlets a los que puede obtener acceso determinan qué opciones se muestran. Por lo tanto, si una ventana de alguna de las GUI exige que tenga ciertos cmdlets de PowerShell en el rol pero no los tiene, pueden pasar dos cosas:

  • Que la ventana no se muestre (aunque es poco probable que se ofrezcan las opciones que provocan esto)
  • Que la ventana se muestre, pero todo el contenido esté deshabilitado (esto es normal si tiene los cmdlets Get- importantes, pero le faltan uno o varios de los cmdlets Set, New, Add, etc.)

Para más detalles sobre el RBAC, lea primero los siguientes artículos:

Exchange 2010 SP2 contiene 71 roles de RBAC, pero ninguno de ellos ofrece subconjuntos limitados de comandos de ActiveSync que se puedan asignar al personal del servicio de asistencia. Para crear roles de este tipo, tiene que encargarse usted mismo. Si el servicio de asistencia funciona con PowerShell, resulta relativamente sencillo, ya que puede crear un rol que solo tenga los parámetros y el cmdlet de PowerShell necesarios. Si los usuarios trabajan exclusivamente a través del ECP, el proceso se complica porque el usuario debe poder navegar hasta el punto donde se lleva a cabo la operación.

En este ejemplo, el cliente necesitaba que el personal del servicio de asistencia pudiese eliminar los dispositivos ActiveSync desde el Panel de control de Exchange. El problema era que solo los miembros de Administración de la organización podían navegar hasta la ventana correspondiente del ECP y eliminar los dispositivos. Agregar a los usuarios del servicio de asistencia al grupo de roles Administración de la organización era imposible: tiene demasiados derechos.

El administrador probó a crear un rol de RBAC que solo contuviese el cmdlet Clear-ActiveSyncDevice. El problema era que el rol nuevo no les permitía obtener acceso a las funciones a través del ECP. El ECP no permitía a los usuarios navegar hasta el lugar donde se encuentra el botón "Eliminar dispositivo" porque el botón está anidado unos cuantos niveles por debajo. El usuario necesita poder hacer una lista de los usuarios de la organización, ver sus propiedades de teléfono y voz, y poder abrir los cuadros de diálogo durante el proceso. Un rol que solo contiene el cmdlet Clear-ActiveSyncDevice no incluye los demás cmdlets que necesitan estos otros pasos en el ECP. Lo que tenemos que hacer es averiguar qué tenemos que agregar a este rol para que poder navegar hasta la ventana y hacer clic en el botón "Eliminar dispositivo".

El primer paso del proceso es mirar de qué roles consta el grupo de roles Administración de la organización. Para ello, ejecutamos:

[PS] C:\>$FormatEnumerationLimit=999
[PS] C:\>get-rolegroup "organization management" | fl roles

Roles : {Active Directory Permissions, Address Lists, ApplicationImpersonation, Audit Logs, Cmdlet Extension Agents, Database Availability Groups, Database Copies, Databases, Disaster Recovery, Distribution Groups, Edge Subscriptions, E-Mail Address Policies, Exchange Connectors, Exchange Server Certificates, Exchange Servers, Exchange Virtual Directories, Federated Sharing, Information Rights Management, Journaling, Legal Hold, Mail Enabled Public Folders, Mail Recipient Creation, Mail Recipients, Mail Tips, Mailbox Import Export, Mailbox Search, Message Tracking, Migration, Monitoring, Move Mailboxes, Organization Client Access, Organization Configuration, Organization Transport Settings, POP3 And IMAP4 Protocols, Public Folder Replication, Public Folders, Receive Connectors, Recipient Policies, Remote and Accepted Domains, Retention Management, Role Management, Security Group Creation and Membership, Send Connectors, Support Diagnostics, Transport Agents, Transport Hygiene, Transport Queues, Transport Rules, UM Mailboxes, UM Prompts, UnScoped Role Management, Unified Messaging, User Options, View-Only Audit Logs, View-Only Configuration, View-Only Recipients, MyBaseOptions, MyContactInformation, MyDiagnostics, MyDistributionGroupMembership, MyDistributionGroups, MyProfileInformation, RetentionPolicies, MyTextMessaging, MyVoiceMail, MyMailboxDelegation}

Ahora tenemos que descartar los roles que no estarán directamente relacionados con la eliminación de ningún dispositivo. Algunos de los roles, como "Dominios remotos y aceptados", claramente no van a contener cmdlets relacionados. En relación con los roles que nos pueden interesar, el paso siguiente es averiguar lo que contienen. Para hacerlo, ejecutamos un cmdlet como este:

[PS] C:\storage>Get-ManagementRoleEntry "Mail Recipients\*"

Name Role Parameters
---- ---- ----------
Write-AdminAuditLog Mail Recipients {Comment, Confirm, Debug, DomainController, ErrorAction, Er...
Update-Recipient Mail Recipients {Confirm, Credential, Debug, DomainController, ErrorAction,...
Test-MAPIConnectivity Mail Recipients {Archive, Confirm, Debug, ErrorAction, ErrorVariable, Ident...
Set-User Mail Recipients {AssistantName, CertificateSubject, City, Company, Confirm,...

He cortado el resultado y he incluido solo unas líneas como demostración (el cmdlet completo arroja 96 resultados).

El paso siguiente consiste en crear roles secundarios de los roles que creemos que nos serán útiles para el trabajo. A continuación presento un ejemplo:

new-managementrole -parent "Mail Recipients" -name StrictlyRecipActiveSyncDeviceWipe

El rol que acabamos de crear es uno secundario de Destinatarios de correo, por lo que tiene todos los permisos del primario. ¿Entonces por qué no usamos el rol Destinatarios de correo? A medida que avancemos, quitaré partes de este rol para que podamos llegar al mínimo nivel posible de permisos. Nunca modifique los roles integrados, como Destinatarios de correo, ya que las funciones se interrumpirían. Otro punto importante: a un rol secundario solo se le pueden asignar las funciones de su rol primario; no se le pueden conceder derechos ni acceso a otras funciones que no estén incluidas en el primario.

Cuando hayamos creado un rol, tendremos que crear un grupo de roles. Esto facilitará la asignación del rol a los usuarios en el futuro. Para la prueba, usamos una cuenta llamada WipeTest. Cuando complete la prueba, reemplace WipeTest por las cuentas o los grupos que quiera.

New-RoleGroup -Name "OnlyActiveSyncDeviceWipe" -Roles "StrictlyRecipActiveSyncDeviceWipe " -members WipeTest

WipeTest puede iniciar sesión en OWA y obtener acceso al ECP. Vemos que podemos navegar a casi todas las opciones que queramos en ECP, pero no a todas. Esto significa que necesitamos un rol más.

Si mira en el directorio de Exchange (de forma predeterminada: c:\Archivos de programa\Microsoft\Exchange), verá la ruta de acceso “ClientAccess\ecp\PhoneVoice”. Fijarse en los archivos que hay aquí le dará algunas pistas sobre lo siguiente que puede agregar. El archivo Web.Config tiene muchas menciones de OrganizationConfig, pero esto no es lo suficientemente específico. Podemos explorar la carpeta para ver si alguno de los archivos menciona cmdlets concretos que podamos usar y que no estén en el rol que ya hemos definido. Uno que destaca es Set-CasMailbox (ubicado en QuarantinedDevices.ASCX). Luego comprobamos dónde reside este cmdlet.

[PS] C:\>Get-ManagementRoleEntry "*\set-casmailbox" | fl name,role,parameters

Name : Set-CASMailbox
Role : Mail Recipients
Parameters : {ActiveSyncDebugLogging, ActiveSyncEnabled, ActiveSyncMailboxPolicy, Confirm, Debug, DisplayName, DomainController, ECPEnabled, EmailAddresses, ErrorAction, ErrorVariable, EwsAllowEntourage, EwsAllowList, EwsAllowMacOutlook, EwsAllowOutlook, EwsApplicationAccessPolicy, EwsBlockList, EwsEnabled, HasActiveSyncDevicePartnership, Identity, IgnoreDefaultScope, ImapEnabled, ImapEnableExactRFC822Size, ImapMessagesRetrievalMimeFormat, ImapSuppressReadReceipt, ImapUseProtocolDefaults, MAPIBlockOutlookNonCachedMode, MAPIBlockOutlookRpcHttp, MAPIBlockOutlookVersions, MAPIEnabled, Name, OutBuffer, OutVariable, OWAEnabled, OwaMailboxPolicy, PopEnabled, PopEnableExactRFC822Size, PopMessagesRetrievalMimeFormat, PopSuppressReadReceipt, PopUseProtocolDefaults, PrimarySmtpAddress, SamAccountName, ShowGalAsDefaultView, Verbose, WarningAction, WarningVariable, WhatIf}

Name : Set-CASMailbox
Role : Organization Client Access
Parameters : {ActiveSyncAllowedDeviceIDs, ActiveSyncBlockedDeviceIDs, Confirm, Debug, DomainController, ErrorAction, ErrorVariable, Identity, OutBuffer, OutVariable, Verbose, WarningAction, WarningVariable, WhatIf}

Name : Set-CASMailbox
Role : User Options
Parameters : {ActiveSyncDebugLogging, Confirm, ErrorAction, ErrorVariable, Identity, ImapMessagesRetrievalMimeFormat, ImapSuppressReadReceipt, ImapUseProtocolDefaults, OutBuffer, OutVariable, PopMessagesRetrievalMimeFormat, PopSuppressReadReceipt, PopUseProtocolDefaults, ShowGalAsDefaultView, WarningAction, WarningVariable, WhatIf}

Name : Set-CASMailbox
Role : MyBaseOptions
Parameters : {ActiveSyncDebugLogging, Confirm, ErrorAction, ErrorVariable, Identity, ImapMessagesRetrievalMimeFormat, ImapSuppressReadReceipt, ImapUseProtocolDefaults, OutBuffer, OutVariable, PopMessagesRetrievalMimeFormat, PopSuppressReadReceipt, PopUseProtocolDefaults, ShowGalAsDefaultView, WarningAction, WarningVariable, WhatIf}

Es interesante destacar las diferencias entre los parámetros. Podemos excluir MyBaseOptions y UserOptions porque sus parámetros no nos ayudarían a eliminar un dispositivo. Ya hemos probado un rol secundario de Destinatarios de correo y no ha funcionado, pero aún podemos probar a usar el rol “Acceso a clientes de la organización”. Como podrá observar, este rol tiene acceso a los parámetros ActiveSyncAllowedDeviceIDs y ActiveSyncBlockedDeviceIDs, que no están en el rol Destinatarios de correo.

Como hemos visto Set-CasMailbox listado en los archivos, podemos intentar crear otro rol secundario de “Acceso a clientes de la organización” y deshacernos de todo menos de Set-CasMailbox.

new-managementrole -parent "organization client access" -name OrgClientAccessWipeDeviceOnly
get-managementroleentry "OrgClientAccessWipeDeviceOnly\*" |where{$_.name -notlike "*set-casm*"}| Remove-ManagementRoleEntry

Ahora agregamos este rol nuevo al grupo de roles que creamos anteriormente:

New-ManagementRoleAssignment -Name "OCA Child ActiveSyncDevice Wipe" -SecurityGroup "OnlyActiveSyncDeviceWipe" -Role OrgClientAccessWipeDeviceOnly

Ahora, cuando WipeTest trate de eliminar el dispositivo, se podrá obtener acceso al botón en el ECP. Sin embargo, sigue habiendo un problema: StrictlyRecipActiveSyncDeviceWipe (un rol secundario de “Destinatarios de correo”) aún tiene demasiado derechos. Tenemos que quitar la mayoría de los cmdlets de StrictlyRecipActiveSyncDeviceWipe usando el cmdlet siguiente:

get-managementroleentry "StrictlyRecipActiveSyncDeviceWipe\*" |where{$_.name -notlike "*activesync*"}| Remove-ManagementRoleEntry

En la siguiente fase hay que volver a agregar al rol los cmdlets uno a uno hasta que podamos navegar a la ubicación adecuada del ECP y realizar la eliminación de dispositivo. El proceso es sencillo: agregue un cmdlet e intente la operación. Si se produce un error, cierre sesión en OWA, agregue otro cmdlet y pruebe otra vez. Cuando consigamos que funcione, podemos parar o volver y quitar cmdlets individuales para tratar de alcanzar un nivel mínimo de permisos. Abajo se han incluido algunos ejemplos de los cmdlets que podemos usar.

Para volver a agregar un cmdlet, tenemos que hacer esto:

add-ManagementRoleEntry "Mail Recipients\get-mailbox" -role StrictlyRecipActiveSyncDeviceWipe

/Aside

Si quiere volver a agregar varios cmdlets, use la sintaxis del ejemplo siguiente:

Get-ManagementRoleEntry "Mail Recipients\*" | where{$_.name -like "get-m*"} | add-ManagementRoleEntry -role StrictlyRecipActiveSyncDeviceWipe

En esta publicación solo quiero insertar los cmdlets uno a uno, pero he incluido esto como ejemplo.

/End Aside

Si queremos quitar un cmdlet del rol, podemos usar esto:

Remove-ManagementRoleEntry "StrictlyRecipActiveSyncDeviceWipe\Get-Mailbox"

(Cuando aparezca la pregunta “¿Está seguro?”, seleccione Sí o Sí a todo).

En este publicación he incluido muchos detalles sobre al viaje que me ha llevado al conjunto final de cmdlets. No he incluido la mayoría de las aburridas pruebas de ensayo y error, pero espero haber incluido suficientes detalles para que los lectores puedan llevar a cabo el proceso solos.

Para aquellos que quieran ver todo junto en una sola presentación concisa, abajo verán un resumen de todos los cmdlets:

new-managementrole -parent "Mail Recipients" -name StrictlyRecipActiveSyncDeviceWipe
new-managementrole -parent "organization client access" -name OrgClientAccessWipeDeviceOnly
get-managementroleentry "OrgClientAccessWipeDeviceOnly\*" |where{$_.name -notlike "*set-casm*"}| Remove-ManagementRoleEntry

(Cuando aparezca la pregunta “¿Está seguro?", seleccione A)

get-managementroleentry "StrictlyRecipActiveSyncDeviceWipe\*" |where{$_.name -notlike "*activesync*"}| Remove-ManagementRoleEntry

(Cuando aparezca la pregunta “¿Está seguro?", seleccione A)

add-ManagementRoleEntry "Mail Recipients\get-mailbox" -role StrictlyRecipActiveSyncDeviceWipe
add-ManagementRoleEntry "Mail Recipients\get-user" -role StrictlyRecipActiveSyncDeviceWipe
add-ManagementRoleEntry "Mail Recipients\get-recipient" -role StrictlyRecipActiveSyncDeviceWipe
add-ManagementRoleEntry "Mail Recipients\get-casmailbox" -role StrictlyRecipActiveSyncDeviceWipe
New-RoleGroup -Name "OnlyActiveSyncDeviceWipe" -Roles StrictlyRecipActiveSyncDeviceWipe,OrgClientAccessWipeDeviceOnly -members WipeTest

Cuando estos cmdlets se ejecuten, el usuario WipeTest (o cualquier otro usuario o grupo que se especifique) podrá abrir OWA, navegar hasta el ECP y abrir todos los cuadros de diálogo necesarios para llegar al punto desde donde se eliminan los dispositivos.

Quiero dar las gracias a Matt Byrd y Brad Hughes, que me ayudaron en la redacción de esta publicación.

Chris Pollitt

Esta publicación del blog es una traducción. Puede leer el artículo original en RBAC: Walkthrough of creating a role that can wipe ActiveSync Devices