I'm using the WNetEnumResource to enumerate all network share connections and WNetCancelConnection2 to close them. Then I am using WNetUseConnection to connect to a share using discrete credentials. This process happens multiple times throughout the day.
The problem that I'm running into is that after the first flow through the process I'm getting:
System Error 1219 has occurred.
Multiple connections to a server or shared resource by the same user,
using more than one user name, are not allowed. Disconnect all
previous connections to the server or shared resource and try again.
This happens even when the enumeration says there are no current connections.
My question is: why? Why am I getting this error? Is the authenticated connection to the server still cached? Can I enumerate these authentication tokens? Kerberos? LSA?
I haven't been able to find the smallest foothold of information to progress forward on this project. Any help is appreciated!
I'm trying to remember the solution we used when we came across this problem for a network backup program a few years ago.
I'm certain the solution involves using either WNetAddConnection2 or WNetAddConnection3 instead of WNetUseConnection. I think that passing the flag CONNECT_CRED_RESET should take care of this, but I'm not absolutely certain.
Note that CONNECT_CRED_RESET is only documented for WNetAddConnection2 and not WNetAddConnection3, though MSDN says the only difference between the two is the hWnd parameter for owner of dialog windows - I'd try with WNetAddConnection2 and only if it works, experiment with WNetAddConnection3. You may even get it to work with WNetUseConnection!
Make sure to note the dependencies CONNECT_CRED_RESET has on other flags.
Related
It appears that in some very rare cases GetComputerName() Windows API returns 'TENTATIVE' as a computer name. Based on information from our customers we suspect that this sometimes happens on laptops when they 'awaken' from a sleep. The odd thing is that this happens after our app is already running and able to connect to a back-end server and retrieve some information from it - i.e. the computer name is written into a log file at the time.
We are considering putting a slight delay during 'awakaning' but would like confirm that the cause is what we suspect.
We could not find anything on-line that would confirm the source of the issue.
I am building a Windows service that will watch for specific occurrences of events and disk activity. When such an event occurs my plan is to alert the user to the event via a client app, and provide remediation if necessary. I have (mostly) completed both the client and service components, which work great... unless the client app isn't running.
In short, I am looking for a way to start up the client app from the Windows service via CreateProcess to provide information to the user. However, it appears the service can't even see the file/folder of the client app to execute it. I suspect this is due to the credentials under which the service is running, or maybe due to service level restrictions, but wanted to reach out for some advise before I get into this any deeper.
So, the obvious question first... am I thinking about this clearly? Is the architecture plan sound, or should I look at another method? I would prefer not to re-do any of the work I have already completed, but obviously want to make sure the plan and process is solid.
Question #2, what are the limitations I face with this model? Is there a service account that will allow this level of access?
I am obviously struggling with this right now, so any thoughts or assistance will be greatly appreciated!
Thanks,
Kris
As others have mentioned already, you can't (easily) launch an application directly from the service, so I think the easiest way around the problem is to create a process that starts on login and runs with the credentials of the logged in user, eg an app that sits in the system tray, and it opens up a named pipe or a network port to the service. If the service needs to alert the user, it sends a message down that channel and then the client process can either show its own UI or launch an application. Interprocess communication using pipes or ports are the simplest way to deal with the restrictions on session 0 processes.
A Windows service does not have access to the user session in Vista and above, so it is blocked from starting an executable on that session. You can download a white paper from Microsoft that goes into detail: Impact of Session 0 Isolation on Services and Drivers in Windows.
Since Vista, services run in session 0 and the user's desktop is always in a different session. Thus you need to work hard to start a service on the user's desktop.
It can be done but it is pretty tricky. Details can be found here: http://blogs.msdn.com/b/winsdk/archive/2009/07/14/launching-an-interactive-process-from-windows-service-in-windows-vista-and-later.aspx?wa=wsignin1.0
If,for example,The socket in my compiled application is designed to connect to 123.456.789.0.
How do I check if its connected to 123.456.789.0? Is there a way to do this?
The idea is this:I want to prevent other people editing my program and changing the address to,for example, 127.0.0.1 and make it connect through a proxy.
Is there any function/way/trick to check the address after the socket is connected?
Use the getpeername function to retrieve the address of the remote host.
If someone edits your program like you mention, they'll probably alter such a check as well though.
nos's comment about the insecurity of this approach is correct, but incomplete. You wouldn't even need to change the program's code to circumvent your proposed mechanism.
The easiest way around it would be to add an IP alias to one of the machine's network interfaces. Then a program can bind to that interface on the port your program connects to, and the OS's network stack will happily send connections to the attacker's local program, not your remote one.
So, now you say you want to know how to list the computer's interfaces so you can detect this sort of subversion. Your opponent counterattacks, launching your program as a sub-process of theirs after installing a Winsock hook that routes Winsock calls back through the parent process.
We then expect to find you asking how to read the executable code section of a particular DLL loaded into your process space, so you can check that the code is what you expect. Now your opponent drops the Winsock shim, switching to an NDIS layer filter, rewriting packets from your program right before they hit the NIC.
Next we find you looking for someone to tell how to list the drivers installed on a Windows system, so you can check that one of these filters isn't present. Your opponent thinks for about 6 seconds and decides to start screwing with packet routing, selecting one of at least three different attacks I can think of off the top of my head. (No, wait, four.)
I'm not a security expert. Yet, I've spent five minutes on this and already have your security beat seven different ways.
Are you doomed? Maybe, maybe not.
Instead of you coming up with fixes to the risks you can see, better to post a new question saying what it is you're trying to protect, and have the experts comment on risks and possible fixes. (Don't add it here. Your question is already answered, correctly, by nos. This is a different question.)
Security is hard. Expertise counts for far more in that discipline than in most other areas of computer science.
I'm using DCOM to provide various application services on a Windows network, using Kerberos to handle authentication. The system normally works fine, but I'm running into issues accessing the service from a separate (trusted) domain. Particularly, the service is unable to make callbacks to the client application, receiving the error "A security package specific error occurred". Also, if I tweak the service to specifically require Kerberos authentication (rather than using SNEGO/negotiate), the client can't even call into the server (again receiving "A security package specific error occurred").
The confusing thing is that things have been working for years without issue. However, a few things are different here, as compared to what we've done before. For one, the servers involved are running Windows 2008, which I have not previously used. Also, as noted above, the errors are only occurring when the service is accessed from an account from a separate domain, and previous usage has never attempted this.
Now to the question: I'm not using an SPN (service principal name) for this DCOM service, but some of the errors and event logs makes me think that might be the problem. However, all the docs I've found are unclear on whether this is correct, or how I would set up the SPN if I do need it. Does anybody know for sure whether an SPN is what I'm missing here? If so, can you point me to how this should be done?
Additional details:
For the scenario where the server is set to force Kerberos authentication, turning on Extended RPC Debugging gives some additional clues. The client can successfully connect using CoCreateInstanceEx, but calls on the service interface fail as noted above. The RPC error records show an error at location 140, and the error code is 0x80090303 ("The specified target is unknown or unreachable"), and the third parameter for that record is an empty string. This points to a missing SPN as the culprit.
For what its worth, Kerberos by definition requires SPNs. You might be able to utilize the built-in SPNS (host/) and the various flavors that host implies (This alias translation is stored in the AD, but for the life of me, I can't seem to find the article listing where this is found).
I'd start by looking at the cross-domain authentication - It can be tricky with kerberos. I'd first turn on full kerberos logging on both the client and server and see if that turns up anything.
Edit: It looks like I may be somewhat mistaken about this. At least one website I found states that DCOM handles SPNs automatically for you (see the bottom of the page), and I confirmed that clients can successfully connect if they demand Kerberos authentication and use "host/[computername]" as the SPN.
It does look like an SPN is required for the service, if you explicitly require Kerberos authentication when calling CoInitializeSecurity in the DCOM server process. For me, the call looked like this:
Warning: Please do not copy this code directly without ensuring that the values are proper for your security needs.
SOLE_AUTHENTICATION_SERVICE sas;
sas.dwAuthnSvc = RPC_C_AUTHN_GSS_KERBEROS;
sas.dwAuthzSvc = RPC_C_AUTHZ_NONE;
sas.pPrincipalName = L"myservice/mymachine";
sas.hr = S_OK;
CoInitializeSecurity( 0, 1, &sas, 0, RPC_C_AUTHN_LEVEL_DEFAULT,
RPC_C_IMP_LEVEL_DEFAULT, 0, EOAC_NONE, 0 );
The SPN can be configured using setspn, as demonstrated below:
setspn -A myservice/mymachine serviceusername
(see the setspn docs for details).
Unfortunately this still didn't solve my problem, but I think the remaining issue is related to some specific problem with the test machines.
I have come across this error while trying to create an instance of the remote COM object. We may face this error If "Delegate" impersonation level is used by the client during the call to CoInitializeSecurity(), and the COM+ service is running under a user account which doesn't have "delegation" permission at the domain level.
We have a fairly standard client/server application built using MS RPC. Both client and server are implemented in C++. The client establishes a session to the server, then makes repeated calls to it over a period of time before finally closing the session.
Periodically, however, especially under heavy load conditions, we are seeing an RPC exception show up with code 1754: RPC_S_NOTHING_TO_EXPORT.
It appears that this happens in the middle of a session. The user is logged on for a while, making successful calls, then one of the calls inexplicably returns this error. As far as we can tell, the server receives no indication that anything went wrong - and it definitely doesn't see the call the client made.
The error code appears to have permanent implications, as well. Having the client retry the connection doesn't work, either. However, if the user has multiple user sessions active simultaneously between the same client and server, the other connections are unaffected.
In essence, I have two questions:
Does anyone know what RPC_S_NOTHING_TO_EXPORT means? The MSDN documentation simply says: "No interfaces have been exported." ... Huh? The session was working fine for numerous instances of the same call up until this point...
Does anyone have any ideas as to how to identify the real problem? Note: Capturing network traffic is something we would rather avoid, if possible, as the problem is sporadic enough that we would likely go through multiple gigabytes of traffic before running into an occurrence.
Capturing network traffic would be one of the best ways to tackle this issue. If you can't do that, could you dump the client process and debug with WinDBG or Visual Studio? Perhaps compare a dump when operating normally versus in the error state?