Authentication Methods

PRACTICE ! PRACTICE ! PRACTICE !

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 !

Kerberos Authentication

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

NetNTLM Authentication

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