Kerberos Security in Windows Server 2003
Introduction to Kerberos Security in Windows Server 2003
My goal on this page is to introduce you to the basics of Kerberos. Rather like subnet mask and DNS, Kerberos is a complex topic where you need to read three separate accounts, or have three different people explain the concepts, before you truly appreciate all its security ramifications.
My aim is to help you understand what Kerberos will do for your security and to show you where to check or configure the settings.
Topics for Kerberos Security?
In Greek mythology, Kerberos was a three headed dog that guarded Hell. Fast forward to 1981 and MIT (Massachusetts Institute of Technology), where a researcher coined the name Kerberos to describe a security system he was developing. Microsoft's involvement with Kerberos came much later when they decided it was time to replace NT 4.0's NTLM security. So Windows 2000 was Microsoft's first system to implement this Kerberos security standard.
The principle behind Kerberos authentication is this: the domain controller's Active Directory knows the user's password and naturally the user know their password. So at logon, a hashed version of their password is sent to the domain controller, if it matches the stored password in Active Directory, authentication is successful and the desktop appears.
The point is that the domain controller must store an encrypted version of the password - plain text is taboo for storing passwords. The level of encryption is 56bit by default and can be increased to 128bit at least in the US.
Kerberos uses a single key to encrypt and decrypt the password. Other terms for this process are private key, single key, or shared secret. When the server stores the password it is said to be hashed and one way encrypted.
User accounts and computer accounts are referred to as security principals, indeed, everything that has a password is known as a security principal.
When it comes to configuring Kerberos you will see that it has two aliases. On domain controllers, when you check the Services, you see not Kerberos but the alias Key Distribution Center (KDC). Technically Kerberos is implemented as SSP and SSPI (Security Service Provider Interface). In addition to logon authentication, SSP ensures that data is not read or modified during transit. (SSP has no easy configuration interfaces.)
Once the user has been authenticated by the server, they are given a ticket. I think of the ticket as being attached to the Explorer, so where ever you explore your ticket gains (or denies) entry.
Your logon password gets you a ticket, when the user wants resources it presents this ticket rather than risking sending a password. This method allows for stronger encryption on the ticket than a password allows. For instance the ticket encryption includes time based elements which makes it difficult to intercept.
If users want resources from a different server they get a second Session Ticket which is only valid for a limited time for a particular purpose.
Provided the user remains logged on the tickets are renewed automatically. All of this underlying technology is hidden from the user and indeed from the administrator.
The default ticket lifetimes are controlled at the domain level by using
domain policy. The defaults are:
If you need to see more details of the tickets get Kerbtray from the resource kit. Or Click here
The main reason to monitor your network is to check that your all your servers are available. If there is a network problem you want an interface to show the scope of the problem at a glance.
Even when all servers and routers are available, sooner or later you will be curious to know who, or what, is hogging your precious network's bandwidth. A GUI showing the top 10 users makes interesting reading.
Another reason to monitor network traffic is to learn more about your server's response times and the use of resources. To take the pain out of capturing frames and analysing the raw data, Guy recommends that you download a copy of the SolarWinds free Real-time NetFlow Analyzer.
At login, clients need to contact their domain controllers. DNS provides the IP address of the domain controllers. When troubleshooting connection problems, I would first check that the client's TCP/IP settings. In particular I would use IPCONFIG /all to make sure the client can query the DNS server.
The next place I would examine is the SRV records on the DNS server. Windows 2003 clients use DNS's SRV records to locate domain
controllers, in particular they attempt to resolve the _ldap._tcp.dc._msdcs
SRV records. Windows 2000/3 domain controllers also publish SRV records for _kerberos
and _kpasswd services. The list of published SRV records can be found on a
domain controller in the following file:
Time Synchronization is crucially important for Kerberos, fortunately the built in Windows Time Service on XP and Windows 2000 Professional synchronises automatically with the PDC Emulator. (This is a special domain controller see FSMO) So, there is no need to create a special logon script for XP and W2K Pro clients.
KDC Service (Key Distribution Center)
Check that the KDC service has started on Domain Controllers, Administration Tools, Services.
Note Telnet and FTP do not use Kerberos
Kiwi CatTools is a free program for backing up configuration settings on hardware devices. Here is Guy's challenge. If you download CatTools, then it will not only take care of backups, but also it will show you something new about the hardware on you network. I could give you a money back guarantee - but CatTools is already free! Thus, I just make a techie to techie challenge, you will learn more about your network if you:
If you like this page then please share it with your friends