We've all heard a lot of buzz about Kerberos Security in Windows 2000. Well what is it? The name "Kerberos" comes from a mythological three-headed dog that guarded the entrance to Hades. Invented by MIT, this form of security has been evolving in the Unix world for over a decade and is now becoming a standard. Many assume that a firewall makes them safe from attacks, however, statistics show that a large number of attacks happen from within a firewall. Kerberos security also addresses this issue in the same way that it prevents outside attacks. The way that this is accomplished is that passwords are not sent over the network in clear text making them unavailable to most sniffers and hacker tools.
The current version, Kerberos version 5, has been published by the IETF (Internet Engineering Task Force) as RFC 1510
What Does Kerberos Do?
The Kerberos security system protects electronic transmissions that get sent across the network. It does this by scrambling the information so that only the computer that's supposed to receive the information can unscramble it. In addition, it makes sure that your password never gets sent across the network, only a scrambled "key" to your password. Kerberos is necessary because there are people who know how to tap into the lines between the computers and listen out for passwords. They do this with programs called "sniffers".
What Versions of Kerberos are Available?
There are several versions of Kerberos available, the most common are:
Kerberos V4:
MIT Kerberos V4, Freely available.
Bones, Freely available.
Transarc AFS, Commercial.
DEC ULTRIX, Commercial.
Kerberos V5:
MIT Kerberos V5, Freely available.
OSF DCE Security, Commercial.
Unfortunately Versions 4 and 5 are based on completely different protocols and are not compatible.
Why are there difference distributions of version 4?
The specifications for Kerberos were available before MIT was recognised as the standard specification. As there was a need for security the designers of Transarc decided to implement their own security system. As a result Transarc's AFS Kerberos uses a different protocol but also understands the MIT Kerberos V4 protocol.
DEC's version of Kerberos is essentially the same as MIT Kerberos V4 with a few changes. The largest change being that the ability to perform any kind of end-to-end user data encryption has been removed in order to comply with export restrictions.
Bones provides the Kerberos API without using encryption and without providing any form of security whatsoever. It allows the use of software that expects Kerberos to be present when it cannot be (export restrictions).
Why are their difference distributions of version 5?
The DCE Security Server was based on an early MIT Kerberos V5 releases and has evolved independently of the MIT code base and as a result some minor incompatibilities exist.
Microsoft uses the MIT version and as a result the DCE would have problems communicating with the Windows 2000 standard set-up. This is due to the Kerberos V5 API which is not supported in the DCE version.
Kerberos in Windows 2000:
Kerberos security only works with computers running Kerberos security software. For Windows 2000, this means that when dealing with other Windows versions, NT Lan Manager will have to be used as these other systems do not support Kerberos security. Windows 2000 Professional will have a Kerberos client installed. MIT Kerberos V5 is used in Windows 2000 with extensions that permit initial authentication using public key certificates rather than conventional shared secret keys. This enhancement allows the protocol to support interactive logon with smart cards.
Encryption
The Windows 2000 implementation of Kerberos introduces a new encryption type based on the RC4 encryption algorithm and using an MD5 HMAC for a checksum. This offers an alternative to using the existing DES based encryption.
The RC4-HMAC encryption type provides a strong encryption, 128-bit key lengths.
The Logon Process
The simple way of describing the logon process is:
Once the user has entered a user name and password – security credentials – at the logon dialogue box, those credentials are passed to the computer’s local security subsystem.
The local security subsystem takes the domain name specified by the user during logon, and uses DNS to locate a domain controller in the domain – DNS SRV records.
When a domain controller is found, the local security subsystem contacts the Kerberos service – Key Distribution Centre (KDC) – at that domain controller, and requests a session ticket for the user. This session ticket will be used by the user’s computer to authenticate itself with the Kerberos service.
The Kerberos services also contacts Active Directory in order to authenticate the user.
The Kerberos service also accesses a global catalogue server to obtain the user’s Universal group membership information.
Once authenticated, the Kerberos service returns the requested session ticket to the user’s computer. This ticket contains the user’s SID and the SIDs of all groups that the user is a member of. This information will be used in all future negotiations with the Kerberos service.
The local security subsystem on the user’s computer sends a copy of the user’s session ticket to the Kerberos Service on the authenticating domain controller and requests another session ticket. This second ticket will be used to authenticate the user to the local computer’s workstation service and is known as a Workstation session ticket.
The Kerberos service authenticates the user’s session ticket using Active Directory and the global catalogue server.
Once authenticated a verified, the Kerberos service sends a Workstation session ticket containing a copy of the user’s session ticket to the user’s computer.
The Local security subsystem constructs a user access token consisting of the user SID and the SID of any groups that the user is a member of, from the Workstation session ticket.
The local security subsystem adds to the access token, any local group membership for the user, plus any local rights and permissions assigned to the user.
The local security subsystem then creates an environment – or process – for the user, to which it attaches the access token. This access token will then be used to identify and authenticate the user whenever this user attempts to access resources.
Technically what is happening when a user logs in by hitting CTRL + ALT + DEL?
First of all, we need a user so we will use User A. User A requires a machine to logon to so we will use Machine B. Both will have an account on the same domain, Domain C. When User A wants to log on to the network they begin with the Secure Attention Sequence (SAS) on computers with a standard Windows 2000 configuration (pressing CTRL +ALT +DEL).
Once this is done the local machines Winlogon service responds to the SAS by switching to the logon desktop and dispatches to the Graphical Identification and Authentication (GINA) dynamic-link library (MSGINA.DLL). The GINA is responsible for collecting logon information from the user, packaging it in a data structure, and sending everything to the Local Security Authority (LSA) for verification.
User A then gives their username, password and select Domain C on the dialog box before pressing OK. GINA then returns their logon information to Winlogon. This then sends the information to the LSA for validation by calling LsaLogonUser.
On receiving User A’s logon data, the LSA immediately converts their clear text password to a secret key by passing it through a one-way hashing function. It then saves the result in the credentials cache, where it can be retrieved when needed for ticket-granting ticket (TGT) renewal or for Windows NT LAN Manager (NTLM) authentication to servers that are not capable of Kerberos authentication.
To validate this logon information and set-up a logon session on the computer, the LSA must first obtain:
A TGT good for admission to the ticket-granting service.
A session ticket good for admission to the computer.
The LSA will get the tickets by working through the Kerberos security support provider (Kerberos SSP), which exchanges messages with the Key Distribution Centre (KDC) in Domain C.
The sequence is:
The LSA sends the KRB_AS_REQ (Kerberos Authentication Service Request) to the KDC in Domain C.
This has:
The user principal name, User A.
The account domain name, Domain C.
Pre-authentication data, which is encrypted with the secret key derived from User A’s password.
If the client’s pre-authentication data is correct, the KDC replies with KRB_AS_REP (Authentication Service Reply).
This has:
A session key for User A to share with the KDC, encrypted by the secret key created from User A’s password.
A TGT for the KDC in Domain C, encrypted with the KDC’s secret key.
The TGT includes:
A session key for the KDC to share with User A.
Authorization information for User A.
The authorization information includes:
The SID for User A’s account.
SIDs for security groups in the Domain C that includes User A.
SIDs for universal groups in the enterprise that include either User A or one of the associated domain groups.
The LSA sends the message KRB_TGS_REQ (Kerberos Ticket-Granting Service Request) to the KDC in Domain C.
This includes:
The name of the target computer, Computer B.
The name of the target computer’s domain, Domain C.
User A’s TGT.
An authenticator, encrypted with the session key shared by User A and the KDC.
The KDC replies with KRB_TGS_REP (Kerberos Ticket-Granting Service Reply).
This includes:
A session key for User A to share with Computer B, encrypted with the session key shared by User A and the KDC.
User A’s session ticket to Computer B, encrypted with the secret key shared by Computer B and the KDC.
The session ticket includes:
A session key for Computer B to share with User A.
Authorization information copied from User A’s TGT.
Having received User A’s session ticket, the LSA decrypts it with the computer’s secret key and extracts the authorization data. It then queries the local SAM database to discover whether User A is a member of any security groups local to the computer and whether any special privileges have been given on the local machine. It adds any SIDs returned by this query to the list taken from the ticket’s authorization data and then uses this to build an access token. A handle to the token is returned to Winlogon along with an identifier for User A’s logon session and confirmation that the logon information was valid.
Winlogon creates a window station and several desktop objects for User A, attaches the access token, and starts the shell process that will be used to interact with the computer. User A’s access token is then inherited by any application process that is started during the logon session.
Enabling Kerberos Event Logging on a Specific Computer
Windows 2000 offers the capability of tracing detailed Kerberos events through the event log mechanism. You can use this information when you troubleshoot Kerberos.
Start Registry Editor.
Add the following registry value:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Registry Value: LogLevel
Value Type: REG_DWORD
Value Data: 0x1
If the Parameters key does not exist, create it NOTE: Remove this registry value when it is no longer needed so that performance is not degraded on the computer.
Quit Registry Editor and restart the computer.
You can find any Kerberos related events in the system log. More information
Sniffing Kerberos:
Kerberos was known to be prone to sniffers soon after it was created, but due to the type of encryption used in Kerberos it was consider complicated enough and seen to be little risk. There have been many documents on how you would go about hacking a Kerberos network, but no-one had yet come up with a program to do this.
Due to the lack of activity in the area, comments from some vendors which over emphasizes the security of Kerberos was issued.
The user password never leaves the local machine with Windows 2000 using Kerberos security. It is never exposed to the network so it should not be able to be sniffed" [typical comment from NT security site]. This is wrong and a very dangerous thing to have been said.
A Kerberos login request contains pre-authentication data that is used by the Kerberos AS to verify the user’s credentials before issuing a TGT. The pre-authentication scheme that is used contains an encrypted timestamp and a cryptographic checksum, both of them using a key derived from the user's password.
The timestamp in the pre-authentication data is ASCII-encoded prior to the encryption and is in the form of YYYYMMDDHHMMSSZ. This provides a structured plaintext that can be used to verify a password attempt. If the decrypted result looks like a timestamp then the password attempt is almost certainly correct.
Now there is a tool for sniffing Kerberos networks. The tool is available here.
Helpful Terminology: Secure Attention Sequence (SAS)
A sequence of keys that begins the process of logging on or off. The default key sequence in Windows is CTRL+ALT+DEL.
Windows NT LAN Manager (NTLM)
The NTLM protocol was the default for network authentication in Windows NT 4. It has been retained in Windows 2000 for compatibility with down-level clients and servers. NTLM is also used to authenticate logons to standalone computers with Windows 2000.
Graphical Identification and Authentication (GINA)
A Graphical Identification and Authentication DLL, or GINA DLL, is a replaceable component of Windows NT and Windows 2000 that performs identification and authentication of interactive users. The Microsoft standard GINA DLL that is shipped with Windows NT and Windows 2000 operating systems is "msgina.dll". Microsoft allows the replacement of "msgina.dll" to allow the use of multiple GINA DLLs.
Local Security Authority (LSA)
A protected subsystem that authenticates and logs users onto the local system. In addition, the LSA maintains information about all aspects of local security on a system (collectively known as the local security policy), and provides various services for translation between names and identifiers.
Ticket - Granting Ticket (TGT)
This ticket is received from the Authentication Service (SA) that contains the client’s Privilege Attribute Certificate (PAC).
Authentication Service (AS)
This service runs on the Key Distribution Centre (KDC) server. It authenticates a client logon and issues a Ticket Granting Ticket (TGT) for future authentication.
Ticket Granting Service (TGS)
This service runs on the KDC server. It grants tickets to TGT holding clients for a specific application server or resource.
Ticket
This ticket is received from the TGS that provides authentication for a specific application server or resource.
Session Key
This is the derived value used strictly for the immediate session between a client and a resource.
Privilege Attribute Certificate (PAC)
This is strictly used in Windows 2000 Kerberos authentication. It contains information such as the user’s Security ID (SID), group membership SIDs, and users’ rights on the domain.
Winlogon
A component of the Windows NT/Windows 2000/Windows XP operating system that provides interactive logon support. Winlogon is designed around an interactive logon model that consists of three components: the Winlogon executable, a Graphical Identification and Authentication dynamic-link library (DLL).
Kerberos Security Support Provider (Kerberos SSP)
The Kerberos authentication protocol is implemented as a security support provider (SSP) that is supplied with the operating system. Windows 2000 also includes an SSP for NTLM authentication. By default, both the Kerberos protocol and the NTLM protocol are loaded by the LSA on a computer that is running Windows 2000 when the system starts.
Key Distribution Centre (KDC)
The service which implements Kerberos authentication via the Authentication Service (AS) and the Ticket Granting Service (TGS). The KDC has a copy of every encryption key associated with every principal. Most KDC implementations store the principals in a database, also known as the Kerberos database.
We've all heard a lot of buzz about Kerberos Security in Windows 2000. Well what is it? The name "Kerberos" comes from a mythological three-headed dog that guarded the entrance to Hades. Invented by MIT, this form of security has been evolving in the Unix world for over a decade and is now becoming a standard. Many assume that a firewall makes them safe from attacks, however, statistics show that a large number of attacks happen from within a firewall. Kerberos security also addresses this issue in the same way that it prevents outside attacks. The way that this is accomplished is that passwords are not sent over the network in clear text making them unavailable to most sniffers and hacker tools.
