Since migrating to AD we have noticed that although you may be an admin of a pc, there are times when you cannot install or run certain programs. The error message from the programs usually consists of something like "You must be an administrator to run this program." We have checked and in fact are admins.
Yesterday, I was tinkering with a script and included @priv in a if statement. Much to my surprise the script would not run. Finally I figured out @priv was returning "User".
Does anyone know where @priv determines this information, because maybe the two problems are connected.
The following script checks for permissions in various ways and the results for my account are:
#77109 - 2003-10-1907:47 PMRe: When admin is not admin?
EveryoneEveryone
Getting the hang of it
Registered: 2003-10-19
Posts: 81
Loc: Beale Air Force Base, CA
I ran into a simular problem recently. Upgraded from an NT 4 domain environment, to a Server 2003 Active Directory environment.
They only let us have Directory Service Operator, and Resource Admin rights, so kix shows @priv as User when logging on to the network. Log on as a local admin to the workstation, and it will show Admin.
I also had a similar problem after an upgrade from NT4 to W2K network environment. The @primarygroup for some reason would not resolve properly. The solution that worked for me was to make ALL users created in the NT4 domain part of the "Pre Windows 2000 users" group. It may sound funny but give it a test run on a few users.
I'm afraid I'm not following this. Did you ever solve this or find a work around for installing programs? Are you just not using Kix to try to find priv level and going by what the program reports?
Sorry, I didn't see a request to test. I have over 800 workstations and only some have this problem. My test machines work fine with Domain User accounts (with the /f switch). I originally thought this had something to do with us "ghosting" machines, so the SID in the cache didn't machine the SID on the new machines, but my most recent results contradict that. Won't be getting around to test any time soon.
Anyway, the this thread seems to tell me that this function is problematic and should be avoided, unless someone has some work around I haven't seen yet, or I'm misunderstanding.
You were given a reference to this thread basically for the little scriptlet to test. To take your problem to this thread is considered hijaaking. You should post to the topic you started. Ingroup
This thread's topic is about @Priv and not about InGroup. There is no "problem" here per se, except for a misunderstanding of how @Priv works.
That said, this example of InGRoup() differs from yours whereby it does not look for <>1. Also there is an example of a LocalAdmin() UDF that is immune to localization.
_________________________
Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.
- We'll either find a way or make one... - Knowledge is power; knowing how to find it is more powerful... - Problems don't exist; they are challenges...
![[Frown]](images/icons/frown.gif){kind=icon}
