DISCLAIM, DISCLAIM

Here at Endocode we love Microsoft Active Directory. Mostly because we don’t have to deal with it internally. But let’s be honest, we do understand that there are a couple of reasons to stick to this long-standing giant. Hence, this article is not another rant about Active Directory. It’s actually quite the opposite, because we are truly excited to tell the internet how it can be federated with Google easily.

It’s all about provision

Now back to square one: One of our customers told us that they were assessing the feasibility of extending their current Active Directory-based identity management solution to Google Cloud Platform. Well, that should be doable, right?! After some Google-googling and Microsoft-binging it turns out that it’s not proverbial rocket science. Both sides provide tools to implement federation. Sounds cool, huh?! Well, not quite. These two tools need to run additionally in the existing environment and that somehow doesn’t feel cloud-native enough. Isn’t there a better way? Yeah, there is! Luckily, the setup had already been extended from an ancient on-premise Active Directory domain to Microsoft’s new-fashioned cloud service Azure AD. And when you stroll around you can find this Enterprise Application named ‘G Suite’, which can be added with two clicks. The description reads ‘Use Microsoft Azure AD to enable user access to G Suite.’ Hmmmmmmm… both G Suite and Google Cloud Platform use Cloud Identity, Google’s Identity as a Service (IDaaS) product. That might work. And indeed: Once you have authorised a Cloud Identity user with sufficient privileges on the Azure side you have established a link between the two worlds. But wait! Before you go ahead and start provisioning users and groups from Azure AD to Cloud Identity, you should check ‘users and groups’. Do you really need to provision every user and group or is it perhaps sufficient to have a subset in Cloud Identity? The second crucial setting is ‘Mappings’. It is essential to have an understanding of user attributes and how they differ on both sides. You’ll need a unique identifier, which is usually the User Principal Name (UPN) on the Active Directory side, whereas Google identifies users and groups by email addresses. Once the attribute mapping is sorted then nothing can stop you anymore. Move the Provisioning Status slider from ‘Off’ to ‘On’… et voilà: The users and groups arrive in Cloud Identity. That feels good!

What if…

Alice and Bob have left the company? So what? Just remove them from the Active Directory and they’ll be automagically removed on the Google side as well. You may rest assured that Azure AD remains the single source of truth. Thus, if a Google account gets deleted, then Active Directory will recreate it.

Save money on post-it notes

The lucky user of a newly created Google account doesn’t have to jot down another password on a post-it note. He can simply stick to the existing note attached to his monitor. The one with the Active Directory password. How does that work? The magic is called Single Sign-On. It allows you to visit the Google Cloud Console without ever entering a password. Cloud Identity delegates the authentication to Azure AD by using the Security Assertion Markup Language (SAML) protocol. This has the positive side effect that the user’s password is never sent to Google. What needs to be done to use Single Sign-On? At first get another instance of the same ‘G Suite’ Enterprise Application. Yes, yes, you could use the same instance that you have already configured, but there is this teeny-weeny storage limitation that we don’t want to talk about. Microsoft is probably fixing the issue while you’re reading this. Anyway, just enter 2 or 3 URLs here and there and Bob’s your uncle. It really works! And speaking of ‘saving money’: the whole setup comes at no additional cost, as long as you don’t exceed 50 ‘Cloud Identity Free’ users. For the 51st and subsequent users you have to pay for ‘Cloud Identity Premium’.