Disable UAC for standard accounts in Windows 10 (Please read full post before replying. Thanks.)
-
OK... Here's the issue: I've been tasked with migrating my company's kiosk music system from Windows 7 to Windows 10. We currently have about 40 machines out on rental. The machines are not internet-connected, and the kiosk launcher runs in a restricted "standard" user account, and uses Parental Controls and Group Policies to maintain its security. I'm currently rewriting the launcher shell in C#/.NET 4.6.2 following MS current security policy guidelines. The main music player app and its registration plugin were written (not by me!) nearly 10 years ago for Windows Vista, and needs read/write access to several files in %programfiles% folder and to registry keys in both HKLM and HKCU. We no longer have the original source code, and the company will not authorise a complete rewrite (despite my protestations!). In Windows 7, I simply disabled UAC across the entire system, and set the music player app and its registration plugin "Run As Administrator" for all accounts. That has worked for us for 7 years now, and caused us no security issues, due to the machines being "locked down" in so many other ways. With the advent of Windows 10, "Run As Administrator" results in the user being prompted for an administrator password every time the music player is started. I've failed completely to disable UAC on the standard restricted user account. Here's all the suggestions which haven't worked: 1) Drop the UAC slider to the bottom in the main Administrator account. This disables UAC on all Admin accounts, but not on standard ones. 2) Change "EnableLUA" to zero in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System. Same result as 1) 3) Create a shortcut to the music player EXE including the administrator password... Basically Aaaaaaargh! That would risk exposing the machine's administrator password and break our other security. 4) Create a task in Task Scheduler to run the app with administrator permissions. This is impractical because the machine administrator password has to be written into the task. All 40 machines have unique passwords, and there is no "automatic" way of writing that into the task. The systems need to be upgradeable with a sysprep'd clone. It also risks exposing the admin password to "local hackers" same as 3). 5) Write the "Run As Administrator" along with the password into the kiosk launcher shell prior to compilation. Gets around the chance of exposing the password, but I'd need to recompile the launcher for each machine, because they all have unique password
-
OK... Here's the issue: I've been tasked with migrating my company's kiosk music system from Windows 7 to Windows 10. We currently have about 40 machines out on rental. The machines are not internet-connected, and the kiosk launcher runs in a restricted "standard" user account, and uses Parental Controls and Group Policies to maintain its security. I'm currently rewriting the launcher shell in C#/.NET 4.6.2 following MS current security policy guidelines. The main music player app and its registration plugin were written (not by me!) nearly 10 years ago for Windows Vista, and needs read/write access to several files in %programfiles% folder and to registry keys in both HKLM and HKCU. We no longer have the original source code, and the company will not authorise a complete rewrite (despite my protestations!). In Windows 7, I simply disabled UAC across the entire system, and set the music player app and its registration plugin "Run As Administrator" for all accounts. That has worked for us for 7 years now, and caused us no security issues, due to the machines being "locked down" in so many other ways. With the advent of Windows 10, "Run As Administrator" results in the user being prompted for an administrator password every time the music player is started. I've failed completely to disable UAC on the standard restricted user account. Here's all the suggestions which haven't worked: 1) Drop the UAC slider to the bottom in the main Administrator account. This disables UAC on all Admin accounts, but not on standard ones. 2) Change "EnableLUA" to zero in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System. Same result as 1) 3) Create a shortcut to the music player EXE including the administrator password... Basically Aaaaaaargh! That would risk exposing the machine's administrator password and break our other security. 4) Create a task in Task Scheduler to run the app with administrator permissions. This is impractical because the machine administrator password has to be written into the task. All 40 machines have unique passwords, and there is no "automatic" way of writing that into the task. The systems need to be upgradeable with a sysprep'd clone. It also risks exposing the admin password to "local hackers" same as 3). 5) Write the "Run As Administrator" along with the password into the kiosk launcher shell prior to compilation. Gets around the chance of exposing the password, but I'd need to recompile the launcher for each machine, because they all have unique password
djdynamix wrote:
- Create a task in Task Scheduler to run the app with administrator permissions. This is impractical because the machine administrator password has to be written into the task.
Not necessarily - you might be able to get away with ticking the "Do not store password" option. The task would only have access to local resources, but it sounds like that's all you need. Alternatively, you could adjust the permissions on the relevant files / folders / registry keys to give the standard user the required access. Or, if the older application doesn't have a manifest, you might be able to get away with file and registry virtualization: Registry Virtualization (Windows)[^] Folder Virtualization in Windows Vista - Rick Strahl's Web Log[^] Using the CorrectFilePaths Shim to Redirect Files on Windows Vista – The App Compat Guy[^] Using VirtualRegistry to Redirect Registry Keys on Windows Vista – The App Compat Guy[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
djdynamix wrote:
- Create a task in Task Scheduler to run the app with administrator permissions. This is impractical because the machine administrator password has to be written into the task.
Not necessarily - you might be able to get away with ticking the "Do not store password" option. The task would only have access to local resources, but it sounds like that's all you need. Alternatively, you could adjust the permissions on the relevant files / folders / registry keys to give the standard user the required access. Or, if the older application doesn't have a manifest, you might be able to get away with file and registry virtualization: Registry Virtualization (Windows)[^] Folder Virtualization in Windows Vista - Rick Strahl's Web Log[^] Using the CorrectFilePaths Shim to Redirect Files on Windows Vista – The App Compat Guy[^] Using VirtualRegistry to Redirect Registry Keys on Windows Vista – The App Compat Guy[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Thanks for your reply, Richard, and apologies for taking so long to reply. Unfortunately I didn't get a notification. Unfortunately, the "Do not store password" option probably won't work, because it will then request an admin password whenever the app is started. I'll have a look through the other links you've supplied. It looks like quite a steep learning curve, but I guess nothing worth doing was ever "easy"! ;-) It amazes me that no one has found a way to totally disable UAC in Windows 10 yet. It seems to be something that a lot of users need to do in order to provide backward compatibility for "badly written" old apps. It's all very well Microsoft trying to push us towards better security practices, and I agree that we need eventually to rewrite some of those dodgy old apps, but I don't know any company which can afford to ditch 15 years of R&D and go back to the drawing board in the few months we're being given, especially with the Intel gen7 processors refusing to install any older OS!
-
Thanks for your reply, Richard, and apologies for taking so long to reply. Unfortunately I didn't get a notification. Unfortunately, the "Do not store password" option probably won't work, because it will then request an admin password whenever the app is started. I'll have a look through the other links you've supplied. It looks like quite a steep learning curve, but I guess nothing worth doing was ever "easy"! ;-) It amazes me that no one has found a way to totally disable UAC in Windows 10 yet. It seems to be something that a lot of users need to do in order to provide backward compatibility for "badly written" old apps. It's all very well Microsoft trying to push us towards better security practices, and I agree that we need eventually to rewrite some of those dodgy old apps, but I don't know any company which can afford to ditch 15 years of R&D and go back to the drawing board in the few months we're being given, especially with the Intel gen7 processors refusing to install any older OS!
djdynamix wrote:
Unfortunately, the "Do not store password" option probably won't work, because it will then request an admin password whenever the app is started.
It probably won't. It just runs the task as the administrator, but without elevated access to network resources. :)
If you select the checkbox labeled Do not store password , Task Scheduler will not store the credentials supplied on the local computer, but will discard them after properly authenticating the user. When required to run the task, the Task Scheduler service will use the "Service-for-User" (S4U) extensions to the Kerberos authentication protocol to retrieve the user's token. When using S4U the ability of the service to use the security context of the account is constrained. In particular, the service can only use the security context to access local resources.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
OK... Here's the issue: I've been tasked with migrating my company's kiosk music system from Windows 7 to Windows 10. We currently have about 40 machines out on rental. The machines are not internet-connected, and the kiosk launcher runs in a restricted "standard" user account, and uses Parental Controls and Group Policies to maintain its security. I'm currently rewriting the launcher shell in C#/.NET 4.6.2 following MS current security policy guidelines. The main music player app and its registration plugin were written (not by me!) nearly 10 years ago for Windows Vista, and needs read/write access to several files in %programfiles% folder and to registry keys in both HKLM and HKCU. We no longer have the original source code, and the company will not authorise a complete rewrite (despite my protestations!). In Windows 7, I simply disabled UAC across the entire system, and set the music player app and its registration plugin "Run As Administrator" for all accounts. That has worked for us for 7 years now, and caused us no security issues, due to the machines being "locked down" in so many other ways. With the advent of Windows 10, "Run As Administrator" results in the user being prompted for an administrator password every time the music player is started. I've failed completely to disable UAC on the standard restricted user account. Here's all the suggestions which haven't worked: 1) Drop the UAC slider to the bottom in the main Administrator account. This disables UAC on all Admin accounts, but not on standard ones. 2) Change "EnableLUA" to zero in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System. Same result as 1) 3) Create a shortcut to the music player EXE including the administrator password... Basically Aaaaaaargh! That would risk exposing the machine's administrator password and break our other security. 4) Create a task in Task Scheduler to run the app with administrator permissions. This is impractical because the machine administrator password has to be written into the task. All 40 machines have unique passwords, and there is no "automatic" way of writing that into the task. The systems need to be upgradeable with a sysprep'd clone. It also risks exposing the admin password to "local hackers" same as 3). 5) Write the "Run As Administrator" along with the password into the kiosk launcher shell prior to compilation. Gets around the chance of exposing the password, but I'd need to recompile the launcher for each machine, because they all have unique password
-
No. 6) app.manifest
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
-
djdynamix wrote:
Unfortunately, the "Do not store password" option probably won't work, because it will then request an admin password whenever the app is started.
It probably won't. It just runs the task as the administrator, but without elevated access to network resources. :)
If you select the checkbox labeled Do not store password , Task Scheduler will not store the credentials supplied on the local computer, but will discard them after properly authenticating the user. When required to run the task, the Task Scheduler service will use the "Service-for-User" (S4U) extensions to the Kerberos authentication protocol to retrieve the user's token. When using S4U the ability of the service to use the security context of the account is constrained. In particular, the service can only use the security context to access local resources.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Thanks again Richard. I appreciate your help. I've now solved the problem. What I did was to download the Compatibility Assistant from MSDN, and created and installed a .sdb compatibility shim, with the setting "Run As Invoker". Everything now works exactly as it did under Windows 7. Thanks again. Ian
