Microsoft and Google have been locked in a battle for the heart of the IT community for years now. This technological arms race has brought about a number of cloud innovations, including in identity and access management (IAM). Both contenders understand that by controlling user identities, they can lock you into their respective ecosystems and sell you additional services. 

In one corner, we have Microsoft Azure Active Directory (AAD), a cloud-based IAM solution for hybrid or cloud-only implementations. In the other corner, we have Google Cloud Identity, a cloud-based solution for managing user identities and access to Google resources. Both organizations seek to control your identities. The interesting problem is that if you are looking to replace your on-prem Active Directory instance or leverage directory services, then neither of these options can provide a solution.
In this article, we’ll compare Google Cloud Identity and Azure Active Directory, before explaining why neither is the best replacement for on-prem solutions.

What is Google Cloud Identity?

If you have ever used Google Workspace, you’re already familiar with Google cloud identities. Google identity management services enable users to connect to various applications and platforms delivered through Google. Google identity management allows for easy integrations to Google’s catalog of SaaS services and SSO applications but it does not offer support for legacy applications or on-prem resources. It also offers some authentication services via OAuth and SAML. An organization’s systems, on-prem applications, and network are outside of the scope of G Suite directory.

Unfortunately, this means that a lot of users will remain locked into their on-prem identity provider instance, namely Active Directory. While Google IDaaS is an excellent cloud user management system for Google Workspace, it is not a stand alone cloud-delivered directory service.

What is Azure Active Directory?

Microsoft’s version of the user management system is called Azure Active Directory (also called AAD, or Azure AD). The name confuses many people, because it makes it seem like Microsoft has moved their on-prem directory to the cloud. But that’s not the case. 

Rather, Azure AD works on top of Active Directory to provide single sign-on (SSO) access to a variety of SaaS applications like Office 365, Salesforce, DropBox, and many others. In essence, it is designed as a bridge between your existing legacy Active Directory instance and Microsoft’s catalog of compatible cloud-delivered services. While it is possible to sync your Active Directory instance with Azure AD, in of itself Azure AD is not a complete cloud-based directory service.

This is because Azure AD does not act as the authoritative source of truth of user identities (unless you are just using Office 365 or Azure resources). This role is still within the domain of Active Directory for many organizations, thus requiring traditional on-prem devices and dedicated IT staff to create and maintain. While Azure AD is meant to be a cloud identity platform, unfortunately, the true source of identity management is still firmly grounded with the legacy directory service, Active Directory.

The Problem with Google Cloud Identity and AAD 

As hinted above, the most glaring weakness of both of these platforms is that neither can truly function as the core identity provider for an organization. Instead, they’re user management systems designed only for their respective platforms.

Google Cloud Identity only organizes identities for Google Workspace and other Google cloud-hosted applications. It isn’t designed to be used for on-prem systems, AWS cloud servers, Azure, Office 365, and a wide range of other web and on-prem applications and networks. 

Azure Active Directory isn’t an Active Directory replacement, either. It’s a user management system for Azure, Office 365, and a web application SSO platform. If you want a core directory service, you won’t find it with either Google Cloud Identity or Azure Active Directory.

Instead, both of these platforms leave it to the IT department to figure out how to build a central, authoritative directory service for the organization. Having multiple user management platforms can create a significant amount of work and a great deal of security risk. 

Thankfully, there’s a better solution. An open directory platform can be your single authoritative source for user identities and authentication – across all platforms and operating systems. 

Open Directory Platform – the best Active Directory Replacement 

A new generation of cloud identity management is here. This independent solution, called an open directory platform, doesn’t rely on a single vendor, but works across platforms and operating systems to support authentication on Windows, Mac, Linux, Google Workspace, and more – all from the cloud, all at the same time. 

JumpCloud’s open directory platform provides the stability and authentication of Azure Active Directory and the flexibility and cloud nativity of Google workspace. You’ll also get many features, like SSO, multi-factor authentication (MFA), and password management you typically have to get from a third-party provider. 

Ready to learn more about why JumpCloud is the best replacement for active directory? Drop us a note to get a live demo, or sign up for your free account today.

