I’m busy enabling LDAP based basic authentication for a Queue Manager as part of a Legacy Broker to EIP Migration project at SARB.

I’m looking for IBM best practice of configuration advice w.r.t. how to maintain both system users and administrative individual users in LDAP.

We are adding LDAP authentication for system clients.

My understanding is that if we use LDAP for authentication that we need to apply it wholesale for the QMGR.

This means that we need to add LDAP based administrative access for our MQ administrators as well.

The challenge is that I need to authenticate LDAP system users that will be located in the LDAP directory at

ou=Services Accounts,ou=Accounts,ou=SARB,o=idmsarb

e.g.

cn=EIPDEVCALYPSO, ou=Services Accounts,ou=Accounts,ou=SARB,o=idmsarb

 

 

As well as admin users (equivalent of members of mqm) that belong to an LDAP group

cn=EIPQUAAdmin,ou=Groups,o=idmsarb

With members like

cn=P9997420,ou=Users,o=IDMSARB

 

The two questions that I’m asking (that I know I don’t know - if there’s more I don’t know I don’t know please add as well):

 

·         I’m struggling to understand from the documentation whether I (or how) can use membership of a group to something similar to:

 

This is to allow us to configure users to an LDAP group similar to adding users to mqm to allow them MQ Explorer access.

 

·         And I’m trying to find out how to configure the BASEDNU, CLASSUSR, USRFIELD setting to allow us to authenticate both users in the service account LDAP directory location as well as normal users that are located in ou=Users,o=IDMSARB

Hello Francois,

From reading the IBM documentation, it seems like you can accomplish that task by doing the following:

 

1. Define the AUTHINFO for the connection to your LDAP:

SSL:

DEFINE AUTHINFO('SOME.SECURE.LDAP') AUTHTYPE(IDPWLDAP) CONNAME('ldap.example.com(636)') SHORTUSR('cn') ADOPTCTX(YES) USRFIELD('cn') BASEDNU('ou=Services Accounts,ou=Accounts,ou=SARB,o=idmsarb') CHCKCLNT(REQUIRED) CHCKLOCL(OPTIONAL) CLASSUSR('ePerson') SECCOMM(YES) LDAPUSER('cn=USERNAME,ou=Services Accounts,ou=Accounts,ou=SARB,o=idmsarb') LDAPPWD('PASSWORD')

NON-SSL:

DEFINE AUTHINFO('SOME.NONSECURE.LDAP') AUTHTYPE(IDPWLDAP) CONNAME('ldap.example.com(389)') SHORTUSR('cn') ADOPTCTX(YES) USRFIELD('cn') BASEDNU('ou=Services Accounts,ou=Accounts,ou=SARB,o=idmsarb') CHCKCLNT(REQUIRED) CHCKLOCL(OPTIONAL) CLASSUSR('ePerson') SECCOMM(NO) LDAPUSER('cn=USERNAME,ou=Services Accounts,ou=Accounts,ou=SARB,o=idmsarb') LDAPPWD('PASSWORD')

 

2. Alter the queue manager to use the SSL or NON-SSL AUTHINFO:

SSL:

ALTER QMGR CONNAUTH('SOME.SECURE.LDAP')

NON-SSL:

ALTER QMGR CONNAUTH('SOME.NONSECURE.LDAP')

 

3. (optional) for SSL only, set the key store to use & set the certificate label:

ALTER QMGR SSLKEYR('/var/mqm/config/certs/KEYFILENAME')

ALTER QMGR CERTLABL('CA_ROOT')

 

4. Refresh security:

REFRESH SECURITY TYPE(CONNAUTH)
REFRESH SECURITY TYPE(SSL)
REFRESH SECURITY TYPE(AUTHSERV)

 

This solution does not use the LDAP group membership for authorization. I am not sure if MQ permits that. This solution only does authentication to the LDAP with the credentials you are passing from the client.

