Updated on November 14, 2024
Every organization has an organizational structure to define employees’ roles and responsibilities; it’s often broken down by departments such as sales, marketing, and IT. It’s usually necessary to enforce access control for enterprise resources so that users remain productive while meeting your compliance and data privacy obligations.
Active Directory (AD) authentication is one such measure you can use to manage users, applications, and other assets within the organization. AD authentication can simplify IT administration and enhance the overall security posture of the enterprise. However, it can fall short in modern enterprises where employees are located in many different places and its identity lifecycle management is a manual process that can increase the attack surface.
This article is intended to help you learn more about AD authentication, how it works, and how JumpCloud can help you modernize its operations for greater efficiency, interoperability, and security.
What Is Active Directory Authentication?
AD authentication is a Windows-based system that authenticates and authorizes users, endpoints, and services to Active Directory. IT teams can use AD authentication to streamline user and rights management while achieving centralized control over devices and user configurations through the AD Group Policy feature.
It also provides limited single sign-on (SSO) functionality, allowing users only to authenticate once and then seamlessly access any corporate resource in the domain(s) for which they’re authorized. AD authentication is a successor to LAN Manager (LM) and NT LAN Manager (NTLM), protocols which were easily exploitable.
Microsoft is in the process of deprecating NTLM. It provides admins with tools to block and track it as it makes the transition to Kerberos as its de facto authentication process.
For example, LM used a fragile cryptographic scheme that modern processors could easily crack. Although NTLM — which succeeded LM — had some security enhancements around the strength of cryptography, it couldn’t provide mutual authentication and smart card authentication services. Due to these weaknesses, Microsoft replaced LM and NTLM protocols with AD starting with Windows 2000 Server operating systems (OSs).
How Does Authentication Work in Active Directory?
Active Directory authentication is a process that supports two standards: Kerberos and Lightweight Directory Access Protocol (LDAP).
Kerberos Protocol
In a Kerberos-based AD authentication, users only log in once to gain access to enterprise resources. Instead of passing on the login credentials over the network, as is the case with LM and NTLM protocols, the Kerberos system generates a session key for the user. The generated session key lasts for a designated period, providing flexibility to users when it comes to authentication.
How Kerberos Works
Besides the session key, the Kerberos system also generates a token containing all the access policies and rights associated with the user. This ensures that users only access resources they are authorized to.
If a client wants to connect to the AD server or the domain controller (DC) in this case, they must authenticate themselves to a key distribution center (KDC), which is a trusted third party. The KDC consists of two servers: authentication server (AS) and ticket granting server (TGS). The AS encrypts clients’ login credentials by using their password’s secret key. This is how the AS authenticates clients to the network.
After getting authenticated, the AS sends the user a ticket granting ticket (TGT), which is encrypted with a different secret key. When the client receives the TGT, it transmits it to the TGS alongside an authorization request to access the target resource on the server. The TGS then decrypts the TGT with its secret key that it shares with the AS.
Next, the TGS issues a token to the client that it encrypts with another key. The third secret key is shared between the target server and TGS. Finally, the client transmits the received token to the target server. When the target server receives the token, it decrypts it with the TGS shared key to allow the client to access resources for a limited time (session).
Security Concerns
Kerberos is vulnerable to several known methods of attack, including Kerberoasting, Golden Tickets, Pass the Ticket, et al. For this reason, Microsoft has prescribed several Entra ID and Defender services to protect identities and detect lateral movement throughout its stack.
Note: Microsoft has deemed AD to be a legacy product that must be protected and secured.
Lightweight Directory Access Protocol
LDAP is an open source and cross-platform protocol that provides AD authentication services. There are two options associated with LDAP-based authentication in AD:
- Simple authentication. In simple authentication, LDAP relies on login credentials to create a request to the server. It also supports anonymous and unauthenticated requests to corporate resources.
Simple authentication and security layer (SASL). The SASL approach uses other authentication services such as Kerberos to connect to the LDAP server. IT teams can use this method to enhance security because it separates authentication methods from application protocols.
Authenticating Linux Devices Through Active Directory
AD works seamlessly with Windows-based systems and services. While Windows may have dominated the OS market share in the 1990s, the same is not true today. Linux and macOS are now integral components in any IT infrastructure. As companies continue to leverage different OSs, the pressure to provide centralized access management becomes real.
There are two primary methods you can leverage to connect Linux-based devices to AD.
LDAP
This approach requires IT teams to reconfigure Linux-based devices to leverage LDAP’s pluggable authentication module (PAM). Since AD authentication largely focuses on the Kerberos protocol, IT teams must manually manage the entire authentication process.
Samba
This is a standard Windows interoperability tool for Linux systems. IT teams can use Samba as an intermediary to support AD authentication in Linux machines. For example, IT teams can use the service to create domains, set up a shared print server, and configure PAM to allow users to authenticate to locally installed services.
Note: Microsoft has also introduced the Windows Subsystem for Linux (WSL) to improve interoperability and developer productivity.
Authenticating Macs Through Active Directory
IT teams can use an LDAP and AD connector to configure Macs to access basic account details in AD DS (Active Directory Domain Services) infrastructures. These tools allow IT teams to leverage AD authentication to allow users to access corporate resources from their Macs when deployed. AD connector can also provide federated SSO by mapping AD identities to macOS identity and access management (IAM) roles.
Note: Microsoft’s preferred method is cloud device and identity management.
For example, the AD connector can generate all the attributes needed to authenticate macOS devices to AD infrastructure. However, machines with macOS 10.12 or later cannot join an AD domain without domain services of at least Windows Server 2008. To use AD on such devices, IT teams must enable weak cryptography, which jeopardizes the organization’s security.
Shortcomings of Active Directory Authentication
In the 1990s and early 2000s, most device management tools and systems were largely driven by on-prem Windows OSs, and AD authentication worked well with such IT environments. However, today’s OS landscape has increasingly become heterogeneous, with Linux and macOS platforms emerging on the scene as well as cloud-based infrastructure.
Consequently, providing access controls and management in a heterogeneous IT environment has become a headache for IT teams in organizations. While legacy AD authentication can address IAM, it is far from efficient. In most cases, IT teams have been forced to use LDAP to authenticate Linux and macOS devices to AD, which creates an added layer to integrate and manage.
Essentially, organizations end up with multiple “mini directories” rather than one centralized and authoritative directory platform to offer authentication and authorization services. Besides heterogeneous OSs, the adoption rate for software-as-a-service (SaaS) applications and other cloud-based services has been dramatic in recent years.
This adoption comes with its own fair share of challenges in the IAM landscape. For example, most SaaS applications tend to be siloed, which complicates their management from an authorization perspective. Also, onboarding users in a SaaS-first environment is time-consuming and tedious because it involves users across multiple departments.
Leverage JumpCloud Directory to Extend Active Directory Authentication in Heterogeneous IT Environments
JumpCloud’s Open Directory Platform provides a smooth path to migrate off or modernize AD, once you’ve succeeded in aligning IT’s and management’s interests. Active Directory Integration (ADI) has configuration options that will enable you to determine where and how you want to manage users, groups, and passwords. It also provides a migration tool to transfer identities.
Cross-OS device management is a critical component to control and protect modern IT infrastructures. JumpCloud pairs the ability to manage every endpoint with an open directory platform to secure every identity and resource. This unified approach delivers strong access control while consolidating your tools for increased IT operational efficiency.
Try JumpCloud for free and find out if it’s the right option for your organization’s journey away from AD.
Our customers tell us that asset management is also important for security and IT operations. JumpCloud is enhancing its platform to unify SaaS, IT security, and asset management.
Learn more about how admins will be able to consolidate security, asset, device, access, and identity management with JumpCloud and how those features go hand in hand.