Sync AD to Google for Cloud Authentication

A K-12 IT environment is often complicated because of the wide range of machines that come under its network purview, from managed Chromebooks to unmanaged BYOD devices. Additionally, managing multiple applications used in the school environment and the school districts not being limited to a single location makes it a highly complex ecosystem.

The use of Active Directory is not so practical for a K-12 environment because it fails to provide single-sign-on (SSO) and is not the most effective for managing cross-platform systems. This often leads to IT administrators manually assigning devices and working on onboarding and onboarding of users, which is an activity that witnesses more activity than other offices due to enrollment and transfers of students.

In this article, we will look at how to extend AD Identities to the Google Cloud Platform, if the transition from AD to Azure AD is viable, and if the integration of AD with Google is possible.

Extend Active Directory Identities to Google

You already have an on-premise infrastructure for IAM (Identity Access Management) for your group management and role-based access management. It has already been signed off by your auditor and the Internal Security team, with everything functioning on point. The question that must be on your mind is: is it feasible to extend your existing on-prem Identity Access Management (IAM) to GCP (Google Cloud Platform). And when doing so, will it be possible to leverage the investments made on the existing on-prem architecture?

Yes, on-premise AD groups used for IAM can be easily extended to Google resources. Using the existing group membership management workflows, you can have your users and groups from the on-prem IDP extended to GCP. If you have a domain controller like Okta or Google Workspace in your on-prem environment, you can configure single sign-on (for your on-prem AD users) for all the platforms and applications in Google. You can continue using your existing SAML-based Identity Provider (IDP).

In GCP, you can provide role-based access management to control which user or machine has access to which application or platform. You can enable this by

1. Syncing your users and groups from on-prem AD to a GC Identity domain.
2. Setting up your Google Cloud identity domain to indicate that you would like the authentication of those users to happen with your on-prem federation endpoint.

Let’s briefly look at how to sync Active Directory to GCP.

1. Create Administrator User Account
2. Create an Active Directory for User provisioning
3. Install Google Cloud Directory Sync
4. Creating a Folder for Configuration
5. Connecting to Google
6. Connecting to Active Directory
7. Decide What to Provision
8. User Provisioning
9. Group Provisioning

You can find the detailed process steps in the later part of this article.

Is Transitioning from AD to Azure AD a Viable Option?

The scope and methods for handling identity and access management are changing drastically, with organizations moving from on-premises to cloud-based solutions. Azure AD does help sync on-prem to Microsoft 365. However, it is greatly limited when it comes to supporting a WPA2-enterprise Wi-Fi.

Azure AD was created to help transition from on-premise AD to connect to cloud services like Microsoft 365. Azure AD, in that sense, was presented as a more accessible recourse to Active Directory Federation Services (ADFS), a single sign-on on-premises identity service designed by Microsoft for enabling sharing of identity information outside an organization’s network.

ADD allows a common identity for Azure, M365, Intune, and other Microsoft cloud products (that permits SSO and multi-factor authentication (MFA) within the Microsoft ecosystem). However, the cost involved in moving to cross-domain SSO and MFA is often high as they are subscription-based services provided by on-prem AD at no extra cost. Microsoft also does not provide cloud Public Key Infrastructure (PKI) or Certificate Authority (CA) services and does not integrate well with major IAM authentication protocols, including LDAP and RADIUS. Organizations, therefore, are often left with no other alternative than to continue managing AD domain hardware, which can be expensive.

Can I sync Google to Azure AD?

The answer is yes. You can sync Google to Azure AD to manage the identities of your on-prem AD, Azure AD, and Google workspace through a single portal. This hybrid setup allows user provisioning and single sign-on (SSO) between a Microsoft Azure Active Directory (AD) tenant and your Google Workspace or Cloud Identity account.

Upon completion of delegating Google cloud identity management to Azure AD, you can redirect the Student Information System’s (SIS) synchronization from Google to either Azure AD or your on-prem AD. Your organization’s Identity Provider (IDP) continues to store the passwords of your users. Instead of Google sign-in screen, your users can sign in from their ChromeOS devices from an Azure authentication page. Signing in is almost the same as a browser sign-in to a Google Workspace account through Security Assertion Markup Language (SAML) SSO.

You will, however, have to continue using on-prem AD solutions to manage the Active Directory Certificate Services and Network Policy Servers (NPS). This means you keep incurring the expenses that are involved in managing on-prem solutions like

