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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey Altman Sent: Monday, August 27, 2007 8:25 AM To: Jeremy Kurtz Cc: [email protected] 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. 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. 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, 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. 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 _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
