The test script is:
if INGROUP ("GlobalGroup")
? "You are in there. Error:@Error"
else
? "You are NOT in there. Error:@Error"
endif

When using kix32 (4.01) the function incorrectly returns that my account is NOT in a global group when in fact it is. The 4.01 INGROUP does correctly return that my account is in some groups though. I have added my account to exsiting groups as well as creating two new global groups. Both of the new groups only have one account in them. Older groups such as "Domain Users" report correctly.

These errors are not reflected when I use the INGROUP function from Kix32 version 3.62.

Our SAM size is ~42MB.

Since the problem does not occur in version 3.62 and does in 4.01, I believe we have a BUG.

I have a 40,000 seat rollout scheduled for next week. HELP.

more info: The groups that fail are not shown when using the ENUMGROUP function. At least the failures regarding the membership seem to be consistent for what it is worth.

[ 17 January 2002: Message edited by: Howard Bullock ]

[ 17 January 2002: Message edited by: Howard Bullock ]

[ 17 January 2002: Message edited by: Howard Bullock ]

you got mail ...

hope this helps

Jochen

_________________________

Version 4.01
C:\Data\Scripts>%temp%\kix32 test.kix

You are NOT in there. Error:0
You are in there. Error:0
You are in there. Error:0
You are NOT in there. Error:0
You are NOT in there. Error:0
You are NOT in there. Error:0
AMP01\Domain Admins: 0
Everyone: 0
AMP01\Domain Users: 0
AMP01\DSS Admins: 0
AMP01\GPS_Admins: 0
AMP01\NT_Techies: 0
AMP01\LAS Admins: 0
AMP01\Mnlo Admins: 0
AMP01\SMS2Admins: 0
AMP01\SMS2SQLAdmins: 0
AMP01\InternetAllowed: 0
AMP01\SoftLibAdmins: 0
LOCAL: 0
INTERACTIVE: 0
Authenticated Users: 0
SMS Admins: 0
Administrators: 0
Users: 0

-------------------------
Version 3.62
C:\Data\Scripts>kix32 test.kix

You are in there. Error:0
You are in there. Error:0
You are in there. Error:0
You are in there. Error:0
You are in there. Error:0
You are in there. Error:0
Domain Users: 0
Domain Admins: 0
DSS Admins: 0
GPS_Admins: 0
NT_Techies: 0
LAS Admins: 0
Mnlo Admins: 0
SMS2Admins: 0
SMS2SQLAdmins: 0
InternetAllowed: 0
SoftLibAdmins: 0
macom_xpremove: 0
macom_su_deploy: 0
macom_pc_admin: 0
macom_howard: 0
H: 0

There is a definite difference in behavior.
Jochen attempted to send me 4.02 but it was stripped by the firewall. Shawn could you for 4.02 to me in a zip file?

[ 17 January 2002: Message edited by: Howard Bullock ]

The tests we conducted today involved altering group names via Perl and altering group memberships for NT4 User Manager and then executing Kix32 3.62 and 4.01 using the INGROUP and ENUMGROUP. Kix 4.01 must reference the global groups that are tagged to the users security token and not interrogate the domain SAM. Kix 3.62 on the hand reflected these changes immediately and therefore must have been accessing current data from the SAM.

During further testing, I deleted my self from a group and execute the test script again under both versions. Again 3.62 showed the current state of my membership. but 4.01 returned that I was still a member of the group. At that point I realized what must be happening. After logging off and back on Kix 4.01 produced the expected results.

I verified this by open a DOS window in my current session and executing the script. the results stated that I was NOT a member of global group XYZ. I then added my account to group XYZ and synced the domain. Executing the script still resulted in my account not being in the group. In the same window Kixtart 3.62 showed correctly that the account was indeed a member. I then opened a new DOS windows using the "run as" function and the same account as my original session. Executing the test.kix script using Kix 4.01 showed that the account was a member of group XYZ. Back to the original window and the account is NOT a member.

I think that the documentation should clearly reflect that the SAM is not being accessed to determine group membership and the static global group memberships associated with the security token is being referenced.

Thank you to all those that responded. Sorry for the false alarm.

For windows NT/2000 what I found to work 100% is as follows:

IF INGROUP ("Fin-To-Corp1") = 1
USE W: \\Servername\Sharename
USE X: \\Servername\Private
ELSE
ENDIF
[EMAIL]null[/EMAIL]

in short: you are 100% correct. Yes, 4.01 indeed uses the user's security token to retrieve group membership information instead of a query of the SAM/DS (as used by previous versions of KiXtart).

This indeed has the side-effect that changes in group-membership are reflected the next time a user logs on.

So why did I change this? Well, the new mechanism enables me to determine a complete list of groups, including BUILTIN Groups, Universal Groups and nested Global Groups.

Hope this clarifies things, and I will look at adding a paragraph on this to the documentation.

Kind regards,

Ruud

and I should've known better !!!

Anyway, you have the latest (and improved) BETA and the documentation will be more precisive (Should be of some interest for other purposes than Login scripts !)

So, no damage was caused but improvement

regards

J.

_________________________

I think you have the solution to your INGROUP problem. If not, post a reply on the forum.