You would expect that a service that is responsible for the naming of objects within a namespace should prohibit the creation of objects with the same leaf name and fully qualified name. Put simply you should not be able to have two files in the same directory with the exact same name in your file system. Likewise a directory service should do the same, or should it…?

It depends on the rules of the service actually, and what those rules specify must be unique. Take good old Windows Server Active Directory for example. Active Directory is based on LDAP and in the LDAP naming scheme an object may have the same Relative Distinguished Name (RDN), as long as the Distinguished Name (DN) is unique. In this case the RDN is the leaf name and the DN is the fully qualified name. So you can have two users named John Doe as long as they do not both reside within the same Organizational Unit (OU), or location, in the directory. So in AD the rules specify that the DN must be unique. There are also other rules like the ones that say no two users can have the same sAMAccountName or UserPrincipalName properties.

Azure Active Directory also has similar rules, for example you can’t create two AAD users with the same UPN (but they can have the same name). Azure AD groups act differently however. First of all they don’t have UPNs, they only have names (DisplayName attribute). So for groups the rules say that it is the ObjectID property of the group that must be unique, not the name. You can test this yourself easily with PowerShell. Run this command against your AAD tenant twice or more:

New-MsolGroup -DisplayName "GroupWithTheSameName"

It will succeed and you are left with a number of groups which look identical until you look at their ObjectID properties. I’m sure you can imagine the interesting side-effects of having more than one group with the same name… How is this allowed you ask?

The answer is hybrid identity. Azure AD and it’s local sync component; Azure AD Connect, supports syncing users and groups from multi-domain forests and multiple disparate forests into the same Azure AD tenant. This is great for consolidation scenarios, but to understand exactly how it relates to duplicate group names in Azure AD; let’s look at the rules for uniqueness in Active Directory again:

• Single forest
  • Users must have a unique UPN attribute within a forest, and a unique sAMAccountName attribute within the domain. No such requirement exists between forests. The RND can be the same as long as the DN is unique.
  • Groups must have unique sAMAccountName attributes within a domain. No such requirement exists between forests. The RND can be the same as long as the DN is unique.

The mechanism within a forest that makes sure the above requirements are met is the global catalog (GC).

• Multi forest
  • Anything goes, nothing is shared between forests, even forests that trust each other. You could even have two forests with the same forest root name and UPN suffixes. There would not be able to interact with each other of course.

Form this we see that we can have groups that have the same name, they are only separated by their sAMAccountName attributes in Active Directory. Azure AD Connect does not synchronize the sAMAccountName into Azure AD so we get duplicate groups.

At this point you may be wondering what happens if you have two disparate forests with the same forest root name, how will they sync? Answer is they won’t, that is not a supported scenario by Azure AD Connect, which uses DNS to find the DCs of the forests.

You may also be wondering why this does not apply to users. Users have a unique attribute that is synced into Azure AD; the UPN. As long as it is unique within the forest the user will sync to Azure AD. If you have two forests with the same UPN for two or more users, but still are able to be part of the same Azure AD Connect sync installation, something which is possible if you configure the same UPN suffix in both forests, Azure AD connect will block the syncing when it encounters these users.

NOTE: Manipulating Active Directory directly it is actually possible to have two users with the same UPN in the same domain or forest. If you try to sync those users into Azure AD they will be blocked like described above.

The good news regarding groups is that Microsoft are working on a way to handle groups better in Azure AD Connect so that we do not get these duplicates.

Always fun with a little directory service internals 🙂