In AD Bridge, Blog, Directory-as-a-Service (DaaS), G Suite, Identity-as-a-Service (IDaaS), IT Admins, RADIUS, Uncategorized, WiFi

IT admins have been moving to Google Apps in large numbers. Google recently announced that they have over 2 million paying businesses using their platform. The question for IT admins then becomes, how can they leverage their Google Apps identities for more than just access to Google Apps? Of particular interest is how to enable Google Apps identities that can be used for WiFi authentication as well. Google’s App Directory doesn’t provide support for this function out of the box. In fact, Google Apps Directory is largely a contact database and single sign-on service to Google services along with a handful of other web-based applications. Connecting Google Apps to your WiFi authentication is possible, but requires a third party integration with the RADIUS-as-a-Service functionality of JumpCloud’s Directory-as-a-Service (DaaS).

Bridging the Google Apps Gap

JumpCloud’s DaaS does all of the heavy lifting for you as it provides a complete, redundant RADIUS infrastructure with which to connect your WiFi networks and your Google Apps identities. Think of Directory-as-a-Service as your bridge between your on-premises WiFi users and Google Apps. It does the translation to ensure that your Google Apps identities can be utilized by your users for their WiFi access.

Here’s how the approach works:

Step 1 – Leverage Existing Google Apps Identities to Integrate with JumpCloud DaaS

Import your existing Google Apps users into a cloud-based directory service. By integrating Google Apps and DaaS, you now have a central user store where you can provision and deprovision users as well as authenticate users across WiFi, LDAP and SAML applications, and devices.

Step 2 – Connect Wireless Access Points to JumpCloud RADIUS Endpoint

Point your WAPs to be authenticated via RADIUS and JumpCloud’s high-availability RADIUS infrastructure. The beauty of this step is that you don’t need to stand-up and manage your own RADIUS infrastructure, which as many IT admins know is a painful experience.

Step 3 – Update Endpoints to Leverage RADIUS

Update your endpoints to leverage the RADIUS protocol. The user will need to enter their Google Apps credentials once in order for their endpoint to be all set to access the WiFi infrastructure through the secure RADIUS protocol, and, most importantly, verify user access based on the same user credentials that are required for their Google Access.

Expanding Google Apps Identities

The benefits of this approach are significant. Your WiFi infrastructure is not back-ended by your core user directory, meaning that somebody with your SSID and passphrase can’t just get on to your network. IT admins know that this is a significant step-up from the existing WiFi security. The decision to connect access to be authenticated by the directory is a no-brainer, but the difficulty lies in executing that goal. Additionally, when you add into the mix Google Apps, which doesn’t really have a core directory service, the challenge grows.

JumpCloud’s Directory-as-a-Service is the solution that performs this function well. Thanks to its RADIUS endpoint, the need to integrate WiFi with your directory yourself has become obsolete. Now, organizations get access to a large number of other services, including hosted LDAP, device authentication and management, single sign-on to applications, and multi-factor authentication. If you are interested in extending your Google Apps identities to also serve as your WiFi authentication credentials, take a look at Directory-as-a-Service as a bridge between the two.

Feel free to drop us a note if you would like to discuss this further or sign-up for a free account and try the Google Apps WiFi authentication for yourself.

Recent Posts