• Inventory management of hardware
• Continual upgrades and licensing costs,
• The time and effort needed to manage on-prem servers

Additionally, the use of this mix of cloud and on-premises solutions also comes with challenges like disconnected admin interfaces. Especially in a K-12 environment, where

• It is a mix of managed and unmanaged devices
• There is a vast number of users that use multiple devices to connect to the network
• The need for managing access to multiple applications and platforms
• There is a need for updating student accounts multiple times a year
• Limited budget for IT infrastructure and management

This makes account management even more complex and can cause unnecessary stress on the already constricted budget that school districts usually have to manage with.

RADIUS Authentication in the Cloud

Active Directory is no longer a viable solution because of its limitations and challenges due to the on-prem solution. The complex K-12 network with multiple locations and types of devices (both managed and unmanaged) and an environment where there are constant changes that need to be made to user access requires a solution that can meet all its needs. Syncing AD to Google for cloud authentication does help. However, the need to continue managing on-prem solutions for AD CS or NPS still makes it a complex solution that requires a lot of manual work and involves the expenses that come with on-prem servers.

You can eliminate the hassle of managing on-prem servers ultimately with SecureW2 solutions. Our Cloud RADIUS is the industry’s only passwordless authentication solution that is designed to work natively with cloud Identities like Azure, Okta, and Google. With SecureW2, there is no need for LDAP or AD servers. Our cloud RADIUS solutions will help with

• Real-time native OAuth integration for policy enforcement using Azure AD, Okta, & Google Workspace.
• Help you go passwordless with digital certificates.
• Network security based on user, group, attributes, device, and conditional access policies for Wi-Fi, Wired, and VPN that can be enforced dynamically.

Talk to our experts to know more about our solutions.

How to Sync Active Directory to Google Cloud Platform (GCP)

Create an Administrator User Account

The first step is creating a user account with administrative privileges for Google Cloud Directory Sync (GCDS). This account allows GCDS to facilitate the interaction between the Directory API and Domain Shared Contacts API of Cloud Identity and Google Workspace. Although you already created one super-admin user at the time of signing up for Cloud Identity or Google Workspace, it is better to create a separate user that is exclusively used by Cloud Directory Sync. The steps are as follows:

1. Open the Admin console and sign in using the super-admin user account (you created this account when signing up for Cloud Identity or Google Workspace).
2. In the menu section, click Directory > Users and then click on Add new user.
3. Feed in the name and email address that best suits your need. (Include the primary domain in the email address, even if the forest you’re provisioning from does not match the domain).
4. Please enter a new password manually. To do this, disable Automatically generate a new password.
5. Disable Ask for a password change at the next sign-in.
6. Click Add New User and then click on Done.

Next, change the status of the Admin Account to a Super Admin. You will need to do this to handle user accounts and group management activities like creating, listing, and deleting. As a fail-safe to enable re-authorization of GCDS (in case of any issues with single sign-on), exempt this user from single sign-on. The steps are as follows.

1. Open the newly created user from the list.
2. Click Assign Roles under Admin Roles and Privileges.
3. Enable the Super Admin role.
4. Click Save.

Create an Active Directory user for User Provisioning

Create a dedicated domain user account that can retrieve information about users and groups from Active Directory instead of using the existing Windows user. The steps to create the domain account are as follows.

Graphical Interface

1. From the Start Menu, go to the Active Directory Users and Computers MMC snap-in.
2. Go to the domain and organizational unit you want to create the user. In case of multiple domains in your forest, create the user in the same domain as the GCDS machine.
3. Right-click on the right window pane to select New > User.
4. Feed in the name and email address best suits your need and click Next.
5. Provide a password as per your company’s password policy.
6. Clear the field User must change password at next logon.
7. Select the option Password never expires.
8. Click Next, and then Finish.

PowerShell

1. Open a PowerShell console as Administrator.
2. To create a user run the command given below:

Please Note: Use the “Path” argument to create a user under a particular organizational unit (OU). For example: -Path “OU=dest,OU=root,DC=domain,DC=com”.

You are now ready to install GCDS.

Installing Google Cloud Directory Sync (GCDS)

To install GCDS, download the installer on the machine where you will run GCDS. You can use the PowerShell command instead of downloading the installer from a browser.

Run the following command to launch the installation wizard.

If you have GCDS already installed in your system, it is recommended to update the same to ensure you have the latest version installed.

