Download pptx - Kerberos explained

Transcript
Page 1: Kerberos explained

Kerberos ExplainedDOTAN PATRICH

Page 2: Kerberos explained

Who's on First? How can Abbot authenticate that Costello is talking?

How can Abbot make sure that Costello is on First?

Page 3: Kerberos explained

Kerberos the three-headed dog Authentication protocol named after a mythical three-headed dog:

◦ Key Distribution Center (KDC)◦ The client user◦ The accessed server

Came out of MIT

Adopted by MS AD to replace NTLM (and failed to do so)

Page 4: Kerberos explained

How does it work?

Active Directory

Page 5: Kerberos explained

How does it work?

Active Directory

User login by entering username and password

Page 6: Kerberos explained

How does it work?

Active Directory

Send authentication request to the KDC, containing:

• User principal name

• Account domain name

• Secret key derived from the user password

Page 7: Kerberos explained

How does it work?

Active Directory

KDC contacts AD to authenticate the user and gather all groups he posses

Page 8: Kerberos explained

How does it work?

Active DirectoryReply with Ticket Granting Ticket (TGT), containing:

• Session key encrypted by the KDC private key

• Authorization information for the user (i.e. groups)

Page 9: Kerberos explained

How does it work?

Active DirectoryReply with Ticket Granting Ticket (TGT), containing:

• Session key encrypted by the KDC private key

• Authorization information for the user (i.e. groups)

Windows Security Event4768 event logged for the

user from source ip

Page 10: Kerberos explained

How does it work?

Active Directory

Windows Security Event4768 event logged for the

user from source ip

Client machine caches the TGTThis is done once per session (until TGT expiration)

Page 11: Kerberos explained

How does it work?

Active Directory

Now the user wants to access server B

Page 12: Kerberos explained

How does it work?

Active DirectoryRequest for Service Ticket, containing:

• Name of target computer (server B)

• User’s TGT

• An authenticator, encrypted with user’s session key

Page 13: Kerberos explained

How does it work?

Active Directory

KDC validate the request (check encryption validity)

Page 14: Kerberos explained

How does it work?

Active DirectoryReturn a Service Ticket, containing:

• Session key to share with computer B, encrypted by User A key

• User A session ticket encrypted with Computer B key

Page 15: Kerberos explained

How does it work?

Active DirectoryReturn a Service Ticket, containing:

• Session key to share with computer B, encrypted by User A key

• User A session ticket encrypted with Computer B key

Windows Security Event4769 event logged for the

user from source ip to computer B

Page 16: Kerberos explained

How does it work?

Active Directory

Send the service ticket to computer B

Page 17: Kerberos explained

How does it work?

Active Directory

Validate the ticket authenticity: decrypt the service ticket with computer B ticket

Page 18: Kerberos explained

So what’s new? Scalable

◦ Servers do not need to contact KDC to authenticate users◦ Only users and machine account authenticate with the KDC, once per 10h of activity

Secure◦ Passwords are not sent over the wire◦ Ticket based authentication based on certificates trusts

Advanced Features◦ Single Sign-On◦ Delegation◦ Cross Domain Authentication

Page 19: Kerberos explained

Wait, machines need to authenticate?

Yes!!◦ Need to ensure that a Service Ticket is addressed and used only by the destination computer◦ The Service Ticket is encrypted by the machine account session key (shared with the KDC)◦ Only the target machine can validate the Service Ticket◦ This is why we see 4768 events and 4769 events for the machine account!

Page 20: Kerberos explained

4769 events with source=target When a user logins to a local computer, a session is created for him:

◦ It doesn’t matter if it is a remote session, or local interactive session◦ In both cases, the computer needs to know the user’s credentials (group membership and SID)◦ It uses a Service Ticket addressed to the local computer to do so◦ Works the same as if we contacted a remote servers◦ This is why we get a 4769 event with source equals to target after each login

Page 21: Kerberos explained

4769 with target equals domain controller?

After each login, the computer needs to pull Group Policy from AD:◦ Need to access the AD domain controller and pull the policy◦ To do so, we need to authenticate with the domain controller ◦ Authentication is done using Kerberos, just like any server access◦ This is why we get a 4769 event with target equals to a domain controller after each login

Page 22: Kerberos explained

So, what events are logged ?Event Type Account Source Destination

4768 Machine B Machine B

4768 Machine C Machine C

4768 User A Machine B

4769 User A Machine B Machine B

4769 User A Machine B Domain Controller

4769 User A Machine B Machine C

Tim

e

Page 23: Kerberos explained

Delegation A mechanism to authenticate on behalf of the user to 3rd party resources

Machine and account doing the delegation need to be trusted by AD

Used by most Windows based web servers (i.e. SharePoint, Sites backed by SQL Server)

User authenticate with the web server

Service Ticket passed to the SQL serverSource ip is the web server!

4769 event logged, with delegated flag set to true

(ticket options field)

Page 24: Kerberos explained

Cross Domain Authentication◦ The client first authenticate with the local domain, asking for a referral ticket◦ The referral ticket is encrypted by a inter-domain key◦ The client sends the referral ticket to the remote domain◦ The remote domain issues a Service Ticket granting access to the remote server

Page 25: Kerberos explained

Interesting Windows Security Events


Recommended