We have an application that programmatically maps network drives. On Vista with UAC on, we get some strange issues.
Our application maps the drive non-elevated, so if the user browses explorer and double clicks to run an exe, it prompts for UAC. So when they approve it, it prompts for a username/password for the share... Strange since the credentials are saved.
It turns out, an elevated process cannot access a mapped drive that was mapped from a non-elevated process.
To see this issue in action, do the following steps:
Run cmd.exe with no UAC
Run "net use w: \yourHostname\yourShare /user:yourUser yourPassword /persistent:yes"
Run cmd.exe as Administrator
Type "w:", and see the error message
At this point you can run plain "net use" and see the connection on the elevated cmd is Unavailable but the other non-elevated cmd sees it as OK.
Does anyone know a workaround to fix this issue? or maybe a way to map a network drive to "All Users"?
This is by design.
Even though the user account is the same, with the elevated version having a token with membership in the administrator group and addition privileges, the tokens are created independently and thus have different LUID's and appear to the kernel to be from different user logons. Since they are from different logons, mapped drives are not shared between them.
http://blogs.msdn.com/cjacks/archive/2007/02/19/mapped-network-drives-with-uac-on-windows-vista.aspx discusses this in additional detail.
Check out this link: Regedit Link
They describe a registry key that allows elevated users to access mapped drives and vice versa. This solves all my issues and was exactly what I was looking for.
EDIT:
The original link is dead, but here's the text as copied from the Jan 24, 2009 snapshot at www.archive.org:
If you are finding that you don't have access to mapped drives from your admin token try the following. When running as a protected admin you have two tokens and this key will maintain the connection for both tokes (that is my understanding anyway). It can also help to clear up issues with Login scripts.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
EnableLinkedConnections =(dword)1
Also of use is the "'Group Policy Scripts can fail due to User Account Control" section of this doc.
http://technet2.microsoft.com/WindowsVista/en/library/5ae8da2a-878e-48db-a3c1-4be6ac7cf7631033.mspx?mfr=true
I will be posting more information on this soon.
Related
I'm running into the problem outlined in this question: How to prevent uninstaller elevating for Standard Windows 10 user? where unstallation of an app installed under the user's AppData folder works correctly from the classic control panel "Programs and Features" page, but fails from the Settings "Apps and Features" page, due to the unilateral attempt by Windows to elevate the uninstall process.
I should be able to fix the issue if I can determine the identity of the user that originally started the uninstallation, but as far as I can tell the token holding their identity is lost when the elevation happens.
Trying to make a comparison with Unix, but my understanding there is that more often the effective UID is changed to gain permissions, in that scenario I'm trying to recover the real UID.
Is this possible via the Win32 API, and if so how? I've googled long and hard, and all I keep turning up are pages telling me how to recover lost accounts or passwords.
Looking at this answer I see that someone has commented that is having the same issue, and a day of googling hasn't found me an answer.
Win10 (I'm on enterprise here at work) won't allow me as an admin user to create symlinks on a non-elevated Powershell or Command Prompt, though elevated prompts of either flavor work as expected. We have a custom tool written in Python for asset management that heavily uses symlinks that we're porting from OSX/Unix to Windows for a number of reasons. UAC is turned off as shown here, I'm an admin account on the computer. We have not yet tested on a non-admin account because this is a tool both admins and non-admins use daily, and elevated prompts require us to remap our network drives on every reboot.
Here's my security policy showing everyone should have access. Is there something obvious I'm missing?
After a successful compiled application, I transferred the executable to a network drive with the post-build event in VS. Every time I start my project, it is opened under my user credential but it needs administrators privilege to run like expected. So VS ask me if I want to close VS and restart it under admin privilege. After that, VS looses my connected network drives because it runs under administrator, not my own credential. If I go in command prompt with admin privilege and type "Net Use" command, there is no network drives attached. After mapping the missing drives, VS is able to compile like expected.
Now, my question is, when I go to command prompt with admin privilege, what is my credential? If I type "whoami", I get my own user name but it is not totally true because there is no mapped network drives like under command prompt without admin privilege. Even if my user is under local administrators group...
We can add a value in the registry to synchronize mapped network drives between linked tokens. This is documented under Some Programs Cannot Access Network Locations When UAC Is Enabled in TechNet:
To work around this problem, configure the EnableLinkedConnections registry value.
The registry key is
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
The EnableLinkedConnections value is a DWORD set to 1 to share mapped drives between linked tokens or to 0 for the default behaviour.
A colleague has a batch script program which needs to to run on a Windows Server in console mode, so that it has access to a Windows interactive session. The server is rebooted at regular intervals automatically (there's an unrelated closed-source application that runs on this machine that we have no control over). After a reboot he wants to automatically start a Windows interactive session and have this script run, plus the service needs to also have access to network resources (CIFS drives, in particular).
Here's what we've tried so far:
Start as Windows service. This failed, since a Windows service can either have access to interactive session or to network resources, but never both.
Used Microsoft management console to add the script to run at startup, however this did not work.
Used an HKLM registry key to start to run this script, however it only gets started when we manually open a remote desktop session on the server.
Creating a scheduled task. The program invoked did not have access to interactive windows session.
Any other suggestions? (Or maybe he missed something when he set up one of these suggestions?)
In case "Interact with desktop" on the service is not enough (I have seen a handful of cases where it is not), you can combine it with AutoAdminLogon. Create three (or four for a domain) REG_SZ values under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon:
DefaultUsername
DefaultPassword
DefaultDomain
AutoAdminLogon
AutoAdminLogon should be set to the string "1", the others are self-explanatory.
Obviously this has security issues big enough to fly Jupiter through.
Have you tried having your script run as a Windows service, but allowing it to interact with the desktop?
Specifically:
Go to the service properties page
Click on the "Log On" tab
Select "Local System account"
Check "Allow service to interact with desktop"
See my similar question and real answer to it: How to start a process from windows service into currently logged in user's session
NOTE: "Interact with desktop" checkbox is not enough at all.
I recommend going about this another way. You could build another Windows app that communicates via IPC to the Windows Service and that could be what deals with the closed souorce application. But if you must, you can specify an option in the service (you can do this through MMC, registry, etc). Basically, you can see this option by going to Computer Management->Services and Applications->Services->Right click your service->Change account to Local System and check "Allow system to interact with desktop."
However, again, I recommend choosing another path.
I had to do something similar recently; a route that I found but discarded due to security concerns is to have the interactive service set self as running in interactive mode and then run the ImpersonateUser function in the win32 API, which I think will provide the benefits of both a user and the interactive session available from the LocalSystem.
Needless to say, if someone broke into a service that did that, they would have total control of the machine.
I've been asked to provide a program/script/whatever that enables or disables the
CD/DVD drive
USB ports
Floppy (!) drive
devices without requiring admin rights, that is, that can be run by a 'normal' user.
Ideally, something like a command line utility:
C:> foobar cdrom /disable
Any pointers, hints or clues gratefully accepted!
Thanks,
Rony
Without finding a security hole in Vista, it just plain can't be done. They require admin rights for a reason --- that's the type of things only admins should be doing.
There is a command-line utility (devcon.exe, available here), which will enable/disable devices, but it's still going to require admin rights. It's syntax is:
DEVCON disable {device id} where {device id} is one of the "Hardware ids" listed under the "details" tab of the device's Device Manager property page.
You could write a service that runs as a privileged account (e.g. Local System), and write a GUI front-end application which communicates with the server. The non-admin user can then run the front-end.
If you happen to be on a domain, I think you can disable all of that through a group policy.
First of all you should check if user without admin rights can do it from windows ui, using Device Manager. And I really doubt it.