Ondřej Ševeček | PM Windows Server | GOPAS a.s.

|
MCM: Directory Services | MVP: Enterprise Security |
ondrej@sevecek.com | www.sevecek.com |

KERBEROS

Why Kerberos

 Stronger authentication
 About 10 times
 Limited attack surface
 Smart card logon
 Delegation
 Protocol Transition
 Logon by any means defined by the application
not using the hash values from AD
Stronger security

 Encryption algorithms
 NT Hash MD4
 can AES (details later)
 Includes user name, domain and timestamp
within exchange
 Prevents reply attacks
 Mutually authenticates all three sides of the
exchange
 Client, DC, Server

Stronger security

 User password use and transmission is limited to

the point of logon
 From that point on only independent “session” keys
are used for further authenticating the exchanges
 Session keys are generate by DC
 And as such their quality doesn’t depend on any
computer, just the solid implementation of the DC
 Target server never receives the user password
 Requires rekeying
RC4, DES and AES

 RC4 by default for Windows 2k-2k3

 DES if enabled in policy for Windows 2k-2k3
 Use FIPS compliant algorithms
 AES
 Windows Vista+
 domain level 2008+
 msDS-SupportedEncryptionTypes
 DES disabled on Windows 2008 R2
 AES256-CTS-HMAC-SHA1-96
 AES128-CTS-HMAC-SHA1-96
 RC4-HMAC

AES Scenarios

Scenario AES

any DC 2003 never

all DCs 2008+ never

domain level 2003-
all DCs 2008+ no
target server 2003-
all DCs 2008+ yes
target server 2008+
Authentication compared

NTLM
Client Server

Pass-through

DC

Authentication compared

Ticket
Client Server

Password

Ticket

DC
Social example

Ticket Theatre
Pensioner
Usherette

Social ID
ID Card Address
Married

Ticket

Ticket office

Demo: Service tickets

 Show, that clients have tickets for services

such as HTTP and CIFS, LDAP etc.
 Use either Kerbtray or KLIST
Trust?

Ticket
Client Server

Trust

DC

In-band vs. out-of-band

Client Client Server

HTTP

Kerberos
UDP/TCP 88

DC
Without Delegation
Impersonation Anonymous

Client Web DB

DC

With Delegation
Impersonation Impersonation

Client Web DB

DC
Principles

 Requires DC or so called KDC

 Key Distribution Center
 Kerberos Domain Controller
 Requires correct system time
 Is not challenge-response but timestamp based
 Generates two types of tickets
 TGT – Ticket Granting other Tickets (user ticket)
 TGS – Ticket Granting Service (service ticket)
 Tickets use is time limited

Ticket

 Authentication of the user

 Authentication of the KDC/server
 Secure transmission of session keys
Authentication Request

Client Server

Password

TGT

DC

Service Request
TGT

Client Server

TGT I am Client

Give me TGS for Server

TGS
DC
Service Request
TGT
TGS
Client TGS Server

DC

Lab: Tickets

 Use machines from Kerberos Name/IP lab

 Machines DC1, WEB, Vista1
 From Vista1 try accessing http://web, \\dc1,
\\web, MSINFO32 against web
 Using KERBTRAY and Network Monitor look
at the ticket generation and the ticket cache
TGT – User ticket

 User sends his login and password to KDC

 Encrypted certainly
 KDC validates this information
 Generates a TGT which is in turn send back to
client
 If the client needs anything further from the
KDC, he uses TGT instead of his password
 After the TGT expires (by default 10 hours) it can
be renewed for some time still without using
password

TGT – User ticket (simpl.)

Encrypted by
Encrypted by
user’s password
KDC’s password

Login Login

Time Generated Time Generated

Time Expires Time Expires

DC Group User DC Group User

Membership SID Membership SID
TGT principles

 KDC knows the user’s password, so it could

generate the user’s part
 User knows his own password so he can read
what is inside the ticket
 KDC has its own password, so when the client
