_ISADMIN with domain account

May 30, 2008
212
1
#1
Is the _ISADMIN variable supposed to work with domain accounts?

My work (domain) account has admin rights on my local workstation but not (obviously) on the domain.

With the domain account _ISADMIN always has the value 0, even if I can do local administrative tasks like the change the time, open device manager, install programs etc.

With a local (workstation) admin account I have created _ISADMIN has the value 1 as expected.

More info:

My work PC is using Windows XP SP3 so it's not a Vista UAC issue. The local Administrators group
also contains my domain account.
 
May 30, 2008
212
1
#3
nikbackm wrote:



Only with your local group.

Rex Conn
JP Software
The domain account IS a member of the Administrators group on the local machine where I test _ISADMIN.

So it should not be too hard to get this case working as well. As it is now the _ISADMIN variable essentially lies if I test it in batch files since the account do have administrative privileges.
 
#4
nikbackm wrote:
| ---Quote (Originally by rconn)---
| nikbackm wrote:
|
|
|
| Only with your local group.
|
| Rex Conn
| JP Software
| ---End Quote---
| The domain account IS a member of the Administrators group on the
| local machine where I test _ISADMIN.
|
| So it should not be too hard to get this case working as well. As it
| is now the _ISADMIN variable essentially lies if I test it in batch
| files since the account do have administrative privileges.

Roger Byrne posted his RB_utils.dll several years ago at
ftp://jpsoft.com/plugins, which has an independently implemented _ISADMIN
internal variable. If you already load the rb_utils.dll plugin, it overrides
the internal (Rex Conn) version, try unloading the plugin and see what
happens without it. OTOH, if you don't load it, try downloading and using
its version. Gives you another shot at getting the result you want.
--
HTH, Steve
 

dim

Dimitry Andric
May 31, 2008
204
1
Netherlands
#5
On 2009-04-26 12:20, nikbackm wrote:

> The domain account IS a member of the Administrators group on the local machine where I test _ISADMIN.
Another way to test this for user %USERNAME% would be:

%@group[%_WINNAME,Administrators,%USERNAME%]

But unfortunately the "administrators" group name is language-dependent...
 

rconn

Administrator
Staff member
May 14, 2008
10,533
94
#6
nikbackm wrote:

> The domain account IS a member of the Administrators group on the local machine where I test _ISADMIN.
>
> So it should not be too hard to get this case working as well. As it is now the _ISADMIN variable essentially lies if I test it in batch files since the account do have administrative privileges.
Microsoft has neglected to document a means of doing this. If you know
of a suitable (undocumented) API, I'll be happy to add it.

Rex Conn
JP Software
 
May 30, 2008
212
1
#7
On 2009-04-26 12:20, nikbackm wrote:


Another way to test this for user %USERNAME% would be:

%@group[%_WINNAME,Administrators,%USERNAME%]

But unfortunately the "administrators" group name is language-dependent...
This works very well. Thank you!

Yes, you have to use the language-dependent group name here, but if you do the same thing by "coding" it's easy to get a reference to the Administrators group by using a language-independent identifier. There's a Win32 symbolic constant defined for it.

nikbackm wrote:

Microsoft has neglected to document a means of doing this. If you know
of a suitable (undocumented) API, I'll be happy to add it.
Why not simply test if the user is a member of the Administrators group like above? Seems to mostly done already.

Or maybe that would not work on Vista with UAC activated?
 

rconn

Administrator
Staff member
May 14, 2008
10,533
94
#9
dim wrote:

> On 2009-04-26 15:57, rconn wrote:
>
> ---Quote---
>> Microsoft has neglected to document a means of doing this. If you know
>> of a suitable (undocumented) API, I'll be happy to add it.
> ---End Quote---
> Please see the description of CheckTokenMembership() in MSDN:
>
> http://msdn.microsoft.com/en-us/library/aa376389.aspx
That's exactly what I'm already doing.

Rex Conn
JP Software
 
May 26, 2008
492
3
#10
Rex, which SID are you checking for when you call CheckTokenMembership? I have code written in Delphi that works properly with this function. It correctly identifies my domain account as having local admin privileges. My domain account is a member of a domain group which in turn is a member of the local Administrators group.

The SID I check for is DOMAIN_ALIAS_RID_ADMINS (0x00000220).
 

samintz

Scott Mintz
May 20, 2008
1,264
11
Solon, OH, USA
#11
If you are logged on locally vs. a domain account, does that still work?

-Scott

Rod Savard <> wrote on 04/28/2009 12:37:35 PM:


> Rex, which SID are you checking for when you call
> CheckTokenMembership? I have code written in Delphi that works
> properly with this function. It correctly identifies my domain
> account as having local admin privileges. My domain account is a
> member of a domain group which in turn is a member of the local
> Administrators group.
>
> The SID I check for is DOMAIN_ALIAS_RID_ADMINS (0x00000220).
>
>
>
>
 
May 26, 2008
492
3
#13
Another way to test this for user %USERNAME% would be:

%@group[%_WINNAME,Administrators,%USERNAME%]

But unfortunately the "administrators" group name is language-dependent...
This is definitely the wrong approach. As you pointed out, it requires that the "Administrators" group be called exactly that. Second, it doesn't check for nested group memberships.

The CheckTokenMembership API is the right way to do this.
 

rconn

Administrator
Staff member
May 14, 2008
10,533
94
#14
Rod Savard wrote:

> Rex, which SID are you checking for when you call CheckTokenMembership? I have code written in Delphi that works properly with this function. It correctly identifies my domain account as having local admin privileges. My domain account is a member of a domain group which in turn is a member of the local Administrators group.
>
> The SID I check for is DOMAIN_ALIAS_RID_ADMINS (0x00000220).
That's the same one I'm checking.

Rex Conn
JP Software