Glossary > Active Directory Authentication
What is Active Directory Authentication?
In infrastructure, different authentication protocols are being used (e.g., LM, NTML, NTMLv2, Kerberos, LDAP) to verify users and grant them access to a domain.
Microsoft® Active Directory (AD) supports both Kerberos and the Lightweight Directory Access Protocol (LDAP). Kerberos is an open standard and provides interoperability with other systems, which use the same standard. The protocol offers strong authentication for clients and servers using secret-key cryptography. Instead of transmitting the user’s actual password over the network, Kerberos utilizes tickets.
Tickets are issued by the Kerberos Key Distribution (KDC), which runs on the Domain Controller as part of Active Directory Domain Services (AD DS). When a user logs in to a system, the client requests a ticket for the user from the Key Distribution Center, leveraging the user’s password to encrypt the request. If the Kerberos Key Distribution can decrypt the request with the user’s password—which it knows—it then creates a ticket-granting ticket (TGT) for the user. The ticket-granting ticket encrypts the ticket with the user’s password and sends it back to the client.
If the client can decrypt the ticket with the password it has, it knows the Key Distribution Center is legitimate. A client requests a ticket for a service from the Key Distribution Center by presenting its ticket-granting ticket and a ticket-granting service (TGS) request that includes the name of the service it would like access to.
The Key Distribution Center then creates a service ticket encrypted with the service’s password hash, then encrypts the ticket and authenticator message with the shared ticket-granting service session key before finally sending it back to the client. The client subsequently requests access to the service by presenting the service ticket it obtained from the Key Distribution Center to the application server, which decrypts the message using its own password hash. If successful, the application server grants access to the client.
Active Directory also supports the Lightweight Directory Access Protocol for directory lookups, and it is not uncommon for it to be used in conjunction with Kerberos. In essence, Lightweight Directory Access Protocol allows systems and applications to talk to directory services such as Active Directory. When utilizing Lightweight Directory Access Protocol, there are two overarching mechanisms: simple authentication as well as the simple authentication and security layer (SASL).
The simple authentication method involves three approaches: anonymous authentication, unauthenticated authentication, and name/password authentication. Typically, simple authentication means a name and password are used to create a BIND request to the server for authentication. The simple authentication and security layer framework leverages another service—like Kerberos—to add another security layer to the authentication process.
Active Directory is a critical part of IT infrastructure. Without a proper approach to access, threat actors can put the entire IT environment at risk.
- Console
- Support
- Developers
- Partners
- redhat.com
- Start a trial
Contact us
Welcome, Log in to your Red Hat account Log in Your Red Hat account gives you access to your member profile and preferences, and the following services based on your customer status:
Register now
Not registered yet? Here are a few reasons why you should be:
- Browse Knowledgebase articles, manage support cases and subscriptions, download updates, and more from one place.
- View users in your organization, and edit their account information, preferences, and permissions.
- Manage your Red Hat certifications, view exam history, and download certification-related logos and documents.
For your security, if you're on a public computer and have finished using your Red Hat services, please be sure to log out.
Log out
Account Log in- Topics
- Understanding IT security
- What is lightweight directory access protocol (LDAP) authentication?
Overview
Lightweight directory access protocol (LDAP) is a protocol that helps users find data about organizations, persons, and more. LDAP has two main goals: to store data in the LDAP directory and authenticate users to access the directory. It also provides the communication language that applications require to send and receive information from directory services. A directory service provides access to where information on organizations, individuals, and other data is located within a network.
The most common LDAP use case is providing a central location for accessing and managing directory services. LDAP enables organizations to store, manage, and secure information about the organization, its users, and assets–like usernames and passwords. This helps simplify storage access by providing a hierarchical structure of information, and it can be critical for corporations as they grow and acquire more user data and assets.
LDAP also functions as an identity and access management (IAM) solution that targets user authentication, including support for Kerberos and single sign-on (SSO), Simple Authentication Security Layer (SASL), and Secure Sockets Layer (SSL).
LDAP v.s. Active Directory
LDAP is the core protocol used in–but not exclusive to–Microsoft’s Active Directory (AD) directory service, a large directory service database that contains information spanning every user account in a network. More specifically, LDAP is a lightweight version of Directory Access Protocol (DAP) and provides a central location for accessing and managing directory services running on the Transmission Control Protocol/Internet Protocol (TCP/IP). The most recent version is LDAPv3.
AD provides the authentication and management of users and groups, and it is what ultimately authenticates a user or computer. The database contains a higher volume of attributes than what is pulled into LDAP. However, LDAP specializes in finding a directory object with little information, so it doesn’t need to extract all of its attributes from AD, or whichever directory service it is pulling from.
The main goal of LDAP is to communicate with, store, and extract objects (i.e. domains, users, groups, etc.) from AD into a usable format for its own directory, located on the LDAP server.
Think of it this way: AD is the largest library in the world, and you’re looking for a book with a title that mentions zombies. In the world of LDAP, the details of whether or not the book was published in the U.S., contains over 1,000 pages, or is a how-to guide on surviving the zombie apocalypse don’t matter–although they do help narrow down the options available. LDAP is the experienced librarian who knows exactly where to find all of the options that satisfy your request and verify you’ve found what you’re looking for.
LDAP authentication process
What prompts an LDAP search, and how does it work?
The LDAP authentication process is a client-server model of authentication, and it consists of these key players:
Directory System Agent (DSA): a server running the LDAP on its network
Directory User Agent (DUA): accesses DSAs as a client (ex. a user’s PC)
DN: the distinguished name, which contains a path through the directory information tree (DIT) for LDAP to navigate through (ex. cn=Susan, ou=users, o=Company)
Relative Distinguished Name (RDN): each component in the path within the DN (ex. cn=Susan)
Application Programming Interface (API): lets your product or service communicate with other products and services without having to know how they’re implemented
The process starts when a user tries to access an LDAP-enabled client program, like a business email application, on their PC. With LDAPv3, users will go through one of two possible user authentication methods: simple authentication, like SSO with login credentials, or SASL authentication, which binds the LDAP server to a program like Kerberos. The login attempt sends a request to authenticate the DN assigned to the user. The DN is sent through the client API or service that launches the DSA.
The client automatically binds to the DSA, and LDAP uses the DN to search for the matching object or set of objects against the records in the LDAP database. The RDNs in the DN are very important at this stage, as they provide each step in LDAP’s search through the DIT to find the individual. If the path is missing a connecting RDN on the backend, the result could turn up as invalid. In this case, the object LDAP is searching for is the individual user account (cn=Susan), and it can only validate the user if the account in the directory has the matching uid and userPassword. User groups are also identified as objects within the LDAP directory.
Once the user receives a response (valid or not valid), the client unbinds from the LDAP server. Authenticated users are then able to access the API and its services, including necessary files, user information, and other application data, based on the permissions granted by the system administrator.
Understanding LDAP components
LDAP’s lightweight structure and use of a DIT make it possible to quickly run an LDAP search and successfully provide results. Understanding the DIT is vital to successfully navigating an LDAP server and understanding how the LDAP searches work.
The DIT makes it possible to quickly navigate through the different levels of the LDAP directory to narrow down search results and provide a response to a query. The DIT starts at the root directory, followed by countries, which then branches out to two subclasses: the Domain Component (dc) and Organization Name (o).
Domain Access Component (dc)
The dc (i.e. dc=com, dc=example) uses domain name system (DNS) mapping to locate Internet domain names and translate them into IP addresses.
Most users don’t know the domain name and/or IP address of the individual they’re searching for. In this case, LDAP uses the Distinguished Name (DN) assigned to the user as a path to quickly navigate through the DIT and find the search result. This is where the o subclass comes in.
Organization Name (o)
The o subclass (ex. o-Company) is one of the most general subclasses listed in the DN, and it is usually where LDAP starts when it runs a search. For example, a simple path usually starts with the o subclass, branching off to the Organizational Unit (ou), followed by a user account or group.
Organizational Unit (ou)
As previously mentioned, the ou is a subclass of o and is often seen as ou=users or ou=group, with each containing a list of user accounts or groups. Here’s how this might look in a directory:
o-Company
ou=groups
cn=developers
ou=users
cn=Susan
Common name (cn)
A common name, or cn, is used to identify the name of a group or individual user account (ex. cn=developers, cn=Susan). A user can belong to a group, so if Susan is a developer, they could also live under cn=developers.
Attributes and values
Each subclass in the LDAP DIT (i.e. o, ou, cn) contains attributes and values, or schema that contains information on a LDAP directory’s structure that can help narrow down a search. Attributes are similar to what you would find in an address book entry, with labels like name, phone number, and address, and there are values assigned to each attribute. For example, Susan would be the value of the name attribute.
In the cn=Susan account, user id (uid) and userPassword are attributes and a user’s login credentials are the values. However, in a group like cn=developers, Susan would have the uniqueMember attribute (ex. uniqueMember=cn-Susan,ou-Users,o-Company). This maps a path to where Susan’s individual user account is located, along with the information LDAP is searching for. A user account is the end of the line in the DIT, and it is where LDAP ultimately extracts the results of the search.
There are many other attribute types and syntaxes that can help narrow down a search, including ObjectClasses, like organizationalPerson (structural) or personal (structural). However, the number of attributes on LDAP is limited in order to keep it lightweight and easy to use.
Why LDAP?
Enterprise network admins are typically managing thousands of users at a time. This means they are responsible for assigning access controls and policies based on a user’s role and access to files for everyday tasks, like a company intranet.
LDAP simplifies the user management process, saves network admins valuable time, and centralizes the authentication process. Before integrating LDAP into your environment, it’s important to consider the following:
Capacity: how much user management data do you need to store? Consider if products that implement LDAP solutions have the capacity to store and manage all the data you need.
Search frequency: are there pieces of data that a user needs to access daily, like a company intranet, email application or service? If so, LDAP may be for you.
Organization: will the simple DIT in LDAP provide enough organization for your data, or do you need a more detailed system?
While LDAP is commonly used in AD, it can also be used to authenticate users for other tools and client environments, including Red Hat Directory Servers on UNIX, and OpenLDAP, an open source application, on Windows. You can also take advantage of LDAP’s authentication and user management capabilities for API management, role-based access control (RBAC), or other applications and services like Docker and Kubernetes.
LDAP authentication with Red Hat Enterprise Linux
Red Hat® Enterprise Linux® includes centralized identity management capabilities that allow you to authenticate users and implement RBAC using a single, scalable interface that spans your entire datacenter.
Identity management with Red Hat Enterprise Linux includes a range of authentication and authorization capabilities, including:
Domain controller for Linux: Centrally manage identities, access, and policies for all users, services, and hosts within this trusted and centralized identity store. This helps reduce administrative overhead and simplifies domain registration to create a trusted security boundary. Users get a streamlined user authentication experience.
AD integration: Bridge the user identity gap between Linux and Windows with the native Red Hat Enterprise Linux integration with Active Directory. Use Active Directory as a single source of truth for user identities and apply tailored access control policies directly to the Linux domain to improve administrative efficiency and centralize where policies are created.
Kerberos SSO: Simplify the user authentication process using Kerberos, the core of identity management authentication, to support SSO for infrastructure. Extend to services so they can authenticate without passwords and support web authentication using SSO (based on Keycloak).
System roles: Save time and resources by making use of consistent and repeatable configuration workflows. Automation will significantly reduce the technical burden and manual tasks associated with deployment and identity administration over time.
Red Hat also offers Red Hat Directory Server as an add-on for those with more specialized needs.
Red Hat Directory Server is an LDAP-based directory that is scalable for large, diverse environments. Use near drop-in replacement for existing costly third-party LDAP solutions and manage distributed and complex directory topologies with a spectrum of replication options. This solution provides flexibility by providing customizable attributes and schema for your directory data.