The Azure Active Directory Domain Services (Azure ADDS), services enables you to run a fully Microsoft managed Active Directory in Azure, which will be populated with users and devices from your Azure Active Directory. By being a fully managed services, you don’t have direct access to the VMs that run the AD, the VM (or set of VMs if you enable replication), is updated and maintained by Azure.
The service doesn’t get much attention but it is actually a pretty decent service if you have some software that requires a real Active Directory to work, and you don’t want to install and run your own Domain Controller on a VM in Azure. It can be used by Azure VMs that you want to domain join or you can talk directly with it through LDAP which is used by a lot of software that was designed in the on-prem era.
You can even connect to it using your favorite AD management tool and browse it like you would with a proper AD. However browsing is pretty much all you can do, you can’t really create any new objects, change the OUs or modify any attributes, because everything is synchronized from Azure AD and is readonly.
Under most circumstances that is exactly what you want from a managed Active Directory – until the synchronizations decides to do something stupid.
A scenario that I have seen happen a few times on our production environment is that the synchronization, have issues when a guest user in Azure AD and a real employee have the same initials in their email/username. Lets say you have invited a guest [email protected] to your AD, but you have also an employee [email protected]. If the guest was synchronized first to the ADDS tenant, it would get the username mycompany.com\xyz as username, then later when the real employee is synchronized that username is obviously not available so ADDS simply prefixes the username with something random so it will look something like mycompany.com\xyz (DF591A). This is pretty annoying because if you have old software that depends on the username to do its logic it now no longer works for you employee.
So what is the solution. Well the simple one would be to delete the external employee from you ADDS, and hope that the synchronization would overwrite the username. But it is not that easy. You cannot delete from ADDS, read-only remember. Secondly, even if you decide to delete the external employee from your Azure AD, the real employee in ADDS will still have the old username, the synchronization simply doesn’t change it after the initial sync.
The only way to solve this issue is to do a complete resynchronization. You can only do this by changing the synchronization scopes on the ADDS services. If you are using scoped synchronization you can remove the group that the problematic users belong to (or if you are lucky and it’s a dynamic Azure AD group, you can filter the problematics accounts out). When you make a change to the scoped synchronization that removes a user, that user will be completely removed from ADDS with the next synchronization run. When you re-add a group with the user in, the user will be created anew, and if you ensured that there are no name-conflicts this time, everything will be correct. Nearly everything. One thing you should be aware of is the the objectIds in the AD Domain Services AD will actually change for all users that was re-added. So if you did like me and removed all users except the AAD DC Administrators group, now all your users have new objectIds, whether this is a issue probably depends on how you use ADDS, but in my case the application I was using held the reference to the AD user, by using it objectId, so I had to fix those after my resynchronization of all users – bummer.
The final take away, if you decide to use Azure Active Directory Domain Services, make sure that you configure it to not synchronize Azure AD guest users, i.e. always use scoped synchronization, unless you really need those guest users. The simplest way to get all your employees synchronized without the guest users, is to create a new Azure AD dynamic group, and create a filter that includes everyone that has an email that ends in your domain, then you are avoiding a lot of headaches down the road.