How to check administrator rights?

[peterbi]

Hi,

I am working on a package, the installation of the package needs to check if the user has 'administrator' rights, if so, the installer will prompt some message.

How can I check the administrator rights during the installation? I saw somebody mentioned AdminUser and Privileged properties, which are not quite proper for my case, because our package needs to support W2K3/XP/Vista. Is there a better way to do it?

Thanks,
Peter

[RobertDickau]

Would adding MSIUSEREALADMINDETECTION to the mix help?

[#3]

I saw somebody mentioned AdminUser and Privileged properties, which are not quite proper for my case, because our package needs to support W2K3/XP/Vista. Is there a better way to do it?

Could you elaborate? Why won't AdminUser or Privileged work for you?

[peterbi]

For our own good reason(s), we suppressed UAC prompt on Vista (by setting 'Word Count' to 8), and the most weired thing is that once UAC is suppressed, 'Privileged' and 'AdminUser' properties are never working: I can see they have value of '1', but I can never catch that in my CA in ExecuteSequence (see my other posts <Changed property on Vista and error 1316 on XP at www.installsite.org>on why I have to do this).



I also tried MSIUSEREALADMINDETECTION, it's not set (and being caught by CA) even with 'Administrator' account.


Any recommends?


Thanks,
Peter

[peterbi]

Repost - don't know how the previous one got corrupted:

For our own good reason(s), we suppressed UAC prompt on Vista (by setting 'Word Count' to 8), and the most weired thing is that once UAC is suppressed, 'Privileged' and 'AdminUser' properties are never working: I can see they have value of '1', but I can never catch that in my CA in ExecuteSequence (see my other posts <Changed property on Vista and error 1316 on XP at www.installsite.org>on why I have to do this).

I also tried MSIUSEREALADMINDETECTION, it's not set (and being caught by CA) even with 'Administrator' account.


Any recommends?


Thanks,
Peter

[peterbi]

Repost - don't know how the previous ones got corrupted:

For our own good reason(s), we suppressed UAC prompt on Vista (by setting 'Word Count' to 8), and the most weired thing is that once UAC is suppressed, 'Privileged' and 'AdminUser' properties are never working: I can see they have value of '1', but I can never catch that in my CA in ExecuteSequence (see my other posts <Changed property on Vista and error 1316 on XP at www.installsite.org>on why I have to do this).

I also tried MSIUSEREALADMINDETECTION, it's not set (and being caught by CA) even with 'Administrator' account.


Any recommends?


Thanks,
Peter

[MichaelU]

It sounds like you're trying to read MSIUSEREALADMINDETECTION, but it's not intended to be used that way. Instead if it's set (at least in the MSI itself or command-line; I'm not sure if you can change it back and forth with custom actions), reading Privileged (or AdminUser) will give you true instead of hopeful information.

[peterbi]

To state the question in another way: is there a RELIABLE property I can use in IS2008 (InstallScript MSI project) that can check if the current user (who runs the installation) has administrator rights, on W2K3/XP/Vista?

I have tried AdminUser/Privileged, but it seems 'Privileged' is relying on UAC turned on (when you reply 'Allow' to UAC, 'Privileged' is set to '1' or ture), if I turn off UAC (by setting "Word Count" to 😎 on Vista, I can never catch 'Privileged' property as true, at least on ExecuteSequence.

BTW, in the above testing case (UAC turned off on Vista), built in InstallShield script function Is(USER_ADMINISTRATOR, "") also failed to catch admin rights in an administrator account.

So I think turning off UAC affected all the properties/functions mentioned above, are there anything else that IS NOT affected by UAC on Vista?

I also searched for some c/c++ function (our prefered way for Custom Action implement) for doing this, such as IsUserAdmin(), CheckTokenMembership(), RunningAsAdministrator(), etc, etc, but none of them works on my case (my guess is that executing the functions/CAs in context of InstallShield may cause them to fail).

It really seems not that difficult: just a property/function that reliably check if the current user has administrator rights, on Vista (UAC turn on/off), XP, and W2K3 (better W2K too, but the above 3 is good enough).

Can anybody provide a solution for this? I know it must be one there 😉

Thanks,
Peter

[MichaelU]

Are you certain that Is(USER_ADMINISTRATOR, "") is incorrect? We had a bug with it some time ago which resulted in it reporting yes whenever the user was the administrators group. This is the case for even the limited user aspect of an administrator account under UAC. I'm not certain what effect turning UAC off would have had, as there are at least two different ways to do it with different results - one makes administrators always full administrators, the other makes all prompts automatically return yes or no.

[peterbi]

Yes, I am.

Here is what I did:

I set two CAs in UI sequence:
1) CheckAdmin, a ISScript CA (immediate execute/without any condition) with the following simple code:
function CheckAdmin(hMSI)
begin

