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

[Jeremy Kurtz]

Thank you for your response.  It is good to know that I'm not completely
crazy.

I am now trying to find who knows any information about this hotfix.

Thanks,
Jeremy

-----Original Message-----
From: openafs-info-admin@openafs.org
[mailto:openafs-info-admin@openafs.org] On Behalf Of Jeffrey Altman
Sent: Monday, August 27, 2007 8:25 AM
To: Jeremy Kurtz
Cc: openafs-info@openafs.org
Subject: Re: [OpenAFS] OpenAFS + Multi-domain AD Forest + MIT Kerberos
Realm Trust

Jeremy Kurtz wrote:

\\AFS appears to the local client to be a remote CIFS server named
"AFS".  The Windows client wants to obtain a Kerberos v5 service ticket
for "cifs/afs@<SOME-REALM>".  Since the OAFW SMB server cannot use
Kerberos v5 cIFS authentication and can only use NTLM loopback
authentication, the search for the cifs/afs@<SOME-REALM> service ticket
must fail.  However, it must fail in a manner that does not appear to be
caused by an attacker preventing the client from communicating with the
KDC that would possess the ticket.

With the realm hierarchy in place at ASU, you are triggering a bug in
Microsoft Windows.  The Kerberos referrals code is detecting loop and
thinks the workstation is under attack.  It therefore causes the
authentication to fail.

> The *only* way I've gotten OpenAFS to retrieve an AFS token is to set
> "SMBAuthType" to 0. =20

Doing so disables authentication between the Windows CIFS client and the
OAFW SMB server.

> 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.

If you use ASUAD\user it will fail because it triggers the bug.


> 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. =20

This is not the issue you are suffering from.

> 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,=20

None of this is necessary.  All of this is done for you by Network
Identity Manager or afscreds.exe.

To view tickets in the LSA cache with Kfw,

  klist -c MSLSA:

> 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.

If you can't communicate with the OAFW SMB server you can't set tokens.
 Its as if the AFS Client Service wasn't even running.

> 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

This is a bug that only Microsoft can fix.  ASU submitted a case with
Microsoft years ago.   A fix was supposedly given to ASU for this issue
back in August 2005.

Jeffrey Altman