Protocols

AD relies on selected essential protocols:

• 389: Lightweight Directory Access Protocol (LDAP)

• 88: Kerberos (and/or)

• DNS

• MSRPC

DNS (53)

The Domain Name System protocol in Active Directory enables servers and clients to perform functions such as discovering domain controllers and communicating with other domain controllers that host directory services.

To implement this, internal networks use Active Directory DNS namespaces. Specifically, Active Directory maintains a database of services running on the network. This database consists of service record entries, which are used by services to discover other services.

As soon as a client enters the network, it sends a request to the DNS service to translate a domain into the service's IP.

The DNS service is often hosted by a domain controller. Keep that in mind while searching for domain controllers. The DNS service is often hosted by a domain controller. Keep this in mind when searching for domain controllers.

By default, DNS uses port 53 and UDP. It is also possible for DNS to use tcp as a fallback if a connection fails or the packet size is greater than 512 bytes.

To perform a DNS query manually, you can use tools such as nslookup:

Example:

> nslookup EXAMPLE.LOCAL

Server:  172.16.4.50
Address:  172.16.4.50

Name:    EXAMPLE.LOCAL
Address:  172.16.4.50

You can even perform a DNS query for the FQDN of a domain controller:

> nslookup DC01.EXAMPLE.LOCAL

Server:  172.16.4.51
Address:  172.16.4.51

Name:    DC01.EXAMPLE.LOCAL
Address:  172.16.4.51

MSRPC (135)

Inter-process communication (IPC) techniques are widely used in client-server model-based applications to facilitate communication and data exchange between processes running on different machines or within the same system. In the context of Windows environments, there are several key interfaces related to Active Directory and domain management that provide critical functionalities for authentication, authorization, and management of security principals. Some interesting examples include:

lsarpc

This set of RPCs (Remote Procedure Calls) is responsible for managing local security policies on computers. It also handles audit policies and provides interactive authentication services. This interface plays a crucial role in managing security settings across a networked environment.

netlogon

The netlogon process in Windows is used for authenticating users and services within the domain environment. It is a key component in the client-server authentication process in Active Directory and is essential for ensuring that users and computers are properly authenticated before being granted access to network resources.

samr

The Security Account Manager (SAM) Remote Protocol provides administrative functionalities for the domain account database. Using this interface, administrators can modify security principal information for users and computers. This is crucial for managing access control and permissions within a domain. However, tools like BloodHound exploit this interface to enumerate attack paths and visualize vulnerabilities within an Active Directory environment.

drsuapi

This API implements the Directory Replication Service (DRS) Remote Protocol, which can be exploited by attackers to obtain a copy of the Active Directory Domain Database (NTDS.dit). The NTDS.dit file contains critical data, including user hashes, which can be cracked to allow attackers to authenticate remotely to systems using protocols like RDP (Remote Desktop Protocol) or WinRM (Windows Remote Management).

These interfaces and protocols are vital for managing and interacting with Active Directory, but they also present potential attack vectors. Tightening security configurations, such as restricting access to sensitive protocols and using least-privilege principles, can help mitigate these risks.

LDAP (389)

Active Directory (AD) supports LDAP (Lightweight Directory Access Protocol) for directory lookups, using port 389 for standard LDAP communication and port 636 for LDAP over SSL (LDAPS). LDAP serves as the protocol through which applications communicate with servers providing directory services.

In AD, this enables the exchange of information such as user details, security settings, and passwords between applications and the directory. LDAP sessions begin by establishing a connection to an LDAP server, which functions as the Directory System Agent (DSA). In AD, Domain Controllers (DCs) fulfill this role, listening for LDAP requests, particularly those related to LDAP authentication.

This process can be compared to the way an Apache web server handles HTTP requests, with LDAP acting as the "language" that facilitates communication between applications and the directory services provided by AD.

Authentication

There are several types of authentication methods in LDAP:

Simple Authentication

This includes anonymous authentication, unauthenticated authentication, and simple username/password authentication. In this method, the client sends a username and password directly to the LDAP server to authenticate the user. It is considered less secure because the credentials are transmitted in plaintext unless used over a secure connection (e.g., via SSL/TLS).

SASL Authentication

The Simple Authentication and Security Layer (SASL) framework enhances security by allowing external authentication mechanisms, such as Kerberos, to be used. When a client attempts to authenticate, the LDAP server uses the LDAP protocol to send a message to the authorization service, which initiates a series of challenge/response messages. This adds an additional layer of security by separating the authentication process from the application protocols, ensuring that sensitive information is handled more securely.

SASL-based authentication helps in protecting credentials, as it supports more robust authentication methods beyond simple username and password, like Kerberos, which can prevent sending credentials over the network in plain text.

LDAPS (636)

In progress....

Kerberos/NTLM

See:

Authentication