Creating a Folder for Configuration

You must secure the folder (configuration is stored in an XML file) used for configuration because it includes the OAuth refresh token that GCDS uses for authenticating with Google. Other than this folder, GCDS does not require access to local resources. You can configure GCDS to run as a limited user.

1. Sign in with a domain or local admin user from the machine where you installed GCDS.
2. Open a PowerShell console (that has admin privileges).
3. To apply an access control list (ACL) so that only GCDS and admins have access, you will need to store the configuration. Run the following commands to create a folder named $Env:ProgramData\gcds

4. Run the command Write-Host $Env:ProgramData to identify the location of the ProgramData folder. For English versions of Windows, this path will usually be c:\ProgramData. You will need this path later.

Connecting to Google

The next step is to employ Configuration Manager to prepare the GCDS configuration. The following steps are to be deployed when running Configuration Manager on the same server that you are going to run the GCDS. If you use a different system to run Configuration Manager, ensure that you copy the configuration file to the GCDS server afterward. You should, however, keep in mind that using a different machine for testing the configuration might not be possible.

1. Launch Configuration Manager. For Windows, go to the Start menu under Google Cloud Directory Sync > Configuration Manager.
2. Click Google Domain Configuration > Connection Settings.
3. Authorize GCDS and configure domain settings.
4. Click File > Save as in the menu.
5. In the file dialog, enter PROGRAM_DATA\gcds\config.xml as the filename. Replace PROGRAM_DATA with the path to the ProgramData folder that the PowerShell command returned when you ran it earlier.
6. Click Save, and then click OK.

Connecting to Active Directory

Please follow the following step to configure GCDS to connect to Active Directory:

1. Go to Configuration Manager and click LDAP Configuration > Connection Settings.
2. The steps to configure the LDAP connection settings are:
   • For Server Type: Select MS Active Directory.
   • Connection Type: Select either LDAP+SSL or Standard LDAP.
   • Host Name: Enter the name of a GC server here. This setting is used only for testing environments, and so you will automate the discovery of the GC server later.
   • Port: 3268 (GC) or 3269 (GC over SSL). The use of a GC server instead of a domain controller will help ensure you provision users from all the domains of your Active Directory forest. Please ensure Microsoft ADV190023 is updated before authentication.
   • Authentication Type: Simple.
   • Authorized User: Enter the User Principal Name (UPN) that you created earlier for the domain user gcds@UPN_SUFFIX_DO. Replace UPN_SUFFIX_DOMAIN with the appropriate UPN suffix domain for the user. You can also use the NETBIOS_DOMAIN_NAME\gcds syntax to specify the user.
   • Base DN: This field is to be left empty so that searches are performed across all domains in the forest.
3. Click Test connection to verify the settings. In case of connection failure, double-check if the hostname you have specified is of a GC server and ensure that the username and password you input are correct.
4. Click Close.

Decide What to Provision

Once you are connected to Google cloud, you can decide what items you want to provision.

1. Click General Settings from Configuration Manager.
2. Select the appropriate User Accounts.
3. To provision groups, select Groups. If you do not wish to provision groups, clear the checkbox.
4. Leave Organizational Units unselected (Synchronizing organizational units is not a part of this guide)
5. User Profiles and Custom Schemas are to be left unselected.

User Provisioning

Configuring user mappings

Next, you can configure user mapping between Active Directory. The steps are as follows:

1. Click User Accounts > Additional User Attributes in Configuration Manager
2. To automatically populate the attributes for Given Name and Family Name with givenName and sn, respectively, click Use defaults.

The rest of the settings depend on what attributes (UPN or email address) you want to use to map Active Directory to users in Cloud identity. This will also determine if you need to apply domain name substitutions.

Configuring Using UPN

1. Click User Accounts > User Attributes in Configuration Manager.
2. Click Use defaults.
3. Change the Email Address Attribute to userPrincipalName.
4. Click proxyAddresses > Clear if you don’t want alias addresses synced.
5. Click the Search Rules, and then click Add Search Rule tab.
6. Enter the following settings:
   • Scope: Sub-tree
   • Rule:

0 Base DN: To search all domains in the forest, leave this section blank

7. Click OK to complete the rule creation.

UPN Domain Substitution

1. Click Google Domain Configuration > Exclusion Rules in Configuration Manager.
2. Click Add Exclusion Rule.
3. Configure the following settings:
   • Type: User Email Address
   • Match Type: Regular Expression
   • Exclusion Rule: To use a single UPN suffix domain, enter the following regular expression:

