asked on

User can install exe without local admin rights

I'm stumped.

I have a user on Windows 7, with no local admin rights, able to install Ghostscript on her PC. Her domain account permissions and member group permissions don't have any sort of admin rights either. She used the 64-bit 9.26 version installation : https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/download/gs926/gs926aw64.exe

I noticed she had version 9.09 installed previously so I did this test on another Windows 7 PC joined to the same domain:

1. I cloned her AD account.
2. Found the oldest version of GhostScript available to download, version 9.18. From my domain admin account on the test PC, I gave that account local admin rights. (using the net localgroup administrator user /add)
3. Logged in with the clone account. I installed GS version 9.18. Logged out. Switched back to my domain admin account.
4. Removed local admin rights for the cloned account (net localgroup administrator user /delete)
5. Logged back in as the user, tried to install version 9.26,. This failed. Without admin rights, the installer cant write into C:\Program Files. See attached error.

I don't know what else to look for. This has to be something local to her computer as on domain level, I can replicate the error. I have a CTO looking at me as if I'm to blame for this AD domain I've inherited.

Thoughts?

Bradley Fox

Was the user account granted NTFS write permissions to the c:\program files\gs folder on their workstation?

un_sysadmin11

ASKER

Using the icacls command, this looks like to only be read, execute, generic read, generic execute:

%windir%\system32> icacls "c:\Program Files\gs"
c:\Program Files\gs NT SERVICE\TrustedInstaller:(I)(F)
NT SERVICE\TrustedInstaller:(I)(CI)(IO)(F)
NT AUTHORITY\SYSTEM:(I)(F)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
BUILTIN\Users:(I)(RX)
BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
CREATOR OWNER:(I)(OI)(CI)(IO)(F)

stefor

Since you installed the software the first time with elevated permissions all other users would default need to use an elevated session to write to that folder.

Could you provide a dump from her logon session on the computer with the error with whoami /groups and also another icacls from the folder she's writing to when installing the software.

I suspect the issue is/was that someone at some point have extended BUILTIN\Users full permissions to that folder or to Program Files on her computer.

Sean Bravener

unfortunately out in the wild there are some poorly written applications that do not check for admin permissions before execution. if the user has the ability to write new folders on their pc they program will execute. an example of would be any program that has a "light" version for running from a thumb drive. programs that use "non standard" installers also have been known to get around local admin permissions.

ASKER CERTIFIED SOLUTION

Steven Carnahan

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

ina_don

As the 2 others have stated, the location of the installation could be worth looking into. Currently, I have worked on an AD machine locked with restrictions and other policies where its possible to get applications and put them in the users\%username%\appdata\local\ which have managed to run and also avoid the blocking of network access for applications place in any other folders.

un_sysadmin11

ASKER

Hi Everyone,

Thank you for the responses!! The installation is in C:\program files\gs. The actual exe is C:\program files \gs\bin\gnswin64.exe I posted the permissions above with icacls command.

"%windir%\system32> icacls "c:\Program Files\gs"
c:\Program Files\gs NT SERVICE\TrustedInstaller:(I)(F)
NT SERVICE\TrustedInstaller:(I)(CI)(IO)(F)
NT AUTHORITY\SYSTEM:(I)(F)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
BUILTIN\Users:(I)(RX)
BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
CREATOR OWNER:(I)(OI)(CI)(IO)(F)"

On my test computer (with errors) with the cloned account, here are the whoami /group results (with some identifying info changed) It's attached.

Here are the icacl from the test computer, when I installed the 64 bit version using my own admin account, then switching back to the clone account and viewing her permissions on c:\program files\gs:

c:\Program Files\gs NT SERVICE\TrustedInstaller:(I)(F)
NT SERVICE\TrustedInstaller:(I)(CI)(IO)(F)
NT AUTHORITY\SYSTEM:(I)(F)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
BUILTIN\Users:(I)(RX)
BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
CREATOR OWNER:(I)(OI)(CI)(IO)(F)

Bradley Fox

It looks from your output that Creator Owner has Full permissions on the folder. Can you check who the owner is on the user's specific workstation? I feel like, since you can't reproduce this on another workstation that someone made a specific change to that user's computer to allow this, maybe unintentionally. Possibly granting their user account Administrator to do the initial install, then revoking her admin rights would make them the owner on that folder.

un_sysadmin11

ASKER

On her workstation, the owner of that folder is BUILTIN\Administrators.

ina_don

Thanks for the update.

It does look weird.
A few steps I would look into;

Have you tried running the installer while logged in as the user (not via cloned account) and on the actual machine?
Are you certain that her specific machine is still able to refresh AD policies? (gpupdate /force)
Are you by any chance running WSUS/SCCM and is it possible at any point someone added the application into sccm for self service?

un_sysadmin11

ASKER

For the last question - no. Not running either of those. I am going to try questions 1 & 2 today as I really think it's something user specific! Stay tuned....