I’ve been working with Stefan van der Busse (suggest you follow him on Twitter) for a couple of years now and have learnt heaps from him in various aspects of the Enterprise Mobility and Security (EMS) Suite, where he has a lot of experience and crafted some great solutions.
Thought I would try something new, and give back to the community by starting a blog. First post is about synchronizing users from Azure AD into to G. Suite Organization Units. Hope it's useful to someone out there!https://t.co/2bmOtLUG8a
— Stefan van der Busse (@Svdbusse) August 17, 2019
I’m really pleased to see he has started a new blog and, in true geeky style, has chosen GitHub as the hosting platform.
He’s kicked off the inaugural post with a topic that we’ve exchanged ideas and knowledge over recently – how to sync AzureAD users into specific Organisational Units (OU) inside of G Suite. You can see this post here.
It’s an important read because it deals with an increasingly common situation: a customer that has no on premise identity platform anymore and wants to do Single Sign On and user synchronization between the AzureAD and Google identity clouds.
The Value of Experience & Testing
One of the many benefits you’re likely to get from Stefan’s blogs is the culmination of his experience and extensive testing and this comes through in the very first post he’s released – finding a probable bug when users are moved between departments or business units in AzureAD, this sync is not acknowledged at the G Suite end. In his words:
A word of warning
This is a great solution for getting users provisioned into G. Suite and into their initially correct OU. But through rather extensive testing and going back and forth with Azure AD support, there’s a major caveat that they don’t mention in any of the support articles.
All provisioning requests that are sent to G. Suite use a POST REST method. This is generally fine; and works perfectly for user creation. But as per the G. Suite Admin Directory API documentation updates to existing users need to use a PUT REST method.
So what does that mean?
Any subsequent changes such as a user moving between departments or business units could result in a user moving between assigned groups, and therefore needing to be moved to a different OU in G. Suite.
The change is sent to G. Suite by Azure AD but simply and unfortunately ignored.
That knowledge is gold if you’re setting up a similar situation in your tenant/business and worth noting and planning around.
If you like what you’re seeing from this initial blog post, then suggest you subscribe to Stefan’s blog – you can do this here.
