Choosing a sourceAnchor for Multi-Forest Sync with AAD Connect - Part 3, An Aside on EmployeeID

  • Article

Update 25th May 2017:- As of AAD Connect May 2017 release, version 1.1.524, the default sourceAnchor used by the setup wizard is mS-DS-ConsistencyGuid. This renders most of this blog post series moot but it will be maintained for reference.

 

This blog post series is based upon and tested with AAD Connect, December 2016 release, version 1.1.380.0. Test all deployment designs before production implementation.

Table of Contents

Part 1, Introduction

Part 2, Lab Setup

Part 3, An Aside on EmployeeID

Part 4, Using msDS-SourceAnchor

Part 5, Using mS-DS-ConsistencyGuid

Part 6, Moving off objectGuid

Part 7, Migrating Users

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.

Conclusion

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.