First of all, I realize this is a messy situation, but it's not of my design, and I'm just trying to help, and for that I need your help.
App A is getting installed automatically via SMS installer under the Administrator account, not the PC owner's User account. App A has a registry key defined in HKEY_LOCAL_MACHINE hive.
After App A is installed, we want to edit the above mentioned registry key, to assign the User's C:\Users\USER_ID\Documents\ folder (I'm told we don't don't know who the user is and don't have access to USER_ID during step 1).
I know all about UAC, Application Manifest, and requestedExecutionLevel. However, I'm told we can't expect that all users will be in the Administrators group on their machine.
Solution must be backwards compatible with Windows XP as well.
I'm searching for options to get `C:\Users\USER_ID\Documents\' into the 'HKEY_LOCAL_MACHINE' hive under the above listed conditions.
I found this thread that might be related to a similar situation, but I don't fully understand it yet (so I will give credit to anyone that explain it better):
Find out (read) logged in user in a cmd started as a different user
I also read something that rules out ClickOnce:
Clickonce + HKEY_LOCAL_MACHINE
After App A is installed with admin privileges you are trying to run an additional script as the local user who does not have admin privileges . In order for your secondary script to write to the local machine key it will have to be run with administrative privileges ..period. That said, you have basically two choices:
1) Use the RunAs command to run the script with elevated privileges and have the user type in a admin username and password to run the script with elevated privileges.
2) This is the better way imo - Since SMS is being leveraged as the delivery tool, use its capability to detect and use local client configuration settings to write the key at the time of installation.
So basically the SMS package would have to be setup to run only when the local user logs on one time so that SMS can grab the current user and write it to a file somewhere.. after that is completed SMS can run a separate package as the admin (user will get prompted) to do the software install looking for the file containing the user and then consequently updating the local machine key to the correct user my document path.
Enjoy!
Related
I am running this in Windows 10
What is the difference between running a program in a user account with admin rights, versus running in a standard account but right clicking and running as admin - and by difference, I mean from the program's point of view.
I thought from the program's point of view, there would be no difference. But apparently that isn't exactly true.
See - I have this piece of hardware (The DLink Air Bridge for the Quest 2 Headset). It won't connect to the desktop app unless I run it in an account with admin rights. But here is the thing, if I run it in the same account (but now with only standard rights) but right click on the program and "Run as Admin" - it still won't connect. How can this be?
I am asking this here because the support for both Meta and Dlink is hopelessly, HILARIOUSLY inept.
Also - what is worse when it comes to security: Using an account for daily stuff with admin rights, or right clicking on particular programs that need it and always running as an admin. I assumed it was the latter - but I am an idiot when it comes to computer security.
When an administrator logs in, the full elevated token is stored in a system process and a more restricted token is generated from this and is used to start Explorer.exe at logon.
When this admin user elevates, UAC starts the new process with the full elevated token (often called "split token"). This causes some minor complications related to mapped network drives and HKCU COM objects but essentially the two tokens refer to the same user account and the same HKCU registry key.
On the other hand, when a non-admin UAC elevates they have to enter the credentials of an administrator and it is this administrator and their account/profile/HKCU that is tied to the token when the new process is started. Meaning, a process running as this administrator is present in the desktop session of the non-admin user. This means a different profile folder and different HKCU compared to other processes in the session.
According to Microsoft, UAC is not a security boundary. If you are really concerned about security then you need to log in as the administrator separately.
Lenovo's system update program can be started without administrator right. When the service starts, it creates a temporary administrator account to perform the installation.
Why can a windows application have right to create an administrator-level account? How can I achieve it when I want to create a similar program?
It's related to TVSU. A design point of TVSU is that even limited users can install updates from Lenovo. And to accomplish this, the TVSU service creates a temporary admin account with a randomized username and password, then uses it to do the installations on behalf of the limited user. This is the only time the account is created. The account is not created when an admin user does updates, because the admin user already has the permissions needed to do installations.
The account is supposed to be deleted after the TVSU session finishes, but I'm aware of a case where this doesn't happen and the account stays around. However there isn't any security risk to this because both the account and password are random and not known by anything except the specific TVSU process that created them, and this process ended the last time TVSU was closed. You can safely ignore the account, delete the account, or else it should be deleted the next time TVSU is run.
I have a script on my domain stored on the Active Directory server. every machine on the domain has a task that when fired, calls this script to run.
Running the task from the AD server works. Running the task from another machine doesn't work. However, running the command that is triggered from cmd manually on the remote computer works?
Could anyone shine some light on this. Basically I call it like this so that the trigger is set up like...
Action: PowerShell.exe
Arguments: -noprofile –ExecutionPolicy Bypass -File "\\<>NameOfADServer<>\C$\Tasks\script.ps1" "Argument 1" "Argument 2"
Running as SYSTEM is probably your issue - it wont have any access outside of the PC its running on.
When you run it manually youll have the access.
There's several problems here.
You're running the task as the local SYSTEM accounts. SYSTEM generally does not have access to any network resources.
You're using the administrative share (\\<servername>\C$) to share the script. Only users that have Administrator access to the server can access the administrative shares. Administrative shares are heavily restricted by design and you cannot modify the access on them.
My guess is that the script works when you run it manually is because it's using the current user's credentials for network access when you do that, but don't quote me on that.
The simplest solution with the least amount of change is to do this:
Create a group in Active Directory. Add the Computer accounts, or, preferably, groups with Computer accounts which you want to be able to run the script to this new group. If you really want any SYSTEM account on any computer in the domain to be able to run the script, you can add the "Domain Computers" group to the group.
Create a folder on the server. Put the script in the folder. Don't put anything in this folder you don't want your users to read. Assign the "Read" NTFS permission to the group created above to the folder.
Share the folder out. Grant the group you just created the "Full Control" share access. If you want, you can make it a hidden share by adding a dollar sign to the end of the name.
Update your scheduled tasks to use \\<servername>\<sharename>\script.ps1.
This is almost certainly not the best method to accomplish what you're actually trying to do, but this is probably the best way to use scheduled tasks running scripts on a network share with the SYSTEM account.
I'm running into the same problem again and again for ages so I decided to ask my question here :
I added a service account "ZYX" into the Administrators group of my Windows 2K8 Server.
Whenever I try to run a scheduled task (running as "ZYX") that modifies a file located under a folder where the Administrators group has full control, my PowerShell script always gets "Access to the path xxxxxxx is denied".
When I check the effective permissions of my service account on this folder, it is written that it is granted every single permission.
I found two ways to overcome the situation, but I find this really ugly :
Running the scheduled task with highest privileges
Add the service account "ZYX" with full control in the folder Security part.
Im starting believing my service account only gets the rights inherited from the Administrators group when the shell runs in elevated mode.
Can someone explain me why Windows manages the rights like this ?
Do you have any better solution for this ?
Thanks
(Skip to the bottom for the TLDR version.)
OK - so I have searched (really!) and all other UAC articles I have found seem to center on enabling, disabling, detecting or hiding UAC. My issue is not one of those, so here goes:
My user used to have the standard dual-token setup where I was in the Administrators group and the UAC's Consent UI would just ask me if I wanted to proceed. Now, we have separate administrative-level accounts that we need to use, and I have to authenticate with this new user. The problem I am having is that previously, starting an app as Administrator just elevated my current user, where now if I use the credentials of the new administrative user, whatever I am running runs AS that new user.
As an example, previously elevating CMD and typing whoami into the command prompt used to return my normal/current user, where it now returns the new administrative user.
This has serious negative consequences - since this is a new user, and an Administrative-level one, if any files are created using this new user, my normal user cannot write to or delete them unless I manually adjust permissions and ownership. If I use my development environment under the new account (e.g. I need to debug a service or work with a driver) and rebuild something, I end up with a bunch of files that I cannot manipulate unless I am an administrator. Likewise if I add a file while running as this new account - my SCM tool will not be able to update that file later unless it also runs under this new administrative account.
Also, Since a profile is associated with this user, things run under a completely different environment (different %USERNAME%, %USERPROFILE%, %LOCALAPPDATA%, etc.)
Installing an application will also work incorrectly if it is installed just for the current user (e.g. the "Just Me" option), instead of for all users. Things that are licensed to/in my normal user account also fail to function if run under the new account, because things are running as that new user.
The ripple effects of this change are getting larger and larger the more I work with it. So...
[TLDR] Is there a way to get temporary elevation of the current user without that user having the normal dual-token setup you get from being in the Administrative group? Or are you stuck with the impersonation behavior?