Every organization has a well-defined structure that defines employees’ roles and responsibilities in various departments such as sales, marketing, and IT. To effectively use enterprise resources and remain productive, organizations must develop access control measures.
Active Directory (AD) authentication is one such measure you can use to manage users, applications, and other assets within the organization. When deployed, Active Directory authentication can simplify IT administration and enhance the overall security posture of the enterprise. Learn more about AD authentication, how it works, and how JumpCloud can help you improve its operations.
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 single sign-on (SSO) functionality, allowing users only to authenticate once and then seamlessly access any corporate resource in the domain for which they’re authorized. AD authentication is a successor to LAN Manager (LM) and NT LAN Manager (NTLM), protocols which were easily exploitable.
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?
1. 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.
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).
2. 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.
This approach requires the IT teams to reconfigure Linux-based devices to leverage the LDAP’s pluggable authentication module (PAM). Since AD authentication largely focuses on the Kerberos protocol, IT teams must manually manage the entire authentication process.
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.
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 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.
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 is a comprehensive cloud-based directory platform that businesses can leverage to address the shortcomings of AD authentication in heterogeneous IT environments. You can use the JumpCloud Directory Platform to extend AD authentication to virtually all IT resources within the organization. You can also use JumpCloud to extend AD to the cloud or eliminate on-prem DCs entirely.