Loading

Groups for External and SSO Users

People who sign in through Active Directory, Azure AD, SAML or a social provider have no password on the platform, but they still need security groups. They have their own list in the Admin Panel, with its own Security Groups row action, and Active Directory users can also be given groups automatically from their AD groups. This article covers both routes and how they interact.

Where to find it

Admin Panel → User Administration:

  • External / SSO Users — every external identity, with the Security Groups row action
  • My Domain's Users — only the people who sign in from the same directory or provider as you
  • User Groups — the groups themselves

Architect Panel → Security:

  • AD Group Mapping — Active Directory groups that confer a security group at sign-in
  • Security Group Managers — who may assign groups to whom
  • Disabled User Accounts — identities refused at sign-in, whatever the provider says

The two lists

  • External / SSO Users lists every external identity the platform has seen: their cached profile, their approval state and their groups. It is granted to the Super Administrator group as standard.
  • My Domain's Users shows the same records filtered to the sign-in method and identity source of the person looking. One tile therefore means "my own directory" for every manager on every directory, which makes it the right tile to give a delegated manager.

An external person appears on these lists once they have signed in at least once, or once they have been provisioned by SCIM.

Giving an external user groups by hand

  1. Open External / SSO Users (or My Domain's Users) and find the person.
  2. Use the Security Groups row action. The Security Group Manager opens, saying how the person signs in.
  3. Switch on the groups they need under User is Member and click Save Permissions.

The Security Groups action is shown for every external user, whether or not they are approved or currently able to sign in: managing someone's groups does not depend on whether they can sign in today. The Approve, Revoke, Decline and Change to Approved actions on the same list only appear when external user approval is switched on for the installation; see Single Sign-On Providers.

Giving Active Directory users groups automatically

AD Group Mapping links an Active Directory group to a security group. At each sign-in the platform reads the person's AD groups and grants every mapped security group. Membership is then managed where it belongs, in the directory, and somebody removed from the AD group loses the mapped group at their next sign-in.

  1. Open AD Group Mapping and add a row linking the AD group, named as the directory reports it (for example CN=Finance,OU=Groups,DC=contoso,DC=com), to the security group.
  2. Ask a member of that AD group to sign out and sign in again.
  3. Open their Security Groups action. The mapped group is shown switched on and locked, naming the AD group that grants it.

Mapping applies to Active Directory sign-in only. For Azure AD, SAML and social logins, assign groups by hand, delegate it, or provision them with SCIM.

What goes wrong

  • Switching off a locked group is impossible. It is granted by AD. Remove the person from the AD group, or remove the mapping.
  • A banner says the directory could not be reached. The screen could not check AD, so groups granted by AD are shown as if not held. Local group changes still save correctly; do not "fix" AD-granted groups while the banner shows.
  • Somebody is missing from the list. They have never signed in and have not been provisioned.
  • A delegated manager sees everybody's users. They were given External / SSO Users instead of My Domain's Users. See Delegating Group Management.

Worked example

A college signs staff in with Active Directory and students with Azure AD. It maps the AD groups "Teaching Staff" and "Support Staff" to matching security groups, so staff access follows the directory. Students are assigned to course groups by each faculty's administrator, who has My Domain's Users and a Security Group Managers row limited to Azure AD and the student tenant. When a teacher moves into a support role and IT moves them between AD groups, their next sign-in carries the new group and not the old one, with nobody touching the platform.

Recommendations

  • Map AD groups wherever a group follows a directory role.
  • Change AD-granted access in AD, never on the platform.
  • Give managers My Domain's Users, not the full list.
  • Disable a departed identity on Disabled User Accounts if you cannot wait for the directory.