Windows 2000-MIT Kerberos Interop Trip-ups Draft 2002-04-01

Below are some of the common trip-ups when setting up a Windows 2000-MIT Kerberos cross-realm authentication environment. They are based on the experiences of various universities across the country.

• Authentication issues when not using password sync – these issues apply to environments using AD user passwords that are unknown to the users:
  • Cross-domain resource access can only work if the underlying service supports Kerberos authentication. Non-Kerberos (clear text, LM, NTLM v1, NTLM v2) services, like Mac UAM, cannot be accessed without known AD passwords.
  • This setup will allow you to access Windows 2000 resources from within the domain only - if users do not know their AD passwords, they will not be able to access domain resources from outside the domain and/or from Win9x, NT4 and Mac clients.
  • Active Directory user accounts should be created with "password never expires". If your domain password expires, pass-thru logons will not work correctly.
• New - MS services currently not leveraging Kerberos for authentication:
  • 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.
  • New - Currently Outlook 2000/2002/XP does not support Kerberos authentication for accessing Exchange resources 5.5 or 2000.
  • New - Accessing a resource using a path of “\\<IP address>\<sharename>” relies on NTLM authentication instead of Kerberos. Using the format “\\<Server NetBIOS name>\<sharename>” or “\\<Server FQDN>\<sharename>” will use Kerberos for authentication. Is this because W2K does not do a reverse look-up of the IP to get a hostname to use for an SPN, or because it doesn’t create IP-based SPNs?
  • New - A W2K/XP client logon using cached credentials will not have Kerberos tickets available to access resources, but will instead attempt NTLM authentications to all resources.
• Kerberos server-side issues:
  • Kerberos trusts from a Windows 2000 domain to an MIT Kerberos realm should be created using a two-step netdom.exe procedure. The second step is required to add the transitivity property to the trust. For example:
    • netdom TRUST MY.W2KDOMAIN.ORG /Domain:MY.MITREALM.ORG /Add /Realm /PasswordT:"someolpswd"
    • netdom TRUST MY.W2KDOMAIN.ORG /Domain:MY.MITREALM.ORG /Transitive:yes
  • When using the 'kadmin' utility to add a W2k domain principal in the MIT realm, be sure to explicitly specify the supported encryption type(s). By default, the kadmin 'addprinc' command will include encryption types not supported by W2k. For example:
    • kadmin: addprinc -e des-cbc-crc:normal krbtgt/my.w2kdomain.org
  • The Microsoft implementation of Kerberos does not currently support non-NULL instances for user authentication. This creates havoc if you are used to using non-NULL instances for system administration tasks. For example you cannot create an account mapping where the foreign Kerberos account is joe/admin@EXAMPLE.EDU. Nor can you create native user accounts that use non-NULL instances; for example you cannot create Windows account of the form joe/admin@WIN.EXAMPLE.EDU. However, you can create user accounts that contain "."; for example you can create an account with the name joe.admin@WIN.EXAMPLE.EDU. Hopefully someday you will also be able to create a Kerberos name mapping to this account with a non-NULL instance, e.g. joe/admin@EXAMPLE.COM.
• Client-side issues:
  • Make sure you have SP1 or later installed on all clients. It includes important kerberos fixes for interoperability.
  • Be sure to use 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.
  • When logging into a client with MIT Kerberos credentials, be sure to select the proper item from the domain pull-down list (eg. “KDC.SCHOOL.EDU (Kerberos Realm)”).
  • Updated - If you wish to use this Kerberos interop to access Unix resources, you will require an additional program. This interop will get you W2K and MIT TGTs, but they will be stored in the W2K local security authority and will not be accessible by traditional MIT Kerberos clients (a kerberized telnet for example). An application called MS2MIT that copies the MIT TGT into the standard MIT cache location is now contained in the distribution of Kerberos for Windows from MIT.
  • Users should be able to change their Kerberos password by hitting Ctrl-Alt-Del once they have logged in, and then choosing the "change password" option. However, this may fail when performed on a multi-homed Windows 2000 machine. How or when this will be fixed has not yet been resolved. Update?
  • If a user attempted to change their MIT Kerberos password via Windows, and the password failed conformance tests, a misleading error message was returned to the user. U-Mich submitted this Kerberos password change bug to Microsoft, and received a fix. Update?
  • Users should be able to log in to a Win2k machine while it is disconnected from the network using the cached credentials feature. MIT has experienced problems with this. In some cases PSS may have an appropriate fix for sites experiencing a problem with this feature. However this problem is still being investigated. Update?
• Encryption
  • 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.
  • 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:
  • Updated - 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 interop (and other functions) to work properly. MS KB article Q258503 describes how to configure AD permissions to allow computers to update their own DNShostname attribute which the SPN is based on. Otherwise, the DHShostname attribute can be set manually with ADSI edit or other tools, or the SPN can be set manually using the setspn tool included in the Windows 2000 resource kit.
• Multi-domain issues
  • Updated - If you are going to have a child domain like eng.win.school.edu, there is a patch for the MIT KDC for referrals. This allows child-domains to properly authenticate using the trust. This is not an official MIT distribution patch. U-Mich has modified the MIT referral patch to support multiple forests. Both the original and modified versions of this patch are available here: http://www.citi.umich.edu/u/kwc/krb5stuff/referral.html
  • In multi-domain forests, the user must be located on the trust path from the computer domain to the MIT realm. For example, if domains B and C are both children of root domain A, a user in domain B cannot perform pass-thru authentication from a computer located in domain C. Another way of looking at this is that all users should be placed in the Windows 2000 forest root domain for pass-thru authentication to work in every circumstance.
  • If a user possesses an account (of the same name) in multiple domains along the Kerberos trust path, and each account is mapped for pass-thru logons, the account closest to the MIT realm will be used for pass-thru logons. This behavior results from the way Kerberos referrals "trickle down" from the MIT realm, allowing the Windows 2000 logon process to discover resources along the way.

From: owner-win2000-hied@lists.Stanford.EDU on behalf of Brad Judy
[judy@colorado.edu]
Sent: Monday, April 01, 2002 13:37
To: W2K List (W2K higher Ed list)
Subject: [win2000-hied]: Updates to kerb interop trip-up list

Last July I sent out a compiled version of some of the W2K-MIT interop
trip-ups many of us have encountered during our work.  I have made a few
additions and updates to this document and would like feedback from the,
now larger, group.  Particularly if you have items to add where there are
red "Update?" notes would be great (/me looks over at MIT and U Mich).  

Of course any additional contributions or changes are welcome.  

As it stands I never published this document to the web, but I know Berkeley
did.  Maybe after TechEd I will look at a more official home for the document.

Thanks,

Brad Judy

Information Technology Services
University of Colorado at Boulder