Поделиться через


Azure AD Object Attribute Uniqueness

You're a cloud engineer. You're organized, methodical, and thorough in your approach to the integration of your cloud deployment with your existing on-premises workloads. By now, you've successfully deployed DirSync for your organization and federated your Active Directory up to the cloud. Not only that but you've been in the game long enough, you've upgraded from DirSync to AD Sync, and now to Azure AD Connect – and you made it look easy. You have hundreds, if not thousands of users that utilize and rely on the products you support. Your skills as an administrator enable your business to be nimble, your users to be productive, and your career to be blazing a path into the Azure sky!

Sounds like you, right? I thought it might. After all, you are my target audience for today’s post!

While my primary focus is supporting Microsoft Azure, I sometimes work on Exchange Online and Office 365, as both ExO and O365 utilize Azure AD! I ran into a very interesting problem a few weeks back that I think deserves mention. Perhaps this post may help others in the same situation.

Within each Azure AD tenant, every User, Group, and Contact object has the following four attributes: UPN, proxyAddresses, TargetAddress, and Mail. There are more, but we’re going to focus on just these four. Why? These four attributes on each object must have unique values amongst all other objects. Wait, what? That doesn’t mean that your UPN and Mail attributes can’t be the same on a single object, but that these attribute values may not overlap between two objects. One object’s UPN attribute cannot match the contents of another’s proxyAddresses attribute, and so on. Any overlap will result in export errors seen within the Synchronization Service Manager on the Azure AD Connector.

I know that last paragraph was somewhat difficult to follow. The best way to explain this is to actually demonstrate what I’m talking about. Let’s use this example for reference: I am Jimmie L. Lightner, III. Yes, my father and grandfather are named Jimmie as well. If you think this is confusing, try being one of us during a holiday get together! Let’s create three user accounts in our on-premises Active Directory, one for each of us. Active Directory will force us to each have a unique userName as seen in the following screen shot. I've created 'Jim' for my Grandpa, 'JimmieL' for my Dad, and 'Jimmie' for myself. 

 

My account is updated to contain my organizational email address, jimmie@homeroot.net, in the Mail attribute of my User Object. This change will be synchronized to Azure AD successfully.

 

Later on, my grandfather's proxyAddresses attribute is updated to include the same SMTP address as my Mail attribute.

 

Our on-premises Active Directory does not care that my Mail and Grandpa’s proxyAddresses attribute values overlap with each other, but this is a problem when we’re synchronizing to an Azure AD tenant. Shortly after the change to grandpa's User Object is brought into the Metaverse via the Active Directory Connector, it will fail to be exported to Azure AD.  If we look at the Synchronization Service Manager console, we will see export errors on our Windows Azure Active Directory Connector.

 

Clicking on the hyperlink in the error report will bring up the Object Properties within the Connector Space. Here we can see that our Pending Export is trying to add the proxyAddresses value to Grandpa's User Object in Azure AD, resulting in a collision.

 

 

I have yet to find documentation that explicitly defines the requirements for these attributes to be unique, but the below article gives us several methods that will enable us to track down the Object with which we're colliding if we do encounter this error. 

KB2643629 One or more objects don't sync when using the Azure Active Directory Sync tool

I hope that you found this post helpful and informative. If you have any questions, please feel free to post them in the comments! Thank you for reading!

Until next time,

Jimmie.

Comments

  • Anonymous
    September 03, 2015
    Very insightful !