Error below occurs when accessing MQ server via .NET Client. Login credential is not asked when CCDT is created. But MQ server is looking for it for some reason.
I cannot find any information that covers both CCDT and the error below together.
IBM.WMQ.MQException: MQRC_NOT_AUTHORIZED
----- cmqxrsrv.c : 2356 -------------------------------------------------------
17/04/2018 23:50:44 - Process(1848.16) User(SYSTEM) Program(amqzlaa0.exe)
Host(APPLE) Installation(Installation1)
VRMF(8.0.0.5) QMgr(LocalQM)
AMQ5540: Application 'bin\Debug\Producer.exe' did not supply a user ID
and password
EXPLANATION:
The queue manager is configured to require a user ID and password, but none was
supplied.
ACTION:
Ensure that the application provides a valid user ID and password, or change
the queue manager configuration to OPTIONAL to allow applications to connect
which have not supplied a user ID and password.
----- amqzfuca.c : 4311 -------------------------------------------------------
17/04/2018 23:50:44 - Process(1848.16) User(SYSTEM) Program(amqzlaa0.exe)
Host(APPLE) Installation(Installation1)
VRMF(8.0.0.5) QMgr(LocalQM)
AMQ5541: The failed authentication check was caused by the queue manager
CONNAUTH CHCKCLNT(REQDADM) configuration.
EXPLANATION:
The user ID 'mqclient' and its password were checked because the user ID is
privileged and the queue manager connection authority (CONNAUTH) configuration
refers to an authentication information (AUTHINFO) object named
'SYSTEM.DEFAULT.AUTHINFO.IDPWOS' with CHCKCLNT(REQDADM).
This message accompanies a previous error to clarify the reason for the user ID
and password check.
ACTION:
Refer to the previous error for more information.
Ensure that a password is specified by the client application and that the
password is correct for the user ID. The authentication configuration of the
queue manager connection determines the user ID repository. For example, the
local operating system user database or an LDAP server.
To avoid the authentication check, you can either use an unprivileged user ID
or amend the authentication configuration of the queue manager. You can amend
the CHCKCLNT attribute in the CHLAUTH record, but you should generally not
allow unauthenticated remote access.
-------------------------------------------------------------------------------
17/04/2018 23:50:45 - Process(14900.9) User(SYSTEM) Program(amqrmppa.exe)
Host(APPLE) Installation(Installation1)
VRMF(8.0.0.5) QMgr(LocalQM)
AMQ9557: Queue Manager User ID initialization failed for 'mqclient'.
EXPLANATION:
The call to initialize the User ID 'mqclient' failed with CompCode 2 and Reason
2035.
ACTION:
Correct the error and try again.
----- cmqxrsrv.c : 2356 -------------------------------------------------------
Server Setup
CCDT file is created by following the links below:
Setting up the server using IBM MQ Explorer
Server-connection Channel: LOCAL.DEF.SVRCONN
MCA User ID: empty
Setting up the client using IBM MQ Explorer
Clinet channe: LOCAL.DEF.SVRCONN
Queue Manager name: LocalQM
Connection name: 192.168.1.9(1415)
192.168.1.9 is localhost address
1415 is queue manager, LocalQM, TCP port.
SET CCDT Environment
1
C:\Users\'#.lp\source>SET MQCHLLIB=C:\ProgramData\IBM\MQ\qmgrs\LocalQM\#ipcc
C:\Users\'#.lp\source>SET MQCHLTAB=AMQCLCHL.TAB
Put AMQCLCHL.TAB also to C:\ProgramData\IBM\MQ (I don't know why which might not be correct, because error on log file:
AMQ9518: File 'C:\ProgramData\IBM\MQ\AMQCLCHL.TAB' not found.
)
IBM MQ.NET
The code is below from here
MQQueueManager qm = null;
System.Environment.SetEnvironmentVariable("MQCHLLIB", "C:\\ProgramData\\IBM\\MQ\\qmgrs\\LocalQM\\#ipcc");
System.Environment.SetEnvironmentVariable("MQCHLTAB", "AMQCLCHL.TAB");
try
{
Hashtable props = new Hashtable();
props.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_CLIENT);
qm = new MQQueueManager("LocalQM",props);
MQQueue queue1 = qm.AccessQueue("LocalQueue", MQC.MQOO_OUTPUT | MQC.MQOO_FAIL_IF_QUIESCING);
MQMessage msg = new MQMessage();
msg.WriteUTF("Hello this message is from .net client");
queue1.Put(msg);
queue1.Close();
qm.Disconnect();
}
catch (Exception ex)
{
Console.Write(ex);
}
IBM MQ V8 on Windows 10
MQ.NET Client V8 on Windows 10
Creating a client channel definition table
Using a client channel definition table with .NET
This thread is related to MQRC_Q_MGR_NAME_ERROR
Update 1
Following the link below. But it seems info on mqccred.ini is not used by MQ Server. Because the same error occurs.
Client side security exit to insert user ID and password ( mqccred )
Setup steps:
1 Create mqccred.ini (D:\mqccred.ini)
QueueManager:
Name=LocalQM
User=mqclient
password=password
2 Set Windows Environment variable
set MQCCRED=D:\mqccred.ini
3 Using mqccred
DEFINE CHANNEL(LOCAL.DEF.SVRCONN) CHLTYPE(clntconn) +
CONNAME(127.0.0.1) +
QMNAME(LocalQM) +
SCYEXIT('mqccred(ChlExit)') +
REPLACE
4 Set ADOPTCTX(YES)
ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) ADOPTCTX(YES)
UPDATE 2
I updated MQ objects to uppercase, and still get the same error as above, but have new error log message below:
Do I need to write exit program in .NET according to Using channel exits in IBM MQ .NET ?
22/04/2018 22:37:15 - Process(11904.1) User('#.lp) Program(mMq.Producer.exe)
Host(APPLE) Installation(Installation1)
VRMF(8.0.0.5)
AMQ9535: User exit not valid.
EXPLANATION:
Channel program 'LOCAL.DEF.SVRCONN' ended because user exit 'mqccred(ChlExit)'
is not valid.
Architecture of the exit library does not match the process's architecture
which is '' bit.
ACTION:
Ensure that the user exit is specified correctly in the channel definition, and
that the user exit program is correct and available.
----- IBM.WMQ.MQChannelExitHandler.LoadExit : 0 -------------------------------
22/04/2018 22:38:21 - Process(5720.1) User('#.lp) Program(mMq.Producer.exe)
Host(APPLE) Installation(Installation1)
VRMF(8.0.0.5)
AMQ9535: User exit not valid.
EXPLANATION:
Channel program 'LOCAL.DEF.SVRCONN' ended because user exit 'mqccred(ChlExit)'
is not valid.
Architecture of the exit library does not match the process's architecture
which is '' bit.
ACTION:
Ensure that the user exit is specified correctly in the channel definition, and
that the user exit program is correct and available.
----- IBM.WMQ.MQChannelExitHandler.LoadExit : 0 -------------------------------
UPDATE 3
I have a different error below when MCA user ID is set to a Windows user.
IBM.WMQ.MQException: MQRC_Q_MGR_NOT_AVAILABLE
22/04/2018 22:38:21 - Process(5720.1) User('#.lp) Program(mMq.Producer.exe)
Host(APPLE) Installation(Installation1)
VRMF(8.0.0.5)
AMQ9535: User exit not valid.
EXPLANATION:
Channel program 'LOCAL.DEF.SVRCONN' ended because user exit 'mqccred(ChlExit)'
is not valid.
Architecture of the exit library does not match the process's architecture
which is '' bit.
ACTION:
Ensure that the user exit is specified correctly in the channel definition, and
that the user exit program is correct and available.
----- IBM.WMQ.MQChannelExitHandler.LoadExit : 0 -------------------------------
Update 4
Sorry for the confusion. Update 2 and 3 are the same. Both updates should have the same error: MQRC_Q_MGR_NOT_AVAILABLE, which comes after update 1. I put MQRC_NOT_AUTHORIZED by mistake.
The usage of a CCDT doesn't eliminate the need to prove identity to the queue manager. The first error you presented is because by default MQ requires a password for admin users.
There are four levels of CONNAUTH for client connections over the network:
CHCKCLNT(REQDADM) this is the default value. Any user with MQ administrative authority must provide a valid password. In addition any user without administrative authority that does provide a password must provide a valid password.
CHKCLNT(OPTIONAL) this is similar #1 but does not REQUIRE a password for users with MQ administrative authority. Any user Admin or not that provided a password must provide a valid password, with this value an administrative user would not be required to send a password.
CHCKCLNT(REQUIRED) this value means that all users must provide a valid password.
CHCKCLNT(NONE) no users are required to provide a password, and even if they do provide a password it will not be validated.
You can set this value for the entire queue manager on the AUTHINFO object set as the CONNAUTH value on the QMGR. If you set it to REQADMIN or OPTIONAL you can then uplift it for specific channels via a CHLAUTH rule to a stricter value such as REQUIRED. You can not set it lower.
If you disable security you have no security and anyone with access to your network can connect to your queue manager.
You have a few options to keep security enabled:
You could use a client security exit specified on the CLNTCONN to pass credentials such as mqcred.
You could use a client side certificate with TLS and map it to a MCAUSER on the SVRCONN.
Note based on your Update 1 you were specifying QMNAME(LocalQM), because there are no single quotes around the name MQ will fold this to UPPERCASE and set this as LOCALQM.
As Roger pointed out you also did not specify port 1415 on your CONNAME . You indicated you had problems with this you need to put single quotes around the CONNAME value if there are ( or ) characters in it.
Note based on your UPDATE 2 (Below gathered from comments that were moved to Chat):
Under the MQ installation directory normally under Program Files or Program Files(x86) you should find a sub-directory called Tools\c\Samples\mqccred, this should have sub-directories for 32bit (lib) and 64bit (lib64). You should copy the file from lib to the exits directory and from lib64 to the exits64 directory.
You only need a native .NET exit if you are using Managed .NET client mode which you indicate you are not using by having props.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_CLIENT);
UPDATE 2a based on your comment:
Sorry, I am using MQC.TRANSPORT_MQSERIES_MANAGED. I copied from
other thread. Does it mean I need to write .NET exit?
mqcred will not work with Managed mode .NET, to use a exit to provide the credentials you would need to write the equivalent in .net.
It would be much simpler to specify the credentials in your program via properties than to write a Managed mode exit similar to mqcred.
Roger's answer to "Sending message on IBM MQ: Hangs on AccessQueue
" provides a excellent sample that demonstrates passing the username and password in Managed mode. You can still get the connection details from the CCDT.
if (inParms.ContainsKey("-u"))
qMgrProp.Add(MQC.USER_ID_PROPERTY, ((System.String)inParms["-u"]));
if (inParms.ContainsKey("-x"))
qMgrProp.Add(MQC.PASSWORD_PROPERTY, ((System.String)inParms["-x"]));
if ( (inParms.ContainsKey("-u")) && (inParms.ContainsKey("-x")) )
qMgrProp.Add(MQC.USE_MQCSP_AUTHENTICATION_PROPERTY, true);
Queue Manager name: LocalQM
Bad idea. You are shooting yourself in the foot. Use UPPERCASE for queue manager name and MQ object names. Once you are an intermediate or advance level MQAdmin, then you can try using mixed-case names.
DEFINE CHANNEL(LOCAL.DEF.SVRCONN) CHLTYPE(clntconn) +
CONNAME(127.0.0.1) + QMNAME(LocalQM) + SCYEXIT('mqccred(ChlExit)') +
REPLACE
1st issue: If you do NOT put quotes around an MQ object name then MQ will AUTOMATICALLY uppercase it! So, MQ will see your command as for LOCALQM and not LocalQM.
The 2nd issue is that you did NOT specify the port # for CONNAME. Therefore, MQ will default to 1414. But you stated that you are using port # 1415.
And in case you don't know, MQ object names ARE case sensitive.
If I were you, I would delete the queue manager LocalQM and start over with LOCALQM and create all MQ objects with uppercase names.
Using CCDT should not require login credentials, which is one of the
purposes of using CCDT.
CCDT entries ONLY contain connection information. They will never include user/application credentials. To specify user/application credentials, you specify them in the application or use the mqccred client-side security exit.
In this day and age, every user and every application should be specifying user credentials so that we can have a secure MQ environments.
Update April 23, 2018
Architecture of the exit library does not match the process's
architecture which is '' bit.
Architecture is referring to the addressability of your program or the running framework of your program. Is it running as a 32-bit or 64-bit program. If it is running as a 32-bit program then you need to use the 32-bit mqccred.dll and if it is running as a 64-bit program then you need to use the 64-bit mqccred.dll.
I seem to remember something about .NET managed-mode (MQC.TRANSPORT_MQSERIES_MANAGED) programs cannot use natively built exits. You should ask IBM Support.
Related
I have an ASP.NET MVC 5 app hosted in IIS 10 on Windows 2016. Our sys admins have created a Managed Service Account (MSA) that is tied to this server and has read/write permissions to a folder on the network. I need to write PDFs to that folder from the web application using the MSA.
Currently, I'm simply trying to write a simple text file to the folder:
System.IO.File.WriteAllText(#"\\SomeUncPath\Reports\test.txt", "sample text");
The above produces this error, which is to be expected,
System.UnauthorizedAccessException: Access to the path '\SomeUncPath\Reports\test.txt' is denied.
I followed this video: https://www.youtube.com/watch?v=lBv81lwZgIo to no avail. It just caused the site to generate a 503 error.
Is it possible to write the files using C# impersonation, such as described in this article? But how do you impersonate an MSA, which has a password set by the system?
I tried the following code using the SimpleImpersonation:
var cred = new UserCredentials("myDomain", "someMsa$", "");
Impersonation.RunAsUser(cred, LogonType.Batch, () =>
{
System.IO.File.WriteAllText(#"\\SomeUncPath\Reports", "sample text");
}
);
The above throws this:
System.ArgumentException: Password cannot be empty or consist solely of whitespace characters. Parameter name: password
Update 1: The server is throwing the following error into the System log:
Application pool SomePool has been disabled. Windows Process Activation Service (WAS) encountered a failure when it started a worker process to serve the application pool.
And these two warnings:
Application pool SomePool has been disabled. Windows Process Activation Service (WAS) did not create a worker process to serve the application pool because the application pool identity is invalid.
and
The identity of application pool SomePool is invalid. The user name or password that is specified for the identity may be incorrect, or the user may not have batch logon rights. If the identity is not corrected, the application pool will be disabled when the application pool receives its first request. If batch logon rights are causing the problem, the identity in the IIS configuration store must be changed after rights have been granted before Windows Process Activation Service (WAS) can retry the logon. If the identity remains invalid after the first request for the application pool is processed, the application pool will be disabled. The data field contains the error number.
I tried this and rebooted the server but the issue persists.
Update 2: If I give the app pool my credentials, the app loads without any issues. It's only on the MSA that it fails with the above error/warnings. What could be wrong with the MSA?
Update 3: The issue was how I was adding the MSA to the app pool. I needed to include my domain in the username: myDomain\someMsa$. Once I had that in, it worked like a charm!
The issue had to do with missing the domain when setting the MSA as the app pool identity. When adding it, I needed to set it as myDomain\someMsa$ instead of simply someMsa$. What's strange is how IIS didn't give an error, perhaps because the MSA account was considered both a local and domain account.
Also, in our case, we didn't need the "Log on as a batch" permission for the MSA. It worked fine without it.
We are making use of ADLDS for our user management and authentication. We can successfully query the instance without problems. However, trying to perform an operation such as SetPassword will fail or even trying to create a new user if a password is not set, it fails. I can successfully update a user as long as its not password I'm trying to update. I've been reading a lot of different articles relating to this but not finding a resolution. Posting to see if I can get some fresh perspective on this issue, thanks for any input.
EXAMPLE
ContextType ctxType = ContextType.ApplicationDirectory;
string server = "myadldsserver.com";
string usersCN = "CN=Users,..."; // container where users reside
ContextOptions ctxOpts = ContextOptions.SimpleBind;
string uname = "myuser";
string pswrd = "mypass";
using(var ctx = new PrincipalContext(ctxType, server, usersCN, ctxOpts, uname, pswrd)
using(var newUser = new UserPrincipal(ctx)) {
newUser.Name = "newusername";
newUser.Enabled = true;
newUser.UserPrincipalName = "newusername";
newUser.Save();
newUser.SetPassword("newuserpassword");
}
ERROR 1
The first problem I encounter if I try to create a new UserPrincipal and call Save without having set the password like in Example above I get the exception A constraint violation occurred. with an InnerException extend message of 0000052D: AtrErr: DSID-033807D7, #1:0: 0000052D: DSID-033807D7, problem 1005 (CONSTRAINT_ATT_TYPE), data 2246, Att 9005a (unicodePwd)
Because of this error I tried moving the SetPassword before calling Save along with other approaches I found online such as getting the DirectoryEntry from the UserPrincipal and trying to call SetPassword but got a different error.
ERROR 2
Calling SetPassword before calling UserPrincipal.Save, when save is called, results in the error The directory property cannot be found in the cache.
Note that the same error will occur if I trying calling ResetPassword or getting a DirectoryEntry and calling Invoke("SetPassword"... as well
ERROR 3
From my research most seem to indicate this could have to do with needing to access AD LDS using a Secure connection. So, I changed my server to include the port of 636 string server = "myadldsserver.com:636" and I changed the ContextOptions to be ContextOptions.SimpleBind | ContextOptions.SecureSocketLayer.
Making these changes when the PrincipalContext is being constructed I get the following exception The server could not be contacted. with an inner exception of The LDAP server is unavailable., HResult is -2146233087
JAVA and LDP
To add some background to this, we do have similar code written in an older Java application. We are trying to port some of this logic over to .NET side in C#. The code in Java makes use of a Java keystore that contains the certificate that was generated on the AD LDS server. The Java application of course has no issues using the SSL port. We know the server seems to be configured correctly, it's just an issue of how to access it from .NET side.
Is there an equivalent on the .NET side such as the keystore in Java? We know that an SSL connection can be made to server. We have verified this using LDP as well.
GOALS
Be able to create a new user and set their password during creation
Be able to ResetPassword or ChangePassword for a user
Connect to our AD LDS instance from .NET securely
Have you tried using Microsoft Management Console to import the certificate?
Two ways to install the certificate
Either
Open a cmd.exe console and type "MMC"
File > Add/Remove Snap-In...
Select Certificates, click Add
Choose Computer Account and Local Computer when prompted, then OK...
Certificates should now be showing under Console Root
Certificates > Trusted Root Certification Authorities > Certificates > (right-click) > All Tasks > Import Certificate...
Find the certificate you want to import, click Next and choose defaults (Trusted Root Certification Authorities should already be
selected)
Click Next, Finish
(or)
Simply double-click on the .cer file for the certificate in Windows
Explorer, click Install Certificate... > Next > select the option to
"Place all certificates in following store" > Browse... > Select
Trusted Root Certification Authorities. Continue with next until done.
At this point your certificate is installed, and you should be able to communicate securely with your ADLDS server.
I am trying to connect to the remote queues using secured SSL connection. I have all the details provided by third party regarding SSL connection and Queue Manager details. I have V8 version of MQ client installed on my windows machine.
SSL folder that thirdparty has shared contains jks,kdb,rdb and sth files.
I am using below code to initialize the properties in .net console application
const string SslKeyRepository = #"ssl folder location with key name included";
const string CipherSpec = "TLS_RSA_WITH_3DES_EDE_CBC_SHA";
const string CipherSuite = "SSL_RSA_WITH_3DES_EDE_CBC_SHA";
const string SslPeerName = "Peername";
const string ConnectionType = MQC.TRANSPORT_MQSERIES_CLIENT;
static Hashtable init(String connectionType)
{
Hashtable connectionProperties = new Hashtable
{
{MQC.TRANSPORT_PROPERTY, connectionType},
{MQC.PORT_PROPERTY, 1496},
{MQC.SSL_CERT_STORE_PROPERTY, SslKeyRepository},
{MQC.SSL_CIPHER_SPEC_PROPERTY, CipherSpec},
{MQC.SSL_PEER_NAME_PROPERTY, $"CN=\"{SslPeerName}\""}
};
// Add the connection type
// SSL
// Set up the rest of the connection properties, based on the
// connection type requested
switch (connectionType)
{
case MQC.TRANSPORT_MQSERIES_BINDINGS:
break;
case MQC.TRANSPORT_MQSERIES_CLIENT:
case MQC.TRANSPORT_MQSERIES_XACLIENT:
case MQC.TRANSPORT_MQSERIES_MANAGED:
connectionProperties.Add(MQC.HOST_NAME_PROPERTY, HostName);
connectionProperties.Add(MQC.CHANNEL_PROPERTY, Channel);
break;
}
return connectionProperties;
}
I have tried few things but I end up getting exception "MQRC_SSL_INITIALIZATION_ERROR"
I would appreciate if you can help me with this.
There are many reasons for MQRC_SSL_INITIALIZATION_ERROR. Some of them are mechanical issues such as whether the keystore files can be accessed. Some are procedural such as whether the handshake fails. The best way to diagnose is methodically checking the configuration and then performing differential testing.
For the first part of this, perform the following checks. If you have already done so, don't cut corners. Do it again.
Verify that the certificates are accessible by issuing runmqakm -cert -list against the KDB to verify that it is structurally intact and the stash file is present with the proper password.
Verify that the kdb file is not in a world-readable directory is that the files are not marked world-readable.
Verify that the service account that runs the app is the owner of the KDB files and containing folder and has write access. (Not sure why but GSKit insists that the KDB must be writeable at run time.)
Issue runmqakm -cert -details to verify that the certificate(s) corresponding to the queue manager is/are present and the details. If the QMgr uses a self-signed cert there will be only one. If the QMgr uses a CA-signed cert there should be an intermediate and a root signer.
Find out from the 3rd party whether they have specified SSLCAUTH(OPTIONAL) or SSLCAUTH(REQUIRED). If OPTIONAL then the KDB should have no personal certs, only signers. If REQUIRED then the KDB must have a personal cert and the label must be ibmwebspheremq[serviceaccount] in lower case.
For the differential testing, try some of the following tests:
Test the app by connecting to a local QMgr using TLS (Note: MQ hasn't used SSL for years. It's TLS now. The old field names still retain SSL labels, though.) until you know that it is correctly configured. Go grab a copy of MQ Advanced for Developers and you can do integration testing on the desktop with your own QMgr, fully licensed for free.
Test using one of the sample programs. Use amqsputc or amqsgetc, depending on whether the real app is supposed to have PUT or GET on the queue. These use the same KDB, samme certs, etc. the main difference being they are known-good code.
Ask your business partner to let you test without SSL to make sure the "mechanical" parts of the configuration are correct. This includes things like the firewall routing, host, port and channel name, QMgr name, etc. If you can't connect with plaintext channels, you definitely won't succeed with TLS channels.
Once that works, test with SSL enabled and SSLCAUTH(OPTIONAL) set at the QMgr. This demonstrates that the client can validate the QMgr's cert.
Once that works, and if the objective is to use mutual authentication, test with SSLCAUTH(REQUIRED) set at the QMgr and a personal cert in the local KDB. This demonstrates that the QMgr can validate the client's cert.
Then, and only then, turn on SSLPEER locally to filter on the QMgr cert's DN.
If these don't help, please update the question with detailed results of your testing. The most common issues include cert labels and KDB permissions. If the business partner gave you the JKS and KDB, these should generally not come with a personal cert, only trusted certs.
I'm currently working with the MQ .NET assemblies and am attempting to read queue depths of various queues for a monitoring application. We have the code working in Java, but our new application is in C# and it would be preferable to keep all this logic in the same application.
From what I've heard online, .NET assemblies ignore MQC.USER_ID_PROPERTY and instead use the user ID of whoever is running the application. Is there really no way to override this? This seems a very strange feature/bug. I know that MQC.TRANSPORT_PROPERTY is supposed to influence how the UserID is inferred, but whether I set to MQC.TRANSPORT_MQSERIES_MANAGED or MQC.TRANSPORT_MQSERIES_CLIENT, I see the same ID going up in Wireshark and get the same error back (MQRC_NOT_AUTHORIZED). Has anyone else found a workaround for this fairly large issue?
properties = new Hashtable();
properties.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_MANAGED);
properties.Add(MQC.HOST_NAME_PROPERTY, hostName);
properties.Add(MQC.PORT_PROPERTY, port);
properties.Add(MQC.CHANNEL_PROPERTY, channelName);
properties.Add(MQC.USER_ID_PROPERTY, userId);
properties.Add(MQC.PASSWORD_PROPERTY, "");
// create connection
queueManager = new MQQueueManager(queueManagerName, properties);
If you are using MQ .NET client (or for that matter MQ C client also) version prior to v8, the user id set by the application is not sent to the queue manager. Instead logged in user id is passed to queue manager for authentication. This is a known behavior of MQ versions prior v8.
You can develop and use what is known as security exit to perform user authentication. A security exit performs username and password authentication against a repository, such as the local operating system on the MQ server, or an LDAP repository.
You can also use SSL/TLS if that's suitable to you. Otherwise you can move up to use MQ v8 to make use of the out of the box user id/password authentication.
This question already has an answer here:
Mercurial "no username supplied" error on Mac
(1 answer)
Closed 7 years ago.
I am totally lost here as i have been trying to create a repository and push my existing Unity3D C# project to it.
The current output is:
realm: Bitbucket.org HTTP
user:
password:
warning: bitbucket.org certificate with fingerprint 46:de:34:e7:9b:18:cd:7f:ae:fd:8b:e3:bc:f4:1a:5e:38:d7:ac:24 not verified (check hostfingerprints or web.cacerts config setting)
warning: bitbucket.org certificate with fingerprint 46:de:34:e7:9b:18:cd:7f:ae:fd:8b:e3:bc:f4:1a:5e:38:d7:ac:24 not verified (check hostfingerprints or web.cacerts config setting)
searching for changes
warning: bitbucket.org certificate with fingerprint 46:de:34:e7:9b:18:cd:7f:ae:fd:8b:e3:bc:f4:1a:5e:38:d7:ac:24 not verified (check hostfingerprints or web.cacerts config setting)
warning: bitbucket.org certificate with fingerprint 46:de:34:e7:9b:18:cd:7f:ae:fd:8b:e3:bc:f4:1a:5e:38:d7:ac:24 not verified (check hostfingerprints or web.cacerts config setting)
abort: error: ''
Peters-iMac:myProject Peter$ hp puch -v --debug
-bash: hp: command not found
Peters-iMac:myProject Peter$ hg push -v --debug
pushing to default-push
abort: default repository not configured!
(see the "path" section in "hg help config")
Peters-iMac:myProject Peter$
I have been trying to understand what i need to do to fix this but have not succeeded, i did check the "hg help config" but did not fully understand anyhow.
Anyone that can lead the blind (me)?
You need to tell mercurial where to push to. You can do that in two ways:
Command line: hg push URL where URL is the pathwhere to push to, e.g. hg push https://bitbucket.org/YOURLOGIN/YOURREPOSITORY (it then will ask for login and pw on the command line)
In your repository's configuration file found in .hg/hgrc:
[paths]
default = https://bitbucket.org/YOURLOGIN/YOURREPOSITORY
See also hg help config.paths
You can also use the hgrc to store the login information in order to remove the need to enter them each time you push, but that is unsecure. Better use ssh authentication which doesn't require storing any credentials.