I need to call WNetGetConnection to get the UNC path and it works good when application run as standard user but it returns 1201(ERROR_CONNECTION_UNAVAIL) error code when application run as admin. According to the documentation its working as expected.
If the network connection was made using the Microsoft LAN Manager
network, and the calling application is running in a different logon
session than the application that made the connection, a call to the
WNetGetConnection function for the associated local device will fail.
The function fails with ERROR_NOT_CONNECTED or
ERROR_CONNECTION_UNAVAIL. This is because a connection made using
Microsoft LAN Manager is visible only to applications running in the
same logon session as the application that made the connection. (To
prevent the call to WNetGetConnection from failing it is not
sufficient for the application to be running in the user account that
created the connection.)
that means its not possible at all to get the UNC path from the app running as admin ? Is there some other way ?
This is by design. Network shares created by a non-elevated account are not visible under elevation, and vice versa.
See this question on Super User for discussion of the issue. There is apparently a registry setting that enables mapped drives to be shared between elevated and non-elevated accounts but I've never tried it myself.
Network connections cannot normally be shared across different Windows login sessions. This is regardless of admin account / elevation level. Each Windows login or impersonation session needs to create its own network connections.
Related
I'm writing a Windows device driver for a custom USB device, but am having trouble opening the device from my user program (using CreateFile) when the user program is run as a domain user. If I run as a local user, or as an administrator (or 'Run As' administrator) I can open the driver fine, but as a domain user GetLastError returns 5 (access denied).
I originally had this problem with local users too, and found I had to add the following SDDL entry to the .inf file, which solved the problem for local users:
HKR,,Security,,"D:P(A;;GA;;;SY)(A;;GA;;;BA)(A;;GRGW;;;BU)
From this reference:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff563667(v=vs.85).aspx
When I discovered that domain users did not have access I thought that simply adding them to this SDDL entry would give them access, but it doesn't seem to work: I still get access denied. I've even tried extreme solutions such as giving all users (everyone (WD), unauthenticated users etc.) full access, but this doesn't work either, which makes me think the problem lies elsewhere; i.e. something else is denying domain users access which takes precedent over the permit in the SDDL entry in the driver inf.
So my question is, what am I missing that is required to give domain users (or all users) access to connect to the driver? Or are there any other solutions to this problem (such as connecting to the driver as a service and then accessing this service from the user program)?
HKR,,Security,,"D:P(A;;GA;;;WD)"
set everyone can access, try it!
I'm wishing to use Visual Studio Load Tests to perform some load testing.
I was hoping to be able to use the counter monitoring that the Load Test provide in order to collect performance statistics from the web server I'm loading.
However there only seems to be support for connecting to machines you wish to monitor via your domain credentials. From http://msdn.microsoft.com/en-us/library/ms182594.aspx, section "To specify computers to monitor with counter sets during load test run"
On each server that you monitor, you must have sufficient user permissions to run performance monitors. Otherwise, errors are generated.
There seems to be no way to provide specific credentials to use to connect to machines you wish to monitor. As the web server I wish to monitor does not belong to a domain, I don't see any way to monitor it using VS Load Tests.
Is there some way to monitor it using VS Load Tests that I've missed?
There seems to be no way to provide specific credentials to use to connect to machines you wish to monitor
There is a way to do this. On Windows 7 it is called Credential Manager and you can access it either by searching for Manage Network Passwords on your Start Menu or via Control Panel > User Accounts. On older versions it was called Stored User Names and Passwords, also accessible via Control Panel > User Accounts.
In a nutshell, it allows you to specify alternative credentials for remote systems. Once you have set up credentials, it works completely invisibly and automatically for remote connection attempts from any application applications that support it, including Visual Studio collecting remote Perfmon data.
NOTE that you have to set up the credentials on the account that actually runs your load tests. If you are only running local load tests with no Controller then that's your own account. However if you run a Controller/Agent rig, the Controller may be configured to run under a service account (i.e. check the account running "Visual Studio Test Controller" service or QTController.exe). You have to login as that account and add the credentials.
I've found the following which is working for me. I'm just running the net use commands by hand because I don't want the user name and password in source control.
To get this working you will need to manually open an IPC channel to
the SQL and IIS machines with an account that has permissions in that
domain. This allows the account running the load tests to "piggyback"
across that IPC channel.
i have found this site to be a great help getting this going myself.
http://blogs.catapultsystems.com/tlingenfelder/archive/2009/06/18/performance-counters-timeouts-and-load-testing-with-visual-studio-2008.aspx
what you can do is create a small bat file and set it up to run in the
.testrunconfig file as a setup script.
net use \\SQLSERVER\IPC$ password1 /user:DOMAIN1\USER /persistent:yes
net use \\IISSERVER\IPC$ password2 /user:DOMAIN2\USER /persistent:yes
I am attempting to control a service on a remote machine using the following code:
// Error checking omitted for brevity
HANDLE hToken = NULL;
// user = username with no domain specification
// domain = targetmachine when targetting computer outside of domain
LogonUser(user, domain, password,
LOGON32_LOGON_NEW_CREDENTIALS, LOGON32_PROVIDER_WINNT50, &hToken);
ImpersonateLoggedOnUser(hToken);
SC_HANDLE hSc = OpenSCManager(targetmachine,
SERVICES_ACTIVE_DATABASE, SC_MANAGER_ALL_ACCESS);
This works fine when run from a computer within our local domain and targetting a machine on the same domain, both when using the credentials from the currently logged on user as well as when using other credentials.
However, when I attempt to target a machine that is not on any domain, the OpenSCManager call fails with access denied if I specify anything other than SC_MANAGER_CONNECT as the desired access. Targetting a domain computer from a computer that is outside the domain works (using user/domain/password combination for a domain user that is a local administrator on the target machine). Targetting a computer outside the domain from a computer outside the domain does not work.
The user/password is for a member of the administrator group on the target computer, so there should not be a problem with the account rights.
I've checked the scmanager security descriptor using sc -sdshow scmanager and it is identical for the domain computer and the non-domain computer. Both are running Windows 7 64-bit.
I've also tested to use psexec, which has the same symptoms, i.e. works fine between domain computers but not when targetting non-domain computer.
I have also tested to disable RPC over TCP on the target machine and rebooting it, as this is described as a possible cause for access denied errors but this does not appear to help. I've also tested to disable the Windows Firewall on the targetmachine, but no change.
Is there some setting that needs to be enabled in order for remote configuration of services to work?
It appears that this was caused by new security features from Windows Vista and above. By default, Windows will not grant remotely connecting users full administrator rights unless it is being done within a domain. So in order for this to work, User Account Control Remote Restrictions need to be turned off, but of course this will also lower the security of your computer.
Thanks to Hans Passant for recommending to check for similar issues posted on serverfault.com.
Here's what I want to do:
a program that listens in the network for a message, and when that message is received, if the user is not logged in (for example the computer just powered on and windows displays the classic login screen), it automatically logs in a certain user accordingly to the message. the username and password are known and stored safely inside the computer in a configuration for the program i'm talking about.
What I had in mind was a windows service that starts with the computer and also listens to those messages, and if one is received, then it does it's job
but I have no idea of where to start
(basically i'm trying to login a user without having to type the password, which I said is stored and known - need something mostly like the fingerprint software windows 7 comes with, and the ones that you had to install in vista/xp so that fingerprint login would work (fingerprint was only an example) )
There's two methods to pursue depending upon which operating system you're looking to run under.
For Windows XP, Windows 2000, and Windows Server 2003 you need to create a GINA.DLL. This is a replacement DLL which must follow specific rules which handles the authentication process. In your case your replacement DLL would be known by the service which was listening for your start signal, and it would make a call into the DLL with the username and password as appropriate.
MSDN Magazine article on customizing GINA.DLL
MSDN entry on GINA
For Windows Vista/7 and above you'll need to look into the Credential Provider API.
MSDN Magazine article on Credential Provider API in Vista.
MSDN entry on Credential Provider API
You can use windows auto logon feature to do this.
Create a service which waits for the required data on a network socket. Make sure this service is started after the network service (Tcpip). Modify winlogon service properties (manually) so that it depends on your service. By depends, I mean that winlogon service is started after your service.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\AutoAdminLogon to 1
Once you receive the data on your network socket, set the following registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultUserName
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultPassword
Once the registry settings are in place, then the winlogon service can read those values and proceed with the login process.
For more details on setting the registry values refer: http://support.microsoft.com/kb/315231
I want clarify a little the suggestion of Vikram.exe.
Of cause the usage of AutoAdminLogon seems native for the problem, but saving of the password in registry as a clear text under HKLM\...\Winlogon\DefaultPassword is not good. Since Windows 2000 it is supported the usage of the secrets DefaultPassword which makes the same effect as the DefaultPassword registry value (see Protecting the Automatic Logon Password for the code example).
Another way to force user login or to do any other actions on the login screen is switching to the Winlogon desktop (full name WinSta0\Winlogon). You can use SwitchDesktop and SetProcessWindowStation to do this (see Window Stations and Desktops). If the service run under System account you will have all rights to do this. Depend on the configuration of your service it could be also needed to use SetTokenInformation with TokenSessionId to change the current session id. After the service process will run on the WinSta0\Winlogon desktop you can use functions like FindWindow and other GUI API to place any information in controls of the window (user name, password and so on) of other process. So you can implement more complex scenarios.
Firstly let me just say im not 100% sure how to fully complete such a application but I have a few tips.
you will need to create a Windows Service that starts during the Pre-Login, you can create a service in C#, An example of creating a C# Service is linked below:
http://msdn.microsoft.com/en-us/library/zt39148a(VS.80).aspx
Within your application you would set the property Startup Type to Automatic, This will automatically start your service on boot.
You should know that windows services run under a secure context by account so you will have to get your service to run with privs do do this.
In your Service Properties you can Click Log On and you can
To specify that the service uses the Local Service account, click This account, and then type the following NT AUTHORITY\LocalService.
To specify that the service uses the Network Service account, click This account, and then type the following NT AUTHORITY\NetworkService.
As your trying to do this remotly you will have to look at WMI (Windows Management Instrumentation) and you will be able to start/stop and send commands to your service.
Your service then would send a command to the Login Management (Not Sure of the name).
you may also wish to check this WOL class which will switch the computer on remotely as long as it supports Wake On LAN, If this is for a corporate environment then I advise you to check your network cards to make sure they are supported
http://www.codeproject.com/KB/IP/wolclass.aspx
I know of some education software that I use for schools that's called CC4 ( http://www.rm.com/shops/rmshop/story.aspx?cref=PS1026195 ) and we can do exactly what you need within this system, I'm not fully sure of how it works fully but i believe it takes the same principles described above.
i'm using a Windows 2003 Server.
I have a session with my username on it and i have a windows application (not service) opened on it. I want this application to always be running.
The problem is, when Security updates force Windows to reboot, my session is closed and i need to reconnect to the session to get my application working again ..
How can i do to automaticaly force the opening of my user's session upon server's reboot ? (application launch is in the startup of my session)
Thanks
If you want to have the program running consistently, I would highly recommend making it into a Windows service (see also this page). Then you can set the username that the service logs on with (this is particularly important if the app needs to access networked resources), and even set the stability values to have the service restart itself if the EXE crashes for some reason.
Otherwise, if you really want the computer to login as your user and run the program, you could set the autologon parameters to your username and password, and put the shortcut to your program in the user's Start Menu Startup folder. (But this does not provide you any of the stability benefits that a service would.)
Add a startup script, http://technet.microsoft.com/en-us/library/cc779329(WS.10).aspx