When it introduced Windows 2000 domains, Microsoft changed its default authentication scheme from NT LAN Manager (NTLM) to Kerberos. Microsoft knew that its authentication sequence was vulnerable to packet sniffing on the local area network (LAN) and turned to a solid and well-documented UNIX-based solution to secure this initial client traffic.

Client-server authentication uses Kerberos only if all the devices--clients, domain controllers (DCs), and file servers--involved in
the authentication and file-sharing process are Win2K or later and members of the same domain or forest. Microsoft ensured legacy authentication compatibility by offering two different domain structures.

Windows 2000 domains can operate in either mixed mode (contains pre-Win2K clients or servers) or native mode (all Win2K or greater clients and servers). In native mode, the logon process and the ports and protocols used to validate the process are very different from the sequence of events that occurs during logon in a mixed-mode domain.


In a nutshell, here's what happens when a user logs on to a client in a native domain:

1. After the user enters his or her security credentials (i.e., username and password) in the logon dialog box, the client passes those
credentials to the local security subsystem.

2. The client sends a domain name service (DNS) request to find the DC for the domain name the user specified.

3. After the client has the DC's IP address, the client contacts the Kerberos service on the DC and requests a session ticket for the user.

4. The DC authenticates the user via Active Directory (AD) and contacts the global catalog server and retrieves the user's Universal Group membership information.

5. If the user is authenticated, the DC gives the user a valid client session ticket.

6. The client sends a copy of the client session ticket back to the Kerberos service on the DC.

7. The DC sends a workstation session ticket back to the client to authorize the user to proceed with logon.


If you're experiencing problems with Kerberos authentication at the client (e.g., you discover a client is suddenly using NTLM authentication, or it can't authenticate with a Win2K file server), there are two easy solutions for finding the problem. You can verify that the proper ports and protocols are open between the client and server, and you can enable Kerberos event logging on the client to troubleshoot the authentication process.

Verify Ports and Protocols

The client authentication and logon sequence can use either UDP 88 or TCP 88, depending on the size of the datagram that bounces back and forth between the client and DC. If the Active Directory information for the client is fully populated, the datagram will probably exceed the 1,500-byte limit of a single Ethernet UDP packet and will be sent as a packet via TCP. To be safe, open both protocols and ports in either direction between your clients and their DC.

Additionally, the client will need DNS service to locate the DC, so make sure that TCP 53 is open between the client and the servicing DNS server.

Enable Event Logging

To enable event logging of Kerberos activity, start the Registry Editor (Regedt32) and add the following value:


Registry Value: LogLevel
Value Type: Reg_Dword
Value Data: 0x1

This will populate the system log with events for Kerberos activity. This logging can slow your client's processor to a crawl, so remember to remove this key once you solve the problem. (Read Microsoft article 262177 for detailed information on Kerberos-related events.)


Windows-based networks rarely have anything to brag about when it comes to security. However, thanks to the hard-working techs at Massachusetts Institute of Technology who developed this authentication mechanism,
Microsoft networks can benefit from Kerberos' solid UNIX roots, and the security of your internal authentication traffic will increase dramatically once you shed your pre-Win2K clients and servers from your network.

NOTE: Editing the system registry is risky. Before making any registry edit, be sure to first back up the registry so you can restore it if something goes wrong.