presents the TGT, KDC can decrypt it and look
what is inside
 User is not able to modify the KDC’s contents
because he does not know the user’s
password

KRBTGT account password change

 Can be done from console

 Special logic
 AD ignores the supplied password and generates
its own random password
 may collide with custom password filters
occassionaly
 Password history - 2 passwords
Reasons to reset KRBTGT

 Not yet populated with AES encryptors

 Forest recovery to prevent invalid DC data
from inbound replication if not possible to
turn them off
 After a security incident

TGT and Pre-authentication

Client Server

nothing?

User
TGT
password
DC
TGS – Service ticket

 If the user wants to access any server he takes

his TGT and requests a ticket for the server
 KDC validates the TGT and creates a new
ticket for that particular server called TGS
 TGS is sent back to client
 Client itself uses the ticket for further
communication with the server

TGS – Service Ticket (sim.)

Encrypted by
Encrypted by
user’s password
server’s password

Server Server
Login Login
name name

User-Server User-Server
Session key Session key

Time Time Time Time

Generated Expires Generated Expires

DC Group User DC Group User

Membership SID Membership SID
TGT and Pre-authentication

Server’s
TGS
Client password Server

TGT

Server’s
TGS
password
DC

TGS principles

 KDC knows the user’s password, so it could

generate the user’s part
 User knows his own password so he can read
what is inside the ticket
 KDC knows the password of the server, so it
could generate the server’s part
 When the TGS is presented to the server, server
knows its own password, so it can decrypt it and
read what is inside
 User couldn’t modify the server’s part, because
he does not know server’s password
Session keys

 KDC always generates a session key for any

ticket it issues
 This limits the use of user’s password for
encryption
 Even the TGT has the session key
 Client-KDC session key
 TGS tickets are not encrypted by user’s
password, but by the Client-KDC session key

Key usage frequency

User password

Server password

KDC password

TGT session key

TGS session key

User password 40 days

Server password 30 days

KDC password 8 days

TGT session key 10 hours

TGS session key 10 hours

TGT – User ticket in detail
Encrypted by
Encrypted by
user’s password
KDC’s password

KDC KDC
Login Login
name name

User-KDC User-KDC
Session key Session key

Time Time Time Time

Generated Expires Generated Expires

DC Group User DC Group User

Membership SID Membership SID

TGS – Service ticket details

Encrypted by
Encrypted by
User-KDC Session Key
Server’s password

Server Server
Login Login
name name

User-Server User-Server
Session key Session key

Time Time Time Time

Generated Expires Generated Expires

DC Group User DC Group User

Membership SID Membership SID
Pre-authentication

 The TGT for a specific user could be obtained

even anonymously
 but the anonymous user would get some piece of
data encrypted by the user’s password
 TGT request should then be pre-
authenticated by user’s password
 It does not use the challenge-response
method
 Instead, it uses timestamps to limit the replay
attacks

Pre-authentication details

Client
I want TGT, please

My login is …

Encrypted by my password

My login is …

My current time is …

KDC
TGT request discussion

 Only the user and KDC know the user’s

password
 If KDC could decrypt the request, it must
have been created only by the user
 This is to prevent anonymous obtaining of
data encrypted by user’s password
 Reply is prevented only on the same DC
 It does not matter because if the attacker was
able to intercept authenticator, he would have
the encrypted data anyway

UPN and SPN

 UPN – User Principal Name

 The login of a user
 ondra@gopas.virtual
 This is searched for by KDC to find the user’s
password in its database
 SPN – Service Principal Name
 The name of the server requested by the user
 This is searched for by KDC to find the server’s
password in its database
SPN definition

 Client application requests a ticket for a

specific name provided by user
 If the name does not exist in the KDC
database, the ticket cannot be issued
 SPN format
 service/server.name.com:port
 service/ip.ip.ip.ip:port
 Port number is used only when required by
the server

Common SPNs

 HTTP, CIFS, LDAP

 MSSQLSVC/sql$INSTANCE
 TERMSRV
 RPCSS/CA
 ExchangeAB/DC1, ExchangeAB/DC2,
