8.3 Ejemplos de cómo DRA procesa las asignaciones de delegación

En los siguientes ejemplos, se describen las situaciones habituales que surgen en cuanto al modo en que DRA evalúa el modelo de delegación cuando se procesa una petición:

8.3.1 Ejemplo 1: cambio de la contraseña de un usuario

Cuando un administrador asistente intenta definir una nueva contraseña para la cuenta de usuario JSmith, el servidor de administración busca todas las ActiveViews que incluyan JSmith. Esta búsqueda devuelve todas las ActiveViews que especifican directamente JSmith mediante una regla de caracteres comodín o una pertenencia a grupo. Si una ActiveView incluye otras ActiveViews, el servidor de administración también busca esas ActiveViews adicionales. El servidor de administración determina si el administrador asistente tiene el poder Restablecer la contraseña de la cuenta de usuario en cualquiera de estas ActiveViews. Si el administrador del asistente dispone del poder Restablecer la contraseña de la cuenta de usuario, el servidor de administración restablece la contraseña para JSmith. Si no dispone de ese poder, el servidor de administración rechaza la petición.

8.3.2 Ejemplo 2: superposición de ActiveViews

Un poder define las propiedades de un objeto que un administrador asistente puede ver, modificar o crear en el dominio o el subárbol gestionados. Varias ActiveViews pueden incluir el mismo objeto. Esta configuración se denomina superposición de ActiveViews.

Si se solapan las ActiveViews, puede acumular un conjunto de distintos poderes para los mismos objetos. Por ejemplo, si una ActiveView permite añadir una cuenta de usuario a un dominio y otra ActiveView permite suprimir una cuenta de usuario del mismo dominio, puede añadir o suprimir cuentas de usuario en ese dominio. De esta forma, los poderes de los que disponga para un determinado objeto serán acumulativos.

Es importante entender cómo las ActiveViews pueden superponerse y puede disponer de más poderes para los objetos incluidos en ellas. Tenga en cuenta la configuración de ActiveView que se muestra en la siguiente ilustración.

Las pestañas blancas identifican ActiveViews por ubicación, Nueva York y Houston. Las pestañas negras identifican ActiveViews por su función administrativa, Ventas y Marketing. Las celdas muestran los grupos incluidos en cada ActiveView.

Los grupos "NY_Ventas" y "HOU_Ventas" se representan ambos en la ActiveView Ventas. Si dispone de poderes en la ActiveView Ventas, puede gestionar cualquier miembro de los grupos "NY_Ventas" y "HOU_Ventas". Si también dispone de poderes en la ActiveView Nueva York, estos poderes adicionales se aplican al grupo "NY_Marketing". De esta forma, se acumulan los poderes a medida que se superponen las ActiveViews.

La superposición de ActiveViews puede proporcionar un modelo de delegación eficaz y flexible. Sin embargo, esta función también puede tener consecuencias no deseadas. Planifique cuidadosamente las ActiveViews para asegurarse de que cada administrador asistente disponga solo de los poderes que desea para cada cuenta de usuario, grupo, unidad administrativa, contacto o recurso.

Grupos en varias ActiveViews

En este ejemplo, el grupo "NY_Ventas" se representa en más de una ActiveView. Los miembros del grupo "NY_Ventas" están representados en la ActiveView Nueva York debido a que el nombre del grupo coincide con la regla de ActiveView NY_ *. El grupo también se encuentra en la ActiveView Ventas debido a que el nombre de grupo coincide con la regla de ActiveView *_Ventas. Al incluir el mismo grupo en varias ActiveViews, puede permitir que distintos administradores asistentes gestionen los mismos objetos de forma diferente.

Uso de poderes en varias ActiveViews

Supongamos que hay un administrador asistente, JSmith, que tiene el poder Modificar las propiedades generales del usuario en la ActiveView Nueva York. Este primer poder permite a JSmith editar todas las propiedades en la pestaña General de una ventana de propiedades de usuario. JSmith dispone del poder Modificar las propiedades del perfil de usuario en la ActiveView Ventas. Este segundo poder permite a JSmith editar todas las propiedades en la pestaña Perfil de una ventana de propiedades de usuario.

En la siguiente ilustración, se indican los poderes que JSmith tiene para cada grupo.

JSmith dispone de los siguientes poderes:

  • Propiedades generales en la ActiveView NY_*

  • Propiedades del perfil en la ActiveView *_Ventas

La delegación de poderes en estas ActiveViews superpuestas permite a JSmith modificar las propiedades generales y de perfil del grupo NY_Ventas. Por lo tanto, JSmith dispone de todos los poderes concedidos en las ActiveViews que representan al grupo NY_Ventas.