|
|
|||||||
I'm experiencing a strange problem with an if ingroup command. I'm not sure if this is AD, Kixtart, or both. Here's the script... Code:
This script won't run if you are a member of this AD group. I checked everything that I can think of (syntax, extra spaces, etc...). So then I thought let me enumerate the group via Kixtart. Here's the script... Code:
Here are the results... Agent DOMAIN\cc_users Now...the cc_users group is a valid group in our domain and there are several users in that group. I don't understand why it shows cc_users as the only member of that group. Does this look like an AD problem or is there something in Kixtart I'm missing? We have 20 if ingroup commands in our production login script. Thanks for any advice. |
||||||||
|
|
|||||||
well, your enumgroup syntax is wrong, to start with. EnumGroup( )
|
||||||||
|
|
|||||||
Ok. What are some things I can try to determine why the script won't run if you're part of the domain group? Thanks |
||||||||
|
|
|||||||
Have you tried flushing the cache? |
||||||||
|
|
|||||||
I don't think you'll need the "= 1" after your IF INGROUP statement. The IF INGROUP command will just step you to the next level of the IF statement if you are a member. You can flush the cache by adding a "/f" at the end of your kix32.exe string. (minus the double quotes) The INGROUP command can enumerate nested groups so if your users are in the CC_Users group they should be running the code. What version of KiX are you running? Also, try double quotes around your SHELL command syntax instead of the single quote (does the SHELLed DOS command recognize UNC paths?) You may need to run the setup file from a mapped drive. You can also DIM your variables above the first IF statement (may clean up your code...) |
||||||||
|
|
|||||||
The quotes on the SHELL line are just fine. I doubt however that the command interpeter would be required. |
||||||||
|
|
|||||||
*BING!!!* |
||||||||
|
|
|||||||
First off, thanks for the quick responses! Quote: I've tried this both ways. With and without "= 1" Quote: I've tried this too. Quote: I'm starting to suspect AD at this point. If I modify the script to use an existing group, it works fine. I've added 3 different groups in AD trying to get this project working and none have worked. I even simplified the script. For example... Code:
Then I ran it with the following command c:\kix32.exe -d PMAgent.kix /f It just exits back out to the DOS prompt. Nothing was echoed to the DOS window. Any thoughts? Thanks |
||||||||
|
|
|||||||
Sorry have to ask this - are you testing this script against your own account, that you just added to this group - and did you logoff and log back in before testing ? -Shawn |
||||||||
|
|
|||||||
Quote: Yes. I've logged off, logged on, and forced replication in AD trying to figure this behavior out. I have also tried it with another user in that group on a different machine. One more test that was done. VBScript was used to query the domain group and it listed the members correctly. Oh...the version we have is 4.12 Thanks |
||||||||
|
|
|||||||
Is your GC healthy? Try to include the domain name with the groupname. |
||||||||
|
|
|||||||
Any events in your application event log ? |
||||||||
|
|
|||||||
Try deleting the HKEY_CURRENT_USER\Software\KiXtart\TokenCache reg key. |
||||||||
|
|
|||||||
It couldn't hurt to upgrade to the latest KiX version too. I would, however, verify with the "pros" about any compatibility caveats that might arise from the upgrade. The physical steps to upgrading, however, couldn't be simpler (if you're on a winNT - 200x network (no 9x)) Just download the newer version and call the newer version's .EXE from your batch file or your user's logon script field (which ever you're using) |
||||||||
|
|
|||||||
Again everyone, thanks for all the tips. Here's the latest... Quote: I've looked at the event logs on all GC servers, nothing out of the ordinary. Is there another method you had in mind to test that? Quote: Didn't work Quote: Didn't help. It repopulated the key as soon as I ran the script. The information was the same as before. Quote: I did this by downloading and copying the newest kix32.exe to my PC and the other test PC I'm using. Didn't work. Now I'm really starting to question AD, yet I get positive results with VBScript querying the group. Thanks |
||||||||
|
|
|||||||
KiXtart get global group references from the user authentication token. The group sids are bound to the token at logon by the global catalog server. So if you do not have a global catalog server that the user can contact you may see these types of issues. |
||||||||
|
|
|||||||
Kixtart will spit-out errors to the local (workstation) appl. event log. |
||||||||
|
|
|||||||
Oh, and you didn't tell us what was listed in the Token cache. Was the group in question listed there? Was the group in question renamed? Do other groups work or do all global groups fail? Is the group name long? |
||||||||
|
|
|||||||
Is it a security group? |
||||||||
|
|
|||||||
Again...my sincere thanks to everyone who responded to this post. Quote: These were wrong. They were showing some, but not all of the correct groups (no new ones). Quote: Nope. I took a look at the GC settings on my domain controllers and noticed that the GC checkbox was unchecked on the domain controller with the FSMO roles. I checked the box and ran my production logon script. The TokenCache registry entry immediately filled up with the appropriate groups. And the original script ran just fine. Not sure how that happened. We haven't had any major changes to our domain lately aside from some new employees. It only really showed up when we started this project to roll out a piece of software based on group membership. Thanks so much everybody! |
||||||||
|
|
|||||||
You need to be careful. If memory serves, there can be a conflict with GC and the IM FSMO role. |
||||||||
|
|
|||||||
Further reading: http://support.microsoft.com/default.aspx?scid=kb;en-us;197132 Quote: |
||||||||
|
|
|||||||
That is for a multi domain setup. Logging in security events would show who changed any settings, but unless you're saving your logs it would still be quite a pain to locate who changed it and when unless it was recently done. How many Admins at your site have rights to modify core AD settings? |
||||||||
|
|
|||||||
I did say "can" and not "most definately will" since there is no mention of the AD design. We run an empty root domain model where the resource domain hold all the domain admins, protecting our root. |
||||||||
|
|
|||||||
I found the fix to have to add "= 0" to your if statement. Read the following site http://www.scriptlogic.com/kixtart/htmlhelp/functions/ingroup.htm and note: 0 InGroup checks for membership of ONE of the groups in the list (default) |
||||||||
|
|
|||||||
you are joking, right? |
||||||||
|
|
|||||||
LOL I think he's serious. :\ |