ExchangeRFR/MBX, ExchangeMDB/MBX
 SMTPSVC
 WSMAN/DC1
Configuring SPN

 SETSPN -a “http/portal” web04

 SETSPN -a “http/portal.gopas.virtual” web04

Service Principal Names

TGT
TGS
TGS Service
Client
Account

Server

DC
Configuring SPN

 SETSPN -a “http/portal” sharepoint-user

 SETSPN -a “mssqlsvc/portal” sql-user
 SETSPN -a “cifs/portal” web04

SETSPN

 A – adds a SPN to a computer or user account

 D – deletes a SPN from a user or computer
account
 L – lists SPNs for a user or computer account
 Q – searches for a SPN on all user and
computer accounts
SPN facts

 Cannot be assigned to more than one user or

computer object
 Can be either service specific or (quite) generic
 host/server5.gopas.virtual
 sPNMappings in CN=Directory Services,CN=Windows
NT,CN=Services,CN=Configuration,…
 Can also contain short names, but this is seldom
required
 http/web
 Can also specify an IP address, but Vista+ does
not use Kerberos for IP addresses

SPN facts

 When there is a CNAME alias, client usually

tries to ask for its real target SPN
 When A alias is used, there must be the SPN
defined manually
Example: SQL Server SPN

 Self registrated by SQL Server service

 DSACLS CN=sql-server-usr,OU=... /G
self:WP;servicePrincipalName

Troubleshooting tips

 Check the aliases for CNAME or A

 IP addresses are using NTLM
 Only local intranet zone is using Kerberos
 Not even Trusted Sites use Kerberos
 Kerberos can be turned off in internet
explorer
 Settings – Advanced – Use Windows
Authentication
 Check time zone
Demo: Show DNS Update keys

 DNS uses DNS/dc1.gopas.virtual SPN

 All traffic is transferred in UDP 53 DNS
packets
 The keys are generated by KRB_AP exchange

Supported Encryption Types

 msDS-SupportedEncryptionTypes
 Service Accounts does not specify it
 Configure the value manually to enable AES
for the TGS
ETypes

ETypes
LAB: Kerberos Name/IP

 Machines DC1, WEB, Vista1

 From Vista1 try accessing http://www. It should
not work.
 Use PORTQRY -n www -e 80 to determine TCP
port availability
 From Vista1 try accessing http http://10.10.0.12
 Use kerbtray to determine that you have a
http/www ticket
 Determine the reason by using SETSPN -q
command and repair the problem

LAB: Kerberos and user

account
 Machines DC1, WEB, Vista1
 From Vista1 try accessing http://www. It should
not work.
 Use PORTQRY -n www -e 80 to determine TCP
port availability
 From Vista1 try accessing http http://10.10.0.12
 Use kerbtray to determine that you have a
http/www ticket
 Determine the reason by using SETSPN -q
command and repair the problem
LAB: Only Kerberos possible

 Machines DC1, WEB, Vista1

 From Vista1 try accessing http://www. It should not
work
 Use PORTQRY -n www -e 80 to determine TCP port
availability
 From Vista1 try accessing http http://10.10.0.12. It
should not work. NTLM is disabled (do not change
this)
 Use kerbtray to determine that you do not have a
http/www ticket
 Determine the reason by using SETSPN -q command
and repair the problem

Lab: duplicate SPNs on computer

accounts
 From client workstation re-join a machine to
a different domain in the same forest
 do not remove the original account
 Try logging on to the workstation
 you will get a nonsense error about mission trust
account
Ticket renewal

 "TGS" request even for a TGT renewal

 TGT renewal asks for krbtgt/gopas.virtual
 ReqBody -> KdcOptions -> KrbFlags -> Renewal
 TGT renewed ca 25 minutes before expiration
 automatic by LSASS, no traffic necessary
 after expiration, TGT cannot be renewed (the
"renew time" has no function)
 TGS never renewed, just a new request 15
