AccessControl::IsUserTheAdministrator

Daniel James
7th March 2008 16:31 UTC

AccessControl::IsUserTheAdministrator
It seems that AccessControl::IsUserTheAdministrator returns "false" unless the named user is the actual Administrator user. That is: It does not return true for all members of the Administrators group.

It seems to me that testing for group membership would be more useful ... or perhaps there should be a new function called AccessControl::IsTheUserAnAdministrator to do that?

Actually, the interesting thing is not whether a user is the administrator, nor even that he is a member of the Administrators group, but that he has write access to the CSIDL_PROGRAM_FILES and the CSIDL_COMMON_STARTMENU directories ... so perhaps a different test altogether would be make mores sense?

Afrow UK
7th March 2008 17:22 UTC

That is correct, it tests if the user is the Administrator user (has an SID ending with 500).

Use UserMgr plug-in for what you want.

Edit: Or yes you could try writing to those folders using FileOpen.

Stu

Daniel James
7th March 2008 18:30 UTC

Originally posted by Afrow UK
That is correct, it tests if the user is the Administrator user (has an SID ending with 500).

Yep, I see that. It's useful to be able to do that but -- you're right -- it's not what I want.

Use UserMgr plug-in for what you want.

ITYM UserInfo? I've been digging further and it looks like UserInfo is for getting info about users while UserMgr is for creating/changing user accounts.

What I'm trying to do, here, is to use the MutliUser plugin, but also to display a page at the start of the install if the user is NOT an admin to tell him that if he quits and reruns the setup from an admin account he will have more choices.

UserInfo::GetAccountType is what MultiUser uses, so that'll do fine.

Thanks for your help.

Afrow UK
7th March 2008 20:59 UTC

Sorry, UserInfo is the one.

Stu

AaronLS
7th March 2008 21:51 UTC

Just out of curiosity since I'm about to dig in to the same task. What is the functional difference, if any, between a user in the Administrators group as a opposed to the Administrator user?