As given in the below example, replace SUBSTITUTION_DOMAIN with the domain that you use to replace the UPN suffix domain:

4. Click OK to complete the rule creation.

E-mail

1. Click Google Domain Configuration > Exclusion Rules in Configuration Manager.
2. Click Add Exclusion Rule.
3. Configure the following settings:
   • Type: User Email Address
   • Match Type: Regular Expression
   • Exclusion Rule: To use a single UPN suffix domain, enter the following regular expression:

As shown in the example below, replace MX_DOMAIN with the domain name that you use in email addresses:

To use more than one UPN suffix domain, extend the expression as shown below:

4. Click on OK for completing the rule creation.

Email Domain Substitution

1. Click Google Domain Configuration > Exclusion Rules in Configuration Manager
2. Click Add Exclusion Rule.
3. Configure the following settings:
   • Type: User Email Address
   • Match Type: Regular Expression
   • Exclusion Rule: To use a single UPN suffix domain, enter the following regular expression:

Replace SUBSTITUTION_DOMAIN with the domain that you use to replace the email domain, as shown in the below example:

4. Click OK to complete the rule creation.

Group Provisioning

The next step is to configure the mapping of groups between Active Directory and Cloud Identity. Based on how you plan to map groups (common name or email address), the steps are different.

Group mappings with Common Name

To start, identify the types of security groups that you want to provision, and then formulate an appropriate LDAP query for the same. Below are some common queries that can be used.

The query for global groups include Active Directory–defined groups like domain controllers. To filter these groups per your needs, restrict the search by organizational unit (ou).

Depending on whether you use UPN or email address to map Active Directory to users in Cloud Identity, the next steps are as follows.

Steps for E-mail

1. Click Groups > Search Rules in Configuration Manager.
2. To add default rules, click on Use Defaults.
3. Click the first rule edit icon.
4. Edit Rule to replace with the LDAP query you want to use.
5. Edit Group Email Address Attribute to enter the setting cn in the Groups box.
6. Click OK.

Steps for UPN

1. Click Groups > Search Rules in Configuration Manager.
2. To add two default rules, click Use Defaults.
3. Click the first rule edit icon.
4. Edit Rule to replace the LDAP query you want to use.
5. In the Groups box, enter the following settings:
   • Group Email Address Attribute: cn
   • User Email Name Attribute: userPrincipalName
6. Click the Prefix-Suffix tab.
7. In the Group Email Address box, enter the following settings:
   • Suffix: @PRIMARY_DOMAIN, where you replace @PRIMARY_DOMAIN with the primary domain of your Cloud Identity. The settings must be specified to prevent multiple Google Cloud Directory Sync instances from erasing group members that they had not added.
   • Example: @example.com
   • Click OK.
8. Click the second rule cross icon to delete that rule.

The same settings will apply if you used domain substitution to map users.

Group Mappings with E-mail Address

To do this; first, you need to determine the types of security groups you want to provision and then formulate the suitable LDAP query. Some of the common queries that you can use are.

The following settings differ depending on whether you use UPN or email address for mapping. The steps for both are as follows:

E-mail

1. Click Groups > Search Rules in Configuration Manager.
2. To add default rules, click Use Defaults.
3. Click the first rule edit icon.
4. Edit the Rule to replace the LDAP query.
5. Click OK.
6. Click the second rule cross icon to remove this rule.

UPN

1. Click Groups > Search Rules in Configuration Manager.
2. To add default rules, click Use Defaults.
3. Click the first rule edit icon.
4. Edit the Rule to replace the LDAP query.
5. In the Groups box, edit User Email Name Attribute to enter the setting userPrincipalName.
6. Click OK.
7. Click the second rule cross icon to delete that rule.

Replace domain names in LDAP email addresses with this domain name, which will also be applicable to email addresses of groups as well as members.

Deletion Policy

Deletion policy in the Googe cloud is similar for groups and users. It’s important to ensure that different GCDS instances don’t interfere with one another when multiple separate instances of Google cloud are used in provisioning different domains or forests to a single Cloud Identity account.
A group member in Cloud Identity that has been provisioned from a different source will by default, be identified in Active Directory as a member that has been deleted. To avoid this, configure GCDS to ignore the group members that are outside the range of the domain or forest that you are provisioning from.

UPN

