| |
|
|||
| ESTABLISH KERBEROS AUTHENTICATION IN WIN2K NATIVE DOMAINS 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 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. NATIVE-MODE AUTHENTICATION 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 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. TROUBLESHOOTING FAILED KERBEROS AUTHENTICATION 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: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters Registry
Value: LogLevel 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.) FINAL THOUGHTS 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, 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. |
||||