One of the most frustrating reoccuring issues with our old installer(which I'm happily busting my butt to rewrite in NSIS) was permissions issues on folders or problems writing/reading to/from the registry. Since actions on the registry only give an error without giving any indication of what went wrong, I'm fearful of having to continue to deal with these issues.

Often times the user swore they are in the administrators group despite the problems.

Also, is there a way to distinguish between a user in the Administrators group of a domain, versus an Administrator on the local machine? This can be confusing because an Administrator on a domain can log into a computer joined to the domain, but not be a part of the local Administrators group of that machine, thus have these issues when installing but misbelieve that they have administrator rights to the machine.

Afrow UK
7th March 2008 22:04 UTC

IsUserTheAdministrator was written for a company that I work for that have machines that have accounts with administrator privileges as well as an Administrator account and I needed to determine which account the install was running on.

To check if a SID is a member of a particular domain, you can use the LookupAccountSid function.

Stu

Daniel James
8th March 2008 11:19 UTC

About Admins

Originally posted by AaronLS
Just out of curiosity since I'm about to dig in to the same task. What is the functional difference, if any, between a user in the Administrators group as a opposed to the Administrator user?

Good question ...

By default -- and these things can be changed -- write access to the "C:\Program Files" directory (or, more correctly, the directory returned by SHGetFolderPath with the CSIDL_PROGRAM_FILES flag) and to the HKLM registry hive is given to all members of the "Administrators" group and to the default administrator user (by default, because that user is their "CREATOR OWNER"). In XP and Win2k access is also granted to the "Power Users" group, but I think this group is not created (by default, at least) in Vista.

The access by the default administrator is really incidental -- the thing that should matter is the access given to members of the "Administrators" group ... but some administrators (and some setup programs and other software run by administrators) may incorrectly grant access to the default administrator (or the current administrator user) rather than to the group.

One of the most frustrating reoccuring issues with our old installer(which I'm happily busting my butt to rewrite in NSIS) was permissions issues on folders or problems writing/reading to/from the registry. Since actions on the registry only give an error without giving any indication of what went wrong, I'm fearful of having to continue to deal with these issues.

Often times the user swore they are in the administrators group despite the problems.

That sounds like what I was talking about, above. If some admin has foolishly given access to himself (default or otherwise) rather than to the administrators groups as a whole then other administrators won't have access.

They can take access by taking ownership of the object and granting access to themselves ... but that is an explicit action (two, actually) and not something that the system will quietly just do because they try to access the object.

So, the moral of the story is: if you want all administrators to be able to access something then you should give access to that object to the "Administrators" group, not to individual users. If there's someone you don't want to be able to access that object then don't make them an administrator, because administrators can always take access to anything (and sometimes mess up other permissions in doing so).

Also, is there a way to distinguish between a user in the Administrators group of a domain, versus an Administrator on the local machine? This can be confusing because an Administrator on a domain can log into a computer joined to the domain, but not be a part of the local Administrators group of that machine, thus have these issues when installing but misbelieve that they have administrator rights to the machine.

This is getting outside my experience ... I admin a small workgroup LAN but when I'm using a domain-controlled LAN I'm not an admin ...

I think what happens is that there is a "Domain Admins" group as well as an "Administrators" group, and that the "Domain Admins" group is automatically added to the local "Administrators" group when a PC logs into a domain. So, all admins - whether local or network - appear as members of the "Administrators" group but those that are only local admins do not appear as part of the "Domain Admins" group.

I assume you can do that with UserMgr::IsMemberOfGroup (but I've never tried).

See "Domain Admins" here:
support.microsoft.com/kb/243330
--
Daniel

AaronLS
9th March 2008 05:51 UTC

Re: About Admins

Originally posted by Daniel James

This is getting outside my experience ... I admin a small workgroup LAN but when I'm using a domain-controlled LAN I'm not an admin ...

I think what happens is that there is a "Domain Admins" group as well as an "Administrators" group, and that the "Domain Admins" group is automatically added to the local "Administrators" group when a PC logs into a domain. So, all admins - whether local or network - appear as members of the "Administrators" group but those that are only local admins do not appear as part of the "Domain Admins" group.

I assume you can do that with UserMgr::IsMemberOfGroup (but I've never tried).

See "Domain Admins" here:
support.microsoft.com/kb/243330
--
Daniel [/B]

What happens on my network, is I can join a computer to a domain, and then log on to the domain as one of the domain administrators, but when I look at the users on the machine, it shows the login that was added is in the Users group. So I didn't have administrator access to the machine by default.

Daniel James
10th March 2008 13:19 UTC

Re: Re: About Admins

Originally posted by AaronLS
What happens on my network, is I can join a computer to a domain, and then log on to the domain as one of the domain administrators, but when I look at the users on the machine, it shows the login that was added is in the Users group. So I didn't have administrator access to the machine by default.

Well ... that link I posted -- http://support.microsoft.com/kb/243330 -- says this:

â€¢ SID: S-1-5-domain-512
Name: Domain Admins
Description: A global group whose members are authorized to administer the domain. By default, the Domain Admins group is a member of the Administrators group on all computers that have joined a domain, including the domain controllers. Domain Admins is the default owner of any object that is created by any member of the group.

I am not quite sure what it means by saying that the Domain Admins Group becomes a member of the local Admins group. Can one group be a member of another? I didn't think so.

When a user logs in the system constructs what is known as an "Access Token", which is basically a list of the SIDs that apply to that user -- the user's own SID and the SIDs of all/any groups of which that user is a member. What I think the above piece of verbiage is trying to say is that when a user who is a member of "Domain Admins" logs into a computer, and that computer connects to the domain, the system adds the SID for "Administrators" to the user's Access Token. That doesn't mean that the user is actually a member of "Administrators" on that machine (as shown by the "Local Users and Groups" administrative tool), just that he will have all the same rights.

Whether that's what actually happens is another matter, of course!

In short: The acid test is whether you can actually perform operations that require you to be a member of "Administrators", not simply whether the system reports that you are a member of that group.

Cheers,
Daniel.

Anders
10th March 2008 13:35 UTC

About local groups: "Although they can't be nested inside each other as domain groups can, they can hold principals and domain groups from any domain in the forest." (from http://www.pluralsight.com/wiki/defa...tIsAGroup.html )

Daniel James
10th March 2008 13:52 UTC

Originally posted by Anders
About local groups: "Although they can't be nested inside each other as domain groups can, they can hold principals and domain groups from any domain in the forest." (from http://www.pluralsight.com/wiki/defa...tIsAGroup.html )

That's a useful link -- explains Windows security better than any of the 'official' documentation than I've read. Thanks for that.

Yes, from that page:

The rule of thumb is that a group can have as a member any other type of group that has already been expanded. For example, the local group is the most flexible because it's expanded last. Pretty much anything can be a member of a local group because by the time the server's authority expands it, all the other group memberships are known.

OK, the reason I said I didn't think a group could be a member of another group is because I only admin weeny little workgroup networks and wasn't aware of the technicalities of domain-based groups.

OTOH, what I wrote about Access Tokens pretty-much agrees with the description given there.

Cheers,
Daniel.