IT admins love the vision of having their G Suite™ (formerly known as Google Apps) identities as the central credentials that can be used across an entire IT infrastructure. Much like how Microsoft® Active Directory® (AD) credentials were used historically as the access for an entire network, G Suite is starting to be viewed as the central set of credentials for a modern organization.
At many organizations, G Suite is the only IT service that every user has, and as such, IT admins would like to leverage that identity elsewhere.
Limitations of Google Apps as a Directory
Unfortunately, when G Suite was created, it was never intended for the G Suite directory to be a full directory. The thought process was not to create an alternative to AD, but rather to create a user store for Google applications.
Unlike AD, where credentials are leveraged to access devices, servers, third-party applications, and the network itself, Google Apps credentials are most often used for Google Apps services such as email, docs, sheets, and occasionally for third-party web applications that leverage OAuth.
Turning G Suite into a True Directory
IT admins have been looking for a central identity to control G Suite, much in the way AD does for other Windows® devices and applications. But the G Suite directory doesn’t have the requisite capabilities built-in.
Ideally, the G Suites account would be the same set of credentials to be used for accessing a user’s laptop or desktop, AWS® or GCP™ cloud servers, on-premises applications, and the WiFi network. In order to make a G Suite identity to function in this manner, the identity would need to be federated to these various types of resources in a variety of different formats, including via LDAP, SSH, RADIUS, and others.
Even if those protocols were leveraged, the challenge is that, in order to control user management on devices as well as have policy execution similar to AD, an agent needs to be installed on each machine. An agent would give a central directory the ability to create users, authenticate access, and terminate users. Further, the agent would have the ability to execute commands or scripts on the device.
Realizing this Vision
The power of leveraging one set of identities for access to all IT resources is immense.
- easier for end users to connect to the IT resources they need.
- more secure – control over access to applications, devices, and networks.
- account management – a user’s access can be terminated across virtually the entire infrastructure from one central point.
- IT admins can create a link from G Suits to AWS cloud infrastructure, as well as from G Suite to Mac®, Linux®, and Windows accounts.
For cloud-forward companies, Google Apps represents an alternative to Microsoft Exchange and O365. With the addition of the ability to connect Google Apps identities to devices and servers, these organizations can effectively eliminate their need for AD and on-premises IAM solutions entirely.
Directory-as-a-Service® can turn Google Apps into a Complete Directory
In order to achieve this vision, a third-party bridge is needed between G Suite and the devices, servers, networks, and applications. This connector is the core identity store that will bridge identities to G Suite and all of the other IT resources.
The most common choice for this bridge is a solution called JumpCloud® Directory-as-a-Service®. Directory-as-a-Service complements G Suite as a cloud-based directory service syncing with G Suite as well as Windows, Mac, and Linux devices.
IT admins can simply import their G Suite user population to get started. JumpCloud Directory-as-a-Service will take control of the identity and subsequently propagate any changes to G Suite and any other IT resources connected to the cloud-based directory services. The same identity used for G Suite is now able to be used across the entire enterprise including devices, servers, on-premises applications, and the network itself.