This blog post series is based upon and tested with AAD Connect, December 2016 release, version 1.1.380.0. Future AAD Connect releases may alter behaviour or expose new features that render this series redundant. Test all deployment designs before production implementation.
Table of Contents
Part 3, An Aside on EmployeeID
Why not use EmployeeID as sourceAnchor?
I don’t have a lot of time to work on this series today but I did want to address a request I had on Twitter. A reader asked if I could discuss the use of EmployeeID as the sourceAnchor. So here it is …
The criteria (as I see it) for selecting your sourceAnchor should be –
- The attribute is unique for all objects synchronised into your Azure Active Directory tenant
- The attribute is populated for all objects synchronised into your Azure Active Directory tenant
- The attribute will never change for any given object synchronised into your Azure Active Directory tenant
Let’s examine each of these and discuss EmployeeID –
The attribute is unique – In most organisations EmployeeID is likely to be unique for each employee. The problem I have with it is that it’s often a user-populated value
- It is not always system-generated and may be subject to human error
- What may happen during a company merger?
- Is there any chance an EmployeeID may be recycled?
- Do you ever copy users to provision new ones?
The attribute is populated – EmployeeID generally applies to employees only – real human beings. There may be objects you sync to Azure Active Directory such as conference rooms or shared mail boxes. These would need an EmployeeID to successfully sync.
The attribute will never change – consider your identity management lifecycle. What happens when
- A contractor becomes a permanent employee
- A contractor finishes early and returns before their identity is removed
- Employees move between companies or organisations inside the same Azure Active Directory tenant
- A contractor stays on longer than their planned employment potentially triggering removal of their identity
As you can see, there are potential problems with EmployeeID. I’m sure there are scenarios I’ve failed to mention but the takeaway is that it’s probably unreliable as a sourceAnchor.
The last thought I have is that if you start with objectGuid, with relative ease, you can change to mS-DS-ConsistencyGuid or msDS-SourceAnchor later. This is a much more difficult undertaking if you start with EmployeeID and later decide it’s not working for you.
You may be able to get away with using EmployeeID as your sourceAnchor but there are often unforseen risks and you can make a better choice.