Active Directory (AD) is a directory service developed by Microsoft for Windows domain networks. It provides a centralized platform for managing users, computers, and other resources, with authentication being a core function.
Here’s how Active Directory works for authentication:
Active Directory Authentication
Active Directory authentication verifies the identity of users or devices attempting to access resources in a Windows domain environment. It ensures that only authorized entities gain access to network resources, such as files, applications, or systems, based on their credentials.
Key Components Involved
1. Domain Controller (DC): A server running Active Directory Domain Services (AD DS) that stores the AD database and handles authentication and authorization requests.
2. Active Directory Database: Stores user accounts, passwords (hashed), group policies, and other objects like computers and groups.
3. Kerberos: The primary authentication protocol used by AD (with NTLM as a fallback for legacy systems).
4. Lightweight Directory Access Protocol (LDAP): Used for querying and modifying directory information, often involved in authentication workflows.
5. Security Accounts Manager (SAM): Manages user credentials locally on non-domain systems but integrates with AD in domain environments.
How Authentication Works in Active Directory
The authentication process typically uses the Kerberos protocol (or NTLM in older or specific scenarios). Below is a step-by-step explanation of the Kerberos authentication process in AD:
1. User Credential Submission:
• A user enters their credentials (username and password) into a client device (e.g., a Windows PC) when logging into the domain or accessing a resource.
• The client hashes the password and sends an authentication request to the Key Distribution Center (KDC), which runs on the domain controller.
2. Authentication Service (AS) Request:
• The KDC consists of two components: the Authentication Service (AS) and the Ticket-Granting Service (TGS).
• The client sends an AS-REQ (Authentication Service Request) to the KDC, including the user’s identity and a timestamp encrypted with the user’s password hash.
• The KDC verifies the credentials by checking the AD database. If valid, the KDC responds with a Ticket-Granting Ticket (TGT), which is encrypted with the KDC’s secret key and includes a session key for further communication.
3. Ticket-Granting Ticket (TGT):
• The TGT is a token that proves the user’s identity to the KDC without requiring repeated credential submissions.
• The client stores the TGT in its Kerberos ticket cache.
4. Accessing Resources (TGS Request):
• When the user attempts to access a resource (e.g., a file server or application), the client sends a TGS-REQ (Ticket-Granting Service Request) to the KDC, presenting the TGT and specifying the desired service.
• The KDC validates the TGT and issues a Service Ticket (or session ticket) specific to the requested service. This ticket is encrypted with the service’s secret key and includes a session key for secure communication between the client and the service.
5. Service Authentication:
• The client sends the Service Ticket to the target service (e.g., a file server).
• The service decrypts the ticket using its own credentials and verifies the user’s identity. If valid, the service grants access to the requested resource.
6. Session Establishment:
• Once authenticated, the client and service use the session key to encrypt communication, ensuring secure access to the resource.
NTLM Authentication (Fallback)
In cases where Kerberos is not supported (e.g., non-domain-joined devices or legacy systems), AD uses NTLM (NT LAN Manager):
• The client sends a hashed version of the user’s credentials to the domain controller.
• The DC compares the hash with the stored hash in the AD database.
• If they match, the user is authenticated, and access is granted based on permissions.
Single Sign-On (SSO)
AD enables Single Sign-On (SSO) through Kerberos. Once a user receives a TGT, they can access multiple services within the domain without re-entering credentials, as long as the TGT remains valid (typically for 10 hours, configurable via Group Policy).
Security Features
• Group Policies: AD uses Group Policies to enforce security settings, such as password complexity, account lockout policies, and Kerberos ticket lifetimes.
• Multi-Factor Authentication (MFA): AD can integrate with solutions like Azure AD or third-party tools to add MFA for stronger security.
• Secure LDAP (LDAPS): Ensures encrypted communication when querying the AD database.
• Trust Relationships: AD supports trusts between domains or forests, allowing authentication across multiple domains.
Authentication Workflow Example
1. A user logs into their Windows PC with their domain credentials.
2. The PC sends an AS-REQ to the domain controller’s KDC.
3. The KDC verifies the credentials and issues a TGT.
4. The user tries to access a shared folder on a file server.
5. The PC sends a TGS-REQ with the TGT to the KDC, requesting a Service Ticket for the file server.
6. The KDC issues a Service Ticket, which the PC sends to the file server.
7. The file server validates the ticket and grants access to the folder.
Key Benefits
• Centralized Management: AD provides a single point for managing user credentials and access policies.
• Scalability: Supports large organizations with thousands of users and devices.
• Security: Kerberos and encryption ensure secure authentication.
• Interoperability: Works with various Microsoft services (e.g., Exchange, SharePoint) and third-party applications.
Limitations
• Complexity: Setting up and maintaining AD, especially in large environments, can be complex.
• Windows-Centric: While AD supports non-Windows systems via third-party tools, it’s primarily designed for Windows environments.
• Dependency on Domain Controllers: Authentication fails if DCs are unavailable unless cached credentials are used.