How authentication works in Active Directory
Learn how Active Directory authentication works to manage identity and access.
Updated November 26, 2025)
Active Directory authentication is the Windows-based system that manages access for users, applications, and other assets to Microsoft's Active Directory.Today, it supports Kerberos and the Lightweight Directory Authentication Protocol (LDAP).
However, Active Directory's manual identity lifecycle management can be challenging for modern organizations with remote employees, and can expand the attack surface.
This guide explains on-premise Active Directory authentication and how UserLock interacts with existing AD authentication processes to support greater security, efficiency, and interoperability.
On-premises Active Directory (AD) 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 centralize user and rights management and to control device and user configurations via AD Group Policy.
Several authentication protocols operate within this infrastructure: LM, NTML, NTMLv2, Kerberos, and LDAP.
Note: On-premises Active Directory authentication is often confused with Microsoft Entra ID authentication. Entra ID uses OpenID Connect, which is outside the scope of this article.
Active Directory IAM
Explore UserLock's straightforward identity and access management for on-prem and hybrid AD environments.
Authentication confirms who a user is, while authorization determines what they can do.
On-premises Active Directory authentication confirms identity. In Active Directory, this typically starts with a username/password combination (Windows credentials) to verify that a user is who they say they are.
Active Directory authorization determines access. Once an identity is confirmed, Active Directory authorizationgrands the authenticated user permission to access specific data and perform specific actions (sometimes shortened to AuthZ). Microsoft uses OAuth 2.0 for this step.
Authentication always precedes authorization. Think of it like airport security: first, your ID is checked (authentication), then you're allowed through (authorization).
Windows NT LAN Manager (NTLM) is a challenge-response authentication protocol used to authenticate a client to the on-premises 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.
Today, NTLM is classfiied as deprecated. It's less secure than more modern protocols, such as Kerberos. It's hashing mechanisms have known weaknesses and it's vulnerable to brute-force and pass-the-hash attacks.
The Kerberos Key Distribution Center (KDC), which runs as part of Active Directory Domain Services (AD DS) on the Domain Controller, issues tickets to authenticated users.
When a user logs in, the client sends a request to the KDC encrypted with the user's password.
If the KDC can decrypt it, it issues a ticket-granting ticket (TGT) which the client uses to present to request access to specific services.
The application server then decrypts the service ticket using its own password hash. If successful, it grants access.
Kerberos is more secure than NTLM but has its own risks. It relies on time synchronization between the client and server. If clocks drift, it becomes vulnerable to replay attacks. And, if attackers compromises the KDC, they can issue fake tickets and gain unauthorized access.
Active Directory uses Lightweight Directory Access Protocol (LDAP) for directory lookups, including intra-directory communication and connections to external applications. It typically works alongside Kerberos.
LDAP supports 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 notable limitations. LDAP traffic is often unencrypted, leaving it exposed to eavesdropping and man-in-the-middle attacks. It also has no native support for multi-factor authentication (MFA).
Credential providers play an important supporting role in Active Directory authentication, especially since Windows 10 and Microsoft Passport expanded their scope to cover authentication for apps, websites, and other system authentication scenarios.
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.
Active Directory gives admins a single location to manage Active Directory user accounts, computers, and resources. From there, they can create, modify, and disable user accounts remotely. They can deploy software and configure multiple computers simultaneously.
AD Domain Services makes managing files, application, and hardware straightforward, lowering the time and overhead of network administration for Active Directory administrative users.
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.
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.
With on-premises Active Directory authentication, authentication stays on-premises. On-premises 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 cybersecurity compliance standards.
On-premises authentication enables direct control and oversight of authentication systems. Organizations can quickly respond to security incidents, implement updates, and enforce policies. The trade-off is upfront investment in servers, hardware, and IT resources.
Take a tour of UserLock
See how to set up a UserLock MFA policy.
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.
As organizations adopt cloud services, Active Directory authentication can struggle to extend to those new environments. Cloud platforms often have their own identity and access management systems.. Ensuring secure, seamless authentication is key to preventing identity security gaps across hybrid environments.
Working around AD's limitations often means layering in multiple third-party tools, leading to directory sprawl. More tools can mean higher costs, more network complexity, and more compatibility issues. Each additional tool often requires separate training and support, adding to the administrative burden.
First, it’s important to note that UserLock is not involved in authenticating users to your on-premises AD. It intervenes only after your AD grants authorization. This allows you to keep using Active Directory as your identity provider, and layer on strong authentication and access controls for more security.
)
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 supports Kerberos authentication protocol in on-premises 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 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 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 strong authentication happens before the Windows session begins.
UserLock’s credential provider also allows you to enable strong two factor authentication 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).
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 identity security and access control to that session, enhancing security without sacrificing usability.
UserLock also allows you to continue using your on-premises Active Directory for authentication, even for access to cloud resources. UserLock SSO combined with MFA maintains a secure on-premises authentication process while embracing the cloud.