Blue active directory (AD) is a directory service containing all the University's staff and students. It is used for user and device management, and to provide authentication and directory services.
What is Blue AD?
Blue AD is a Microsoft Active Directory which 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. (e.g. CHRIS, CamSIS, Lookup, Jackdaw).
Blue AD Toolkit
UIS has developed a delegated management system (DMS) that allows University institutions to have some self service features. e.g. group and distribution lists management. We currently target new releases of Toolkit for the start of term. Suggestions for features for Toolkit are welcome.
Benefits
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 going forward
- 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 - Azure AD Application Registration
This is the preferred way for authentication. Your application/service is registered in Azure AD. 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 Azure AD you can use Toolkit to create application registrations.
2 - ADFS
This is similar to Azure AD Application Registration but it 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 Azure AD (above) instead.
3 - LDAP
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 blue.cam.ac.uk
If your client does not support DNS SRV records you can use the address ldaps.blue.cam.ac.uk
LDAP & 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.
Azure AD Applications
Azure hosts a range of third party applications that users can request to access our Azure AD.
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 Azure AD 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.
Development roadmap
Contact
If you would like more information, or are interested in integrating with Blue AD, please contact the UIS Service Desk.
Last updated: 19th May 2021