minutes before expiration

Kerberos

TIME SYNCHRONIZATION
Time constraints discussion

 Couldn’t the request be used later?

 No
 Shouldn’t the client and KDC have absolutely the
same system times?
 No
 KDC actually remembers the timestamps it
received from clients
 It cannot remember its own time, it just remembers
what was received
 To limit the number of timestamps KDC has to
remember, there is the 5 minutes requirement

Time constraints discussion

 What about client with a too large skew?

Wouldn’t he log on?
 No, he would
 KDC just rejects the original request and tells the
client to use a different time instead
 Client does not adjust its own clock, it only
recreates the ticket request
 The resulting TGT is either expired or not
effective yet from clients perspective
 But it does not matter to the client, but the server
Client time skew

1.1. 1.1.
2006 2008
Client KDC

1.1.
Try it again with 2008
1.1. 2008
Client KDC

Client time skew and ticket

1.1. 1.1.
2006 2008
Client KDC

Ticket
1.1.
From 1.1.2008 2008
Client KDC
To 2.1.2008
Client time skew and ticket
Ticket
1.1.
From 1.1.2008 2006
Client Server
To 2.1.2008

1.1.
2008
KDC

Time synchronization

PDC
Root Domain

PDC PDC
Child Domain Child Domain

Client
DC
Child Domain Server
Reliable Time Source

 AnnounceFlags
 10 = 2 + 8 = time service auto, reliable auto (DC)
 5 = 1 + 8 = time service yes, reliable yes (PDC)

Time Difference Too Big

 HKLM\System\CurrentControlSet\Services\W
32Time\Config
 MaxPosPhaseCorrection
 MaxNegPhaseCorrection
 Windows 2000/XP/2003
 no limit
 Windows Vista/2008+
 48 hours = 0x2A300 = 172800
Kerberos

PRIVILEGE ATTRIBUTE
CERTIFICATE

PAC

 Privilege Attribute Certificate is a ticket

extension which contains user groups
 User groups are included in the form of SIDs
 Global groups from the user’s logon domain
 Universal groups from all domains
 Domain Local groups from resource domain
 After logon Access Token is constructed
locally
PAC
 _KERB_VALIDATION_INFO
 PrimaryGroupId = ULONG
 UserId = ULONG
 LogonDomainId = SID
 GroupCount = ULONG
 GroupIds = p * PGROUP_MEMBERSHIP (RelativeId)

 SidCount = ULONG
 ExtraSIDs = q * PKERB_SID_AND_ATTRIBUTES

 ResourceGroupDomainSid = SID
 ResourceGroupCount = ULONG
 ResourceGroupIds = r * PGROUP_MEMBERSHIP (RelativeId)

PAC and TGS

Global Groups from user’s domain 8B

TGT Universal Groups from user’s domain 8B

Universal Groups from other domains 40 B

Domain Local Groups from resource domain 40 B

TGS
 PAC and TGS
Kamil S-1-5-IDTT-1158
Marketing Global 3082 8 Bytes
Sales Global 3083 8 Bytes
ParisVisitors Domain Local S-1-5-Paris-2115 40 Bytes
Paris
RomaManagers Domain Local S-1-5-Roma-1717 40 Bytes
Roma
Documents Domain Local S-1-5-IDTT-3084 40 Bytes
IDTT
Business Owners Universal 3085 8 Bytes
IDTT
Employees Universal S-1-5-Paris-2116 40 Bytes
Paris

Access Token Size

 Access Token is limited in size

 1025 groups of whatever type
 Cannot log on with more groups
 “During logon attempt, the user’s security
context accumulated too many security IDs.”
Kerberos Ticket Size

 HKLM\System\CurrentControlSet\Control\LS
A\Kerberos\Parameters
 MaxTokenSize = DWORD = 0-65535
 Windows 2000 defaults to 8000
 Windows 2003 defaults to 12000
 must be set on all domain members
 Windows 2012/8 defaults to 42500

