Quantcast
Channel: TechNet Blogs
Viewing all articles
Browse latest Browse all 34890

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

$
0
0

Table of Contents

Part 1, Introduction

Part 2, Lab Setup

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 populatedEmployeeID 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.


Viewing all articles
Browse latest Browse all 34890

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>