Loading

Delegating Group Management

Delegated group management lets people who are not architects put others into security groups, limited to the groups you choose and, optionally, to the people from one directory or identity provider. Use it so a team leader, a regional IT desk or a customer's own administrator can keep membership current without being given broad administrative access.

Where to find it

Architect Panel → Security:

  • Security Group Managers — each row grants one editor group the right to hand out one target group
  • AD Group Mapping — puts directory users into a security group from their Active Directory groups

Admin Panel → User Administration:

  • User Groups — create the editor and target groups
  • My Domain's Users — the list a manager uses to find people from their own directory
  • All Users — local accounts, with the Manage Security Groups row action

How a delegation works

Each row on Security Group Managers is one grant of authority, with four parts:

  • The editor group: who the managers are. Anybody in this security group holds the grant.
  • The target group: the one group they may add people to and remove people from.
  • Limit to Login Method: restricts them to people who sign in with one method, such as Active Directory. Leave it empty for no limit.
  • Limit to Identity Source: restricts them further to one source within that method: the domain's row ID for Active Directory, the row ID on Azure AD Tenants for Azure AD, the row ID on SAML Identity Providers for SAML, or 0 for local accounts and social logins. Leave it empty for no limit.

A group is offered to a manager for a given person only when a single row both grants that group and covers that person. Empty limits mean "anybody", which is what every delegation created before the limits existed carries.

What a manager can never do

  • Change their own groups. They see "You cannot change your own security groups." Only an architect can, which stops a delegation turning into a promotion.
  • Reach a group they have no row for, or a person outside their limits. These checks are made on the server when the screen is drawn and again when it is saved, whatever the list shows.
  • Act on somebody who does not exist. The person must be a real local account or a known external identity.

Every refusal is written to the Error Log with the manager and the person they tried to change.

Setting up a manager for one directory

Example: anyone in the Contoso IT Support AD group may put Contoso users into Field Engineers, and nobody else's users.

  1. In User Groups, create the target group (Field Engineers, with no admin access) and the editor group (Contoso AD Managers, with admin access level 1). Level 1 is needed because the Security Group Manager is an administrative screen. Never use level 2, which confers architect access.
  2. Put the managers in the editor group. Either map the AD group to it on AD Group Mapping, so membership is held in the directory and picked up at each sign-in, or add people individually with the Security Group Manager.
  3. On Security Group Managers, add a row: editor group Contoso AD Managers, target group Field Engineers, Limit to Login Method Active Directory, Limit to Identity Source the contoso.com domain's row ID. Add one row per group they may hand out.
  4. Give the editor group the My Domain's Users tile in the Admin Panel (item permissions are set from the item's row in Admin Panel Builder; see Admin Panel). That tile lists only people who sign in from the same directory or provider as the person viewing it. Grant this rather than External / SSO Users, which lists everybody.
  5. Give the editor group Read on the datastore behind that list: in Architect Panel → Data → Datastores, find the .users-externalcache datastore and use its Permissions row action. Without Read the list refuses them before the row action is drawn. Read is enough; they change groups through the Security Group Manager, not by editing profiles.
  6. Sign in as one of the managers, open My Domain's Users, use Security Groups on a Contoso user and confirm only Field Engineers is offered.

What goes wrong

  • "You do not have access to manage any security groups for this user." No row covers this person: the target group is not granted to any of the manager's groups, or the person is outside the login method or identity source limits.
  • A manager sees My Domain's Users but no Security Groups button. Their group lacks Read on the .users-externalcache datastore.
  • A manager put in the editor group through AD Group Mapping has no rights yet. Membership from the directory is read at sign-in, so they need to sign out and in again.
  • A limit of 0 in Limit to Identity Source stops a manager reaching AD users. 0 means local and social accounts only. Leave it empty for no limit.

Worked example

A managed service provider runs one installation for several client companies, each on its own Azure AD tenant. For each client it creates a managers group and adds a Security Group Managers row per group the client may assign, limited to Azure AD and that client's Azure AD Tenants row ID. Each client's IT lead can now move their own staff between groups from My Domain's Users, and cannot see or touch another client's people.

Recommendations

  • Delegate with limits wherever more than one directory signs in.
  • Give manager groups admin access level 1, never 2.
  • Grant My Domain's Users, not External / SSO Users, to delegated managers.
  • Hold manager membership in the directory through AD Group Mapping where you can.
  • Review Security Group Managers alongside your other permissions.