JumpCloud delivers single sign-on (SSO) to everything, including RADIUS authentication and authorization for network devices. Multi-factor authentication (MFA) is environment wide, delivering Push MFA for RADIUS. RADIUS is a core network protocol that’s widely used for Wi-Fi authentication, and it provides authentication, authorization, and accounting (AAA). 

JumpCloud Cloud RADIUS simplifies and secures privileged administrative access for network admins. It’s also an option to configure access to LANs for all of your SSL VPN users. JumpCloud eliminates the need to use Fortinet’s FortiTokens for MFA.

This two-part blog series explores two use cases with FortiGate next-generation firewall:

• Option 1: Use existing local FortiGate groups that contain FortiGate remote users. This approach is ideal for existing appliances that already have settings and users.
• Option 2: Use remote groups (JumpCloud) and attribute mapping to set up access control on a new Fortinet device. This approach spares admins the work of having to establish local groups using ACLs on the Fortinet appliance.

This article focuses on Option 1.

We’ll demonstrate how to bind the local user to the JumpCloud RADIUS server that is configured inside your FortiGate so that JumpCloud becomes the authentication authority without changing anything in the way the appliance is configured for network posture. 

Note: It’s also possible to accomplish this using a different brand of network appliance.

Configuring JumpCloud RADIUS and Groups

Follow this guide to get started with JumpCloud groups. You may also refer back to this previous tutorial on how to configure SAML access for Fortinet devices if it better suits your requirements. However, RADIUS has the advantage of also mapping groups and authorizations/permissions.

Establishing Groups and MFA

You may have MFA required for individual users or leverage groups with conditional access. Skip this step if you’ve already configured your access control policies.

To require MFA factors for the User Portal on an individual user account:

1. Edit a user or create a new user in the Admin Portal. See Getting Started: Users.
2. In the User Security Settings and Permissions section, select Require Multi-Factor Authentication for User Portal option. Note: The enrollment period only affects TOTP MFA. See Considerations. 
3. Click save user.

To require MFA factors for the User Portal on existing users from the more actions menu:

1. Select any users you want to require MFA for.
2. Click more actions, then select Require MFA on User Portal.
3. Specify the number of days the user has to enroll in MFA before they are required to have MFA at login. You can specify a number of days between 1 and 365. The default value is 7 days.
4. Click require to add this requirement to the selected users.

To require MFA factors with a Conditional Access Policy: 

1. Log in to the Admin Portal: https://console.jumpcloud.com/. 
2. Go to SECURITY MANAGEMENT > Conditional Policies. 
3. Click (+). 
4. Enter a unique Policy Name.
5. Optionally, enter a description for the policy.
6. If you don’t want the policy to take effect right away, toggle the Policy Status to OFF and finish the rest of the configuration. When you’re ready to apply the policy, you can toggle the Policy Status to ON. 
7. For users, choose one of the following options:
   • Select All Users if you want the policy to apply to all users. 
   • Select Selected User Groups if you want the policy to apply to specific user groups, then search for those user groups and select them. If you need to create user groups, see Getting Started: Groups. 
   • If there are User Groups you want to exclude from the policy, search for the user groups and select them in the search bar under Excluded User Groups.
8. Optionally, set the conditions a user needs to meet. Note: Conditions is a premium feature available in the Platform Plus plan. Learn more about conditions in Getting Started: Conditional Access Policies. 
9. In Action, select Allow authentication into selected resources, then select the Require MFA option. 
10. Click create policy. 

Two JumpCloud groups were created for the purpose of this tutorial:

• RADIUS-FortiGate_VPN_Users
• RADIUS-FortiGate_Admins

Setting Up RADIUS

Create a RADIUS server in JumpCloud:

1. Log in to the JumpCloud Admin Portal: https://console.jumpcloud.com/login.
2. Go to RADIUS.
3. Click (+). The new RADIUS server panel appears.
4. Configure the RADIUS server:
   • Enter a name for the server. This value is arbitrary.
   • Enter a public IP address from which your organization’s traffic will originate.
   • Provide a shared secret. This value is shared with the device or service endpoint you’re pairing with the RADIUS server.
5. Select an identity provider.

Now select an authentication method:

