#118172 - 2004-04-16 11:48 PM
TokenCache not 'sticking'
|
Steve_B
Fresh Scripter
Registered: 2004-02-04
Posts: 15
|
Hello all,
Here's a problem I've been battling for a few weeks. I have an Active Directory domain with a trusting NT resource domain (ie. NT domain trusts AD domain). The users in the AD domain log on to NT4 PCs in the resource domain.
At each logon, the Kix cache has to be re-populated which delays logons significantly (obviously), especially over my slower links. So, upon more investigation I find that the "CacheAge" value is not being written to the TokenCache registry key, and it looks like the cached group list is incomplete (only grabbing about 2/3 of the groups). Essentially, Kix doesn't know it's supposed to be maintaining the cache because there's no CacheAge value, so it repopulates. If I force the CacheAge value to be there (through a reg hack), the logon speeds immediately get improve.
The Event Log on the NT4 PC has a corresponding error: "Event ID 1332. Failed to resolve SID(s) Error : No mapping between account names and security IDs was done. (0x534/1332)." My thoughts are the cache starts populating, Kix can't resolve the SID to an account name, so Kix aborts the caching process prior to writing the CacheAge value.
The NT workstations are using the resource domain's WINS and DNS. If I move the machine to the AD domain AND use the AD domain's DNS the cache gets populated, the CacheAge gets set and all is well.
I think it's a name resolution issue at the DNS in the resource domain, and Kix is only a symptom so that's where I'm focusing attention now. It has similarities to this recent thread. Anyone have any thoughts or seen behaviour like this?
Thanks,
Steve
|
|
Top
|
|
|
|
|
#118174 - 2004-04-17 12:17 AM
Re: TokenCache not 'sticking'
|
Steve_B
Fresh Scripter
Registered: 2004-02-04
Posts: 15
|
Thanks Les. Hope using 3.63 isn't the solution though. I don't want to lose my UDF's and all else good that comes with 4.22. We have another NT resource domain that used to have NT workstations (they've since moved to the AD domain) and we never saw the problem there. But there are many differences that may cause one to have the problem and the other to not have it, like a 2-way trust, using different DNS, etc.
|
|
Top
|
|
|
|
|
#118175 - 2004-04-17 01:09 AM
Re: TokenCache not 'sticking'
|
burnsc
Starting to like KiXtart
Registered: 2004-04-14
Posts: 171
|
There are some similarities.
1) My TokenCache is not always retrieving all the Groups. (I was not watching this before so I ran some quick tests. On Average I am retrieveing 75-80% of the member groups. Apparently the group I needed was early in the 'pull list'.)
2) This domain has trusts with MANY other domains (I would say 50+ domains)
3) Corporate has an Active Directory Domain. They will be deploying it soon.
I do not believe the Active Directory domain is currently trusted with the 'working domains'. However, corporate does say they have some people at higher level on that domain.
I admit that I am a newbie to kixtart, and most of my network knowledge has been learned from trial and error and book reading. So sometimes I am still a little nieve on some of the inner workings 
Just a sidenote Kixtart 3.63 did not help my time any.
|
|
Top
|
|
|
|
|
#118177 - 2004-04-17 01:28 AM
Re: TokenCache not 'sticking'
|
Steve_B
Fresh Scripter
Registered: 2004-02-04
Posts: 15
|
I guess there's two questions here: a) why is my SID match failing and b) why does Kix bail if my SID match fails.
I'd love to hear Ruud's input on b) . As for a), I think it may have something to do with some of the groups. They were migrated from an NT domain to the AD domain. I'm testing this now and will post results.
Steve
|
|
Top
|
|
|
|
|
#118178 - 2004-04-19 07:00 PM
Re: TokenCache not 'sticking'
|
Steve_B
Fresh Scripter
Registered: 2004-02-04
Posts: 15
|
Lonkero,
Do you think this is a bug in the Kix code? Are there other methods for submitting bugs, or does Ruud actively monitor the board to offer input?
I haven't found the cause of the failing SID matching yet. The only workaround that I've come up with so far is to write the CacheAge key in the login script so the users won't have to re-build their cache every time. This obviously is not a nice workaround.
Steve
|
|
Top
|
|
|
|
|
#118179 - 2004-04-22 08:26 PM
Re: TokenCache not 'sticking'
|
Steve_B
Fresh Scripter
Registered: 2004-02-04
Posts: 15
|
Well, I'm still trying to figure this one out, so I'm putting forth another call for help. And if Ruud's watching, I'd love some input.
Does anyone have an environment similar to mine that they could see if they get the same results?
- Active Directory domain with a user ID
- NT resource domain with a 1-way trust (Resource domain trusts AD domain)
- NT4 workstation in the resource domain
- Log into the NT 4 machine with your AD ID.
- Delete the HKCU\Software\KiXtart\TokenCache\CacheAge entry
- Run a kix script that uses Kix4.22 and runs the @HOMEDIR macro (any macro that makes a call to AD should do, but this is the one I've been testing with)
- look in Event Viewer on the NT workstation, in the Application log, for an Event ID 1332 associated with the KiX script running
- Check the registry at HKCU\Software\KiXtart\TokenCache to see if the CacheAge value has been re-added.
I've tried this in 3 of my NT resource domains and get the same results across the board. 1-way and 2-way trusts give the same results. Just trying to determine if this is something limited to our environment or not.
Any help or thoughts would be appreciated.
TIA
Steve
|
|
Top
|
|
|
|
|
#118180 - 2004-04-24 01:43 PM
Re: TokenCache not 'sticking'
|
burnsc
Starting to like KiXtart
Registered: 2004-04-14
Posts: 171
|
I am wondering where we are on this too. I was forced to put out the kixstart script for all my users irregardless of slowness  .
Thanks
|
|
Top
|
|
|
|
Moderator: Jochen, Allen, Radimus, Glenn Barnas, ShaneEP, Ruud van Velsen, Arend_, Mart
|
0 registered
and 472 anonymous users online.
|
|
|