1. Click Google Domain Configuration > Exclusion Rules.
2. Click Add Exclusion Rule.
3. Configure the following settings:
   • Type: Group Member Email Address
   • Match Type: Regular Expression
   • Exclusion Rule: If you use a single UPN suffix domain, enter the following regular expression:

Replace UPN_SUFFIX_DOMAIN with your UPN suffix domain, like the example below:

To use more than one UPN suffix domain, extend the expression as below:

4. Click OK to create the rule.

UPN Domain Substitution

1. Click Google Domain Configuration > Exclusion Rules.
2. Click Add Exclusion Rule.
3. Configure the following settings:
   • Type: Group Member Email Address
   • Match Type: Regular Expression
   • Exclusion Rule: If you use a single UPN suffix domain, enter the following regular expression:

Replace SUBSTITUTION_DOMAIN with the domain that you use to replace the UPN suffix domain, like in this example:

4. Click OK to create the rule.

Configure Logging and Notifications

To keep users in sync, you need to schedule GCDS runs. Control how and when GCDS writes its log file o keep track of GCDS activity and any potential problems.

1. Click Logging in Configuration Manager.
2. Set File name to PROGRAM_DATA\gcds\gcds_sync.#{timestamp}.log. Replace PROGRAM_DATA with the path to the ProgramData folder that the PowerShell command returned when you ran it earlier.
3. Click File > Save to execute the configuration modifications, and then click OK.

GCDS can also send email notifications too. Click Notifications and provide connection information for your mail server to activate email notifications.

User Provisioning Simulation

The GCDS configuration is now complete, and you need to simulate a user provisioning run to confirm the configuration is working as you want it to. To do the simulation, first, save the configuration to disk and then run a simulation. GCDS does not execute changes to your Cloud Identity account during the simulation. Instead, it will report the changes it will perform during a regular provision run.

1. Click Sync in Configuration Manager.
2. Select Clear cache (bottom of the screen), and then click Simulate sync.
3. Once the process is complete, check the Proposed changes section of the log (in the lower half of the dialog) to confirm there are no suggested changes you don’t want, like suspending or deleting users or groups.

Initial user provisioning

To initiate a provision run, follow the below steps:

1. Click Sync in Configuration Manager.
2. Select Clear cache (bottom of the screen) and click Sync & apply changes. A dialog will appear with the status.
3. After the process is completed, check the log (in the lower half of the dialog):
   • Under Successful user changes, check to confirm that a minimum of one user has been created.
   • Under Failures, confirm that no failures have emerged.

Scheduling

Schedule a task to initiate a provisioning run every hour to confirm that changes implemented in Active Directory are getting replicated to your Cloud Identity.

1. Log in as an administrator and Open a PowerShell console.
2. Check to confirm that the Active Directory PowerShell module is installed on the system:

Download and install the Remote Server Administration Tools to try again if the command fails.

3. Create a Notepad file, and copy the content below into it. Next, save the file to %ProgramData%\gcds\sync.ps1. Close the file once you are done.

4. A secret key is created by the Configuration Manager to encrypt the credentials in the config file. Run the command below to copy the secret key to the profile of NT AUTHORITY\LOCAL SERVICE. This needs to be done so that Google cloud can read the configuration at the time of running a scheduled task.

Check if you have opened PowerShell console as Administrator if you get a command failure notification.

5. Run the following command to create a scheduled task. This task will be initiated every hour and it conjures the sync.ps1 script as NT AUTHORITY\LOCAL SERVICE.

User Provisioning Testing

Installation and configuration of GCDS is now complete with the scheduled task will be triggering a provision run every hour. If you want to initiate a provisioning run manually, run the following command from the PowerShell console.

Uninstalling GCDS

The following steps will help you uninstall GCDS.

1. Click Programs > Uninstall a program from Windows Control Panel.
2. To launch the uninstall wizard, go to Google Cloud Directory Sync, click Uninstall/Change and follow the instructions provided in the wizard.
3. Run the following command from the PowerShell console to terminate the scheduled task:

4. The following command will delete the configuration and log files.

Amrita Medhi

Amrita moved from human resources & operations management to becoming a writer and pursuing her passion for learning and creating new things. She enjoys applying her past experiences to create content that can be of value to her readers. Amrita treasures being a dog mom and living around nature. She loves traveling and experiencing new cultures. Wherever she goes, she endeavors to learn local languages, as she believes the right words have the power to change the world.