I believe that there is no problem with these functions INGROUP and ENUMGROUP in Kixtart 4.0x. Confusion within our test community occurred because the behavior of 3.62 and 4.01 were different. This behavior most likely is by design and I would like confirmation of that if possible.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.