This post describes the use of UDP versus TCP Kerberos in cross-forest access, Kerberos logging, network requirements, cross-forest user-based group policy processing and authentication protocols. I have used this information to provide firewall rules between forests, diagnose Kerberos issues and just generally have a better understanding of what's happening with cross-forest access in an enterprise environment. 53/TCP 53/UDP 88/TCP 88/UDP 123/TCP 123/UDP
Cross-forest management
Depending on whether a standard authentication request has been made, or whether an administrative function is performed can have an effect on whether Kerberos over TCP or Kerberos over UDP is used.
Using the standard GUI object picker, setting up trust relationships, or management scripting using ADSI/LDAP makes use of Kerberos UDP Port 88, whereas an actual authentication request - an interactive user logon - will use Kerberos TCP Port 88.
This is an important distinction when setting up firewall rules, although Kerberos can be modified to use only TCP if required.
Kerberos Logging and utilities
Turn on detailed Kerberos logging (see the 'Troubleshooting Kerberos Errors' reference for more information).
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters]
"LogLevel"=dword:00000001
Useful utilities:
- Kerbtray, klist - show/purge tickets and TGT information
- tokensz - Show the token size, useful for determining if the Privilege Attribute Certificate (PAC) data in the TGT will be over-sized, causing UDP transmission to fail.
Network Ports for Kerberos
Port requirements for Kerberos:Port Service Description DNS service The internal DNS server needs to be accessible to all clients for the location of KDC computers. The Active Directory domain controllers need to be able to access external DNS servers for resolving external domain name requests. Kerberos ticket-granting service All clients need to be able to connect to this port on the KDC servers. Time service All clients need to be able to connect to this port for time synchronization, either to an internal time server or to an external time source. The internal time server will need to connect to an external time source to synchronize. 464/TCP Microsoft Windows 2000 Kerberos change password protocol This port is also used by the kpasswd protocol. This port should only be open if clients use the kpasswd protocol.
Cross-domain Group Policy processing
When logging on to a computer in another domain with an account in a trusted domain, group policy is not applied by default. To change this behaviour, the 'Allow Cross-Forest User Policy and Roaming Profiles' policy setting must be set to enabled. If enabled, user policy will be applied from the user's forest, and roaming profiles will be available if configured and accessible.
Once cross-forest policy processing has been enabled, accessing that cross-forest Group Policy has the following requirements:
- SMB/NetBIOS over TCP/IP access to a Domain Controller in the users's domain from the machine being logged on to. This is not necessarily a DC in the computer domain, and could be a member server or workstation.
- LDAP over TCP from the local trusting Domain Controller (the computer account domain) to a trusted Domain Controller in the user forest
Cross-domain authentication References Documentation on domains and forests, including Kerberos and NTLM http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/4a1daa3e-b45c-44ea-a0b6-fe8910f92f28.mspx How to configure Windows 2003 SP1 firewall for a Domain Controller Domain and Forest Trust Tools and Settings How to force Kerberos to use TCP instead of UDP in Windows Server 2003, in Windows XP, and in Windows 2000 Active Directory Replication over Firewalls Troubleshooting Kerberos Errors Download token size
Many different scenarios exist for authenticating across domains and forests, depending on the request type, the domain trusts, the trust types, the OS types, name resolution and Active Directory domain levels.
In a default Windows 2000 or Windows Server 2003 domain, Kerberos is usually the protocol of choice. When Kerberos is unavailable, for example due to Network access or time synchronisation issues, NTLM/NTLMv2 will be used. Each protocol has different requirements.
Excerpt from the references below: In an Active Directory environment the Kerberos-based authentication process is most commonly used. To access a shared resource in another domain by using Kerberos authentication, a computer where the user logs on first requests a ticket from a domain controller in its account domain to the server in the trusting domain that hosts the requested resource. This ticket is then issued by an intermediary trusted by both the requesting computer and the server. The computer then presents this trusted ticket to the server in the trusting domain for authentication. This process, however, becomes more complex when a workstation in one forest attempts to access data on a resource computer in another forest.
In this case, the Kerberos authentication process contacts the domain controller for a service ticket to the SPN of the resource computer. Once the domain controller queries the global catalog and determines that the SPN is not in the same forest as the domain controller, the domain controller sends a referral for its parent domain back to the workstation. At that point, the workstation queries the parent domain for the service ticket and continues to follow the referral chain until it reaches the domain where the resource is located. For more detailed information about how authentication requests are processed across domains and forests, see 'How Domain and Forest Trusts Work.'
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/c22cda18-263a-4ba7-a71e-76c68c217a25.mspx
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/f5c70774-25cd-4481-8b7a-3d65c86e69b1.mspx
http://support.microsoft.com/default.aspx?scid=kb;en-us;555381&sd=rss&spid=3198
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/108124dd-31b1-4c2c-9421-6adbc1ebceca.mspx
http://support.microsoft.com/default.aspx?scid=kb;en-us;244474
http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/deploy/confeat/adrepfir.mspx
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx
http://www.microsoft.com/downloads/details.aspx?FamilyID=4a303fa5-cf20-43fb-9483-0f0b0dae265c&displaylang=en
Wayne's World of IT (WWoIT), Copyright 2008 Wayne Martin.
2 comments:
Wayne,
I have a question about Cross Forest Authentication and AD Sites/Subnets. Given that sites from Forest A are not respected on computers in Forest B, how can I isolate the traffic to a specific list of DCs in Forest A? I have a firewall between the two networks and do not want to permit all clients in Forest B to talk to all DCs in Forest A.
Hi Greg, sounds like you need cross-forest site synchronisation - enabling clients in one forest to understand the topology of another forest when using the DC locator.
Essentially this would mean that Forest B would contain sites from Forest A and a site link between the forest B client site and Forest A's site (in Forest B). When Client B or DC B wants to talk to Forest A, it would then be able to determine the closest site and query DNS for a DC in that site (assuming Forest B has access to Forest A's msdcs).
Have a read of this post and the references in the post:
http://waynes-world-it.blogspot.com/2008/06/cross-forest-authentication-and-site.html
Post a Comment