How it works: user logon

Service discovery through DNS

Domain authentication

Service authentication

Service authorization

Kerberos Authentication Protocol in Windows

 DNS: Kerberos service

Kerberos Authentication Protocol in Windows

 DNS: client, app server and DC

Kerberos Authentication Protocol in Windows

 How it works: user logon

Service discovery through DNS

Domain authentication

Service authentication

Service authorization

Kerberos Authentication Protocol in Windows

 Domain authentication: user logon

Kerberos client = TEST\user1

KDC service account = KRBTGT
1. Logon prompt 2. KRB_AS_REQ (client name/realm)

3. KDC_ERR_PREAUTH_REQUIRED (negotiate etype) KDC AS

4. KRB_AS_REQ (client name/realm + PAData (timestamp)) KDC TGS

5. KRB_AS_REP (TGT + client/KDC session key)

TEST\PC1: client computer
192.168.178.101 6. KRB_TGS_REQ (client name/realm + TGT + authenticator)
TEST\DC1: DNS & KDC
7. KRB_TGS_REP (service ticket (PC) + client/PC session key) 192.168.178.10

8. Loading user͛s desktop

Kerberos Authentication Protocol in Windows

 User logon in NetMon

Kerberos Authentication Protocol in Windows

Kerberos Authentication Protocol in Windows
 Capture user logon in NetMon

Demo: how to use NetMon

KerberosV5 and (Source == "PC1 " OR Destination == "PC1 ")

Kerberos Authentication Protocol in Windows

 Step 1: user secret key is created on PC

User secret key (AES)

Client computer PC1

User credentials cache

User password
salted with User1 key
REALMsamaccountname
hashed through
string2key function Client computer
PBKDF2+DK credentials cache
PC1 system key
Winlogon

Local Security Authority

Kerberos Security Support Provider

Kerberos Authentication Protocol in Windows

 Step 2: initial user auth request

Kerberos client = TEST\user1

KDC service account = KRBTGT
1. Logon prompt 2. KRB_AS_REQ (client name/realm)

3. KDC_ERR_PREAUTH_REQUIRED (negotiate etype) KDC AS

4. KRB_AS_REQ (client name/realm + PAData (timestamp)) KDC TGS

5. KRB_AS_REP (TGT + client/KDC session key)

TEST\PC1: client computer
192.168.178.101 6. KRB_TGS_REQ (client name/realm + TGT + authenticator)
TEST\DC1: DNS & KDC
7. KRB_TGS_REP (service ticket (PC) + client/PC session key) 192.168.178.10

8. Loading user͛s desktop

Kerberos Authentication Protocol in Windows

 Step 2: initial user auth request

Kerberos Authentication Protocol in Windows

 Step 2: initial user auth request cont.

Kerberos Authentication Protocol in Windows

 Step 3: pre-authentication etype options

Kerberos client = TEST\user1

KDC service account = KRBTGT
1. Logon prompt 2. KRB_AS_REQ (client name/realm)

3. KDC_ERR_PREAUTH_REQUIRED (negotiate etype) KDC AS

4. KRB_AS_REQ (client name/realm + PAData (timestamp)) KDC TGS

5. KRB_AS_REP (TGT + client/KDC session key)

TEST\PC1: client computer
192.168.178.101 6. KRB_TGS_REQ (client name/realm + TGT + authenticator)
TEST\DC1: DNS & KDC
7. KRB_TGS_REP (service ticket (PC) + client/PC session key) 192.168.178.10

8. Loading user͛s desktop

Kerberos Authentication Protocol in Windows

 Step 3: pre-authentication etype options

Kerberos Authentication Protocol in Windows

 Step 4: user auth request

Kerberos client = TEST\user1

KDC service account = KRBTGT
1. Logon prompt 2. KRB_AS_REQ (client name/realm)

3. KDC_ERR_PREAUTH_REQUIRED (negotiate etype) KDC AS

4. KRB_AS_REQ (client name/realm + PAData (timestamp)) KDC TGS

5. KRB_AS_REP (TGT + client/KDC session key)

TEST\PC1: client computer
192.168.178.101 6. KRB_TGS_REQ (client name/realm + TGT + authenticator)
TEST\DC1: DNS & KDC
7. KRB_TGS_REP (service ticket (PC) + client/PC session key) 192.168.178.10

8. Loading user͛s desktop

Kerberos Authentication Protocol in Windows

 Step 4: user auth request

KDC AS

KDC TGS

TEST\PC1: client computer TEST\DC1: DNS & KDC

192.168.178.101 KRB_AS_REQ 192.168.178.10

User credentials cache Realm + username KDC database

User1 key Target service: KDC AS KRBTGT key

PAData: timestamp User1 key

