MIT/Win2k/XP Kerberos trust relationship bug?

[krbusr]

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