I try to remote debug C# application (remote PC under WinXP (32bit), VS runs under Win7 (64bit) i got an error message:
Error while trying to run project: Unable to start debugging.
Logon failure: unknown user name or bad password. See help for more information.
On both machines i set-up user accounts with same name/password, and both machines locates on same work group in LAN.
When I enabled login audit on WinXP I see strange record on event log, common sense of this is: login forbidden for user SYSTEM, but i run VS and remote debug moniton by another user name.
Can somebody explain me how to beat this strange error?
Upd: I tryed to run VS2010 as remote user with command:
runas /user:pc_name\user_name path_to_vs_ide
then pass password. IDE was started succesfully, but when i choose "Attach to process..." and wrote pc_name in qualifier field, i got same error as above:
Logon failure: unknown user name or bad password.
So my question is still yet actual. How to remotely debug C# applications?
Upd2: Problem solved after install new pure copy of WinXP.
Assume you have two computers, C1 and C2. You create a user Alex on both, and each copy of Alex has the same password. Same user, right?
These are not the same user login. Each has a different unique identifier (UID).
If you try to log in to C1 from C2 using "Alex" as the user name, the user you are using is the Alex from C2, not the Alex from C1, which is the principal the remote system will use to authenticate. But the remote system doesn't know who Alex from C2 is.
Try changing your remote credentials to your equivalent of "C1\Alex": the remote computer name, a \, and the user name.
You can see more info here on how to set up remote tools: http://msdn.microsoft.com/en-us/library/bt727f1t.aspx Gregg's blog is very useful for account requirements: http://blogs.msdn.com/b/greggm/archive/2008/05/15/visual-studio-remote-debugger-service-user-account-requirements.aspx
You really want two local user accounts, one on host and remote host, with the same username and password (to have Visual Studio authenticate using a local account that matches a remote account (username and password) that has been given permissions to debug in msvsmon.exe)
Windows cached credentials - if you accessed a resource and checked “remember me”, Windows cached credentials to that resource. If you ever attempted to Attach To Process using the current user logged into the local machine, Visual Studio will pick up these cached credentials and attempt to use this as authentication for remote debugging. So you’ll need to clear these credentials (control userpasswords2, Advanced tab, Manage Passwords, Delete the credentials for that remote host)
Now you can either attempt to access the resource (like a share) using a different credential and store it, or you can run Visual Studio as that user you want to debug with that corresponds to the user on the remote side.
Alex, you may need to change the Local Security Policy setting on the Windows XP machine, here are more details: http://msdn.microsoft.com/en-us/library/ek2256kk(v=vs.100).aspx
Related
I have reviewed lots of similar questions but none seems to cover this case. So please check the details before assuming it is a duplicate.
Scenario:
I have a client and server application written in c# targeting .NET Framework 4.7.2 that communicates using NamedPipeClientStream and NamedPipeServerStream respectively.
The server is running as the local administrator account and creates the NamedPipeServerStream like this:
PipeSecurity ps = new PipeSecurity();
ps.AddAccessRule(new PipeAccessRule(WindowsIdentity.GetCurrent().Owner, PipeAccessRights.FullControl, AccessControlType.Allow));
ps.AddAccessRule(new PipeAccessRule(new SecurityIdentifier("S-1-5-32-544"), PipeAccessRights.ReadWrite, AccessControlType.Allow));
NamedPipeServerStream mypipe = new NamedPipeServerStream("mypipe", PipeDirection.Out, 1, 0, PipeOptions.WriteThrough, 0, 0, ps);
mypipe.WaitForConnection();
On the server I have created a local account called "testuser" that is a member of the local administrators group. This account is used for authentication on the client when connecting to the Named Pipes over the network.
The client program is running as a local user on a different machine connected via network and creates the connection like this:
NamedPipeClientStream mypipe = new NamedPipeClientStream("<ip of server>", "mypipe", PipeDirection.In, PipeOptions.None);
mypipe.Connect();
When running the server software on Windows Server 2012 this works fine. But on Windows Server 2016 and Windows Server 2019 I get the UnauthorizedAccessException. If instead of my local user "testuser" I authenticate with the built-in Administrator account over the network, it works fine on all three version of windows server.
If I change the pipe security to use a SID of for example S-1-5-11 to allow "authenticated users" it also works on all three versions but the requirement is to only allow members of the local administrators group from connecting to the server over the network. Ideally it should not matter if the account is a local or domain account, but I have only tested with local accounts.
I have done some debugging using Event Viewer on the server and I can see Event 5145 (Detailed File Share) with Audit success for my testuser when accessing the pipe, but the client still reports UnauthorizedAccessException.
Is there any way to restrict access for only members of the local administrators group on windows server 2016 and 2019?
If anyone else runs into this problem I found the cause.
The problem was "UAC remote restrictions". More information can be found in Microsoft's KB 951016
If a local account is a member of the Builtin\Administrators group and authenticates over the network for instance to an SMB share such as \\remotecomputer\C$ or a named pipe, the account will not authenticate as a "full" administrator and thus not have access to administrative resources. Such accounts will have to be elevated from a interactive logon such as RDP to gain full administrative privileges. As such, my scenario with builtin accounts does not work because of this security feature.
There seems to be three ways to handle this problem.
Disable this security measure in the registry (probably not recommended).
Use a domain account and add that as a local administrator. This security restriction appears to only affect SAM (local) accounts.
Only use the builtin Administrator account as this is also not affected by the security restriction.
Note that if the registry is edited incorrectly there might be serious consequences. So backup the registry before performing any changes. The following instructions are based on Microsoft's article on the subject:
To disable the restriction in the registry:
Open the registry using regedit and select the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Create the following key (type DWORD) if it does not exist, otherwise just edit it to have a value of 1: LocalAccountTokenFilterPolicy.
I have a windows service that polls a folder continuously for new files.For local directories this works fine.But when it comes to UNC Paths on another system in the same network,the service cannot access the folder it seems.I have refereed to this post https://serverfault.com/a/881272 ; it states that i need to run the service as the currently logged in user.How im i supposed to do that?
The path i wish to monitor using the service is
\DESKTOP-PC\Users\me\myfolder
Please advice
UPDATE:
I have developed the service using topshelf.I want to poll a folder on another local machine in the same network.I go to network places,double click on the computername,it asks for credentials,i enter the username and password of the remote computer i get access to the files on the system for that user(in explorer).
Now when i set the service to run as the local machine user under this machine,it cannot access the remote UNC Path that is accessible using explorer.I have tried installing it as the remote machine user,but it fails.
myService.exe install -username:DESKTOP-REMOTE\myname -password:mypassword
Open the Control Panel > Administrative Tools > Services window on
your Windows server.
Stop your windows service.
Open the Properties > Log On dialog.
Change the service user account to the target user account.
Start your service.
If you are developing the service in Visual Studio, and want to emulate a different account you can also press shift + right mouse click on devenv.exe and click on "run as different user".
Also make sure you are specifying the full path to the folder and that the account you use has full rights to the folder.
If you try to run your service under the desktop-remote\myname account you probably will fail. The local machine only likes accounts belonging to itself.
What I would do is to turn it around. Make the remote computer share a folder for your machine to poll. That way the remote machine has control over which data it is publishing, just like an object has its properties to private or public. If you are ok with having anyone who knows the address \\desktop-remote\my-not-so-secret-folder\ being able to read it, set it so anyone can read. If you are more secretive, suffix the folder with $ like so: \\desktop-remote\my-secret-folder$. Now it is not visble but still reachable.
You can also create a special account that has access to said folder.
Then you let your service run any account (with network access) of your choosing on your local machine. Let it try to connect to the remote folder with the special account.
(I have learned, the hard way, that reading a shared folder is slightly different between machines without domain and machines in a domain; the anyone-can-read does not work. At least in WindowsXP it was that way. I have since then not have the need to share a folder.)
HTH
When you set the service to run as the local system account, it cannot access the remote UNC Path that is accessible using explorer with local machine account.
Simply because the explorer manages logged on user credentials, so, you have added UNC path credentials to the LOGGED user only.
When you change it to Local System Account, the user credentials to the share is not stored.
Try to create a local user without password expiration and then enable it access to the Share.
All you will need to do is to setup windows service with this new account registered.
I was facing this problem with my UNC storage in the Azure cloud.
What worked is setting up the credentials in the windows credentials manager:
windows credential manager
You can get the connection string from the Azure portal.
This resolved our problem.
You can have a look at Impersonation. Also, if the service is running as a localuser, then it would help to create the same user with similar password on the machine where the folder resides.
Have a look here (the OP in this post is experiencing the same issue and he/she has given the shared folder “Everyone access to full control”.
https://serverfault.com/questions/177139/windows-service-cant-access-network-share
Hi I have a strange problem and am unable to find out the root cause. We build and deployed our application using Redemption things were working fine but suddenly the installation on UAT server has stopped working. But the same is working in production(Thank God).
Our application is of console based and written using .NET 3.5 its not totally down, it is working but when we try to run the same application via scheduler task it didn't work, but when we double click the exe file it works properly, successfully connect to Exchange reads and download the files as per our business logic but not executing when we try to run under scheduler task.
below is small error info might be helpful for you..
2012-06-15 16:05:06,724 EmailProcess.Program - message = Error in
IMAPISession::OpenMsgStore: MAPI_E_FAILONEPROVIDER ulVersion: 0 Error:
Microsoft Exchange is not available. Either there are network
problems or the Exchange computer is down for maintenance. Component:
Microsoft Exchange Information Store ulLowLevelError: 2147746069
ulContext: 1318
Please suggest
Edit 1: More info Windows 2008 Server, a user named SpecialTasksUser is configured on the server to login and has admin rights. Outlook is installed and profile is configured for different user name OutlookSpecialUser, when we login using SpecialTasksUser user and launch the outlook it loads and shows the inbox and private folders...so far so good.
We created the scheduled task and configured to run under user name SpecialTasksUser because this user has admin rights and this is where it gives error. On the other hand, when we go to installation directory and double click the *.exe file the application works and redemption successuflly reads the email and does what it is suppose to do...please help
I hope this information would be helpful .....
Most likely you are using a wrong parent identity of your process - scheduler runs under its own account by default. Make sure you specify the right Windows account.
I believe I understand why I am getting this -- but could be wrong... I believe that the PC I am running msvsmon.exe (the pc to debug) is a domained PC, and I have been given it to work on without its domain server, it is offline to its domain sever. I do have local administrative account and privileges - to do all - but not attach my VS studio to the msvsmon running on this PC....
I added a 2nd lan adapter -- and have a private connection.... still no...
Can I make this 2nd Lan connection be Workgroup'ed? --- and thus by-pass the domain server logon name requirement....
Is there a setting for MsVsMon.exe -- to say hey --- this is a LAB evironment -- give up and allow the connection....
The unauthorized connection works..... but -- that I have learned is not allowing the .PDB files to match and thus no symbols!!!!!!!!
So any way -- at all?????
To have remote debugging with symbols --- any possible way?????
Thanks in advance....
best regards,
Kevin Waite
NOTE: ===> One added addition characteristic..... despite the PC being debugged is offline to its domain controleler . . . . I can create a new Admin user and successfully remote desktop to this PC - - - one would think that if I can connect for remote desktop I should be able to connect for remote debugging ..... !####!
I usually only have success with remote debugging if I'm logged on with exactly the same credentials on both machines.
This works (for me) if I'm logged on to the domain as the same user on both machines.
It also works if I create a local non-domain account with the same name and password on both machines, and ensure that I'm logged on using that on both machines.
In all other cases, I get the same problems as you do...
Unless someone has a way for 'workgroup' connection on LAN adapter #2 to
coexist on a domained controlled PC via its LAN adapter #1. This seems impossible.
From above, recall, I am trying to debug on a domained PC that is offline to its
domained controller, and the remote debug connection fails with no service available
to processes the log-on request....
And thus the only solution to connect successfully to this PC was to switch it
to a Workgroup PC for remote debug connection.
The credentials: user name and password must be identical between both the
PC with VS 2010 and the PC to be debugged running MsVsMon.exe....
The user must have on the debugged PC security privilege 'logon on to service' set.
One can archive the domained configuration for restoration by force taking a Windows
checkpoint prior to switching to workgroup configuration.
best regards,
Kevin Waite
This is my code :
DataClassesDataContext data = new DataClassesDataContext();
var hey = from p in data.Provas
select p;
Response.Write(hey.First().title_it);
if I open this playing start to Visual Studio, it opens http://localhost:51180/Website1/ and I get the value taken from DB.
But, if I open the website with http://localhost:8080/ (which usually I open with this) I get :
System.Data.SqlClient.SqlException: Cannot open database "Website1" requested by the login. The login failed.
Login failed for user 'IIS APPPOOL\Website1'.
How can I should settings? IIS problem?
As #usr pointed out the answer is in front of you.
When you run the app in debug mode form Visual Studio the user connecting to the database is the user logged into the PC and running Visual Studio - the odd are that this user (you!) is an administrator and has administrator rights with SQL Server (I'm assuming a local instance).
When you run the app via the local installation of IIS (which it is reasonable to assume is the full version, not express) then, unless you change the app pool for the application, it will be running as a local system user (right now I forget which one, you can go look at the app pool to see) and by default that user will not have access to the databases in SQL Server.
To fix this you need to do one of two things either:
a) Change the user in the app pool to one that has rights to the database in SQL Server (if you want good practice then you should define an explicit user)
b) Grant the appropriate rights to the appropriate system account to access the database
(Note that in both cases you're going to need to add the user to SQL Server using Management Studio or equivalent)
Verify login names on http://localhost:8080/. Possibly this article will help you.