if( Is(USER_ADMINISTRATOR, "")) then
MsiSetProperty(hMSI, "ADMINLOGIN", "1");
else
MsiSetProperty(hMSI, "ADMINLOGIN", "0");
endif;
end;
2) CheckRights (after CheckAdmin), a Type 19 CA, with condition ADMINLOGIN="1", and certain message.


The above works fine on W2K3 - non-admin user will go through install; admin-user will see the error message from 'CheckRights' CA and exit install.

On Vista with UAC turned off (or 'Require Administrator Privileges' set to 'No', or 'Word Count' set to 8, which I think all are equivalent), it failed to execute 'CheckRighs' CA on an account with admin rights (thus failed to prompt error message and exit install), non-admin still went through since it should. Here is the part of log file about 'CheckAdmin' function (from Vista user with admin rights):


Action ended 15:16:25: CheckPrivileged. Return value 1.
Action 15:16:25: CheckAdmin.
Action start 15:16:25: CheckAdmin.
InstallShield 15:16:26: Running InstallScript function f1
InstallShield 15:16:26: Using temp folder C:\Users\ADMINU~1\AppData\Local\Temp\{CCC8733B-57F1-40B3-819B-46F97B6A7191}
InstallShield 15:16:26: Installing engine...
InstallShield 15:16:26: Using product language 1033
InstallShield 15:16:26: Extracting support file setup.inx to C:\Users\ADMINU~1\AppData\Local\Temp\{CCC8733B-57F1-40B3-819B-46F97B6A7191}\setup.inx
InstallShield 15:16:26: Opening stream of file C:\Users\ADMINU~1\AppData\Local\Temp\MSI54F4.tmp
InstallShield 15:16:26: Extracting support file ISRT.dll to C:\Users\ADMINU~1\AppData\Local\Temp\{CCC8733B-57F1-40B3-819B-46F97B6A7191}\ISRT.dll
InstallShield 15:16:26: Extracting support file IsConfig.ini to C:\Users\ADMINU~1\AppData\Local\Temp\{CCC8733B-57F1-40B3-819B-46F97B6A7191}\IsConfig.ini
InstallShield 15:16:26: Extracting support file _isres1033.dll to C:\Users\ADMINU~1\AppData\Local\Temp\{CCC8733B-57F1-40B3-819B-46F97B6A7191}\_isres.dll
InstallShield 15:16:26: Extracting support file String1033.txt to C:\Users\ADMINU~1\AppData\Local\Temp\{CCC8733B-57F1-40B3-819B-46F97B6A7191}\String1033.txt
InstallShield 15:16:26: Skipping optional support file _isuser1033.dll
InstallShield 15:16:26: Setting script cmdline...
InstallShield 15:16:26: ProductCode is {A3D94F6E-F73B-4183-9C20-021DFF7D9B9B}
InstallShield 15:16:26: Initializing Engine
InstallShield 15:16:27: Done Initializing...
InstallShield 15:16:27: Registering Msi Server...
InstallShield 15:16:27: Invoking script function CheckAdmin
InstallShield 15:16:27: CallScriptFunctionFromMsiCA() ends
Action ended 15:16:27: CheckAdmin. Return value 1.
//It skipped 'CheckRights', which means 'ADMINLOGIN' is not 1, in other words, Is(USER_ADMINISTRATOR, "") failed to set the property correctly. But W2K3 worked.Action 15:16:27: DetermineAppsRunning.
Action start 15:16:27: DetermineAppsRunning.


