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.
Related
Situation:
We installed a self-hosted WCF Service on a new Windows Server 2016 Machine (machine X). This service makes a call to a Tibco BW webservice on a different Windows Server 2016 machine (machine Y).
When the WCF service is run with user A (part of built-in Adminstrators) all requests are processed successfully. When the service is run as user B (service user) we receive the following message: "http request forbidden for authentication scheme anonymous"
Both services run under basicHtttpBinding.
We were able to do the same installation on a different windows server 2016 environment with different users sucessfully.
Steps taken so far:
We compared the packages that are sent when the service is run with user A and with user B and found out that when the service is run with user B no package will reach machine Y.
We disabled the Windows Firewall on both machine but this did not change the behaviour.
We compared the rights and policies of user A and B via gpresult but could not see any difference regarding network access or http related policies.
Our Speculation
We suspect that User B is missing somekind of privilege to make http requests like User A is able to do.
Questions
Is there a group policy that governs this kind of behaviour?
What settings could prevent a User from sending these requests?
Why do we get this error message despite not using any security settings?
Thank you
We did a wireshark analysis and found out that there was still a policy in place that required the service account to redirect all traffic over a proxy server. This proxy most likley had no idea how to handle WCF traffic and all requests resulted in the error message we observed.
Once we altered the policy to allow prevent the service user from using the proxy, the requests went trough as expected and as observed with the other administrator users.
I'm working with a SignalR server application that is available via the Internet. It implements a regular authentication based on credentials. I'm now working on another service that I'd like to hook up to this server with access to a different set of functions as opposed to my regular users. I could create a special internal user with a different role and hardcode it (its login and password) in my internal app as by definition the binary wouldn't even be available anywhere, but for some reason it seems fishy to me.
I've also thought about creating a secondary SignalR server that would listen on a different port but only internally in my VPN, behind a firewall (the service will be hosted with Amazon VPC). The issue with that solution is the obvious need to create a second server application.
What should I do? How do you handle internal APIs and their authentication?
Use ASP.NET Identity
Details see:
https://www.asp.net/identity
How to use with signalr:
https://learn.microsoft.com/en-us/aspnet/signalr/overview/security/hub-authorization
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 a WCF service which is called from a winforms app. This is over the named pipes binding.
The WCF service (Server) itself goes across the network on the domain to download some files.
In named pipes, is there any issue with having the user on a locked down domain account and the wcf service, hosted in a win svc, on a powerful account in the same domain which goes across the network to download some files (network being within the same domain)? I read something somewhere about named pipes not working with network logins (which I assume are domain accounts).
Thanks
I say go for it. I'm not sure why there would be any problems as long as everything is properly configured. NamedPipes is just the transport protocol from your client to your service. It shouldn't have anything to do with what the service can do.
You won't have any problems if your service process identity has the necessary permissions to access the network resource. The default security configuration of the NetNamedPipeBinding will not cause the WCF service to impersonate the WCF client, so the service process identity will be used to get the files from the network share.
The ACL on the named pipe transport stops users accessing the WCF service from a remote connection. It will not prevent access by your WinForms application running in a local interactive session.
Domain accounts and network logons are two completely orthogonal concepts. A domain account is an identity which is authenticated by a domain controller rather than a machine's local security authority. A network logon is one where the user has gained access to a particular machine via a network protocol (e.g. accessing a network file share or making a request to an HTTP application which impersonates the caller). A domain account can have a local interactive logon (as in your WinForms app); a local account can be used to get a network logon.
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.