Active Directory Security
The information about different AD objects is stored in AD in object and attribute format, all of that is defined in Active directory Schema as we discussed earlier. This data stored in the Active Directory is replicated across the forest since AD is highly scalable and designed in such a manner that it handles a large numbers of read and search operations as well as changes and updates by authenticating the requests and responding to them with access to the required resources. In this section, we’ll discuss about Active Directory from a security perspective and see how authentication works in the AD environment. We’ll discuss different security protocols used in AD, different level of permissions.
Kerberos
Kerberos is an authentication protocol which was initially developed at MIT and uses symmetric key cryptography. To verify user identities, it requires trusted third-party authorization. Microsoft uses Kerberos as the preferred authentication protocol in domain environments. Kerberos (or Cerberus) was the name of the three-headed dog that guarded the entrance to Hades in Greek mythology and, here it just like its name, it requires three entities to authenticate:
1
2
3
- Client (or user that requires access to a service)
- KDC (Key Distribution Center)
- Resource server (which hosts the service required by user)
Detailed information about Kerberos Protocol can be found in RFC 4120.
Components of Kerberos
Kerberos has the following components:
1
2
3
4
5
6
7
8
• Principal: Client (user) or service.
• Realm: A logical Kerberos network.
• Ticket: Data that authenticates a principal's identity.
• Credentials: A ticket and a service key.
• KDC: Key Distribution Center, which authenticates principals.
• TGT: Ticket Granting Ticket.
• TGS: Ticket Granting Service.
• C/S: Client Server, regarding communications between the two.
In case of Active Directory environment, each domain controller acts like a Key Key Distribution Center that provides two core services:
1
2
Authentication Service : Authenticates clients and issues them tickets.
Ticket-Granting Service : Issues tickets to authenticated clients to access other resources.
In this scenario, users are allowed to prove their identity to gain access to domain resources securely. Kerberos uses tickets to allow users to be authenticated against a principal like a service. To request a ticket for an service, you have to specify its Service Principal Name for example, HTTP/RDSWEB01. SPN is a unique identifier of a service account.
TGT
TGT stands for “Ticket Granting Ticket”. A ticket-granting ticket (TGT) is a special ticket that permits the client to obtain additional Kerberos tickets within the same Kerberos realm. When a client sends a request for a ticket to the Key Distribution Center (KDC), the KDC creates a ticket-granting ticket (TGT) for the client, (encrypts it using the client’s password as the key) and sends the encrypted TGT back to the client. The client then attempts to decrypt the TGT, using its password. If the client successfully decrypts the TGT (i.e., if the client gave the correct password), it keeps the decrypted TGT, which indicates proof of the client’s identity.
TGT permits the client to obtain additional tickets (like TGS) which gives permission for specific services.
TGS
TGS stands for “Ticket granting service”. TGS is a KDC component that issues a service ticket when a client requests connection to a Kerberos service. Client needs to have a valid TGT, only then the TGS will be issued to it.
Inter-Realm TGT
In case of authentication in inter-forest trusts, instead of encrypting with Domain1’s krbtgt account, a ticket is encrypted/signed with the inter-realm trust key that the domains previously exchanged, which is called as an “Inter-realm ticket-granting-ticket/TGT.” Then Domain2 verifies the TGT included in the referral, decrypts it with the previously negotiated inter-realm trust key and proceeds further. An inter-realm TGT can be forged. We’ll do that in coming posts. I’ll explain the Kerberos process in detail in the next posts when performing kerberoasting.
Let’s say a client from Domain 1 wants to access the server located in Domain 2.
Here is how it happens:
- A client from Domain1 requests a TGT from the DC1.
- DC1 responds back with the TGT (encrypted with krbtgt hash)
- Client shows the TGT and requests a TGS for accessing the server in Domain2.
- As DC1 doesn’t find the server in current domain and realizes that the TGS needs to be issued by the DC2 (of Domain2) because the server is located in the Domain2. So it responds back to client with the Inter-realm TGT.
- Client shows the TGT encrypted with Inter-Realm trust key to DC2 in the Domain2 and requests TGS to access the server.
- DC2 sends back the TGS for Server encrypted with server’s account hash
- Client presents the TGS (encrypted with server’s account hash) to the server for access.
Kerberos Authentication Flow
Kerberos authentication works like this:
- Client requests an authentication ticket (TGT) from the Key Distribution Center (KDC)
- Key distribution server verifies the credentials and sends back an encrypted TGT and session key
- TGT is stored by client and the local session manager will request another TGT when it expires.
When Client requires access to a service/resource on the network, below process is followed:
- Client sends the current TGT to the TGS with the Service Principal Name (SPN) of the resource the client wants to access
- KDC verifies TGT of the client and also if client has access to the service
- TGS sends a valid session key for the service to the client
- Client forwards the session key to the service to prove it has access, and the service grants access.
PAC validation
In the above diagram, PAC validation is happening between the resource server and KDC. Let’s discuss more about PAC validation. PAC (Privilege Attribute Certificate) represents an structure (included in almost all tickets) which contains useful information like security identifiers, group membership, user profile information, and password credentials. PAC is signed with the KDC key.
PAC validation is the process of validating the PAC of a user authenticating to a server against Active Directory to make sure that it is valid. The server’s OS performs Kerberos PAC validation to protect from a man in the middle attack tampering with the PAC structure to avoid forged PACs.
It can be enabled with the registry key ValidateKdcPacSignature found here: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
“ValidateKdcPacSignature”=dword:00000001
When the value of this entry is 0, Kerberos does not perform PAC validation on a process that runs as a service. When the value of this entry is 1, Kerberos performs PAC validation as usual. You have to restart the computer after you modify this registry entry. When this entry is not present, the system behaves as if the entry is present and has a value of 1. The default value in Windows Server 2008 for this entry is 0.
NTLM
NTLM stands for NT Lan Manager. It is a challenge-response authentication protocol. Before Kerberos, Microsoft used NTLM for authentication. The target computer or domain controller challenges and checks the password, and stores password hashes for continued use. It is still available for older clients and systems on a workgroup.
NTLM relies on a challenge-response protocol to confirm the user without requiring them to submit a password
References: