Windows 2000-MIT Kerberos Interop Trip-ups Draft

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 work if the underlying service supports Kerberos. Non-Kerberos (clear text, LM, NTLM v1, NTLM v2 only) 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.
  • 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.
  • Active Directory user accounts should be created with "password never expires". If your domain password has expired, pass-thru logons do not work correctly.
• 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)”).
  • 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). Carnegie Mellon and other schools have written code to copy the MIT TGT to the standard MIT credentials cache location.
  • 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.
  • 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.
  • 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.
• 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:
  • 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.
• Multi-domain issues
  • 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.
  • 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: Friday, July 20, 2001 12:40
To: W2K List
Subject: MIT/W2K Kerberos interop trip-ups

Hello everyone,

I finally got around to compiling additions from the community. I want to
thank U Mich, MIT, and UCI for contributing to the effort. If there are
additional contributions, feel free to send them to me. Sometime I will
post a PDF version of the doc online, but I'm not sure when as I'm closing
on a first house on Monday.

Brad Judy
Information Technology Services
University of Colorado at Boulder

-++**==--++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server. If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe win2000-hied" to majordomo@lists.stanford.edu