You mentioned there was a bug on it (the function), but my problem seems the opposite (hope it's not another bug). I am using IS2008 - Premier Edition, Version 14, With Licensing Hotfix. But I haven't downloaded hotfixes for quite a while.

But I prefer there is a property or external c/c++ function I can use in this case - all our CAs are C/C++ functions and we are not using any script function to create CAs yet, and we want to remain that way if possible.


Thanks again,
Peter

[peterbi]

I still think IS should have a reliable property to determin if current runner is with admin rights or not on Vista (and probably plus other OSs like W2K3/XP), disregarding UAC is on or off. It might have been there, that's why I am posting for help:D

If unfortunately I have to yield (for whaever of reasons MSI/IS/OS all tangled together), at least in my current case I need a property that can tell me about the admin rights on current user on Vista with UAC turned off so I can make two checks: one for non-Vista, all the functions/properties seem work on it; the other is for Vista (with UAC off).

Thanks,
Peter

[#12]

Generally speaking, searching for explicit user rights (e.g. an Administrator) is not best practices and explicitly not recommended by Microsoft. However, the AdminUser property is reliable as long as you author the MSIUSEREALADMINDETECTION property in the property table:
http://msdn.microsoft.com/en-us/library/aa367545(VS.85).aspx

Also, setting that bit does not suppress UAC like you are stating it does. It simply informs Windows Installer that your setup does not require Administrative Privileges and thus should install in a per-user context. It only does not display the UAC prompt by merit of this requirement:
http://msdn.microsoft.com/en-us/library/aa367800(VS.85).aspx

If you're installing a per-user application and want to make sure only the appropriate user installs it then a simpler solution is to remove the ALLUSERS property from the property table (and ensure it never gets subsequently set) and Windows Installer will take care of the rights management for you.

[peterbi]

Thanks for your reply!

I have to search for 'administrator' rights explicitly because 'Privileged' and 'AdminUser' didn't work for me. MSIUSEREALADMINDETECTION is no use to me either because it's only useful to distinguish 'Privileged' and 'AdminUser', but in my case neither of 'Privileged' and 'AdminUser' works.

You could be right that setting the bit doesn't 'suppress' UAC, but just hide the display of UAC dialog. But one thing for sure is that "Word Count" and "Require Adminstrative Privileges" are equivalent or related, if you change one, the other will be changed (automatically). And most importantly, if I suppress the display of UAC dialog (making "Word Count" to 😎 will make 'Privileged' and 'AdminUser' useless. I am attaching a simple testing project (zipped .ism file), you can try to play with the setting (it's currently off. What I did is to create two accounts on Vista, with/without admin rights. If UAC display is on, the CAs can catch Privileged/AdminUser correctly at ExecuteSequence; once the display is turned off, the CAs can never catch the properties at all).

In my project, "ALLUSERS" property is not in the Property table.


Another question: the logic that I want to search for 'administrator' rights is that since UAC display is suppressed, so there is no way the user can be privileged or elevated, is that right? Our package is only for non-admin, non-elevated/non-privileged users, so if the possibility of being privileged/elevated has been eliminated, now I only need to check if the user has administrator rights. Are there any other ways to elevate a user other than UAC on Vista? How about other OSs like W2K3 and XP?

Thanks,
Peter

[peterbi]

Everything is about UAC:mad:

If you turn off (not just the display) UAC, all the properties and conditions work perfectly - I just tried it!

So now back to my question: is there a property/function (C/C++) that IS NOT DEPENDENT ON or AFFECTED BY the UAC on Vista that can help me to check if the user has administrator rights?

Anybody please, especially experts from InstallShield or MSI


Thanks,
Peter

[#15]

the logic that I want to search for 'administrator' rights is that since UAC display is suppressed, so there is no way the user can be privileged or elevated, is that right? Our package is only for non-admin, non-elevated/non-privileged users, so if the possibility of being privileged/elevated has been eliminated, now I only need to check if the user has administrator rights. Are there any other ways to elevate a user other than UAC on Vista? How about other OSs like W2K3 and XP?

I guess the real question is why you're very worried about whether an administrator attempts to install your package. Perhaps if we got to this logic, we could attempt to distinguish some kind of potential workaround.

The bit doesn't even suppress the UAC dialog, it simply indicates to Windows Installer that elevation isn't required. Vista employs a split-token method of user management, so when UAC is enabled and you have not elevated you do not have Administrative Privileges. However, this doesn't mean that your account is/isn't a member of the Administrators group. Is that what you want to test? Testing for "Administrator Rights" is a misnomer because it tells you nothing. The issue is that you are finding out only if the current token has administrator rights when the user might have access to a seperate token with administrator rights (through UAC elevation for example). Your test only works because you gave yourself a different token by turning off UAC. That's one reason why you must logout before that change goes in to effect.

Testing whether the current user may or may not have administrative privileges at the time of your test isn't really going to be a helpful test. The AdminUser property will tell you whether the current user is a member of the Administrators group if you author MSIUSEREALADMINDETECTION in the property table. If it does not then that would qualify as a Windows Installer bug and you should probably get in touch with Microsoft at http://support.microsoft.com.

In my testing, it does seem to work, but I don't have the resources to test at the moment.

[peterbi]

I guess the real question is why you're very worried about whether an administrator attempts to install your package. Perhaps if we got to this logic, we could attempt to distinguish some kind of potential workaround.

The reason that this installer is a slim version of our full product. Since our product can be used by users without admin rights - I call them 'restricted' users, which means they don't have rights to upgrade the full version product (unless they get help from admin), but we are releasing monthly update of data files which should not require a full version install. This data-only update is the installer I am working on, we are trying to make it only for restricted users so they can update the data files without requesting help from admin, if a user has admin rights, we would recommend to use the full version update.

The bit doesn't even suppress the UAC dialog, it simply indicates to Windows Installer that elevation isn't required.

I think it does because if the setting is 'Yes' (or 0), UAC dialog prompts during my install, if the setting is 'No' (or 8), UAC dialog never shows up during install. If it's not of the setting, can you see where in the installer (.ism) causing the UAC disappering? Or something on my Vista system? Can you give me any hints where to look for?

Vista employs a split-token method of user management, so when UAC is enabled and you have not elevated you do not have Administrative Privileges. However, this doesn't mean that your account is/isn't a member of the Administrators group. Is that what you want to test? Testing for "Administrator Rights" is a misnomer because it tells you nothing. The issue is that you are finding out only if the current token has administrator rights when the user might have access to a seperate token with administrator rights (through UAC elevation for example). Your test only works because you gave yourself a different token by turning off UAC. That's one reason why you must logout before that change goes in to effect.

Thanks for the information. I think I didn't state it precisly using 'administrator rights'. If the answer to my question (the logic that I want to search for 'administrator' rights is that since UAC display is suppressed, so there is no way the user can be privileged or elevated, is that right? ) is yes, then I should use 'a member of administrators group'.

Testing whether the current user may or may not have administrative privileges at the time of your test isn't really going to be a helpful test. The AdminUser property will tell you whether the current user is a member of the Administrators group if you author MSIUSEREALADMINDETECTION in the property table.

Again the 'AdminUser' (and 'Privileged') property is not working as described (by you and others in internet), maybe because in this specific installer, UAC dialog is suppressed so the user is never considered 'elevated' or 'privileged', no matter he/she is an administrator or not? - This is really my key question, there gets to be a way to tell if the current user is among 'administrtors' group or not disregarding UAC on or off (from MSI or InstallShield), UAC can't be on top of everything, right?

Here is the summary of the issue now:
With the following settings:
InstallShield 2008 MSI (Basic or InstallScript)
'Require Administrator Privileges = No' (and Word Count =8)
MSIUSEREALADMINDETECTION = 1 in Property Manager
No 'ALLUSERS' in Property Manager
Required Execution Level = Invoker

my simple testing installer failed to catch [AdminUser="1" or Privileged="1"] condition on a Vista system with UAC on - it failed the above condition in an account that is a member of 'administrators' group.

So -

If it does not then that would qualify as a Windows Installer bug and you should probably get in touch with Microsoft at http://support.microsoft.com.

Then it got to be a MSI bug??

In my testing, it does seem to work, but I don't have the resources to test at the moment.

Did you test my installer, or you mean your previous installers when you say 'in my testing'? If not, can you quickly build the installer and try on a Vista to see if you can repeat my result? Then I will contact MS ...


Thanks for your patience,
Peter

[#17]

I just re-tested this with my own sample project and it worked as expected, but I realized how that could be confusing. The issue is that the test is only checking the current token's admin rights. If the user hasn't elevated then the condition will return that the user isn't an admin. So basically MSIUSEREALADMINDETECTION tells Windows Installer to not set AdminUser if the user can elevate.

I did not test your installer because your installer doesn't have MSIUSEREALADMINDETECTION authored in the property table.

If it's not of the setting, can you see where in the installer (.ism) causing the UAC disappering? Or something on my Vista system? Can you give me any hints where to look for?

What I'm not describing well is that the flag simply tells MSI that it shouldn't attempt to elevate the application the installer. Stating that it's suppressing UAC leaves open the interpretation that UAC may or may not have still been required anyway or that it's allowing UAC to do something it's normally not supposed to do.

the logic that I want to search for 'administrator' rights is that since UAC display is suppressed, so there is no way the user can be privileged or elevated, is that right?

A user can launch your application from an Administrative Command Prompt and will be elevated.

[peterbi]

I just re-tested this with my own sample project and it worked as expected, but I realized how that could be confusing. The issue is that the test is only checking the current token's admin rights. If the user hasn't elevated then the condition will return that the user isn't an admin. So basically MSIUSEREALADMINDETECTION tells Windows Installer to not set AdminUser if the user can elevate.

It is CONFUSING!! So as the question you didn't answer, IS THERE A WAY THAT NOT CHECKING THE CURRENT TOKEN'S ADMIN RIGHTS, BUT CHECKS IF THE CURRENT USER (NOT TOKEN:eek: ) IS A MEMBER OF ADMINISTRATORS GROUP, WITHOUT BEING FOOLED BY UAC? That's really the thing I want to have:rolleyes:

Obviously MSIUSEREALADMINDETECTION doesn't work since it "tells Windows Installer to not set AdminUser if the user can elevate" even if the current user is a member of Administrators group.

[#19]

So as the question you didn't answer, IS THERE A WAY THAT NOT CHECKING THE CURRENT TOKEN'S ADMIN RIGHTS, BUT CHECKS IF THE CURRENT USER (NOT TOKEN ) IS A MEMBER OF ADMINISTRATORS GROUP, WITHOUT BEING FOOLED BY UAC?

Well, I believe both our testing has demonstrated that the answer to this is more than likely "No" since the property would have to check for group membership, which is not what the properties do unfortunately.

However, you could write a custom action that calls CheckTokenMembership ( http://msdn.microsoft.com/en-us/library/aa376389(VS.85).aspx ) for membership in the Administrators group.

Keep in mind that since you're distributing an MSI someone can just take out your conditions and/or custom actions.

[peterbi]

Noop, CheckTokenMembership is also under control of UAC, I have tried and it didn't work.

So now the whole world needs to comply UAC, the monster :mad: So neither MS nor InstallShied can beat it:(

[#21]

Yeah, sorry, I forgot. You want to use GetTokenInformation ( http://msdn.microsoft.com/en-us/library/aa446671(VS.85).aspx ) instead because the other one doesn't really work. It's handy for seeing if you're currently elevated or not to some extent, but at the same time useless as there's no real reason to test for that - you already know whether you're elevated based on application manifest.

If you search for the RunningAsAdministrator function you can find a sample here: http://msdn.microsoft.com/en-us/library/ms995339.aspx