[OpenAFS] OpenAFS + Multi-domain AD Forest + MIT Kerberos Realm Trust

[Jeremy Kurtz]

Hello world (wow that brings back memories),

At Arizona State University, there seems to be a unique situation in how
the centralized Active Directory infrastructure is laid out.  Although I
do not manage the centralized AD infrastructure, I do manage our own
separate one that is its own standalone forest containing only one
domain.  In our own domain we have an external MIT Kerberos Realm Trust
that everyone logs on to, and OpenAFS works perfectly.  The AD accounts
all have randomized passwords which isn't an issue due to logging on to
the external trust.

For the greater good, we are migrating our domain resources to the
centralized AD infrastructure.  This has lead to some very strange
behavior that I will explain later.  First, consider the following about
this infrastructure:

*  The forest root domain is ad.asu.edu.  All users are populated in
this domain with randomized passwords, along with their Kerberos
Principals (user@ASU.EDU).  This is the same as our domain.
*  The child domain asurite.ad.asu.edu is where all workstation computer
objects reside in.
*  There is a trust to the external MIT Kerberos V5 Realm.  Also the
same as our domain.

The *only* way I've gotten OpenAFS to retrieve an AFS token is to set
"SMBAuthType" to 0.  And even then, the only way I can do it is with a
"net use \\afs\asu.edu\<path> /user:(user)" - note the /user: switch.
If I omit it, it attempts to logon as ASUAD\(user) and fails.  In my own
separate domain, everything is totally seamless, I don't need to change
SMBAuthType, and I don't need to use the /user switch.  I can use the
UNC path immediately without issue.

Another strange thing that is occurring is that users' AD accounts are
getting locked out of AD for 5 minutes upon logoff.  I can only assume
that this is due to some strange bug occurring with Kerberos.  There are
LSA events in the event log about attempted downgrade attacks to
cifs/afs.

Now to things I have tried to resolve the problem.  I came across the
following MS KB article last evening:
http://support.microsoft.com/kb/931192 - it *almost* exactly describes
our issue, except that we don't have separate forests.  I installed that
hotfix to no avail.  I've also tried installing Kerberos for Windows to
view tickets.  I've tried ms2mit (after setting the necessary
environment variable), aklog, aklog -m, aklog -4, using the USE524 flag
for OpenAFS, setting AllowTGTSessionKey to 1, ensuring that the LSA
cache is enabled in Windows, and no matter what, I just can't get an AFS
token without setting SMBAuthType to 0, and the weird AD lockout still
occurs.  And of course, as I mentioned before, in my own domain this all
works perfectly with just OpenAFS out of the box.

So my question is does anyone have any idea what to try at this point?
I can't help but think only Microsoft can fix the problem at this point,
especially given that the KB article above explains a bug in their
Kerberos implementation that so closely matches our infrastructure. =20

If anyone has insight or more troubleshooting tips, I'm all ears.

Thanks,
Jeremy