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 ([EMAIL PROTECTED]). 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. If anyone has insight or more troubleshooting tips, I'm all ears. Thanks, Jeremy _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
