Active Directory Protocols SG-Learning
Active Directory Protocols
By: Souleiman Guedi
Active Directory Protocols SG-Learning
Content Table
Lightweight Directory Access Protocol (LDAP)
What is LDAP?
Kerberos
User Client-based Login without Kerberos
Client Authentication
Client Service Authorization
Client Service Request
Support by operating systems
Active Directory Domain Services
NTLM Authentication
LAN Manager (LM) Hashes
Active Directory Protocols SG-Learning
Lightweight Directory Access Protocol
LDAP assumes the same information model and namespace as X.500. It is also
clientserver based, with one important difference: there are no referrals returned in
LDAP. An LDAP server must return only results or errors to a client. If referrals are
involved, the LDAP server is responsible for chasing them down. This model is depicted
in Figure 2, though the intermediate server shown is not required (i.e., an
implementation could choose to have its DSA speak “native” LDAP).
What is LDAP? Structure and Usage
Imagine a giant company phone book one where you can look up employees by name,
title, department, or even the printer in their office. That’s basically what LDAP is.
LDAP is a protocol used to access and manage information in directory services
(structured databases optimized for read-heavy operations).
Key Concept:
LDAP is like querying a read-optimized hierarchical database.
• It stores objects like users, groups, computers, printers.
• Each object has attributes (e.g., cn=John Smith, mail=jsmith@company.com).
• These are stored in a tree structure (like folders and subfolders).
Active Directory Protocols SG-Learning
Kerberos
Introduction to Authentication & Kerberos Basics
Let’s say you want to enter a secure office building. At the entrance, the security guard
checks your ID and gives you a badge (like a hall pass). You use that badge to access
rooms inside, without showing your ID every time. That’s how Kerberos works.
Kerberos is a computer-network authentication protocol that works on the basis
of tickets to allow nodes communicating over a non-secure network to prove their
identity to one another in a secure manner. Its designers aimed it primarily at a client–
server model, and it provides mutual authentication—both the user and the server verify
each other's identity. Kerberos protocol messages are protected
against eavesdropping and replay attacks.
Kerberos builds on symmetric-key cryptography and requires a trusted third party, and
optionally may use public-key cryptography during certain phases of
authentication.[2] Kerberos uses UDP port 88 by default.
The protocol was named after the character Kerberos (or Cerberus) from Greek
mythology, the ferocious three-headed guard dog of Hades.
Description
The client authenticates itself to the Authentication Server (AS) which is part of the key
distribution center (KDC). The KDC issues a ticket-granting ticket (TGT), which is time
stamped and encrypts it using the ticket-granting service's (TGS) secret key and returns
the encrypted result to the user's workstation. This is done infrequently, typically at user
logon; the TGT expires at some point although it may be transparently renewed by the
user's session manager while they are logged in.
Active Directory Protocols SG-Learning
When the client needs to communicate with a service on another node (a "principal", in
Kerberos parlance), the client sends the TGT to the TGS, which is another component of
the KDC and usually shares the same host as the authentication server. The service
must have already been registered with the TGS with a Service Principal Name (SPN).
The client uses the SPN to request access to this service. After verifying that the TGT is
valid and that the user is permitted to access the requested service, the TGS issues
a service ticket (ST) and session keys to the client. The client then sends the ticket to
the service server (SS) along with its service request.
User Client-based Login without Kerberos
1. A user enters a username and password on the client machine(s). Other
credential mechanisms like pkinit (RFC 4556) allow for the use of public keys in
place of a password. The client transforms the password into the key of a
symmetric cipher. This either uses the built-in key scheduling, or a one-way hash,
depending on the cipher-suite used.
2. The server receives the username and symmetric cipher and compares it with the
data from the database. Login was a success if the cipher matches the cipher
that is stored for the user.
Client Authentication
1. The client sends a plaintext message of the user ID to the AS
(Authentication Server) requesting services on behalf of the user. (Note:
Neither the secret key nor the password is sent to the AS.)
2. The AS checks to see whether the client is in its database. If it is, the AS
generates the secret key by hashing the password of the user found at the
database (e.g., Active Directory in Windows Server) and sends back the
following two messages to the client:
• Message A: Client/TGS Session Key encrypted using the secret
key of the client/user.
• Message B: Ticket-Granting-Ticket (TGT, which includes the
client ID, client network address, ticket validity period, and
the Client/TGS Session Key) encrypted using the secret key of
the TGS.
3. Once the client receives messages A and B, it attempts to decrypt
message A with the secret key generated from the password entered by
the user. If the user entered password does not match the password in
the AS database, the client's secret key will be different and thus unable
to decrypt message A. With a valid password and secret key the client
decrypts message A to obtain the Client/TGS Session Key. This session
Active Directory Protocols SG-Learning
key is used for further communications with the TGS. (Note: The client
cannot decrypt Message B, as it is encrypted using TGS's secret key.) At
this point, the client has enough information to authenticate itself to the
TGS.
Client Service Authorization
1. When requesting services, the client sends the following messages to the
TGS:
• Message C: Composed of the message B (the encrypted TGT
using the TGS secret key) and the ID of the requested service.
• Message D: Authenticator (which is composed of the client ID
and the timestamp), encrypted using the Client/TGS Session
Key (found by the client in Message A).
Active Directory Protocols SG-Learning
2. Upon receiving messages C and D, the TGS retrieves message B out of
message C. It decrypts message B using the TGS secret key. This gives it
the Client/TGS Session Key and the client ID (both are in the TGT). Using
this Client/TGS Session Key, the TGS decrypts message D (Authenticator)
and compares the client IDs from messages B and D; if they match, the
server sends the following two messages to the client:
• Message E: Client-to-server ticket (which includes the client ID,
client network address, validity period, and Client/Server
Session Key) encrypted using the service's secret key.
• Message F: Client/Server Session Key encrypted with
the Client/TGS Session Key.
Client Service Request
1. Upon receiving messages E and F from TGS, the client has enough
information to authenticate itself to the Service Server (SS). The client
connects to the SS and sends the following two messages:
• Message E: From the previous step (the Client-to-server ticket,
encrypted using service's Secret key by the TGS).
• Message G: A new Authenticator, which includes the client ID,
timestamp and is encrypted using Client/Server Session Key.
2. The SS decrypts the ticket (message E) using its own secret key to
retrieve the Client/Server Session Key. Using the sessions key, SS decrypts
the Authenticator and compares client ID from messages E and G, if they
match server sends the following message to the client to confirm its true
identity and willingness to serve the client:
• Message H: The timestamp found in client's Authenticator
(plus 1 in version 4, but not necessary in version 5[11]), encrypted
using the Client/Server Session Key.
3. The client decrypts the confirmation (message H) using the Client/Server
Session Key and checks whether the timestamp is correct. If so, then the
client can trust the server and can start issuing service requests to the
server.
4. The server provides the requested services to the client.
Active Directory Protocols SG-Learning
Support by operating systems
Microsoft Windows
Windows 2000 and later versions use Kerberos as their default authentication
method.[13] Some Microsoft additions to the Kerberos suite of protocols are
documented in RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and
Set Password Protocols". RFC 4757 documents Microsoft's use of the RC4 cipher. While
Microsoft uses and extends the Kerberos protocol, it does not use the MIT software.
Kerberos is used as the preferred authentication method: in general, joining a client to a
Windows domain means enabling Kerberos as the default protocol for authentications
from that client to services in the Windows domain and all domains with trust
relationships to that domain.
In contrast, when either client or server or both are not joined to a domain (or not part of
the same trusted domain environment), Windows will instead use NTLM for
authentication between client and server.
Internet web applications can enforce Kerberos as an authentication method for
domain-joined clients by using APIs provided under SSPI.
Microsoft Windows and Windows Server include setspn, a command-line utility that
can be used to read, modify, or delete the Service Principal Names (SPN) for an Active
Directory service account.
Unix and other operating systems
Many Unix-like operating systems, including FreeBSD, Apple's macOS, Red Hat
Enterprise Linux, Oracle's Solaris, IBM's AIX, HP-UX and others, include software for
Kerberos authentication of users or services. A variety of non-Unix like operating
systems such as z/OS, IBM i and OpenVMS also feature Kerberos support. Embedded
implementation of the Kerberos V authentication protocol for client agents and network
services running on embedded platforms is also available from companies.
Security
Active Directory Protocols SG-Learning
The Data Encryption Standard (DES) cipher can be used in combination with Kerberos,
but is no longer an Internet standard because it is weak.[16] Security vulnerabilities exist
in products that implement legacy versions of Kerberos which lack support for newer
encryption ciphers like AES.
Active Directory Domain Services
A directory is a hierarchical structure that stores information about objects on a
network. A directory service, such as Active Directory Domain Services (AD DS),
provides the methods for storing directory data and making this data available to
network users and administrators. For example, AD DS stores information about user
accounts, such as names, passwords, phone numbers, and so on. AD DS also provides
a way for authorized users on the same network to access this information.
AD DS stores information about objects on the network and makes this information
easy for administrators and users to find and use. AD DS uses a structured data store
as the basis for a logical, hierarchical organization of directory information.
This data store, also known as the directory, contains information about AD DS objects.
These objects typically include shared resources such as servers, volumes, printers, and
the network user and computer accounts. For more information about the AD DS data
store, see Directory data store.
Security is integrated with AD DS through sign-in authentication and access control to
objects in the directory. With a single network username and password, administrators
can manage directory data and organization throughout their network, and authorized
network users can access resources anywhere on the network. Policy-based
administration eases the management of even the most complex network. For more
information about AD DS security, see Best practices for securing Active Directory.
AD DS also includes:
• A set of rules, the schema, that defines the classes of objects and attributes
contained in the directory, the constraints and limits on instances of these
objects, and the format of their names. For more information about the
schema, see Schema.
• A global catalog that contains information about every object in the
directory. Users and administrators can use the catalog to find directory
information regardless of the directory domain that actually contains the
data. For more information about the global catalog, see Global catalog.
• A query and index mechanism, so that objects and their properties can be
published and found by network users or applications. For more
Active Directory Protocols SG-Learning
information about querying the directory, see Searching in Active Directory
Domain Services.
• A replication service that distributes directory data across a network. All
domain controllers in a domain participate in replication and contain a
complete copy of all directory information for their domain. Any change to
directory data is replicated to all domain controllers in the domain. For
more information about AD DS replication, see Active Directory Replication
Concepts.
NTLM Authentication
In addition to Kerberos and LDAP, Active Directory supports multiple legacy
authentication mechanisms that are still used—and potentially misused—by various
applications and services. These include LM (LAN Manager), NTLM, NTLMv1, and
NTLMv2. It's important to distinguish between hash types and authentication protocols:
LM and NTLM refer to the hashing algorithms, whereas NTLMv1 and NTLMv2 are
authentication protocols that leverage either LM or NT hashes.
While none of these legacy methods are ideal from a security standpoint, Kerberos
remains the preferred authentication protocol in modern AD environments due to its
stronger security model.
When evaluating authentication mechanisms within Active Directory, it’s important to
distinguish between the cryptographic methods, trust models, and protocol capabilities
of each. NTLM, NTLMv1, and NTLMv2 rely primarily on symmetric key cryptography and
lack mutual authentication, making them less secure and more susceptible to attacks
like relay and pass-the-hash. Kerberos, by contrast, utilizes both symmetric and
asymmetric cryptographic techniques, supports mutual authentication, and operates
through a trusted Key Distribution Center (KDC), making it the most secure and
preferred option in modern environments.
The table below summarizes the core differences between these authentication
protocols:
Active Directory Protocols SG-Learning
Cryptographic Mutual Trusted Third
Protocol Message Type
Technique Authentication Party
Symmetric key Challenge/response Domain
NTLM No
cryptography using random number Controller
Symmetric key MD4 hash with Domain
NTLMv1 No
cryptography challenge/response Controller
MD4 hash with
Symmetric key Domain
NTLMv2 No enhanced
cryptography Controller
challenge/response
Symmetric &
Key
asymmetric Encrypted tickets and
Kerberos Yes Distribution
cryptography (DES, authenticators
Center (KDC)
MD5, RSA/AES)
LAN Manager (LM) Hashes
LAN Manager (LM) hashes are one of the earliest password storage mechanisms
implemented in Microsoft operating systems, originally introduced in 1987 with the
OS/2 platform. When enabled, LM hashes are stored locally in the SAM (Security
Account Manager) database on Windows hosts or in the NTDS.DIT file on Domain
Controllers in an Active Directory environment.
Due to critical cryptographic weaknesses, LM hashing has been disabled by default
since Windows Vista and Windows Server 2008. However, LM hashes can still be found
in large or legacy environments where outdated systems remain operational.
Key Characteristics of LM Hashes
• Password Length Limitation: LM hashes support passwords up to a maximum of
14 characters.
• Case Insensitivity: Passwords are converted to uppercase before hashing,
drastically reducing the complexity of the keyspace.
• Keyspace Size: The total keyspace is limited to 69 characters, making brute-
force attacks significantly faster.
LM Hashing Process
1. The plaintext password is converted to uppercase and padded with null bytes if
it's less than 14 characters.
2. The 14-character string is split into two 7-character blocks.
3. Each 7-character block is used to generate a DES key.
4. Each DES key encrypts a known constant string: "KGS!@#$%".
Active Directory Protocols SG-Learning
5. The resulting two 8-byte ciphertexts are concatenated to produce the final 16-
byte LM hash.
Security Weaknesses
• LM’s predictable structure means that cracking only requires brute-forcing two
7-character segments, rather than a full 14-character string.
• If the password is 7 characters or fewer, the second half of the hash becomes
static, often recognizable even without specialized tools.
• Tools like Hashcat can exploit these characteristics to rapidly crack LM hashes,
especially when using modern GPUs.