Client computer
credentials cache
User1 key PC1 system key
PC1 system key

Kerberos Authentication Protocol in Windows

 Step 4: user auth request in NetMon

Kerberos Authentication Protocol in Windows

 Step 4: user auth request in NetMon – TGT flags

Kerberos Authentication Protocol in Windows

 TGT flags

Forwardable: Tells the KDC that it can issue a new TGT, based on the presented TGT, with a different
network address based on the presented TGT.

Renewable: Used in combination with the End Time and Renew Till fields to cause tickets with long
life spans to be renewed at the KDC periodically.

Name-canonicalize: In order to request referrals, the Kerberos client MUST explicitly request the
"canonicalize" KDC option for the AS-REQ or TGS-REQ.

Renewable-ok: Indicates that a renewable ticket will be acceptable if a ticket with the requested life
cannot otherwise be provided, in which case a renewable ticket may be issued with a renew-till
equal to the requested end time. The value of the renew-till field may still be limited by local limits,
or limits selected by the individual principal or server.

4768(S, F): A Kerberos authentication ticket (TGT) was requested

https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768

Kerberos Authentication Protocol in Windows

 TGT flags: canonicalize

Name Canonicalization

A service or account may have multiple principal names. For example, if a host is known by multiple
names, host-based services on it may be known by multiple names in order to prevent the client
from needing a secure directory service to determine the correct hostname to use. In order that the
host should not need to be updated whenever a new alias is created, the KDC may provide the
mapping information to the client in the credential acquisition process.

If the "canonicalize" KDC option is set, then the KDC MAY change the client and server principal
names and types in the AS response and ticket returned from the name type of the client name in
the request. In a TGS exchange, the server principal name and type may be changed.

Kerberos Principal Name Canonicalization and KDC-Generated Cross-Realm Referrals

https://tools.ietf.org/id/draft-ietf-krb-wg-kerberos-referrals-12.html#rfc.section.6

Kerberos Authentication Protocol in Windows

 Step 5: user receives TGT

Kerberos client = TEST\user1

KDC service account = KRBTGT
1. Logon prompt 2. KRB_AS_REQ (client name/realm)

3. KDC_ERR_PREAUTH_REQUIRED (negotiate etype) KDC AS

4. KRB_AS_REQ (client name/realm + PAData (timestamp)) KDC TGS

5. KRB_AS_REP (TGT + client/KDC session key)

TEST\PC1: client computer
192.168.178.101 6. KRB_TGS_REQ (client name/realm + TGT + authenticator)
TEST\DC1: DNS & KDC
7. KRB_TGS_REP (service ticket (PC) + client/PC session key) 192.168.178.10

8. Loading user͛s desktop

Kerberos Authentication Protocol in Windows

 Step 5: user receives TGT

KDC AS

KDC TGS

KRB_AS_REP
TEST\PC1: client computer TEST\DC1: DNS & KDC
192.168.178.101 Ticket Granting Ticket
192.168.178.10

User credentials cache Realm + username KDC database

Realm + username
User1 key KRBTGT session key KRBTGT key

KRBTGT session key TGT validity info

User1 key
Client computer
TGT validity info User1's signed PAC
credentials cache
PC1 system key
PC1 system key User1 key
KRBTGT key

Kerberos Authentication Protocol in Windows

 Step 5: user receives TGT in NetMon

Kerberos Authentication Protocol in Windows

 Step 6: user requests service ticket

Kerberos client = TEST\user1

KDC service account = KRBTGT
1. Logon prompt 2. KRB_AS_REQ (client name/realm)

3. KDC_ERR_PREAUTH_REQUIRED (negotiate etype) KDC AS

4. KRB_AS_REQ (client name/realm + PAData (timestamp)) KDC TGS

5. KRB_AS_REP (TGT + client/KDC session key)

TEST\PC1: client computer
192.168.178.101 6. KRB_TGS_REQ (client name/realm + TGT + authenticator)
TEST\DC1: DNS & KDC
7. KRB_TGS_REP (service ticket (PC) + client/PC session key) 192.168.178.10

8. Loading user͛s desktop

Kerberos Authentication Protocol in Windows

 Step 6: user requests service ticket

KDC AS

KDC TGS

TEST\PC1: client computer

KRB_TGS_REQ
192.168.178.101
Target service: PC1
User credentials cache TEST\DC1: DNS & KDC
PAData 192.168.178.10
User1 key
Authenticator KDC database
KRBTGT session key
Realm + username
KRBTGT key
Ticket Granting Ticket Timestamp
User1 key
KRBTGT key Session key

PC1 system key

Client computer Ticket Granting Ticket
credentials cache
KRBTGT key
PC1 system key

Kerberos Authentication Protocol in Windows

 Step 6: user requests service ticket in NetMon

