George Bryan's Notes

August 20, 2003 AD Meeting Notes:

Cross-Realm Issues with AD

I wanted to post the notes from the last AD meeting. The main topic for discussion was issues with Cross-Realm trusts and how it adversely effects AD. It is important that we carefully consider both sides of this issue.

Some General Information

• PeopleSoft Authentication
  Currently, general campus authentication into myUFL portal occurs when a user presents a valid set of GatorLink credentials to PeopleSoft. Once these credentials are validated via the campus LDAP server, PeopleSoft assigns a token as a memory resident cookie, PS_TOKEN, which is maintained to validate further access requests by the user during his/her session. PeopleSoft does not currently support direct authentication with Kerberos via the delivered sign on integration modules.
• Cross-Realm
  Cross-Realm trust is part of the initial AD design for the University of Florida. Its purpose was to tie authentication for AD to an existing university security mechanism. In the original diagram it looked as though AD and the MITKDC communicated directly but in reality the tokens are required at the workstation level requiring communication from the workstation to both the MIT KDC and AD Domain Controller. Failure to either point would cause login and access failure.
• Account Management
  Account management is a separate process. Accounts are synchronized for both LDAP and AD. These two accounts have identical logon ID. Attributes in the accounts for AD will observe all security and protection flags in addition to proper account provisioning, account deprovisioning will also be observed. AD accounts are populated from Campus Registry Data through SQL and MIIS. AD accounts are connected to MIT KDC through the "AltSecurityIdentites" attribute in the user object (viewable only through ADSI or Name Mappings in ADUC). This field is populated automatically when a user account is created. Account synchronization is a process separate from cross-realm. Open-LDAP is populated by a Perl script. Both sources use the Campus Registry as an authoritative source.
• Tickets from AD and MIT KDC
  Tickets are obtained from MIT KDC (1) and AD (2) at logon. These tickets should allow access to resources in both realms theoretically. Unfortunately it is not presently clear what ticket (1) will be used for. In addition, for UNIX resources to be accessed directly in most cases requires the installation of additional programs at the workstation level.
• Issues
  In general, there is a consensus that Cross-Realm adds complexity, multiple points of failure and is a security risk. This added to the fact that there no clear benefit has led to a request that it be removed from the initial charter and tabled until such time as a true campus wide benefit (reasons to do it) or methodology (way to safely implement it) be arrived at. Omitting Cross-Realm from the initial implementation seems to have no impact on availability of services. If anything it would lessen administration and simplify the end-user experience. It could be added at a letter date when there is a compelling reason to do so. The addition of this to the design increases the complexity of operations for both unit administrator and end-user.

Here are the issues that were brought last meeting up as CON's to adding Cross-Realm: Some are specific and some are General.

1. Windows XP Cached Credential logins.
   When a user places their laptop online and login using their Kerberos account they are logged in fine but when offline they can't login. This is due to an issue with Windows XP. Statement from Paul Hill at MIT: Users should be able to log in to a Win2k or XP machine while it is disconnected from the network using the cached credentials feature. MIT has experienced problems with this. This problem is still being investigated and may be addressed.
2. The Microsoft Remote Installation Service (RIS) does not support Kerberos.
   The Microsoft Remote Installation Service (RIS) does not support Kerberos authentication at this time. You will likely need at least some accounts in your Windows domain that do not rely on cross-realm authentication for using RIS. Long delays for fixes in cross-realm. In the case of XP the problem of denial of service has been known since XP's release December 2001. SP2 will correct this issue but it is due for release in Q3 of 2004.
3. An issue with with remote DC's when link to remote KDC is down.
4. Issues with single credentials.
   Confusion surrounding when to use AD credentials or Cross-realm credentials is a major issue with end users. Using Uppercase Letters for Kerberos Realm Names -> http://support.microsoft.com/?kbid=248807 This article was previously published under Q248807 SUMMARY -All Windows 2000 domains are also Kerberos realms. However the realm name is always the all uppercase version of the domain name. There is no way to have a Kerberos realm name that is different from the domain name. Because the Windows 2000 domain name is also a DNS domain name, the Kerberos realm name for the Windows 2000 domain name is always in uppercase letters. This follows the recommendation for using DNS names as realm names in the Kerberos V 5 protocol document (RFC-1510). This only affects interoperability with other Kerberos-based environments. Custom GINA wrappers might address this issue but it was the consensus of the group that installing custom GINA's on all workstations would be time consuming and problematic.
5. Increased points of failure.
6. Restricted upgrade ability.
   This is true on both sides. Paul Hill's example: If you have recently moved from Kerberos 4 to Kerberos 5, users who have not changed their passwords since the move will have to change them to update the encryption. Windows 2000 does not support the Kerberos 4 encryption. All applications in AD must be thoroughly LAB tested with cross-realm before they are sanctioned for release to UFAD.
7. Increased complexity for zero benefit.
   No kerberized applications currently and if they occur in the future these applications be configured to accept the token from AD.
• Client-side issues: KSETUP (included on the W2K CD in the x:\support\tools\support.cab file) or direct registry editing to configure clients for the correct MIT Kerberos realm and KDC.
• Encryption: When you install a W2K DC the default login encryption is set to "medium" security setting. If you have changed that to "high" you could have a problem after installing SP2. SP2, as you know, upgrades you to 128-bit over the default 56-bit. On the MIT KDC side the default is also 56-bit. Whatever the case both sides must match. So, if you had you W2K set to high and installed SP2 you would have to set the MIT KDC to 128-bit as well.
• Namespace ramifications: Since you are placing your domain in a DNS sub-domain you will need to consider DNS ramifications. If your computers are named-served in your sub-domain, then everything will work fine. If you name-serve your computers in root.edu (by selecting not to have the DNS suffix changed when joining the domain) you will have to set the computer's SPN or DNS hostname in the Active Directory for the Kerberos interoperability (and other functions) to work properly... etc. Some details taken from Brad Judy's document http://calnetad.berkeley.edu/documentation/test_environment/kerb_interop_trip-ups.html
• Patching for security becomes tricky and slowed:
  In light of recent security issues there are many concerns that patches that are necessary to maintain secure systems would somehow break the cross-realm mechanism. An example of this is SP2 for windows 2000 and SP1 for XP. Windows client team members have confirmed that SP2 will be delivered in 2004; the company's product lifecycle web site however indicates that it is scheduled for Q3 2004. http://www.theregister.co.uk/content/4/32430.html
8. Overall, while Microsoft has provided spotty support for cross-realm.
   The cross-realm functionality has not received priority in the past. It has taken as much as two years to address some issues.

It has been decided to go over the PRO's and CON's at the next meeting. Be there.

I will meet setup a meeting with Mike Conlon prior to this meeting and get his feedback, as promised, and present the issues. I have also asked the Higher Education discussion list for information on the PRO's and CON's and we will go from there.