• To use certificate authentication, select Passwordless.
  • Once Passwordless has been selected, the Save button will be disabled until a certificate has been successfully uploaded (or the authentication method has been changed back to Password).
• If desired, select Allow password authentication as an alternative method.
  • If this checkbox is selected, admins can enable certificates for some users while allowing others to continue validating by username and password. Users will continue to have the option to validate by username and password, but once they choose to validate with certificates and a valid certificate is found, the password option will no longer be presented.
  • The MFA Configuration section will be available if using JumpCloud as the identity provider, and Passwordless is selected as the Authentication Method, and the Allow password authentication as an alternative method checkbox is selected.
• Configuring multi-factor authentication (MFA).
  • ​​Toggle the MFA Requirement option to “enabled” for this server. This option is disabled by default.
  • Select Require MFA on all users or Only require MFA on users enrolled in MFA.
    • If selecting Require MFA on all users, a sub-bullet allows for excluding users in a TOTP enrollment period, but this does not apply to JumpCloud Protect™ (users in a TOTP enrollment period who are successfully enrolled in Protect will still be required to complete MFA).
    • If JumpCloud Protect is not yet enabled, users can select the Enable Now link.
• Uploading a Certificate Authority (CA).
  • To upload your certificate, click on the Choose a File button, navigate to the file location, and select it for uploading.
  • Once the file has uploaded successfully the file name will display on the screen and options will change to replacing or deleting the file. There is also an option to view the full CA chain.
  • Clicking Save will return the user to the main RADIUS screen, where the Certificate badge will display in the Primary Authentication column.
    Note: For more information about where and how to find trusted certificates outside of JumpCloud, see RADIUS-CBA Tools for BYO Certificates.

Select Users for Access to the RADIUS Server (User Groups tab):

• To grant access to the RADIUS server, click the User Groups tab then select the appropriate groups of users you want to connect to the server.
  • Every user who is active in that group will be granted access.
• ​​​​​​​Click save.

Note: Users who are being granted access to a RADIUS server and leveraging delegated authentication (with Azure AD as their identity provider) must be imported into JumpCloud and assigned to a User Group.

FortiGate Settings

Follow these instructions to configure the RADIUS server(s) in your FortiGate appliance. Next, we’ll make it possible for your existing users to use JumpCloud’s identity and access management (IAM).

Local Groups with Remote Users

You may enter more than one JumpCloud RADIUS server IP for redundancy. The next section uses the FortiGate command line interface (CLI) to convert your existing local users into RADIUS users. Then, you’ll match the usernames with the respective JumpCloud usernames. Significantly, there will be no changes made from an access control list (ACL) perspective. Yet, you’ll increase your network security and easily meet compliance requirements. The steps are simple, and will spare a small and medium-sized enterprise (SME) the time and expense of allocating/billing blocks of hours with a network technician or MSP partner.

Converting Local Users Into RADIUS Users

The first step is to launch your CLI to convert users that already exist in FortiGate. 

This may be scripted to streamline the process for a group of users. The steps include:

# config user local
(local # edit “USER NAME”
# show
# set type radius
# set radius-server YOUR SERVER
# end

Checking Your Work

You may verify these settings by entering:

# config user local
(local) # edit USER NAME
# show
# end

Ensure that the user is a member of the corresponding RADIUS group in JumpCloud with the exact same user name as on your appliance. JumpCloud now controls authentication, including enabling MFA without having to engage with FortiTokens or a third-party MFA solution.

This is an example of an existing FortiGate user:

Reporting

JumpCloud’s Directory Insights captures and logs RADIUS authentications. It makes it possible to determine which user is attempting to access your resources and whether it was successful. Directory Insights is useful for debugging and testing your RADIUS configuration deployments.

Try JumpCloud RADIUS

JumpCloud’s full platform is free for 10 users and devices with premium chat support for the first 10 days to get your started. The open directory platform provides SSO to everything:

• SAML
• OIDC/OAUTH
• LDAP
• RADIUS

Attribute-based group access control, mobile device management (MDM), commands, and GPO-like policies are included in the platform for advanced identity lifecycle management. JumpCloud also features integrated remote assistance, reporting, and an optional password manager and cross-OS patch management. The directory platform works across Android (soon), Apple, Linux, and Windows devices, managing identities wherever the user is.

Need a Helping Hand? Reach out to professionalservices@jumpcloud.com for assistance to determine which Professional Service option might be right for you.

They used Word for word processing, Excel for spreadsheet work, PowerPoint for presentations, and Active Directory for domain management. However, the old paradigm has been shifting for some time now.

While Windows-based PCs and laptops are still the market leaders for large and small-to-medium-sized enterprises (SMEs), many organizations have begun to adopt Mac, Linux, and Android devices. Improved usability, convenience, and affordability are commonly cited reasons for switching.

Translation: administrators must manage and control access to their Azure Active Directory from different types of devices and operating systems.

So, can you bind a Mac to Azure Active Directory?

Let’s find out.

Mac and Azure AD: Unwilling Bedfellows

The short answer is yes — you can bind Mac to Azure. But as you can imagine, it is far from straightforward.

Competitors hardly find incentives to make life easy for each other. Think of Pepsi and Coke’s cola wars or Nike and Adidas’ sportswear battles; they’ve been at it for decades. Apple and Microsoft are no different.

With Microsoft’s Azure being a leading access management solution, many IT managers have found themselves being the grass that suffers the pinch between the giant boots of these two tech giants.

Since its release in 2000, Active Directory (AD) has been a staple for Windows networks. It provides users and IT admins with identity management, access control, and policy enforcement for Windows servers, desktops, and laptops.

Azure Active Directory (AAD) is Microsoft’s cloud-based version of its traditional on-premise Active Directory service. It allows businesses to securely access their applications and resources from anywhere on their windows device.

However, the problem arises when it comes to Apple’s Macs. While Microsoft has done an excellent job of making Windows computers compatible with AAD, the same cannot be said for Mac users.

The Challenge of Binding Macs to Azure AD

The challenge of binding Macs to Azure Active Directory is twofold:

1. No thanks to the Apple-Microsoft rivalry, there is no native integration between Macs and AAD.

2. Even when workaround solutions exist, ensuring a seamless user experience can also take time and effort.

For example, some admins have taken a cobbled approach of creating a domain within Azure using the Azure AD Domain Services (AD DS) before setting up a VPN connection between their Macs and the Azure domain. The problem, however, is that this solution is complicated and even discouraged by Microsoft.

Others, which already utilize Active Directory, can choose to implement an on-prem directory extension. However, this presents a new set of challenges, from extra costs to more infrastructure to manage.

In addition, this doesn’t enable direct Mac integration into Azure AD. Instead, admins are left with a non-future-proof method of managing endpoints.

The Solution: Step Out of Platforms And Into Identity

A better approach that IT admins take to resolve this problem is to think away from platforms and into identity.

Rather than relying on a cobbled solution that requires managing multiple directories or on-prem extensions, cloud identity management solutions such as the JumpCloud Directory Platform provide a single-user directory that can manage all users’ access to the network and other applications from one central platform.

This solution enables admins to bind not only Macs but also Windows, Linux, and other devices to Azure Active Directory in an intuitive and hassle-free manner. With JumpCloud, admins can securely manage users’ AAD access, regardless of their device or platform.

Also, IT teams that leverage other cloud-computing platforms, such as Amazon’s AWS, or Google Workspace, needn’t worry about managing different identities.

Users can access every network or resource with a single identity, such as Wi-Fi, VPN, web applications, legacy LDAP application, and on-prem or cloud-based file storage solutions. This configuration creates a true single sign-on (SSO) experience for users, making it more convenient and secure.

Manage Identity with the JumpCloud Directory Platform

JumpCloud provides an all-in-one solution for IT admins to bind Macs to Azure Active Directory without any of the earlier-mentioned problems. It’s an identity provider that delivers secure, cloud-based access services to users regardless of their devices.

The platform streamlines user experiences with SSO while unifying admin tools for mobile device management (MDM), multi-factor authentication (MFA), and compliance controls behind one pane of glass. Want to get a better handle on your heterogeneous environment? Watch our demo video and sign up for a free trial today.