To set authorization, you can accomplish so by creating groups on your MQ server, and adding your service account to those groups. On Linux it would look like this:

A. You add the cn of your LDAP user in the Linux group:

[mqm@server1 ~]$ cat /etc/group | grep EIPDEVCALYPSO
qmgradmin:x:3010:EIPDEVCALYPSO

B. You can set authorizations for that group in MQ :

[mqm@server1 ~]$ setmqaut -m QMGR -t qmgr -g qmgradmin +connect +all +alladm

C. You can view authorizations for that group in MQ:

[mqm@server1 ~]$ dspmqaut -m QMGR -t qmgr -g qmgradmin
Entity qmgradmin has the following authorizations for object QMGR:
 inq
 set
 connect
 altusr
 crt
 dlt
 chg
 dsp
 setid
 setall
 ctrl
 system

 

Hope this helps.

Joey

You can add the following to the AUTHINFO command above to set LDAP group membership:

GRPFIELD(cn) BASEDNG(ou=Groups,o=idmsarb) CLASSGRP(groupOfNames)

... and set authorizations for that group this way:

SET AUTHREC OBJTYPE(QMGR) GROUP('EIPQUAAdmin') AUTHADD(connect)

 

I'm afraid I wasn't able to find if there is a way to authenticate with accounts from two different LDAP OUs. Maybe someone that is reading this thread can answer that question?

Thanks Joey, much appreciated

Hi Francois!

I figured I'd send you a response to this topic as I've been dealing with MQ and LDAP for the better part of almost 2 years now. Now my approach isn't the easiest and would require some help from your AD admins to get groups and such sorted but here's what worked for us.

