Hello
Let’s break down the Kerberos authentication process and address your questions step-by-step.
Kerberos Authentication Process
1.Initial Login and Ticket Request:
When a user logs into a Windows 11 workstation, they enter their username and password.
The client sends an Authentication Service Request (AS_REQ) to the Key Distribution Center (KDC), which is typically a Domain Controller (DC). This request includes the username but not the password.
The KDC verifies the user’s credentials by checking the username against its database. If the username is valid, the KDC sends back an Authentication Service Reply (AS_REP), which includes a Ticket Granting Ticket (TGT) and a session key, both encrypted with the user’s password hash.
2.Ticket Granting Ticket (TGT):
The client decrypts the TGT using the user’s password hash. The TGT contains the user’s identity and a session key, encrypted with the KDC’s secret key.
The TGT is stored on the client and used for future requests to the Ticket Granting Service (TGS).
3.Service Ticket Request:
When the user tries to access a service (e.g., RDP to a Windows Server 2019), the client sends a Ticket Granting Service Request (TGS_REQ) to the KDC, including the TGT and an authenticator (a timestamp encrypted with the session key).
The KDC verifies the TGT and the authenticator. If valid, it issues a Ticket Granting Service Reply (TGS_REP), which includes a service ticket and a session key for the requested service.
4.Accessing the Service:
The client sends the service ticket and a new authenticator to the service server (e.g., the Windows Server 2019).
The service server decrypts the service ticket using its own secret key and verifies the authenticator. If everything checks out, the user is granted access to the service.
Multi-Domain Network Scenario
In a multi-domain network with domain controllers in different locations (e.g., South America and North America), the process involves additional steps for password changes and replication:
1.Password Change:
When a user changes their password, the request is sent to the nearest domain controller (e.g., in South America).
The domain controller forwards the password change request to the Primary Domain Controller (PDC) Emulator, which holds the Flexible Single Master Operations (FSMO) role, located in North America.
2.Replication:
The PDC Emulator processes the password change and updates its database.
The updated password is then replicated back to the domain controller in South America and other domain controllers in the network.
This ensures that the password change is propagated throughout the network, maintaining consistency across all domain controllers.
I hope this clarifies the Kerberos authentication process and how it works in a multi-domain environment!