Case-sensitivity of realm in AD/Kerberos cross-realm

[Leonard J. Peirce]

Back in November I posted to this list about cross-realm with Active
Directory trusting Kerberos.  At that time I said that my colleague
who manages AD says that while AD can successfully authenticate against
our Kerberos the user is required to enter the realm to make it work
and that he could find no way to force a default realm in AD.  A few
people responded with links, registry settings, and options to the
Windows ksetup command that I had hoped would resolve the issue but
while we continue to investigate another related issue has popped up
as we move to Office 365.


My colleague recently posted the message below to the Windows Higher
Ed mailing.  With his permission I'm reposting it here in case someone
can offer any insights.  He asked me if I knew of a way to have our
KDC translate a lowercase realm in a ticket request to all uppercase.
I don't see any way to do it and I'm sure it would be a good idea
regardless.

TIA...

- Leonard

====================

Subject: How do you deal with the case sensitivity of an external realm/kerberos trust?


I have seen many posts by people with an external realm trust and I am
wondering how you have handled this issue.

We have had an external realm trust to our campus Kerberos on and off for
a long time. The problem we have always had with it is that the username
and domain/realm name are case sensitive. In our case, the AD domain is
wade.wmich.edu and our campus Kerberos realm is WMICH.EDU.

I have not found a way to get AD to "fix" the realm/domain if a user enters
user at wmich.edu instead of user at WMICH.EDU.  Also, USER at WMICH.EDU does not work.

Has anyone found a way to pre-filter the credential, either in AD or Kerberos,
so Kerberos sees and returns (the case must also match the altSecurityIdenties
entry) user at WMICH.EDU no matter what case the user types it in?

This has always been a problem but now We are in the process of implementing
Office 365 mail and using user at WMICH.EDU as the login name (it does not care
about case!) and I just discovered that if instead of defining an alternate
login domain in ADFS, I have a trust for that domain (WMICH.EDU) I can authen-
ticate ADFS against Kerberos as long as the case is correct.  If the case is
incorrect, it will still pass the authentication to Kerberos but it will always
fail.  If we could use this it would solve the problem of the mail accounts not
currently in AD that need to be added but the passwords are only known to
Kerberos (we normally sync passwords when they are changed, since they were
not in AD the last time the password was changed, AD can not get the password
now).