1. We had the AD admins create two new groups under the same part of the AD tree so that it was easier for MQ (MQ isn't smart enough to search outside of a nested tree). Something like MQ_Admin and MQ_Dev would work or whatever naming convention you use where you work.

Obviously you would put the admins in the MQ_Admin group and the Devs or whoever would have "read-only" access into the MQ_Dev group.

2. You then need to make sure MQ is at the correct fix pack level, which if I remember it needs a minimum of MQ 8.0.0.2 and that you set the command level to 802. The command level doens't have anything to do with the actual version of MQ from what I remember as a side note. To do that, you'll need to stop the qmgr and then issue the command:

strmqm -e CMDLEVEL=802

Then you can start it normally and verify with echo "dis qmgr all" | runmqsc

3. You need to create an authinfo object to connect to your ldap server and somethings will be different in your setup based upon IP addresses and group names and such but I'll show you mine just so you can see what settings are enabled.

DEFINE AUTHINFO('USE.LDAPG') AUTHTYPE(IDPWLDAP) AUTHORMD(SEARCHGRP) CHCKCLNT(OPTIONAL) CHCKLOCL(OPTIONAL) CONNAME('1.2.3.4(389') LDAPUSER('CN=iibadmin,OU=it,OU=corp,OU=Members,DC=test,DC=com') LDAPPWD('XXXXXX') SECCOMM(NO) USRFIELD('CN') BASEDNU('OU=data,OU=Groups,DC=test,DC=com') CLASSUSR('user') ADOPTCTX(YES) SHORTUSR('sAMAccountName') FINDGRP('memberOf') GRPFIELD('CN') BASEDNG('OU=data,OU=Groups,DC=test,DC=com') CLASSGRP('group') NESTGRP(YES) FAILDLAY(60) replace

This will allow you to set all of your MQ authorizations for the groups you had created in LDAP with your setmqaut commands (I scripted it and can post that too).

4.refresh security type(connauth)

4a. You can issue

echo " dis qmstatus all" | runmqsc <qmgr> 

to see if the LDAP connections says "CONNECTED" or "ERROR" if it's error you'll need to check the AMQ Logs.

5. Tell the qmgr to use the newly created connauth with alter qmgr connauth('USE.LDAPG')

6. Refresh security connauth again as in step 4.

7. This one is optional / I was told to do it by IBM but I don't believe you need to. Add the following to the qm.ini:

Security:
GroupModel=GlobalGroups

8. We then created channels specific for those groups so that we can later secure them with chlauths. We created an admin only server conn channel and a dev utils server conn channel. Each will get different perms.

9. Here's my admin script for the admin channel:

#!/bin/bash
### ADMIN FOR MQ ###

if [ $# -ne 1 ]
 then
 echo -e "\nUsage: QMGRNAME\n"
 echo -e "Example: $0 MBUFTW01 \n"
 exit 1
fi

echo "def channel(LTADMIN.SVRCONN) chltype(svrconn) trptype(tcp) replace" | runmqsc $1
setmqaut -m $1 -g iib_Admin -t qmgr +all +alladm +allmqi +crt
setmqaut -m $1 -g iib_Admin -n '**' -t queue +all +alladm +allmqi
setmqaut -m $1 -g iib_Admin -n 'SYSTEM.ADMIN.COMMAND.QUEUE' -t queue +all +alladm +allmqi
setmqaut -m $1 -g iib_Admin -n 'SYSTEM.MQEXPLORER.REPLY.MODEL' -t queue +all +alladm +allmqi
setmqaut -m $1 -g iib_Admin -n 'SYSTEM.DEFAULT.MODEL.QUEUE' -t queue +all +alladm +allmqi
echo "set chlauth(LTADMIN.SVRCONN) type(addressmap) address(*) mcauser('iib_Admin') action(replace)" | runmqsc $1
echo "set chlauth(LTADMIN.SVRCONN) type(addressmap) address(*) usersrc(channel)" | runmqsc $1
echo "set chlauth(LTADMIN.SVRCONN) type(blockuser) userlist('nobody')" | runmqsc $1
setmqaut -m $1 -g iib_Admin -n '**' -t namelist +all +alladm +allmqi
setmqaut -m $1 -g iib_Admin -n '**' -t process +all +alladm +allmqi
setmqaut -m $1 -g iib_Admin -n '**' -t authinfo +all +alladm +allmqi
setmqaut -m $1 -g iib_Admin -n '**' -t channel +all +alladm +allmqi
setmqaut -m $1 -g iib_Admin -n '**' -t service +all +alladm +allmqi
setmqaut -m $1 -g iib_Admin -n '**' -t listener +all +alladm +allmqi
setmqaut -m $1 -g iib_Admin -n '**' -t clntconn +all +alladm +allmqi
setmqaut -m $1 -g iib_Admin -n '**' -t topic +all +alladm +allmqi
# Default allow-all browse,inq and dsp to all queues
setmqaut -m $1 -g iib_Admin -n '**' -t queue +all +alladm +allmqi
# Allow limited access to command queue.
setmqaut -m $1 -g iib_Admin -n 'SYSTEM.ADMIN.COMMAND.QUEUE' -t queue +all +alladm +allmqi
# Allow access to SYSTEM.MQEXPLORER.REPLY.MODEL if it exists.
setmqaut -m $1 -g iib_Admin -n 'SYSTEM.MQEXPLORER.REPLY.MODEL' -t queue +all +alladm +allmqi
# Allow access to SYSTEM.DEFAULT.MODEL.QUEUE.
setmqaut -m $1 -g iib_Admin -n 'SYSTEM.DEFAULT.MODEL.QUEUE' -t queue +all +alladm +allmqi

echo "refresh security(*)" | runmqsc $1

And here's our read only script:

### READ ONLY FOR MQ ###
if [ $# -ne 1 ]
 then
 echo -e "\nUsage: QMGRNAME\n"
 echo -e "Example: $0 MBUFTW01 \n"
 exit 1
fi

echo "refresh security type(connauth)" | runmqsc $1

echo "def channel(DEVUTILS.SVRCONN) chltype(svrconn) trptype(tcp) replace" | runmqsc $1
setmqaut -m $1 -g iib_Users -t qmgr +connect +inq +dsp
setmqaut -m $1 -g iib_Users -n '**' -t queue +all
setmqaut -m $1 -g iib_Users -n 'SYSTEM.ADMIN.COMMAND.QUEUE' -t queue +all
setmqaut -m $1 -g iib_Users -n 'SYSTEM.MQEXPLORER.REPLY.MODEL' -t queue +all
setmqaut -m $1 -g iib_Users -n 'SYSTEM.DEFAULT.MODEL.QUEUE' -t queue +all
echo "set chlauth(DEVUTILS.SVRCONN) type(addressmap) address(*) mcauser('iib_Users') action(replace)" | runmqsc $1
echo "set chlauth(DEVUTILS.SVRCONN) type(addressmap) address(*) usersrc(channel) action(replace)" | runmqsc $1
echo "set chlauth(DEVUTILS.SVRCONN) type(blockuser) userlist('nobody') action(replace)" | runmqsc $1
setmqaut -m $1 -g iib_Users -n '**' -t namelist -all +dsp +inq
setmqaut -m $1 -g iib_Users -n '**' -t process -all +dsp +inq
setmqaut -m $1 -g iib_Users -n '**' -t authinfo -all +dsp +inq
setmqaut -m $1 -g iib_Users -n '**' -t channel -all +dsp
setmqaut -m $1 -g iib_Users -n '**' -t service -all +dsp
setmqaut -m $1 -g iib_Users -n '**' -t listener -all +dsp
setmqaut -m $1 -g iib_Users -n '**' -t clntconn -all +dsp
setmqaut -m $1 -g iib_Users -n '**' -t topic -all +dsp +sub
# Default allow-all browse,inq and dsp to all queues
setmqaut -m $1 -g iib_Users -n '**' -t queue -all +browse +inq +dsp
setmqaut -m $1 -g iib_Users -n '**' -t queue +put +get
# Allow limited access to command queue.
setmqaut -m $1 -g iib_Users -n 'SYSTEM.ADMIN.COMMAND.QUEUE' -t queue -all +inq +put +dsp
# Allow access to SYSTEM.MQEXPLORER.REPLY.MODEL if it exists.
setmqaut -m $1 -g iib_Users -n 'SYSTEM.MQEXPLORER.REPLY.MODEL' -t queue -all +inq +put +get +dsp +clr
# Allow access to SYSTEM.DEFAULT.MODEL.QUEUE.
setmqaut -m $1 -g iib_Users -n 'SYSTEM.DEFAULT.MODEL.QUEUE' -t queue -all +inq +put +get +dsp +clr

echo "refresh security type(connauth)" | runmqsc $1

echo "refresh security(*)" | runmqsc $1

 

Now here's where it gets a little weird. You have to switch the authinfo back for user search. Because the authinfo above in step 3 is for group search in order to put the auths on the groups (so you don't have to run them for each user), you can't do a user look up...so to get around that, you can define the same authinfo object with the replace option at the end with the following:

DEFINE AUTHINFO('USE.LDAPG') AUTHTYPE(IDPWLDAP) AUTHORMD(SEARCHUSR) CHCKCLNT(OPTIONAL) CHCKLOCL(OPTIONAL) CONNAME('1.2.3.4(389)') LDAPUSER('CN=iibadmin,OU=it,OU=corp,OU=Members,DC=test,DC=com') LDAPPWD('XXXXXX) SECCOMM(NO) USRFIELD('') BASEDNU('OU=Members,DC=test,DC=com') CLASSUSR('user') ADOPTCTX(YES) SHORTUSR('sAMAccountName') FINDGRP('memberOf') GRPFIELD('OU=data,OU=Groups,DC=test,DC=com') BASEDNG('OU=data,OU=Groups,DC=test,DC=com') CLASSGRP('group') NESTGRP(YES) FAILDLAY(60) replace

After that refresh security type connauth again

Then we defined channel auths for those two channels:

set chlauth(DEVUTILS.SVRCONN) type(addressmap) address(*) mcauser('iib_USers') action(replace)

set chlauth(LTADMIN.SVRCONN) type(addressmap) address(*) mcauser('iib_Admin') action(replace)

refresh security once more / recycle the qmgr and now all users coming in should be required to be in ldap and all tools such as RFHUTIL, MQ Explorer, etc will require user ID / password (their windows creds). You can add ssl and certs on top of everything as well.

We added some other chlauths and security measures in as well but this is the base of how we got things connecting and working.

Sorry for the long post! If you have any questions feel free to to contact me at nmurn@leveragingtechnology.com as I don't check these boards very often (A co-worker forwarded me your post).  Good luck!

Hi Francois,

To start with, LDAP servers are generally pretty good at resolving queries, even when there are a large number of entries. MQ requires that all users that are visible are in the same subtree, so in your environment, the BASEDNU would need to be 'O=imdsarb' in order for both service accounts and administrative users to be available.

Always use TLS for connections to LDAP. Otherwise credentials can flow in clear text.

The IBM Redbook publication "Integrating the IBM MQ Appliance into your IBM MQ Infrastructure" might not sound like a promising source of information about connecting MQ to LDAP for authentication and authorisation, but Chapter 7 (section 7.4) provides a worked solution for connecting MQ to LDAP. MQ on an appliance is essentially the same as software MQ, but you will need to translate the appliance specific certificate management commands into runmqakm style commands. There's an appendix in the book to help with that (Appendix A).

Watch out... some of the other responses have misleading information, especially with regard to setting up TLS connections to LDAP. You must not change the queue manager CERTLABL to point to the CA_CERT for example.

When working with LDAP, and using AUTHORMD(LDAP), MQ will authenticate users using LDAP, then search for groups using LDAP, and then authorise access based on permissions granted in the OAM to both the user itself and to any groups that the user is in and that match the group search criteria. You don't have to do any fancy footwork to make that happen, although you do need to be at version 8.0.0.3 or higher, and command level 802, as was pointed out by another responder.

 

Regards,

 

Neil Casey.

Thanks Neil, much appreciated Best regards / Vriendelike groete Francois van der Merwe Team Lead
IBM Hybrid Cloud (All that Integration stuff)Phone: +27 (0)82-556-9467
E-mail: fvdm@za.ibm.comTwitter: francoisvdmerwe  90 Grayston Drive
Sandton, 2031
South Africa  

Original message -----
From: Neil Casey <wsmqfam-ws@lists.imwuc.org>
To: WSMQFam-ws@lists.imwuc.org
Cc:
Subject: [WSMQFam-ws] - RE: MQ and LDAP - best practice
Date: Thu, Aug 10, 2017 1:33 AM

Hi Francois,
To start with, LDAP servers are generally pretty good at resolving queries, even when there are a large number of entries. MQ requires that all users that are visible are in the same subtree, so in your environment, the BASEDNU would need to be 'O=imdsarb' in order for both service accounts and administrative users to be available.
Always use TLS for connections to LDAP. Otherwise credentials can flow in clear text.
The IBM Redbook publication "Integrating the IBM MQ Appliance into your IBM MQ Infrastructure" might not sound like a promising source of information about connecting MQ to LDAP for authentication and authorisation, but Chapter 7 (section 7.4) provides a worked solution for connecting MQ to LDAP. MQ on an appliance is essentially the same as software MQ, but you will need to translate the appliance specific certificate management commands into runmqakm style commands. There's an appendix in the book to help with that (Appendix A).
Watch out... some of the other responses have misleading information, especially with regard to setting up TLS connections to LDAP. You must not change the queue manager CERTLABL to point to the CA_CERT for example.
When working with LDAP, and using AUTHORMD(LDAP), MQ will authenticate users using LDAP, then search for groups using LDAP, and then authorise access based on permissions granted in the OAM to both the user itself and to any groups that the user is in and that match the group search criteria. You don't have to do any fancy footwork to make that happen, although you do need to be at version 8.0.0.3 or higher, and command level 802, as was pointed out by another responder.

Regards,

Neil Casey. Site Links: View post online   View mailing list online   Start new thread via email   Unsubscribe from this mailing list   Manage your subscription  

This email has been sent to: fvdm@za.ibm.com

Thank you Neil for pointing me in the right direction.

Joey

In Reply to Neil Casey:

Hi Francois,

When working with LDAP, and using AUTHORMD(LDAP), MQ will authenticate users using LDAP, then search for groups using LDAP, and then authorise access based on permissions granted in the OAM to both the user itself and to any groups that the user is in and that match the group search criteria. You don't have to do any fancy footwork to make that happen, although you do need to be at version 8.0.0.3 or higher, and command level 802, as was pointed out by another responder.

 

Regards,

 

Neil Casey.

Hi Neil,

I am using this config to connect the MQ Appliance M2001B to LDAP(Microsoft Active Directory). Like you see i use for parameter AUTHORMD the SEARCHGRP value and not LDAP like you advice. Is it wrong to use SEARCHGRP and not LDAP, and if so what is the difference because the Appliance is working fine ?

DEFINE AUTHINFO(LDAPPRD) +
AUTHTYPE(IDPWLDAP) +
ADOPTCTX(YES) +
DESCR('Connector to Active dir' ) +
CONNAME('corp.testme.nl(389)') +
CHCKCLNT(OPTIONAL) +
CHCKLOCL(OPTIONAL) +                   
CLASSGRP(GROUP) +
CLASSUSR(USER) +                      
FAILDLAY(1) +
FINDGRP(member) +
BASEDNG('DC=corp,DC=testme,DC=nl') +
BASEDNU('DC=corp,DC=testme,DC=nl') +
LDAPUSER('CN=SA_LDAP_DP_ESB,OU=Service Accounts,OU=Users,OU=TestBeheer,DC=corp,DC=testme,DC=nl') +
LDAPPWD('secret') +
SHORTUSR('name') +              
GRPFIELD('sAMAccountName') +
USRFIELD('sAMAccountName') +             
AUTHORMD(SEARCHGRP) +
NESTGRP(NO) +
SECCOMM(NO) +
REPLACE

ALT QMGR CONNAUTH(LDAPPRD)
REFRESH SECURITY

Kind regards

Bernard

Hi Bernard,

you are exactly right. That will teach me to post without checking the manual first. The options are SEARCHGRP or SEARCHUSR. Either of these will cause MQ to search LDAP to discover group membership, but the mechanism is different. SEARCHGRP does a general search for groups which contain the user DN in the 'member' field (not always called 'member' - set in the FINDGRP attribute). In your case the LDAP field is called 'member'. The other option is SEARCHUSR which retrieves all the 'memberOf' attributes from the user record. Again, the attribute doesn't have to be called memberOf, and is set using the FINDGRP attribute.

With AD, my recollection is that you should be able to use either one. Pick the one recommended by your local Access Management or AD specialists.

You should check the SECCOMM(NO) setting though. It is rare for unencrypted authentication traffic to meet corporate standards, although if you use a dedicated network for that traffic, it might be fine.

Regards,

Neil.

Hi Neil,

Thanks for your reply. You are right about using unencrypted authentication trafic. At this moment our MQ appliances are in a test environment but thats gonna change soon.

Is it possible to set only the SECCOMM parameter to YES without using SSL certificates ?  I've tested this on a MQ Windows Server and it seems that I can set this parameter to YES without using LDAPS(636), is that correct ?

Is the authentication trafic to the LDAP server encrypted  this way and what is the cipher what is used for encryption ?

Kind Regards

Bernard

Hi Bernard,

There are 3 options for SECCOMM:

NO means no encryption. No certificates are needed.

ANON means the LDAP server needs a certificate, but the queue manager won't use its cert, even if it has one. 

YES means both the LDAP server and the queue manager use certificates to authenticate.

In the general sense, there are 2 mechanisms available to implement TLS with LDAP. One uses a special port (636) and always runs TLS (or SSL). The second uses the base port (389) and after getting the initial TCP socket, uplifts to TLS using STARTTLS. AD supports both mechanisms, but in either case, the AD LDAP server does need a certificate.

However, I can't find any documented evidence that the LDAP client used by MQ supports using STARTTLS to uplift a non-secure socket. I haven't tried it, so I can't say for certain, but I don't think it will work.

So, I think you need to use SECCOMM(ANON) or SECCOMM(YES) depending on whether you want to authenticate to LDAP using bind credentials or the queue manager certificate. You also need to set up the queue manager key store to include the trusted certificates needed to authenticate the LDAP server certificate.

I don't believe you can use SECCOMM(YES) without certificates, or on port 389. Please check whether you performed a REFRESH SECURITY(*) TYPE(CONNAUTH) after changing the authinfo. I suspect that things kept working because the queue manager wasn't using the new configuration.

With SECCOMM(YES) or SECCOMM(ANON) traffic to the LDAP server is encrypted. With SECCOMM(NO) there is no encryption at all.

I don't know what cipher will be used. If you get a packet capture and analyse it (I would use wireshark for that) you will see how the cipher is negotiated. The normal mechanism is that the client (in this case MQ) presents a list of ciphers it can accept, and the server chooses one of those ciphers. The server (LDAP in this case) can be configured to use either the client preference or its own preference. 

You could ask IBM about what ciphers are presented, but I think it would be quicker to just run the packet capture. In any case, IBM can't state exactly what cipher will be used anyway, because the server gets to choose. They could only tell you the allowed list of ciphers they will negotiate from, which you can see by getting it from the packet capture.

BTW, there are some blog posts about doing LDAP authentication with MQ that provide some examples too. See: https://www.ibm.com/developerworks/community/blogs/messaging/entry/bite_size_blogging_securing_the_queue_manager_s_ldap_server_connection_using_seccomm?lang=en and https://www.ibm.com/developerworks/community/blogs/messaging/entry/bite_size_blogging_mq_v8_setting_up_a_qmgr_to_use_ldap_authentication?lang=en

I have some concerns about both of those blogs though because they don't discuss adoptctx very well (which is critical for effective security if you allow user/password authentication).

 

Regards,

Neil.

Hi Neil,

Thanks very much for your reply, it make some things clear to me and I can get to work. I did a refresh security and even restarted our Qmanager to be sure that the SECCOMM(YES) setting was accepted. I think the reason why I can connect with this param is that I run MQ Server on a Windows Server 2012 and LDAP is also based a Windows Server 2012 Active Directory domain controller, so maybe the authentication is not done on the MQ queuemanager level but on Windows server level with a kerberos token. That explains why this is working. But the strange part is that if I change for example ADOPTCTX param from YES to NO in the LDAP config at MQ manager then I notice in the MQ client behaviour when using MQCSP and use a user/password in the client to connect that this change works. That is the part I don't understand. Maybe there is an explenation for this ?

I think if I try to change the SECCOMM(YES) param on the MQ appliance M2001B that I can't connect, but these machines are installed in our datacenters at this moment so they are not available.

Thanks in advance.

Kind Regards

Bernard

Hi Neil, I believe the different between ANON and YES for SECCOM involves 1 way or 2 way (mutual auth) TLS.  ANON means that your MQ server is validating the LDAP server's certificate against it's own keystore.  YES would mean that your MQ server is validating the LDAP server's certificate against its own keystore and the ldap server is also validating the certificate sent by MQ against its own key/trust store.

In either case, the ldap server still needs LDAPUSR and LDAPPWD as a bind id if that is required by the ldap server.