Technical implementation of Active Directory provisioning

Groupcall IDaaS implements the following behaviours when provisioning into Active Directory.

Firstly, an IDaaS username can belong to more than one person; this means that a username cannot be assumed (as is the classic case) to be only a single role:school combination and therefore cannot be placed into e.g. a per-school OU or a role-based OU.  Consequently an IDaaS username is provisioned into Active Directory in a single OU container for all users, and group memberships are used to indicate role:school assignments.  This has some implications for GPO but they are addressed below.

For IDaaS each role:school assignment for a username is called a presence, for example a person may have one username for IDaaS which links to their part-time teaching role in three different schools by virtue of each of the three school MIS products having an unrelated record for that person as a teacher.  In IDaaS terminology we would say that there is one IDaaS Login which is linked to three IDaaS Presences, where the Presence is the role:school assignment interpreted from the school MIS record.

Each IDaaS Presence will then have membership of groups within the applicable school based on MIS data, for example a student or teacher presence will have links to (for differing reasons) year groups, house groups, registration groups, and academic classes.

Attributes for an Active Directory User


This is populated with the Groupcall IDaaS login username and appended with a suffix of your selection.  The suffix is granular down to role and school, for example it is possible for staff and students in the same school to have a different suffix.


This is typically left to AD to populate automatically.  It is possible to populate it with the Groupcall IDaaS login username but these can be longer than the 20 character legacy limit on this attribute.


This is populated with ‘IDaaS-LoginId-{LoginId}’ where LoginId is the IDaaS internal key for the Groupcall IDaaS login username

Attributes for an Active Directory Group


This is the display name of the group, taking the format of:

  • {LAID}_Students
  • {LAID}_Teaching
  • {LAID}_Year_{DisplayName}
  • {LAID}_Reg_{DisplayName}

 Where LAID is the school LA/DfE number and DisplayName is the name of the group in MIS.


Contains ‘IDaaS-ESTAB{LAID}-{GroupId}’ which is used as a glue record to issue further updates to the group.

Life Cycle of an AD User

An Active Directory user is created or updated when a Groupcall IDaaS login has a new presence assigned to it and that presence is linked to a school that is provisioned into one or more Active Directories.  In each case the login in AD will be created if not already in existence (IDaaS looks for its marker in employeeNumber) and then the presence is assigned a role group membership and a set of school group memberships.  If the AD user already exists during provisioning and is marked disabled at that time then it is re-enabled by the provisioner.

When a presence is removed from a Groupcall IDaaS login, or a presence is removed from the school MIS (usually because the person has left) IDaaS removes the applicable school group and role group memberships from the AD user.  If the AD user has no groups left then the AD user itself is disabled.

Life Cycle of an AD Group

When applicable an AD group is created as soon as a new MIS group is seen at IDaaS; the group persists in AD (referenced by the IDaaS marker stored in adminDescription) until it is no longer seen in the groups active in the source MIS.