Share This Article
Cloud productivity platforms G Suite™ and Office 365® are immensely popular today. Nearly every organization has an instance of one, if not both. Because of this high level of usage, we strive to make it easy to use these identities for more. That’s why our directory seamlessly integrates with both O365 and G Suite, allowing the use of those identities for systems (Mac®, Windows®, Linux®), cloud and on-prem apps (through SAML, LDAP), data storage, and much more. As a result, we often get questions asking how our Directory-as-a-Service® platform integrates with these productivity platforms. In this post, we will explain how JumpCloud® (DaaS) integrates with Office 365.
JumpCloud’s O365 Integration
Essentially, JumpCloud’s directory-level integration with Office 365 comes from two components. The first of the components is our direct provisioning and sync bridge (which can also import users in from O365), and the second is SAML-based SSO. In the following sections, we will go through how they both work. Or watch the video below and see how it’s done in the JumpCloud console.
JumpCloud and Azure Active Directory (AAD)
“Wait, I thought we were talking about Office 365 integration components, not Azure® Active Directory?” Well, you’re right. But, what’s important to point out here first is that JumpCloud’s first integration with Office 365 is all possible through having a deep relationship with Azure® Active Directory® (AAD). This is because AAD acts as the underlying identity layer of Office 365. What goes into AAD, can get pushed up into O365. So, the first question we need to ask is, “How does JumpCloud integrate with Azure Active Directory?”
The answer to that question is that JumpCloud establishes a deep integration layer through APIs. We are using an OAuth-based connection to securely connect JumpCloud via a Office 365 super administrator account, and are specifically utilizing Microsoft’s Graph API. With that secure connection established, we then communicate with AAD through the API to perform our user management tasks. The first indication we make to the AAD instance is that we will be deferring in objects that we create within it to another directory source. This means any kind of metadata changes, password updates, and so on that are made in JumpCloud will be reflected in Azure AD and to any bound user objects such as the Office 365 account.
In this whole transaction, there is no middleware server needed. Contrast that with G Suite/Active Directory/LDAP integration set-ups. Many of those services require the middleware to orchestrate and communicate all of the user provisioning and password changes (e.g. GCDS), but in our implementation of O365 (and our G Suite integration) none of that is needed. Now let’s go into how this relationship with AAD enables JumpCloud’s O365 integration.
JumpCloud / O365 Direct Provisioning and Sync Bridge
The direct provisioning and sync is a fairly straightforward process. See how it happens here. Imagine an existing JumpCloud user, let’s call him User A. Using our integration bridge, if we push him into Azure AD, it naturally creates a user named “User A” and incorporate him into its directory. Once that process is complete, we then surface that user into Office 365. It’s as simple as that.
But, this process works both ways. Imagine there were a user stored in Office 365. Let’s call them User B. Now of course User B has their core representation located inside of the underpinning AAD. Knowing this, we go through the same process as with User A, but in reverse. Simply pull the user out of AAD into DaaS, and create User B in JumpCloud based off of that information. Then, once created, JumpCloud takes control over the user.
This second method is something that we see quite frequently with our platform, due to the fact that many times when JumpCloud is introduced to the organization there is already an established O365, Azure Active Directory, or even G Suite implementation. So, by using this process in reverse, we can import the users from those implementations, and get the users inside of your core directory — JumpCloud.
Now that this relationship is established through the API, the crux of the transaction is this: All changes must occur within JumpCloud and be pushed into the service. This is where all of the benefits of JumpCloud appear. Because the password changes, metadata changes, etc. are all pushed from JumpCloud all the way through to maintain everything in sync, this means that these credentials can be used for all of your other resources as well. From your systems, WiFi networks, data storage, web applications, and much more, those O365 credentials are able to grant users access to all of the IT resources they need access to. So as you can see, just like with an authoritative Active Directory implementation, JumpCloud is the source of truth in the relationship with O365. One example of this involves password changes. If a user were to try and change their password in O365, the Directory-as-a-Service platform would recognize that password change and immediately overwrite it. This ensures that the employee’s credentials stay in sync, allowing for the True Single Sign-On™ functionality that the platform provides. No more will users need to remember multiple sets of credentials for their different IT resources. With JumpCloud acting as the core directory, you get one identity to rule them all™.
SAML-based SSO
The second of the O365 integration components is SAML-based SSO. Web application SSO is a great tool for end users convenience, as it provides one central area for a user to log in to before accessing the sites they need to visit. Once logged in to this SSO area, users only need to click on icons that link to each of the respective sites. JumpCloud’s SAML-based SSO connection with O365 provides just that. Once you have everything that is required to setup the SAML-based SSO connection, simply connect JumpCloud with O365 and a icon will appear inside of the User Portal for O365. Then, your end users can log into their portal, and select Office 365 from a list of provisioned application icons. After clicking, the end user will be authenticated to Office 365 and they gain access. It’s as easy as that.
Do I Use Direct Provisioning or SAML?
The thing that’s important to clarify here is that these two pieces of technology are both independent from each other. They both work with Office 365, but they can be used entirely separately. For example, there are many JumpCloud customers who aren’t using the provisioning mechanism, but who are using the SAML-based SSO. Conversely, many customers don’t use the SSO functionality, but do use the provisioning bridge. In that second scenario, a user logging into the O365 portal would be entering their corporate domain name and their JumpCloud password, and the authentication would work just as well. While both of these work well independently, the ideal scenario is to enable both of the integrations. With both integrations set-up, users get the easy SSO capabilities for O365 that enable quick and easy access through the user portal, and admins get the control over the identities that the provisioning and sync connection provides as well. This means that users are happy with the ease of access, and admins are happy with the centralized control over the accounts. In the end though, the choice on which process you want to use is entirely up to you. Because the identities are all interconnected with our core version of the identity, you choose the solution that works best for your environment.
Learn More About JumpCloud’s O365 Integration
So, as you now know, JumpCloud’s O365 integration all comes from what we do with the two integration points of SAML and the API driven direct provisioning and sync. If you would like to learn more about this process, you can find a deep dive on the topic located in our Knowledge Base. There, you will find step-by-step instructions on how this process works. Alternatively, you can also reach out to us.
We are happy to answer any questions that you might have on the topic and explain why the O365 integration could simplify and streamline your approach to identity management. If you would rather try it out for yourself, sign up for a free account. Your first 10 users are free forever, with no credit card required. That free account includes full-product functionality, so you’ll be able to try out every aspect JumpCloud has to offer. From your own admin console, you will be able to see the process of integrating JumpCloud with O365 in action with your own users, and truly gauge for yourself how it will work for you.
