Bibek Dhungana | Penetration Tester | CRTP

Let's say you are a sysadmin, a pentester or someone on the defensive side working on enterprise administration or security. You might have heard about Active Directory. Active Directory is the most commonly used identity management service in the world. But today we are talking about the bit complex subject about trust and Kerberos authentication across forests in the Active Directory environment.

What is Kerberos in Active Directory?

Kerberos is the default authentication protocol used within Active Directory domains in Windows networks.

Well, now let's understand how the Kerberos authentication actually works in an Active Directory.

Kerberos Authentication Flow in Active Directory

Kerberos Authentication Process

The user (Victim/User) authenticates with the Domain Controller (DC) using their password.
They get a Ticket Granting Ticket (TGT). This TGT is encrypted using the krbtgt account's password hash (held by DC).
The user wants to access a network service like SQL, SharePoint, or a file server.
They send the TGT to the DC and request a TGS (Ticket Granting Service) ticket for the SPN (Service Principal Name) of that service.
The Domain Controller checks the TGT.
Then it builds a TGS ticket encrypted with the target service's account password hash (usually a domain user/service account).
It sends this ticket back to the user.
The user sends the TGS to the application server.
The server decrypts it using its own credentials and validates the session.

This is a workflow when you work within a domain in a single forest or in the Active Directory. Now let's understand forests in Active Directory.

Understanding Forests in Active Directory

In simple terms, a forest is a collection of one or more domain trees. However, with security in mind, we can define it as a security boundary. An Active Directory environment of Organization A and Organization B can't directly access each other by default since these are separate forests.

So, now in modern organizations or businesses there are requirements where an Active Directory of one organization should be able to communicate and access another in different scenarios such as merge or acquisition, partnership with vendors on a project, or other factors. This requirement can be fulfilled by the feature named trust in the Active Directory environment.

Understanding Trust

In an AD environment, trust is a relationship between two domains or forests which allows users of one domain or forest to access resources in the other domain or forest.
Trust can be automatic (parent-child, same forest etc.) or established (forest, external).
Trusted Domain Objects (TDOs) represent the trust relationships in a domain.

Understanding Trust Direction

One-way/Unidirectional Trust

Users in the trusted domain can access resources in the trusting domain but the reverse is not true.

Two-way/Bi-directional Trust

Users of both domains can access resources in the other domain.

Understanding Trust Transitivity

Transitive

Can be extended to establish trust relationships with other domains. All the default intra-forest trust relationships (Tree-root, Parent-Child) between domains within the same forest are transitive two-way trusts.

Nontransitive

Cannot be extended to other domains in the forest. Can be two-way or one-way. This is the default trust (called external trust) between two domains in different forests when forests do not have a trust relationship.

Understanding Trust Types

Default/Automatic Trusts

Parent-child trust: It is created automatically between the new domain and the domain that precedes it in the namespace hierarchy, whenever a new domain is added in a tree. This trust is always two-way transitive.
Tree-root trust: It is created automatically whenever a new domain tree is added to a forest root. This trust is also always two-way transitive.

External Trusts

Between two domains in different forests when forests do not have a trust relationship. Can be one-way or two-way and is nontransitive.

Forest Trusts

Between forest root domains. Cannot be extended to a third forest (no implicit trust). Can be one-way or two-way transitive.

So, as of now we should be aware that we need to explicitly create a Forest Trust between two separate forests of different organizations to communicate with each other or let's say perform Kerberos authentication across separate forests which was our major objective.

Cross-Forest Kerberos Authentication Flow

Forest 1 (User's Home Forest):

Client sends timestamp to KDC (AS-REQ).
KDC replies with TGT encrypted using krbtgt secret (AS-REP).
Client sends TGT to request access to a service (TGS-REQ).
KDC sees the service is in Forest 2 and returns an inter-realm TGT.

Inter-Realm Trust:

Inter-realm TGT is encrypted with trust key shared between Forest 1 and Forest 2.
This TGT allows client to talk to Forest 2 KDC.

Forest 2 (Resource Forest):

Client sends inter-realm TGT to Forest 2 KDC.
Forest 2 KDC validates the ticket using the trust key.
Forest 2 KDC issues a service ticket for the application server.

Accessing the Resource:

Client presents the service ticket to the application server.
Optional: mutual authentication between server and client.

Key Concepts

Inter-realm TGT: Acts like a passport for crossing into another Kerberos realm (forest).
Trust Key: A shared secret between forests that allows each to verify each other's TGTs.
Explicit Trust: Must be manually configured between forests/domains to allow cross-realm Kerberos authentication.

Conclusion

As a pentester who wants to get more into post exploitation in large Active Directory and cross-forest networks, understanding the above-mentioned concepts can be very useful. Further attacks related to cross-forest environments will be discussed in the near future.

Active Directory Cross-Forest Kerberos Authentication