IS Decisions logo

IS Decisions Blog

How authentication works in Active Directory

Active Directory authentication manages user identities and access within an organization's network. Learn how authentication works in Active Directory, and identify the challenges, and solutions, for organizations moving towards cloud adoption.

Published Jun 18, 2024
Active Directory authentication

Every organization has a structure, usually divided into departments like sales, marketing, and IT. To make sure users stay productive while complying with compliance and privacy regulations, it's essential to control access to enterprise resources. Active Directory authentication is a common way to manage access for users, applications, and other assets.

It simplifies IT administration and improves security. However, Active Directory's manual identity lifecycle management can be challenging for modern companies with remote employees, potentially increasing the attack surface.

This guide explains on-premise Active Directory (AD) authentication and how UserLock layers on top of existing AD authentication processes to achieve greater efficiency, interoperability, and security.

What is Active Directory authentication?

In infrastructure, different authentication protocols verify users and grant access to a domain. To name a few: LM, NTML, NTMLv2, Kerberos, and LDAP.

On-premises Active Directory authentication is a Windows system that authenticates and authorizes users, endpoints, and services to the on-premises Active Directory. IT teams use AD authentication to streamline user/rights management and centralized control over devices/user configurations via AD Group Policy.

Note that on-premises Active Directory authentication, which is what we’re describing above, is often confused with Microsoft Entra ID authentication. Entra ID uses OpenID Connect for authentication, which lies outside the scope of this article.

What’s the difference between Active Directory authentication and authorization?

On-premises Active Directory authentication proves that your on-prem Active Directory identities are who they say they are by verifying their identity. The first step of this is usually achieved through username/password combination (your Windows credentials).

On the other hand, Active Directory authorization grants an authenticated party permission to access something. It specifies allowed data and actions, sometimes shortened to AuthZ. Microsoft uses OAuth 2.0 for authorization — assigning the correct level of access after identity confirmation.

Authentication confirms who a user is, while authorization determines what they can do. Authentication precedes authorization to prevent unauthorized access. It's like showing ID at an airport — first, they authenticate (check information matches), then authorize (let you through).

How does authentication work in on-premise Active Directory?

NTLM protocol

Windows NT LAN Manager (NTLM) is a challenge-response authentication protocol used to authenticate a client to the on-premise Active Directory. NTLM transmits hashed values and encrypted responses to Active Directory, but the password itself is never transmitted directly over the network. The hashed values and encryption make it more difficult for an attacker to intercept and recover the password in cleartext. However, it’s important to note that NTLM is considered less secure than more modern protocols, such as Kerberos, mainly because of vulnerabilities in the hashing mechanisms used and the possibility of brute-force or pass-the-hash attacks.

Kerberos protocol

The Kerberos Key Distribution Center (KDC), part of Active Directory Domain Services (AD DS) on the Domain Controller, issues tickets. When a user logs in, the client requests a ticket from the KDC, encrypting the request with the user's password.

If the KDC can decrypt it with the known user password, it creates a ticket-granting ticket (TGT) encrypted with the user's password and sends it to the client.

The client presents the service ticket to the application server, decrypting it using its password hash. If successful, the server grants access.

However, Kerberos has some security concerns as well. It relies on time synchronization between the client and server, making it vulnerable to replay attacks if the clocks are out of sync. So, if an attacker compromises the KDC, they can issue fake tickets and gain unauthorized access.

LDAP

Active Directory also supports Lightweight Directory Access Protocol (LDAP) for directory lookups, often used with Kerberos. Active Directory employs LDAP for intra-directory communication or connection to apps outside the network.

With LDAP, there are two main authentication mechanisms: simple authentication and the simple authentication and security layer (SASL). Simple authentication involves anonymous, unauthenticated, or name/password approaches — typically using a name/password BIND request to the server.

SASL adds an extra security layer by leveraging another service like Kerberos for authentication. LDAP works by sending a BIND request to the directory server, which then verifies the client's credentials and grants access if successful.

However, LDAP has limitations and security concerns in Active Directory. LDAP traffic is often unencrypted, making it susceptible to eavesdropping and man-in-the-middle attacks. Also, it doesn't support multi-factor authentication (MFA) natively, which can be a security risk.

The role of the credential provider

For logons and other system authentication scenarios, credential providers also play an important role in Active Directory authentication. Since Windows 10 and Microsoft Passport, credential providers have grown more important for authenticating into apps, websites, and more.

The credential provider installed on server applications offers CLI or native API tools to retrieve passwords across platforms like Java, C/C++, and NET. It eliminates hard-coded credentials in apps and scripts.

To prevent credential theft attacks, the credential provider has anti-tampering mechanisms that authenticate applications at runtime. Installed per server, it caches credentials locally for high performance and availability.

Advantages of using on-premises AD authentication

Centralized resources

With Active Directory authentication, admins centrally control Active Directory user account access, computers, and resources. They can also create/modify/disable user accounts remotely, deploy software, configure multiple computers simultaneously, and troubleshoot remotely.

Active Directory administrative users easily manage resources like files, applications, and hardware through AD Domain Services. AD allows managing users, computers, and other resources from one location, simplifying network tracking and maintenance and saving time and resources.

Single point of access

Active Directory authentication provides a single point of management for network resources. It uses single sign-on, allowing access to any domain server resources after one authentication.

Once Active Directory identifies and authenticates a user, it's done. After this process, they sign on once to access authorized network resources per their assigned AD roles and privileges.

AD authentication offers single sign-on (SSO) functionality. Users access multiple resources with one set of credentials. With Active Directory SSO, users authenticate once to gain access to multiple resources, reducing login prompts and streamlining the process. It saves time, improves productivity, and reduces risks like weak/forgotten passwords.

Simplified resource allocation

Active Directory authentication allows publishing files and print resources on the network, simplifying resource allocation. Users securely access network resources by searching the Active Directory database for the desired published object.

Active Directory is highly scalable, supporting thousands of users and devices. As an enterprise grows, Active Directory scales to meet changing organizational needs. It also supports multiple domains and forests, efficiently managing resources across locations and business units.

Authentication stays on-premise

With on-premise Active Directory authentication, authentication stays on-premise. On-premise refers to hosting authentication systems and processes within an organization's infrastructure and deploying and managing authentication servers on-site. Organizations have complete control over their authentication data for customization, tailored security, and regulatory compliance.

On-premise authentication enables direct control and oversight of authentication systems. Organizations can quickly respond to security incidents, implement updates, and enforce policies. However, it requires investing in necessary infrastructure like servers, hardware, and IT resources potentially costlier upfront than cloud authentication.

The challenges of on-premises Active Directory authentication

Linux and Mac compatibility

Active Directory authentication excels as a directory service for Windows environments. However, it doesn't seamlessly integrate with non-Windows platforms like MacOS, Linux, or Unix, which is challenging for heterogeneous IT environments.

Group policies allow admins to control multiple computers and push group instructions. However, admins cannot deploy or enforce AD policies on Mac and Linux devices without third-party tools or custom scripting. These tools often introduce inconsistencies and security gaps.

Active Directory operates on and suits traditional on-premises architecture and Microsoft business applications. It's less suitable for organizations that use cloud-based non-Microsoft solutions and support remote users.

Authenticating cloud access

As organizations adopt cloud services and hybrid environments, Active Directory authentication may face challenges extending capabilities to these new environments. Cloud services often have their own identity and access management systems. Organizations must ensure seamless integration and secure authentication across diverse environments to prevent identity attacks.

Directory sprawl

Active Directory authentication often calls for workarounds, leading IT teams to implement multiple tools. Directory sprawl increases costs, network complexity, and managerial challenges. Compatibility issues may arise when integrating third-party tools with AD and amongst themselves. Directory sprawl requires admins to undergo separate training and support for each tool, adding to the learning curve and overall costs.

How UserLock works with on-premise Active Directory authentication protocols

First, it’s important to note that UserLock is not involved in authenticating users to your on-premise AD. It intervenes only after your AD grants authorization. This allows you to keep using Active Directory as your identity provider, and layer on UserLock’s MFA and access controls for more security.

Active Directory authentication

On the other hand, UserLock does authenticate for certain operations across the network, either as a Network Service (which is the identity of the UserLock service, in line with the principle of least privilege) or with the depersonalization account for specific administration tasks. In both cases, the protocol used will be the one defined by your network, either NTLM or Kerberos.

UserLock and Kerberos in Active Directory

UserLock supports Kerberos authentication protocol in on-premise Active Directory. This is the protocol we recommend, since it’s more secure. There’s a registry key in Microsoft to force Kerberos on the server where UserLock is installed, so you don’t need to set anything directly in UserLock if your network is set up with Kerberos protocol. The software is supported directly in the Windows communication libraries, which will use the protocol authorized in the network.

UserLock and LDAP in Active Directory

UserLock only supports read access to the AD with LDAP. UserLock accesses as the machine account of the UserLock server. Machine accounts have default read access to the AD. And access is only granted to find out the members of groups/OUs, machine names, and user account names.

UserLock and credential provider

Offering a custom credential provider, UserLock integrates seamlessly with the Windows agent and credential provider, providing an experience that's close to native Windows logon. It eliminates the need for a separate UserLock agent, except for enrollment (as of UserLock 12.2).

With this approach, UserLock maintains its non-interference in your Windows logon. But the UserLock credential provider ensures your MFA authentication process happens before the Windows session begins.

UserLock’s credential provider also allows you to prompt for MFA on User Account Control (UAC) prompts displayed during administrative tasks and “run as administrator” so you can add an extra layer of security when your users try to elevate privileges (key to preventing lateral movement).

UserLock and Windows Hello

While not mentioned above, Windows Hello is an authentication technology that allows users to log on to their Windows devices without a traditional password. Instead, they can use biometric data or a PIN. UserLock is compatible with Windows Hello. Using Windows Hello for no-password login, UserLock can seamlessly apply MFA and access control to that session, enhancing security without sacrificing usability.

UserLock SSO and secure access to the cloud

UserLock also allows you to continue using your on-premises Active Directory for authentication, even for access to cloud resources. UserLock's SSO, combined with MFA, maintains a secure on-premise authentication process while embracing the cloud.

Try UserLock for free

3400+ organizations like yours choose UserLock to secure access for Active Directory identities and meet compliance requirements.

Download a free trial