TGS and HTTP

 Problem with HTTP.SYS Header size

 By default limited to 16386 B for each header
 MaxRequestBytes
 Kerberos tickets Base-64 encoded into the
header
 About 12000 B ticket exceeds the limit
Windows 2012+ KDC

 Resource SID compression

 newly uses the ResourceGroupIds member of PAC
 previously only the ExtraSIDs was used
 Disable by
 msDS-SupportedEncryptionTypes = 0x80000
 HKLM\System\CCS\Service\KDC\Parameters
 DisableResourceGroupsFields = DWORD = 1

PAC Validation
svc-user TGS
Service running under
PAC svc-user identity

Create Access Token PAC

Operating System LSASS

SMB Secure Channel

DC
PAC Validation Error

Windows 2008 Improvements

 Limit PAC validation performance problems

 TGS should be for computer identity
 Release users from SPN creation overhead
 TGS should be for computer identity which has
SPNs created automatically
Windows 2008 Improvements

 IIS Kernel Mode Authentication

 Service Accounts
 NT Service\MSSQL$IS
 NT Service\MSSQL$Portal
 IIS: AppPoolIdentity

Delegation

 There are services that require impersonation

of the user
 This is achieved by the TGS
 But the service sometimes needs to forward
the same credentials further back to some
other service
 If the user and KDC allows it, the service can
itself ask for a TGS for the backend server
Delegation
TGT Web

Client Web DB

Web DB

DC

Types of delegation

 Unconstrained delegation
 To any backend server/service
 The proxy service must have user’s TGS for itself
 Windows 2000+
 Constrained delegation
 To a specified service (SPN) only
 The proxy service must have user’s TGS for itself
 Windows 2003+ Domain Functional Level
 Protocol transition
 To a specified service (SPN) only
 The proxy service does not need anything
Security considerations

 In general, it is a severe security issue

 The client does not actually know about the
Web server asking for the backend credentials
 The web server’s administrator could ask for a
ticket for any backend server if not limited
 Windows 2000 cannot limit the server name
 Windows 2003+ can limit the backend services
explicitly

LAB: Delegation

 Machines DC1, WEB, Vista1

 From Vista1 try accessing http://www. It
should work, but the list of users nor the
remote files should be accessible
 On WEB determine identity that runs the
DefaultAddPool
 Enable delegation corretly, so that the
http://www access works completelly
DNS integration

 U/SPN suffix is queried in DNS to find KDC

 Without DNS Kerberos will not work
 For example: ondra@gopas.virtual

 NSLOOKUP
 SET Q=SRV
 _kerberos._tcp.gopas.virtual
 _kerberos._tcp.Berlin.sites.dc.gopas.virtual

Trusting domain local logon

Kamil

SRV5
Paris Trust

Berlin
 Trusting domain local logon

Kamil

SRV5
Paris

TGT
Berlin

TGS

Multi-domain environment
2

TGS Czech

Europe 3

TGS Prague
1

TGT Kamil
Czech 4
TGS Europe TGS Server

Paris
Prague
Kamil
Server
Multi-domain facts

 Client’s computer must be able to find any

domain by using DNS
 _kerberos SRV record especially
 Client’s computer will connect directly to the
KDC of each domain
 Client’s computer will query all domain along
the trust path from its logon domain to that
of the server
 Here come the shortcut trust usage
 Kerberos trusts are transitive

Network Load Balancing

 Balanced web servers have each a different

computer account
 All of them appear as a single name to the
network
 When user requests TGS for such a single
name, there must be only a single SPN for
both the servers
 You must run the application under a
common domain user account which will
have the SPN configured
Network Load Balancing

SRV1

http/intranet.company.com

NLB
SRV2
Switch

10.10.0.20

SRV3

Network Load Balancing

SRV1
web-user

http/intranet.company.com

NLB
SRV2
web-user
Switch

10.10.0.20