Kerberos Authentication Protocol in Windows

 Step 6: user requests service ticket - flags

Kerberos Authentication Protocol in Windows

 Step 7: user receives service ticket

Kerberos client = TEST\user1

KDC service account = KRBTGT
1. Logon prompt 2. KRB_AS_REQ (client name/realm)

3. KDC_ERR_PREAUTH_REQUIRED (negotiate etype) KDC AS

4. KRB_AS_REQ (client name/realm + PAData (timestamp)) KDC TGS

5. KRB_AS_REP (TGT + client/KDC session key)

TEST\PC1: client computer
192.168.178.101 6. KRB_TGS_REQ (client name/realm + TGT + authenticator)
TEST\DC1: DNS & KDC
7. KRB_TGS_REP (service ticket (PC) + client/PC session key) 192.168.178.10

8. Loading user͛s desktop

Kerberos Authentication Protocol in Windows

 Step 7: user receives service ticket

KDC AS

KDC TGS

TEST\PC1: client computer

192.168.178.101
KRB_TGS_REP
User credentials cache
TEST\DC1: DNS & KDC
Service Ticket
User1 key 192.168.178.10

KRBTGT session key Realm + username KDC database

Realm + username
Service session key KRBTGT key
Ticket Granting Ticket
Service session key Service ticket validity info
KRBTGT key User1 key
Service ticket validity info
User1's signed PAC
Client computer PC1 system key
KRBTGT session key Service key
credentials cache
PC1 system key

Kerberos Authentication Protocol in Windows

 Step 7: user receives service ticket in NetMon

Kerberos Authentication Protocol in Windows

 Step 8: PC1 validates user1, loads desktop

TEST\PC1: client computer

192.168.178.101

User credentials cache

User1 key • Kerberos SSP hands the service ticket to LSA.

KRBTGT session key
• LSA decrypts the ticket with system key.
Service session key
• LSA evaluates PAC against SAM.
Ticket Granting Ticket
KRBTGT key
• LSA creates token and hands it over to Winlogon.
• Winlogon loads user1 desktop.
Client computer
credentials cache
• User1/PC1 session key will be used for future.
PC1 system key communication between user1 and PC1.
Service ticket
Service key

PC1 system key = PC1 service key

Kerberos Authentication Protocol in Windows

 TEST\PC1: client computer
192.168.178.101

User credentials cache

User1 key
• Kerberos SSP hands the service ticket to LSA.
KRBTGT session key • LSA decrypts the ticket with system key.
Service session key • LSA evaluates PAC against SAM.
Ticket Granting Ticket • LSA creates token and hands it over to Winlogon.
KRBTGT key
• Winlogon loads user1 desktop.
Client computer • User1/PC1 session key will be used for future.
credentials cache
PC1 system key
communication between user1 and PC1.
Service ticket
Service key

PC1 system key = PC1 service key

Kerberos Authentication Protocol in Windows

 • Kerberos SSP hands the service ticket to LSA.
• LSA decrypts the ticket with system key.
• LSA evaluates PAC against local SAM.
• LSA creates token and hands it over to Winlogon.
Service Ticket
• Winlogon loads user1 desktop.
Realm + username
• User1/PC1 session key will be used for future.
Service session key

Service ticket validity info

communication between user1 and PC1.
User1's signed PAC

Service key

Kerberos Authentication Protocol in Windows

 Local Security Authority

•
Privilege Attribute Certificate Local SAM Database
Kerberos SSP hands the service ticket to LSA.
• LSA decrypts the ticket with system key.
• LSA evaluates PAC against local SAM.
Complete list of user SIDs
• LSA creates token and hands it over to Winlogon.
• Winlogon loads user1 desktop.
• User1/PC1 session key will be used for future.
Access Token communication between user1 and PC1.

Winlogon

Kerberos Authentication Protocol in Windows

 User1 token for access to PC1

• Kerberos SSP hands the service ticket to LSA.

• LSA decrypts the ticket with system key.
• LSA evaluates PAC against local SAM.
Winlogon • LSA creates token and hands it over to Winlogon.
• Winlogon loads user1 desktop.
• User1/PC1 session key will be used for future.
communication between user1 and PC1.

Kerberos Authentication Protocol in Windows

 • Kerberos SSP hands the service ticket to LSA.
• LSA decrypts the ticket with system key.
• LSA evaluates PAC against local SAM.
• LSA creates token and hands it over to Winlogon.
• Winlogon loads user1 desktop.
• User1/PC1 session key will be used for future communication
between user1 and PC1.

Kerberos Authentication Protocol in Windows

 User TGT

Kerberos Authentication Protocol in Windows

 User access token

Kerberos Authentication Protocol in Windows