I installed MQ8.0.0.4 on a ubuntu(14.4) server. I am able to launch a local MQ explorer and connect to local Queue Managers. I want to connect to the same Queue Manager from a remote windows machine. When I try this I get authorization errors:
Access not permitted. You are not authorized to perform this operation. (AMQ4036)
Access not permitted. You are not authorized to perform this operation. (AMQ4036)
Severity: 10 (Warning)
Explanation: The queue manager security mechanism has indicated that the userid associated with this request is not authorized to access the object.
This link shows a list of auth commands to enable remote windows connection, but the page only lists upto version 7.5 for which this is applicable. Will I have to do the same setup on 8.0 as well?
I already enabled remote administration using the local MQ Explorer.
"The queue manager security mechanism has indicated that the userid associated with this request is not authorized to access the object." Are you using the mqm ID or another ID? You could use the MQS_REPORT_NOAUTH or MQSAUTHERRORS setting to get more info the authority failure.
To answer your other question, I believe the settings in the link will also apply to v8 - but v8 also has additional new authority checks as well.
Related
I'm using git over ssh on a remote machine that is running Windows 10. When I try to do a git pull, I get the error message in the title after entering my credentials.
Fixed by installing the latest version of git credential manager on chocolatey (not sure if this is necessary) and switching my git credential store to dpapi.
See https://github.com/GitCredentialManager/git-credential-manager/blob/main/docs/credstores.md#dpapi-protected-files for instructions on how to do so.
This could be illustrated by GitCredentialManager/git-credential-manager issue 325
The error you're seeing is related to the way that Windows handles "logon sessions" and "credential sets".
GCM Core uses the Windows Credential Manager (wincred.h) to store credentials safely on Windows.
We interact with wincred via the Windows APIs: CredRead, CredWrite, CredDelete, and CredEnumerate.
The error being returned in your case here is ERROR_NO_SUCH_LOGON_SESSION (0x520) which means:
The logon session does not exist or there is no credential set associated with this logon session.
Network logon sessions do not have an associated credential set.
The key part here is in bold.
When you connect via SSH, the sshd daemon/Windows service is running as the NT AUTHORITY\NETWORK SERVICE account (most likely/by default), which creates network logon sessions when an SSH client connects.
From some searching online, one workaround posted is to change the account that sshd runs as to be your real user, which would then have an associated credential set. Your milage may vary here depending on setup.
If you try to use the built-in cmdkey command for interacting credentials stores in the Windows Credential Manager, you'll see similar errors or messages like "saved for this login only".
Upgrading to the latest version of GCM comes with:
With the latest GCM Core release (v2.0.567) there is support on Windows to use a different credential store other than the Windows Credential Manager that shouldn't have the same remote-session limitations.
You can read more about the different options here: https://aka.ms/gcmcore-credstores
The specific store that may help this SSH scenario is the DPAPI-protected file store.
Credentials are protected using Windows DPAPI encryption (based on your current user account) and are written to files on disk (configurable; defaults to %USERPROFILE%\.gcm\dpapi_store).
There are similar questions to this one, but not quite the same...
I have a C# program that is using amqmdnet.dll (from 9.0.1.0 MQC Redist)
The code to connect is:
Hashtable mqProperties = new Hashtable();
mqProperties.Add(MQC.CHANNEL_PROPERTY, channelName);
mqProperties.Add(MQC.HOST_NAME_PROPERTY, hostname);
mqProperties.Add(MQC.PORT_PROPERTY, port);
queueManager = new MQQueueManager(strQueueManagerName, mqProperties);
It works fine and writes to the queue. I assume it picks up my current login id from Windows.
When I run the same code on IIS, it connects but fails with an auth error 2035 when trying to write to the Queue.I assume this is because IIS is running as a different user-id.
I tried adding:
mqProperties.Add(MQC.USER_ID_PROPERTY, "myuserid");
mqProperties.Add(MQC.PASSWORD_PROPERTY, "mypassword");
and it did not work. Trying "mydomain\myuserid" did not work either. Some other posts mentioned that MQ needs the Windows SID. I tried using that string, but that did not work either.
At this point, I am playing with this, so I'd prefer not to ask the admins to set up a new userid on the MQ server side. With this in mind, is there any way I can login when running under the IIS user, but pass in my userid/password or some other credential to make this work?
If the queue manager is v8.0 or later and is configured to use CONNAUTH and has ADOPTCTX(YES) set you can present an id and password. If it does not have this set then the value presented in the UserId and Password property of a .NET client will be ignored.
A IBM developerWorks MQdev blog post "MQCSP Password Protection in MQ V8 has details on how to do this in various languages."
For .NET you should be able to use what you have with the addition of the MQC.USE_MQCSP_AUTHENTICATION_PROPERTY set to true:
mqProperties.Add(MQC.USER_ID_PROPERTY, "myuserid");
mqProperties.Add(MQC.PASSWORD_PROPERTY, "mypassword");
mqProperties.Add(MQC.USE_MQCSP_AUTHENTICATION_PROPERTY, true);
The queue manager will then authenticate this ID. If the queue manager is set with ADOPTCTX(YES) then it will always use the authenticated ID for OAM checks. If it is set to ADOPTCTX(NO) it will still use the ID the process is running under to perform OAM checks. It is highly recommended that this be set to ADOPTCTX(YES).
Update 2017/02/20:
Related to the comment "I can see that it might be turned off by admins so that MQ relies on the larger organizational SSO infrastructure.". Without setting up CONNAUTH and ADOPTCTX(YES) you can assert any id you want to over the channel. If a CHLAUTH rule is not in place to block administrative users then you can obtain full MQ administrative authority without any form of authentication.
I developed an Intranet application which needs to realize a "git push" from a local repository (on the disk of the web server) to a remote repository.
I launch the git process from the web server, it runs under the IIS pool identity which is a domain account member of the administrators group of the web server machine.
Git needs the user credentials to perform the push action. I integrated a custom version of git-credential-winstore. This program uses the Windows Credential Manager to store generic credentials for a web site. But when the call to the credential's write occurs, I get the error :
Failed to write credential: A specified logon session does not exist. It may already have been terminated
I checked the policy "Network access: Do not allow storage of passwords and credentials for network authentication", it is disabled.
What goes wrong here ?
Pool account needs to gain access to its user profile.
So we need to connect one time to a Windows Session to create user profile (I think it's necessary). Next in the Advanced Settings of the dedicated Application Pool, set "Load User Profile" = true.
Note about credentials : Windows credential target must be changed to manage different users in the same Windows vault. I change "git:https://remote-host" by "git_USERID:https://remote-host".
I set this property to enabled and it works now, maybe it will work for you also:
I have installed MQ server on HP Nonstop and client version 8 on windows server. When i am trying to access MQ server via websphere MQ explorer on windows i am getting Access not permitted,You are not authorized to perform this operation (AMQ4036) error. Can you guys help me here?
If you look in the AMQERR01.LOG on the queue manager it will tell you the reason you were rejected access. There are several different possibilities for security failures, but the exact nature of your failure will always be found in the error log. If you are not sure of the meaning of what you find in the error log, update your question with more information and I will update this answer with more information too.
I am trying to figure out how we would configure / setup the authentication, Queues, and Queue managers for connecting an MQ Client that is on a server / domain completely separate from the MQ Server it will be forwarding messages to.
I would assume that in a normally organizational environment you could just use Active Directory (if hosted on windows servers) for the authentication / AD lookup. However, in this scenario because they are different orgs you couldn't do that?
Can you simply apply SSL certs to both client / server and use that as your authentication? If so is that just applied to the Channel used in the connections?
Not sure how to proceed forward with this.
Any suggestions would be greatly appreciated.
Thanks,
S
Take a look at the Hardening WebSphere MQ presentation for v7.0 and earlier. The thing to remember is that WMQ does not authenticate anything. It authorizes based on OS identities and groups but there is no password checking being done.
For situations where QMgrs and clients live on Windows networks, the connection uses the SID and so it appears that some useful authentication was performed. BUT if a connection from a non-Windows platform is attempted, the Windows QMgr uses the string representation of the ID. So for example, if someone has a Linux VM on their desktop they can easily create a user ID called MUSR_MQADMIN and the Windows QMgr will accept the connection. There is a setting that causes the Windows QMgr to only accept connections with SIDS that it can resolve but even there its just a matter of knowing what the SID values are to spoof them on a connection.
The lesson here is that any QMgr, even one on Windows, must be configured to authenticate remote connections. With WMQ v7.1 and later, the QMgr has functionality to map X.509 certificate DNs to user IDs, or to perform IP filtering. Prior to v7.1 these functions required an exit such as BlockIP2. Capitalware sells MQAUSX which has the functions of BlockIP2, plus will perform ID and password authentication and is supported.
The first recommendation is to use a v7.1 QMgr so that you get the CHLAUTH rules for mapping and filtering. Even if you don't use certificates v7.1 limits administrative connections so it is harder for an attacker to gain full admin rights. Then if you need password validation, use SSL channels (to encrypt the password and prevent simply replay attacks) in combination with an exit that you can write yourself or purchase.
Just be aware that allowing a connection from outside your domain doesn't present any new challenges. The pre-v7.1 Windows QMgr that does not have MCAUSER set in the channel definition or by an exit allows remote administrative access, even from connections originating in the local Windows domain. There was always a need to harden that QMgr, even though honest users will have received authorization errors if the administrator did not set up auths for them.
Summary:
For clients originating outside your administrative domain, I'd recommend mutually authenticated TLS/SSL channels. The same page I linked to above also contains the WMQ Security Lab guide and scripts which show how to script the creation and exchange of WMQ certs and configure WMQ Explorer with them.
Whatever else you do, the MCAUSER on any legitimate channel must be set either in the configuration or by an exit. If the client is allowed to specify the ID, there is nothing to prevent it from specifying an administrative ID. For channels that are NOT being used such as SYSTEM.DEF.* and SYSTEM.AUTO.*, set the MCAUSER to a value that cannot be a local ID such as no!body or on v7.1 and later *NOACCESS.