Delegating access within PowerFuse is something that seems simple in theory and is covered on the official RES PowerFuse 2010 Basic Course (RPFBC-300). In practice, designing and implementing a delegation model takes a lot of thought and knowledge. The delegation model is something that has to be taken in to account during the design stage of a PowerFuse deployment otherwise you’ll find yourself re-architecting your environment!
Whilst working on the “soon-to-be-released” RES PowerFuse 2010 Workspaces White Paper, I thought that this was worthy of sharing now. What follows is some elaboration on how the delegation model works and things you need to know to implement it effectively, right from the start.
Administrative Roles
Administrative Roles (or ARs) are used to restrict what nodes within management console a PowerFuse administrator can see, manage and configure.
Administrative Roles are cumulative
- That’s to say that if an administrator is assigned two Administrative Roles they’ll get the combination of both.
- If Administration Role #1 only grants read access to the ‘Managed Applications’ node and Administration Role #2 grants read access to the ‘Drive and Port Mappings’ node, the effective rights are read to both nodes (assuming the administrator falls within both Administrative Roles).
Deny does not override Read and Modify rights
- Unlike the NT ACL model.
- If Administrative Role #1 grants Deny access to the ‘Managed Applications’ node and Administrative Role #2 grants Read access to the same node, the effective right is Read (assuming the administrator falls within both Administrative Roles).
Locations and Devices are not accounted for with Scope Control
- Therefore only static agent assignments in Workspaces can be used to limit the agents displayed in the management console.
- If the effective rights of all assigned Administrative Roles results in Deny access to the Locations and Devices node, then administrators cannot use or assign them to objects. No access to read the Locations and Devices means no access to assign them to objects either (which makes sense!).
Scope Control
Scope Control is used to further restrict what a PowerFuse administrator can see and target within each node in the management console as a result of their effective Administrative Roles. For example, we might allow an administrator to create/update objects within the ‘Managed Applications’ node in the management console, assign them to a particular OU within Active Directory and/or only attach them to a specific Workspace Container.
Sounds so simple! Unfortunately, there are numerous factors that you need to be aware of when designing a delegation model.
The Workspaces and Identities defined within a Scope are exclusive
- The objects to be managed must be exclusively assigned to Workspace and/or Identities that are within the administrator’s Scope.
- If two Workspaces are assigned to an object and the administrator’s Scope only includes one of them, the administrator will not be able to manage the object. The resulting permission is Read Only.
- If two Identities are assigned to an object and the administrator’s scope only includes one of them, the administrator will not be able to manage the object. The resulting permission is Read Only.
- When two or more Scopes are in effect they cannot be combined. For example, if AR #1 restricts an administrator to OU #1 and Workspace #1 and AR #2 restricts access to OU #2 and Workspace #2, an administrator cannot assign access on an object to OU #1 and Workspace #2. They can restrict access to OU #2 and Workspace #2 as defined by the Scope Control.
Administrators can only create objects that target the Identities and Workspaces within their scope
- Workspaces have to be assigned when creating objects if Workspaces are included within the administrator’s Scope. For example, if an administrator has only been given Workspace #1 in their Scope, they have to assign objects to the Workspace #1 during creation, the “All Workspace Containers” nor any other Workspace cannot be selected.
- All objects created by the administrator can only be assigned to users and groups that are defined on the administrator’s Scope. For example, if an administrator has only been given OU #1 in their scope, they have to assign objects to either users or groups that reside in OU #1, the “All Users” access principal cannot be used.
- When both Workspaces and Identities are in an administrator’s Scope, both have to be explicitly assigned to every object during creation. The management console will give the “Object can not be saved because it does not match the scope that is currently in effect” error message meaning it has to be assigned both an Identity and a Workspace included within their Scope.
- PowerFuse will allow administrators to assign groups to objects if the groups reside within Organisational Unit Identities defined within their Scope. For example, if application groups need to be assigned to objects, then the group objects have to exist with an OU assigned under the Identity tab in the Scope Control definition. The individual groups do not need to be listed explicitly.
The “All Users” Identity can be assigned by any Administrative Role regardless of their assigned Access Control Scope
- Any Administrative Role can create an object (assuming the Administrative Role permits) targeted at the “All Users” access principal.
- This is however, restricted to “All Users” that fall within the targeted Workspaces in Scope, but only if Workspaces are assigned.
- Objects assigned to both the “All Users” and the “All Workspace Containers” access principals are visible (Read Only) if the Administrative Role grants either “Read” or “Modify” rights, whilst technically being out of Scope.
The Scope Control is taken in to account when displaying RES PowerFuse agents (only if the “Include All Computers” is not selected on any Workspaces within the Administrator’s Scope)
- Checking the “Include All Computers” option on any Workspace Container will grant access to all agents if the Workspace is in the administrator’s Scope.
- The Administration Role has to be granted Read or Modify via the Administrative Role to the Agent node to be to view the “Agents” node within the management console.