SRV3
web-user
Clustering
Exchange MBX
SRV1
SRV1
ExchangeMDB/mbx.company.com

Switch SRV2

SRV3

Clustering

SRV2
SRV1
ExchangeMDB/mbx.company.com
Exchange MBX

Switch SRV2

SRV3
Clustering

MBX$
SRV1
ExchangeMDB/mbx.company.com
Exchange MBX

Switch SRV2

SRV3

Linux/MIT integration
Protocol transition

Client ISA Server Web

TGT Web
Certificate

I have nothing, give me

ticket for Judith
Ok, you are welcome
DC

Protocol transition

 Trust computer for delegation to any service

 Must be enabled by a domain administrator
 Should be enabled only for some back-end
services

 Is extremely security sensitive

 The service can generate TGTs for virtually
any user providing just his UPN
Demo: Hell secured by
Kerberos

 By using the Hell application demonstrate the

fact protocol transition can log users on
without even knowing their passwords
 Such logged on users can then access beck-
end resources as normal users could

Demo: ISA Server certificate

authentication
 ISA Server can secure private web server
access (such as OWA) by requiring a user to
provide a certificate for logon
 ISA Server must be member of a domain
 Protocol transition must be enabled for the
computer account
 Users must be issued certificates with valid
UPNs in SAN
 Subject Alternative Name extension
 LAB: ISA Server protocol
transition

 Machines DC1, WEB, Vista1, FW

 Log on to Vista1 as a user
 Generate a user certificate for the Vista1 user
 Move Vista1 computer to 80.0.0.101 external
IP address
 Make WEB IIS DefaultWebSite run under
web-user account

LSASS 2003 CTRL-ALT-DEL

Login + password

Server Process
Login + NTHash

Process DC
TGT
Process
Server
TGS
TGS
TGS
Process

LSASS
 LSASS Vista CTRL-ALT-DEL
Login + password

Server Process
Login + Heslo + NTHash

Process DC
TGT
Process
Server
TGS
TGS
TGS
Process

LSASS

Credentials delegation

 Credentails Provider
 DLL which appear on logon screen and provide
credenetials for logon
 Can delegate default (logon) credentials to
network servers
 Can delegate freshe/saved credentials to
network servers
RDP Requires Clear Password

Full
SSL
Client Password Server

Local Logon

TGT

DC

Incorrect!
Client
Full
MSTSC TGS Server
Password

IE

Full
Virus
Password

LSASS.EXE

Full Text
Password
Credentials Delegation Public
TGS Private
Client

MSTSC TGS Public Server

IE
Public Password

Virus

Public Password
LSASS.EXE

Full Text
Password

Credentials Delegation

 Terminal Server
 Windows 2008+
 Windows Vista+
 Client
 MSTSC 6.0+
 Windows Vista+
 Windows XP SP3 (KB 951608)
Note about Negotiate

 Security Service Providers (SSPs)

 Negotiate
 NTLM
 Schannel
 Schannel
 SSL Client Certificate authentication
 Negotiate
 Kerberos
 fallback to NTLM

Negotiate

 Can be used only when a DC available

 KB891559
 Tries to use Kerberos first
 If not possible falls back to NTLM
 HTTP offers
 WWW-Authenticate: Negotiate
 WWW-Authenticate: NTLM
 Negotiate can be disabled in IE
 Enable Windows Integrated Authentication
IIS Notes
 useKernelMode
 authenticates in kernel mode (no PAC validation)
 enables switching over apppools without reauthentication
 requires machine TGS
 useAppPoolCredentials
 with Kernel Mode Authentication requires TGS for the apppool
identity
 AuthPersistNonNTLM
 default = False
 authPersistSingleRequest
 default = False
 nego2 (Negotiable 2) cannot be used with Kernel Mode
Authentication

Takeaway

 Kerberos is more difficult to crack

 Kerberos does not send passwords through
the target server
 Kerberos works only for names/SPNs
 Kerberos allows for delegation and protocol
transition
 Kerberos sometimes requires time
synchronization