Q: I read that the Kerberos authentication protocol mighty fail in environments that use Network Address Translation (NAT) or DHCP. What is causing Kerberos authentication to fail in these environments? Is this something I need to worry about in my Windows Active Directory (AD) environment?
A: A Kerberos ticket has an optional field called “client addresses” that can contain the IP addresses of the Kerberos client that's authorized to use that particular ticket. The Kerberos Key Distribution Center (KDC--each Windows 2000 and later domain controller hosts a Kerberos KDC service) can use this field to check whether the ticket was sent from the client that initially requested the ticket. As such, the KDC can detect ticket replay attacks in which an impostor tries to impersonate a client by intercepting the client’s ticket and sending it to the KDC to obtain other tickets on the client’s behalf.
If the KDC checks and validates client addresses, Kerberos authentication will fail when Network Address Translation (NAT) is used on the communication link between the Kerberos client and the KDC. Authentication will also fail if the Kerberos client has received a new IP address from a DHCP server while its old address is still in its Kerberos ticket. In these scenarios, you might want to disable the inclusion of client IP addresses in Kerberos client ticket-granting ticket (TGT) requests or disable the checking of these IP addresses on the KDC. The following paragraphs explain how Windows uses the Kerberos client addresses field and how you can control this behavior in Windows 2003, XP, and Win2K. Windows 2003, XP, and Win2K Kerberos clients don't automatically send their client addresses and don't automatically request their client addresses to be included when they request a ticket from a KDC. When a ticket doesn't include client addresses, it can be used from all addresses. This also means that by default, the Kerberos client addresses field won't pose problems when Kerberos is used in NAT or DHCP environments.
You can control Windows Kerberos “client addresses” behavior by using the ClientIPAddresses (REG_DWORD) registry key located in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters registry folder. If this key doesn't exist or is set to 0, the Kerberos client won't include its client addresses in a ticket request (which is the default behavior).
For non-Windows KDCs (for example UNIX or Linux KDCs) that do require client addresses, you can selectively require the inclusion of client addresses on Windows clients for a particular Kerberos realm. You can do this using the ksetup Support Tools utility. The following command will make a registry change on a Windows client that will tell it to send its client addresses when it requests a TGT from a KDC in a realm named Unixrealm:
ksetup /setrealmflags Unixrealm sendaddress
In Windows 2003, Microsoft also added new registry keys to control KDC behavior for client address checking and client address propagation. Both Win2K and a Windows 2003 KDC will, by default, check client addresses it they are present and won't propagate them to the new tickets it generates. To reverse this default behavior in Windows 2003, you must use the KdcUseClientAddresses and KdcDontCheckAddresses registry keys (both REG_DWORD) that are located in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Kdc registry folder. Setting both keys to a value of 1 will disable client address checking and will enable client address propagation to newly generated tickets. If the KdcDontCheckAddresses key doesn't exist or is set to 0, the KDC will check client addresses. If the KdcUseClientAddresses key doesn't exist or is set to 0, the KDC will not propagate client IP addresses to tickets.
