Hi, I'm a network admin for about 400 PCs. Recently we've moved to a Win2K Server Active Directory domain with Windows XP clients. We've setup a trust relationship between our AD domain and our MIT K5 realm. Our users can logon to the XP clients on the AD domain with their MIT K5 realm passwords just fine every time.
We are now seeing a problem that is a show stopper for us. It looks very much like it may be a bug in Microsoft's Kerberos trust implementation. I'd like to know if anyone out there has seen a similar problem, or if anyone has any idea of what might be going on. The Problem When the users logon to the WinXP clients they usually get their MIT kerberos TGT along with various AD service tickets into the Microsoft ticket cache. For our users on the AD domain we have setup group policies and logon scripts to run. We are finding that occasionally the user's logon scripts and group policies don't execute. We are seeing that the AD domain is returning error messages like "unknown user or bad password" when the user's processes access the AD domain shares. We are also seeing an event viewer messages on the XP clients referencing SPNEGO problems. The event id is 40961 (what is the cause of this?). (btw, this is not 40960 as others have gotten) To make matters worse we can cause the XP clients to be totally be denied access to the AD shares just by locking and unlocking the user's XP sessions (with ctrl+alt+del -> lock/unlock workstation). Very odd behavior ensues when we lock and unlock the workstations multiple times. Sometimes we are allowed access to the shares even without proper tickets. Other times, depending on whether we use upper or lower case, fully qualified domain names, or just the first part of the domain name, we see different ticket service names in the Microsoft ticket cache. Sometimes we reach a point where we are denied access to the shares altogether and the WinXP box refuses to fetch the cifs service tickets. We then have to wait for about 15-20 minutes before the client will again allow access to the share. We can reproduce this behavior every time a user logs on. Users that are outside our building router get this problem at logon all the time. We dont forward netbios packets through the router so the XP machines can't drop back to netbios for help. This is very odd behavior for such a simple network setup that we have. We've done everythine by the book. Our Network Setup 1. Before we had setup the AD or PCs we had an existing UNIX MIT K5 realm kdc. We also had an existing UNIX hosted (BIND) DNS system. 2. The existing domain and realm were the same...such as "CAMPUS.EDU." Our PCs would be hosts such as "hostx.CAMPUS.EDU." 3. We setup our AD domain as a single domain/forest for simplicity. We just used the AD wizard and setup a subdomain/realm like "Win2k.CAMPUS.EDU". This is just out-of-the-box stuff, nothing complicated here. The AD box is running DNS and is authorative for its domain. (We are not putting the XP clients into the Win2k domain, but we have tried this and it doesn't solve the problem.) 4. We authenticated our WinXP boxes to the AD domain without problems. 5. We then setup the trust relationship between the AD realm and the MIT K5 realm without problems. 6. We added user accounts on the AD domain with random passwords. We assumed they could be random since we were going to use the trust. Was this correct thinking? 7. The users can now logon to the WinXP machine with their MIT K5 passwords without a problem...the trust seems to work fine. 8. The user accounts on the AD domain are setup so that they have logon scripts and group policies to execute. When the users logon, if they are in the same building as the AD server, they usually get their logon scripts and group policies executed by the WinXP machine. But, sometimes this does not happen. Upon investigation of why this was happening we found that we could simply logon as a user, go to the command prompt, and try to access the shares manually such as "dir \\Win2k.CAMPUS.EDU\netlogon". This usually works, we can then run Microsoft's KLIST and see all of our service tickets for the domain...including CIFS tickets. Now, locking the workstation with (ctrl+alt+del -> lock workstation), then unlocking it...we then look at our Microsoft ticket cache again with KLIST. Ok at this point we've fetched a new MIT K5 TGT from the kdc and weve got a host service ticket, but thats all. Seems not to be a problem, we'll just try to access the share and all of our service tickets will come back. When we do this we see that we are denied access to the share, and we don't get a service ticket. But, on the other hand, sometimes we are allowed access to the share and we dont have any service tickets! What is going on here???? I know this is a long wind'ed problem report, but I'm at my wits end. I can contact Microsoft support, but they are so slow at figuring out exactly what the problem is, after you go through 10 people before you finally make it to that one guy at Redmond who knows anything (and he's on vacation), then they take 6 months to patch. You could rewrite the Win2k kernel before they fix the problem! We need this problem solved ASAP and I'm not even sure if its a real bug. Have I done anything wrong? Note: For a test, we reset the password for one of our users so that it matched the MIT kdc password. We then logged on the WinXP box using the AD domain (not the MIT realm). This worked fine, and fixed the problem. But, this is not using the trust relationship! Is there a bug in Microsoft trust implementation? Much help is appreciated. Thanks, Totally lost Krbusr ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
