Authentication Methods
PRACTICE ! PRACTICE ! PRACTICE !
Last updated
PRACTICE ! PRACTICE ! PRACTICE !
Last updated
While using the Windows Domain, all the credentials are stored in the Domain Controllers
Whenever a user tries to authenticate to a service using valid credentials, the service will need to ask the Domain Controller to verify if they are correct or not !
The most used 2 protocols that are used for network authentication in windows are namely
Kerberos - This is the default protocol in any recent domain
NetNTLM - The Traditional way of verifying our identity, which is still being used for compatibility
Most of the networks will have both protocols enabled !
Users who log into a service using Kerberos will be assigned tickets
Tickets are nothing but a proof of a previous authentication by the user
When Kerberos is used for authentication, the following process happens !
When the user enters his username and sends it via a service, a timestamp is encrypted using a key derived from their password to the Key Distribution Center (KDC)
A Key Distribution Center is a service which is usually installed on the Domain Controller which is in-charge of creating Kerberos tickets on the network
The KDC will create and send back a Ticket Granting Ticket (TGT), which will allow the user to request additional tickets to access specific services, but why do we need for a ticket to get more tickets ??
This TGT mechanism allows users to request service tickets without passing their credentials every time they want to connect to a service, hmm vulnerable right ?
Along with the TGT, a Session Key is given to the user !
We can notice that the TGT is encrypted using the krbtgt account's password hash and therefore the user can't access its contents
One important thing to notice is the encrypted TGT includes a copy of the Session Key as part of its contents, and the KDC has no need to store the Session Key as it can recover a copy by decrypting the TGT if needed
When a user wants to connect to a service on the network for example say like a share, website or database they will use their TGT to ask the KDC for a Ticket Granting Service (TGS)
TGS are tickets that allow connection only to the specific service they were created for
Inorder to request a TGS, the user will send their
username
timestamp encrypted using the Session Key,
along with the TGT,
and a Service Principal Name (SPN)
A SPN indicates the service and server name we intend to access
As a result, the KDC will send us a TGS along with a Service Session Key which we will need to authenticate to the service we want to access
If we clearly notice the TGS is encrypted using a key derived from the Service Owner Hash
The Service Owner is the user or machine account that the service runs under
The TGS contains a copy of the Service Session Key on its encrypted contents so that the Service Owner can access it by decrypting the TGS
Since we've got the encrypted TGS, we can now establish a connection to our desired service
The service will use its configured account's password hash to decrypt the TGS and validate the Service Session Key
It basically works on challenge-response mechanism
The client sends an authentication request to the server they want to access
The server generates a random number and sends it as a challenge to the client
The client then combines their NTLM password hash with the challenge to generate a response to the challenge and sends it back to the server for verification
The server forwards the challenge and the response to the Domain Controller for verification
The Domain Controller uses the challenge to recalculate the response and compares it to the original response sent by the client, If they both match - the client is authenticated otherwise, access is denied - The result is sent back to the server
The server forwards the result to the client
Note that the user's password (or the hash) is never transmitted through the network for security reasons
The above process applies when using a Domain account and not a Local account !
What happens in a local account is the server can verify the response to the challenge itself instead of sending the challenge + response to the Domain Controller - since it has the password hash stored locally on its SAM
