Hey Google Admins, this is Goldy again. In this video let’s talk about Google’s newly launched functionality called Context aware Access for Google Admin Console.
Now as you know, Google Admin console is the place where you go to take care of your identities, create users, groups, members, etc. so regardless whether you are using Cloud Identity or Google Workspace or Google Cloud Platform, or in fact any other Google Enterprise application, you will be dealing with Google Admin Console because that’s where you manage all your identities.
With this new launch, you should be able to apply context aware or conditional access policies to admin console.
So for example, you can leverage user context like which IP address is this accessing request coming from, which geographic location is the user coming from, You can also leverage device context like what’s the device posture, Is this device encrypted, Is it running minimum operating version XYZ, Is it a company on device or a personal device, and based on that you can then say whether with this specific context an admin would be able to access Google Admin Console or not.
Now before I show you the step by step demonstration, let’s talk about the logistics that you should have in place to configure Context Aware Access (CAA) on Google Workspace Admin console.
1. You should be running Google Workspace Enterprise Standard or plus or you should have Google Workspace Education Standard or plus. If you have Cloud Identity (maybe if you’re just using Google Cloud Platform), then this is only available in Google Cloud Identity Premium.
2. You should be a super admin to set this up. If you have a Reseller in place who is taking care of your Google Workspace or GCP, then they can also help you do that.
3. Finally, you should be very cautious, very careful when applying the Conditional Access to Admin Console to avoid the lockout.
So there are some best practices that I read in Google’s help article. The first one is that you must review the policy before applying it.
You should really pay attention to messages that Google will show when you’re applying the Conditional Access to Admin Console to make sure that you are minimizing the chances to lock out, you should prefer applying policies to groups than to individual users.
And last but not least, make sure you have access to Google’s support portal just in case If you miss anything and there is lock out, you should be able to reach Google support team so that they can help you with unlocking and letting you access Google Admin Console.
So with that in place now let’s configure Conditional Access or context aware access for Google Admin console. So here is my Google Workspace or Cloud Identity Admin Console. I’ll go to Security here.
Under Security I will click on Access and Data Control and I will be clicking on context aware access.
Note : Please make sure that the context aware access is turned on.
Now, as a first step, let us create an access level.
So we will call it Allow access from US Only (considering adding some description to it so other admins can easily understand what this rule does).
Now when you’re applying conditions, there are two ways, you can either apply the basic conditions which means you can do it via the user interface with simply adding the attributes, or you can also create an advanced condition by leveraging common expression language.
For now, just to keep this short, I’ll go with basic condition and I will say the geographic location is let’s say United States.
let’s say if my company only operates in United States and all our admins are here and I want to make sure that nobody else should be able to access Admin Console other than the admins coming from the United States.
If there is a need, I can also add more conditions to it e.g device operating system, company or personally managed device, IP range etc. You can also combine other access levels that you have created in the past.
In my rule here, I’ll just say that users should be able to access Admin Console if they’re trying from United States, then let me click on Save button to save the access level.
Once you have it saved then you will go to the second level which is to assign this access level to required audience (e.g all users or a subset of users by selecting the orgUnit or group).
Now here, other than the applications which are workspace native apps like Gmail, Drive, you will also see third party SAML applications that you have configured like Asana and others (where Google is acting as Identity provider), if you apply, then this Conditional access would also be applicable to these SAML Apps.
As you see in the screenshot below, at the top here you will see this new bar coming up which says Admin Console. It says continuous evaluation point which essentially means that the context would be evaluated at every request (it is dynamic unlike the traditional session which is valid for x hours etc).
In case if there is a change in your context, for e.g in my policy which is to only allow access from United States, if I log in now, maybe I’m sitting at airport somewhere leaving United States, I should be able to access but when I land in some other country, my context would change and at the next attempt or next API call it will read the context and revoke my access.
So I’ll go ahead and click on Assign here, I will see all my conditional access policies that I created. I only have one which is shown here “Allow access from us only”. I’ll go ahead and apply this now.
Note : You can either apply the access levels on the root organizational unit which means it’ll be applied to all users, or you can go granular by applying it only on a subset of users by choosing the child orgUnit or a group.
It depends in case if the application is available in mobile or desktop apps too. For example in case if this is specific to Google Admin Console which also has iPhone application.
If I apply this checkbox that means this conditional access will also be applicable to those mobile apps and with that I will just make sure you’re reading these messages and be very careful toward lockout and then you will go ahead and click on save.
Now, as I have applied the CAA policy to our google workspace admin console, let me show you the demo by trying to access from U.S and a non U.S location.
I am using a remote machine based in India, and ideally I should not have access via it my Google Workspace or Google Cloud Identity admin console based on the context access policy we just applied.
So let me enter my google admin credentials along with two step verification code.
As you see, I got the error saying you don’t have access, and thats because we only allowed access to workspace admin console from U.S, however this access request came from India.
However, I am still able to access other applications like Google Drive, because my context aware access policy was only applied to Admin Console. This is very useful when you need to provide access to less sensitive applications like Google Meet from any location / device but want to restrict applications that may have sensitive data like Gmail, Drive etc from specific locations, or IP ranges or company owned devices.
You can of course customize the conditions based on your needs.
I would recommend you to create multiple conditions, and then create access levels based on those conditions (e.g one condition says ‘company owned devices only’, other one says ‘company IP range only’, and then create access levels like Low Tier, Medium Tier, High Tier etc by adding multiple conditions you created.
Finally, leverage these security level tiers to grant access to your Google Workspace and/or SAML applications and other resources.
You may also compliment Google Workspace context aware access with BeyondCorp to go one step further and apply zero trust policies on resources in Google Cloud platform, other clouds, on-prem resources etc.
If you have any questions, comments or feedback, please do not hesitate to put that under this video and I’ll be happy to. Collaborate. Thank you so much.