Share This Article
Azure® Active Directory® (Azure AD or AAD) has been a popular identity management tool used among IT admins since its introduction. As a useful resource for bridging Azure credentials to select pre-integrated applications, Azure AD’s authentication protocols provide value for IT admins looking to allow their Azure users to employ single sign-on (SSO) for a number of applications.
Below, we’ll discuss Azure AD’s native authentication capabilities, as well as options for admins looking to connect AAD users to additional resources.
Breaking Up with Active Directory
Don’t let your directory hold you back. Learn why it’s time to break up with AD.
Using Azure AD For Authentication
Authentication is the process of making sure users are who they say they are, which is vital for protecting sensitive information contained within IT resources.
Natively, AAD authenticates Azure user credentials to Windows® 10 Pro devices and select web apps via SAML 2.0, OpenID Connect, OAuth 2.0, and WS-Federation. IT teams seeking a tool for connecting Azure users to applications like Office 365™ may find great value in Azure AD’s native capabilities. However, cloud-forward organizations looking to implement a single cloud IdP for connecting users to their systems, networks, applications, and files may require additional solutions.
Authenticating to All IT Infrastructure
Azure Active Directory was originally designed as a complementary service to on-prem Active Directory. As such, for admins wanting to use Azure AD as a cloud-based directory service, AAD may lack key features.
Though it is a useful solution for integrating Azure credentials with certain apps, AAD’s list of available authentication protocols often leave IT teams searching for other solutions for authenticating their infrastructure. Azure AD struggles to intrinsically authenticate users to systems beyond Windows 10 Pro. These include other Windows systems, macOS® machines, and Linux® servers hosted in AWS®.
In addition, IT admins who want to use Azure AD for network authentication will have to implement and configure their own FreeRADIUS server (or RADIUS compatible solution) that syncs with Azure AD. This is usually done via a managed LDAP domain in Azure AD Domain Services (Azure AD DS).
Azure AD also requires additional support for authentication to legacy applications via LDAP. To achieve LDAP connectivity, IT teams can enable an Azure AD DS instance (note, this is a separate solution that requires additional costs) with configured network security groups through Azure Networking. However, since this LDAP traffic isn’t encrypted by default admins must manually configure these ports. The lack of automation can leave organizations open to human error, making them vulnerable to cyberthreats such as brute force attacks.
Overall, IT teams can manually configure and implement additional solutions to make Azure AD work as a core identity provider, but this process can be intensive on an admin’s time and budget. For organizations seeking a cloud-hosted solution that natively authenticates to heterogeneous systems, cloud and on-prem applications, wired and WiFi networks, and file servers, there may be a solution beyond Azure AD.
JumpCloud Directory-as-a-Service
JumpCloud® Directory-as-a-Service® is the first directory service that authenticates users to nearly all their resources via entirely cloud-based SAML 2.0, LDAP, and RADIUS. By using the DaaS portal, IT admins can use built-in tools like PowerShell to enact automated user provisioning and deprovisioning, ensuring that directory services in the cloud are scalable and secured.
And, through Office365 Integration, organizations can keep Azure AD as an authentication resource and integrate it with JumpCloud, effectively providing organizations with an entirely cloud-based identity and access management suite.
Interested in learning more? Check out our product page to learn more about our core features, or register for a personalized demo to see DaaS in action.
