Share via

MPS Delegation Model

  • Article

A key component of the MPS Delegation Model is support for roles based access checking. There are a few different ways in which this access checking is implemented in MPS however the general idea is that a check is made on behalf of the authenticated user to ensure the following:

  • The user belongs to the Organization or has delegated access to the Organization on which they are acting.

  • That the user is a member of the specified role (based on group membership, verified by an attempted DACL access)

The MPS User Roles

As a general rule, roles based access checking in MPS Namespaces is only performed on the top level roles defined below. The more specific roles will be checked through additional controls in place through AD ACL'ing.

  • Domain Admin

    • Any user that is a member of the Domain Administrators group.

    • This user has full administrative privilages over every aspect of the system both inside of and outside of the Hosting OU.

  • OrgCreators

    • Hosting Admin

      • Member of Admins@Hosting

      • Generally has full administrative privileges over all objects under the Hosting OU

    • Reseller Admin

      • Member of the Admins@<resellerOrg>

      • Generally has full administrative privileges over all objects under a specific Reseller OU

    • From a hosted services perspective, OrgCreators are primarily tasked with the creation and maintenance of organizations. While these users can perform all of the actions that UserCreators and Users can, they should not be required to perform any actions necessary for service enablement or user maintenance. In a self service/support environment, these tasks should be delegated to UserCreators.

  • UserCreators

    • Business Admin

      • Member of Admins@<businessOrg

    • Consumer Admin

      • Member of Admins@<consumerOrg>

      • Generally less privileged then a Business Admin

      • The Consumer Model is specific to our Exchange implementation and is not heavily used.

    • Individual Information Worker (IIW) Admin

      • Most IIW users will fall into this role with the exception of friends and family users created by an IIW admin.

    • UserCreators are generally responsible for the creation and maintenance of user objects, as well as service subscription and enablement. When deciding between granting a right to UserCreators consider the following.

      • Once an Org is created that Orgs Administrator should be able to perform any action on the critical path to Service Enablement for both the Org and User objects.

      • UserCreators should not have to enlist the help of an OrgCreator (place a call into customer support) in order to perform necessary day to day user management tasks.

  • Users

    • Business User

      • Member of AllUsers@<businessOrg>

    • Consumer User

      • Member of AllUsers@<consumerOrg>

      • Generally less privileged then a Business User.

      • The Consumer Model is specific to our Exchange implementation and is not heavily used.

    • Individual Information Worker (IIW) User

      • Friends and family user created by an IIW admin.

    • Users should be granted the right to perform only the tasks that a user in any standard business or enterprise might allow their users to perform within the context of their own organization. This is generally limited to the right to read a limited set of properties on all users in the org and the right to modify a limited set of properties.

    • The most common task that a User would perform through the provisioning system would be Password Changes, most other user actions are performed through the respective service clients such as Outlook, Outlook Web Access, IE and Communicator

UI Roles

To take the concept of User roles a bit further and to aid in the development of Control Panels, Delegated Admin Consoles ect. HMC exposes a feature called UI roles. This is exposed through the GetCallerUIRoles procedure found in both the Managed and Hosted Active Directory namespaces. The idea is that if a developer knows the Role of a calling user, they can easily calculate which actions should be exposed to that user at any given level in an Active Directory hierarchy.

User Role calculation is performed as follows: There is a container under the "hosting" OU _Prvate container called WatUIPermissions. The WatUIPermissions container contains 8 groups, obscurely named 0000, 0100, 0500, 1000, 2000, 5000, and 6000 these groups are created during the creation of the "hosting" OU by the procedure Managed Helpers::InitializeADForHosting. The groups are configured as follows:

  • sAMAccountName : "0000"

    distinguishedName : "CN=0000,CN=WatUiPermissions,CN=_Private,OU=Hosting,DC=fabrikam,DC=com"

    member : "CN=AllUsers,CN=_Private,OU=Hosting,DC=fabrikam,DC=com"

  • sAMAccountName : "0100"

    distinguishedName : "CN=0100,CN=WatUiPermissions,CN=_Private,OU=Hosting,DC=fabrikam,DC=com"

    member : "CN=AllCustomerCSRAdminsGroups,CN=_Private,OU=Hosting,DC=fabrikam,DC=com"

  • sAMAccountName : "0500"

    distinguishedName : "CN=0500,CN=WatUiPermissions,CN=_Private,OU=Hosting,DC=fabrikam,DC=com"

    member : "CN=AllCustomerAdminsGroups,CN=_Private,OU=Hosting,DC=fabrikam,DC=com"

  • sAMAccountName : "1000"

    distinguishedName : "CN=1000,CN=WatUiPermissions,CN=_Private,OU=Hosting,DC=fabrikam,DC=com"

    member : "CN=AllResellerCSRAdminsGroups,CN=_Private,OU=Hosting,DC=fabrikam,DC=com"

  • sAMAccountName : "1500"

    distinguishedName : "CN=1500,CN=WatUiPermissions,CN=_Private,OU=Hosting,DC=fabrikam,DC=com"

    member : "CN=AllResellerAdminsGroups,CN=_Private,OU=Hosting,DC=fabrikam,DC=com"

  • sAMAccountName : "2000"

    distinguishedName : "CN=2000,CN=WatUiPermissions,CN=_Private,OU=Hosting,DC=fabrikam,DC=com"

    member : "CN=CSRAdmins@Hosting,OU=Hosting,DC=fabrikam,DC=com"

  • sAMAccountName : "5000"

    distinguishedName : "CN=5000,CN=WatUiPermissions,CN=_Private,OU=Hosting,DC=fabrikam,DC=com"

    member : "CN=Admins@Hosting,OU=Hosting,DC=fabrikam,DC=com"

  • sAMAccountName : "6000"

    distinguishedName : "CN=6000,CN=WatUiPermissions,CN=_Private,OU=Hosting,DC=fabrikam,DC=com"

    //This group has no members

GetCallerUIRoles attempts to read the DACL on each of these groups. Only administrators and group members are allowed to read the DACL (read permissions) on a group object. So this becomes an effective and efficient way to determine whether a calling user has membership in one of the roles indicated by the group. Only the groups that the user can read the DACL on will be returned in the list of uiRoles.

Using Roles Based Access Checking

Each procedure has the specific minimum role that can perform a given action. The following is the general guidelines for role based access checking:

  • Role should be checked prior to any elevation of privileges.

  • Role checking should be performed at the lowest appropriate level in the stack, generally at the Managed Level Namespace.

  • For Plans or Resource Management specific procedures, you will also need to check role at the Hosted Level namespace.