skip to content

IT Help and Support

University Information Services
Blue AD project page carousel

What is Blue AD?

Blue AD is a Microsoft Active Directory that contains everyone with a CRSid. The data in Blue is fed into the University's Office 365 environment, which then appears in places such as the Exchange Online Global Address List (GAL).

Blue takes data feeds from multiple data sources to build its directory, including CHRIS, CamSIS, Lookup and Jackdaw.

Blue AD Toolkit

UIS has developed a delegated management system (DMS) that allows University institutions to have some self-service features – for example, group and distribution lists management. Suggestions for features for Toolkit are welcome.

 Further information

 User guide

 Blue AD Toolkit access


Having a single authoritative University-wide directory creates the potential for a number of benefits:

  • simplifies user registrations in institutions
  • institutions don't have to build their own AD
  • easier to access UIS services
  • simplification of authentication across the University
  • consistent user experience
  • using a common platform helps futureproof institutions' ability to interface with UIS services
  • available at no cost.

Authenticating to Blue AD

There are multiple ways a service/application can be configured to use Blue AD for authentication.

1. Microsoft Entra ID Application Registration

This is the preferred way for authentication. Your application/service is registered in Microsoft Entra ID (formerly Azure Active Directory). This allows you to host your application/service anywhere and has the lowest ongoing support overhead.

This authentication mechanism is based on OAuth 2.

To register an application to use Entra ID, you can use Toolkit to create application registrations.


This is similar to Entra ID Application Registration, but has the overhead of managing Metadata between the ADFS servers and the application. Although there are mechanisms to automate the management of this metadata, in our experience there are few vendors who bother to implement this. For example, when certificates change on the ADFS severs, all applications/services need manual intervention to get working again. Because of this, we recommend the use of Entra ID instead.


We do not support using LDAP for authentication but do support LDAP for getting details of users, etc.

The preferred way is to use a client that understands DNS SRV records and then point it at

If your client does not support DNS SRV records you can use the address

LDAP and expired accounts

One nuance of the LDAP interface is that it reveals accounts that have been disabled but not yet deleted from the system. If you look at the accountExpires object attribute it will contain one of three possible values:

  • 0 (zero): the account has never been marked as expired.
  • -1 (64 bit integer): this account has previously been marked as expired but has since been unexpired.
  • Any other value is the date/time the account was expired, expressed as the number of 100-nanosecond intervals since January 1, 1601 (UTC).

Expired accounts cannot be used for authentication and are usually deleted after 90 days.

4. AD Bind

This is a legacy Microsoft technology and should not be considered for any new services.

Entra ID applications

Entra ID hosts a range of third-party applications that users can request to access our Entra ID.

If the application only performs actions as the logged in user, then the application is likely to be approved.

If the application requests system wide/level privileges, the requested application is likely to be denied access to our Entra ID unless it can be shown that there is a contract in place between the application vendor and the University which has appropriate data protection clauses.

Further information


If you would like more information, or are interested in integrating with Blue AD, please contact .


Last updated: 2 Feb 2024