I have set up a WCF service on a server which lives in its own Workgroup. I've tried to make a TCP/IP connection to it from a client that lives on the corporate domain. When I try to open a connection, I get a SecurityNegotiationException with the message:
"A remote side security requirement
was not fulfilled during
authentication. Try increasing the
ProtectionLevel and/or
ImpersonationLevel." The inner
exception reads: "The network logon
failed"
After speaking with some coworkers about the issues and performing some google research, I came to the conclusion that the issue is that the client is attempting to log on to the server using my corporate network login and password. Since the server is not part of the corporate network, it has no knowledge of my corporate identity and then rejects the login / connection attempt. Whether this analysis is correct or not, I have no idea.
Google results seem to suggest that perhaps the solution is that I need to impersonate user account that exists on the server machine. --I have also stumbled across this codeproject article which demonstrates user impersonation. Since the only account on the server is Administrator with no password, I tried domain as the computer's ip address as "10.0.0.11", username as "Administrator", and password as "".
http://www.codeproject.com/KB/dotnet/UserImpersonationInNET.aspx?display=Print
Unfortunately, it fails with the message:
"Logon failure: unknown user name or bad password"
Another hint to the problem: When the client and server are both machines on the corporate network, there are no connection problems at all.
How can I resolve the error and complete the connection to the server?
Even though it is not a best practice, I am completely okay with removing any security so I can keep this project moving forward
Until you grasp the details, best way to learn is to disable security. You have to create a new binding configuration at the server side with security mode set to "None". Name it "NoSecurity" for convenience. This configuration must have the same type (wsHttpBinding, etc.) you use at your endpoint. Then set the bindingConfiguration property of your endpoint to "NoSecurity".
Update your client configuration and you are set to go.
I know of no way to have a workgroup trust a domain, which means you have a couple of choices, as i see it
Add another endpoint in your WCF service that uses HTTP (a web service endpoint) and use this from the domain. This gets around the security problem, as you can impersonate here, or even set up a specific user that can access goodies in your workgroup server.
Whack down security in the WCF service. i would have to think about how to do this, but it is not a good idea anyway.
Create a domain and get a trust relationship.
The code project you mentioned is not dealing with impersonation in a way that is directly useful to WCF, as the authentication happens before you can even hit this code. I imagine you can whack at the framework bits to do it, but that would be nasty. There might be a way to use the code in an HTTP endpoint, but that can already be done without incurring the overhead of adding code that circumvents windows security.
Related
I'm currently working on integrating a third party API to our software. One requirement of this is the use of an OAuth style authentication system over SSL/TLS.
This isn't a problem, and it WAS working for about a day and a half. Then all of a sudden, it starts returning this error to me constantly, even when trying to authenticate.
The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
The fact that it was working and now it isn't confuses the bag out of me, and I have no idea where to even begin looking to solve this.
The methods involved are called from our WCF service hosted in an HTTPS environment. We have a valid signed certificate from a provider. Nothing changed in the implementation, it simply stopped working.
Do any of you have any suggestions on why we would get an error like this? I have no idea where to even begin looking.
UPDATE
The certificate exists in the trusted store.
We currently have our website as www.mywebsite.co.uk, with a valid certificate for said website. Our services are located at www.mywebsite.co.uk/Services.
We also use a Windows Service, which consumes the appropriate WCF located at www.mywebsite.co.uk/Services. Could it be the Windows Service that is causing issues? The Windows Service application is located on the hosting server, which is Windows Server 2012.
UPDATE 2
In order to workaround this issue, we've decided to use the method to ignore the certificate validation errors. This code excerpt can be found on a tonne of other articles here, but here it is anyway for any reader.
ServicePointManager.ServerCertificateValidationCallback = (obj, certificate, chain, errors) => true;
UPDATE 3
Okay, after a bit more looking I managed to get these errors from the ServerCertificateValidationCallback. It tells me that there is this error
RemoteCertificateNameMismatch
The server we are trying to access for API calls has an odd web address, that doesn't match the issuer/subject of the certificate. Is this what is throwing it off?
The server we are trying to access for API calls has an odd web address, that doesn't match the issuer/subject of the certificate. Is this what is throwing it off?
Yes, it is. Certificates are validated by checking for a match between the host name you are opening a connection to and the host name(s) identified in the certificate. The host name is the first part of the "web address" - e.g., stackoverflow.com or www.google.com.
Okay so this is probably a very confusing title for this question I am sure. Hopefully I can clear up that title with the actual question.
I am putting together a website for employees to connect to that is internet facing but I want them to be able to log into the site using their Active Directory login as well as access data that will be behind a firewall that is not accessible to our internet facing sites. Someone made mention to me that I could have the site communicate with a server behind the firewall and have that server make the requests back and forth. (Sort of a check point)
So now that the back story to this is out there, I am not really looking for how to configure the server's or the network itself but rather how would one make an API call to an Intranet server from an Internet server? They will be on the same network but one behind the firewall and the other in front of the firewall.
Would you make the call directing to the server name or IP address or what? This may be too premature of a question to be asking since I still don't have the servers setup but none-the-less it is a concern I am having and need to figure out.
This site is going to be all done in ASP.NET MVC 4
The best way to accomplish this type of a setup is via firewall and/or domain configuration.
Most recently I have seen this implemented by first creating a one way trust relationship between the external and internal domains, this will serve to allow the external application to resolve the address of the internal server by name.
Theoretically you could also accomplish this by using port forwarding on the firewall; in this configuration the external application will use the address of the firewall and the firewall will take care of sending the request to the correct server.
Once this confiugration is in place your external application should be able to communicate directly with your internal servers without any special code.
I'm working on a client-server project implemented using WCF. The clients are deployed on different machines and communicate with services through the internet. I'm relatively new to WCF, and am a bit confused on choosing the appropriate binding for my Web services. The clients need to be authorized to perform operations, however, I'm implementing my own authentication algorithm and trying to avoid Windows authentication for various reasons, but I still need to make sure the message transferred in the channel is encrypted.
Right now I'm using wsHttpBinding with security mode set to Message. Full configuration looks like this:
I've set the authentication type in IIS to Anonymous Authentication to make sure the requests are passed through, and was expecting a service call to fail since MessageClientCredentialType in my binding is explicitly set to Windows. However, when I run the code, the service successfully gets called and returns the expected values. I have a feeling that I'm missing something - why is the call authorized? Can I make sure the message is still encrypted even though authentication type is set to Anonymous? Any help is appreciated.
Edit
To clarify on this, I tested the service with a client deployed to a machine outside the network on a different domain.
This MSDN article kind of sums up a lot of security issues relevant to WCF
http://msdn.microsoft.com/en-us/library/ms733836.aspx
regarding your specific situation,
the negotiateServiceCredential="true" means that you streamline certificate distribution to your clients for message encryption.
This option will only work with windows clients and has some performance problems.
read more here http://msdn.microsoft.com/en-us/library/ff647344.aspx
search the topic "streamline certificate distribution" in this page.
Which account do you use to make the call to the service? Allowing anonymous in IIS lets your request pass through to the service and service should authenticate if your caller has credentials that windows understands (Active directory/NTLM).
In your case, I think you are testing it in your own environment so service responds. Once you deploy it over internet, I doubt your service will allow anybody outside of your domain if you keep clientcredentialtype to windows.
Check these link for securing services on the Internet -
http://msdn.microsoft.com/en-us/library/ms734769.aspx
http://msdn.microsoft.com/en-us/library/ms732391.aspx
I have created a simple WCF web service to write some messages into MQ (Websphere MQ).It was hosted in IIS 6.0 server. Service stated successfully, but while writing the message into MQ it was throwing a exception with reason code 2063.
Is there any way to override the run-on user(in code) for web service ?
Thank you in advance..
The reason code 2063 0x0000080f MQRC_SECURITY_ERROR refers to something external to WMQ. For example, if configuration files are not accessible to the application, if the keystore password is incorrect or if the QMgr or application are unable to access domain resources.
When accessing WMQ using one of a Windows server's administrator accounts, the account resolves on the local host and there is no need for WMQ to query the domain. However when accessing WMQ with a domain account it is necessary for the QMgr to query the domain to get the groups that the account requesting a connection is a member of. For this reason, it is common for a running QMgr to appear healthy for administrators but to fail when accessed from a domain account.
One way to test if this is the issue is to make sure that the access resolves with a local account. In this example, I'll assume the QMgr is running as MUSR_MQADMIN - the default account for Windows. I'll also assume the server name is bigserver. The following test isolates the problem to either the QMgr or the application.
If it is not already doing so, make the application connect in client mode. Alter the client channel used by the application with MCAUSER('MUSR_MQADMIN#bigserver') (substitute your own service account and server name) and attempt to reconnect. If you get another 2063 then the error is in the client app configuration. If you get connected then the QMgr needs to b granted rights to query the domain. There is a whole section in the manual which explains to domain admins what exactly is required. If this is the problem, please point your domain admin here.
Please do NOT leave the channel set up like this. Anyone who can access it will be a WMQ administrator! Instead, once you get it working, place the application's service account in the MCAUSER field and use setmqaut to authorize it appropriately.
When connecting to an SSL enabled queue manager using C#, what values do I need to set to get the queues to work?
I currently get this error:
Reason Code: 2393
MQRC_SSL_INITIALIZATION_ERROR
In my code I am setting the MQEnvironment.SSLKeyRepository and MQEnvironment.SSLCipherSpec
Is there something else I need to set with C# to make this work? I have seen some Java examples that set keystore passwords and types and things.
I have also seen examples setting system environment variables too, but that hasn't seemed to make any difference either.
The general pattern for debugging WMQ SSL is as follows...
Get the application to connect using no SSL. This eliminates problems with connectivity, wrong queue or queue manager names, etc.
Get SSL working with server-only authentication. This means setting SSLCAUTH(OPTIONAL) on the SVRCONN channel. The QMgr will present a certificate that the application must trust but the application does not need to authenticate back to the server. This validates that both the application and the QMgr can access their keystores and that the QMgr's certificate or CA chain are properly loaded in the app's keystore.
Finally, set SSLCAUTH(REQUIRED) in the SVRCONN channel so that the application authenticates back to the QMgr. At this point the only possible problems are that the QMgr doesn't trust the app's cert or CA.
If the connection attempt is refused by the QMgr, the errors at the client will purposely be cryptic. The detailed messages will be found in the QMgr's AMQERR??.LOG files. If the failure is at the client, these messages will be found in the client's error logs or you can enable trace.
Enable trace using the strmqtrc command and stop it with endmqtrc. The WMQ Clients manual has a section describing where client trace files end up and another section dedicated to tracing on Windows in general. This can be very useful in determining client-side configuration problems such as failing to find a private key, failing to find a keystore, etc.
In your case, the 2393 indicates that something in the client configuration is failing. Since you are no longer getting the error with the keystore password, I'm guessing it may be having problems finding a private key or not trusting the cert provided by the QMgr. In the first case, setting SSLCAUTH(OPTIONAL) will work because the client' won't need it's private key. However if the problem is trusting the QMgr or other configuration issues, SSLCAUTH(OPTIONAL) won't help but tracing should sort that out.
Incidentally, the need to trace and diagnose on the client side is why IBM does not support client installations where the jars or libs were copied over rather than running the full client install. Although you can get the client to run by copying a few lib files and classes, this does not provide all the facilities for tracing and diagnostics. If you have not performed a full client install, some of what I've described here will not be possible. If that is the case, download and install the client from SupportPac MQC7.