The queue manager does not use the SASL options. It uses the simple bind, either anonymously or with userid/password, regardless of TLS configuration.
Usually, SASL is an interactive (or at least multiple-phase) operation which would be inappropriate for the qmgr with lots of configuration required. And worse, it could be potentially using a user-supplied module for the processing. The
OpenLDAP documentation for the API calls does not mention EXTERNAL as a specific mechanism for certificate handling, so perhaps it's an IBM extension to the LDAP flows for client and/or server.
------------------------------
Mark Taylor
Winchester
------------------------------
Original Message:
Sent: Wed October 13, 2021 11:28 AM
From: Colin Paice
Subject: is authinfo LDAP and certificate logon supported?
Hi Morag,
I've done a big more digging into this.
If I do a certificate logon using LDAP_SEARCH, the LDAP trace has
INFO process_sasl_bind()1722: Processing request for the 'EXTERNAL' SASL mechanism
ACL process_external_mechanism()2040: Authentication name is 'CN=rsaca256,O=cpwebuser,C=GB'
LDAPBE srv_process_bind_request()939: do_return_bind msgID=1, connID=5, bindDN='CN=RSACA256, O=CPWEBUSER,C=GB', safUserID='ADCDA', dnList=0x0, grpList=0x0, rc=0
If I try an MQ logon I get in the trace
LDAPBE srv_process_bind_request()374: do_bind
v_process_bind_request()939: do_return_bind msgID=1, connID=6, bindDN='', safUserID=''
0x0, grpList=0x0, rc=0
This is using the regular ( non SASL) bind_request.
SECCOMM(YES) seems to be for the session - not the logon. I can see the TLS handshake in the gsktrace on z/OS.
Is there another magic option I need to specify to say use the SASL = external logon? instead of the normal ldap_bind request.
Cheers
Colin
------------------------------
Colin Paice
Original Message:
Sent: Tue October 12, 2021 01:46 AM
From: Morag Hughson
Subject: is authinfo LDAP and certificate logon supported?
If you're asking whether the connection to LDAP can be made using a certificate identifying the client end of this connection (that is the queue manager), then I believe the answer is yes. The description of the SECCOMM attribute is as follows:-
SECCOMM
Whether connectivity to the LDAP server should be done securely using TLS
- YES
- Connectivity to the LDAP server is made securely using TLS.
The certificate used is the default certificate for the queue manager, named in CERTLABL on the queue manager object, or if that is blank, the one described in Digital certificate labels, understanding the requirements.
The certificate is located in the key repository specified in SSLKEYR on the queue manager object. A cipherspec will be negotiated that is supported by both IBM MQ and the LDAP server.
If the queue manager is configured to use SSLFIPS(YES) or SUITEB cipher specs, then this is taken account of in the connection to the LDAP server as well.
- ANON
- Connectivity to the LDAP server is made securely using TLS just as for SECCOMM(YES) with one difference.
No certificate is sent to the LDAP server; the connection will be made anonymously. To use this setting, ensure that the key repository specified in SSLKEYR, on the queue manager object, does not contain a certificate marked as the default.
- NO
- Connectivity to the LDAP server does not use TLS.
You don't say so, but I assume you have set SECCOMM(YES) and you have a certificate in your queue manager KDB that will be accepted by your LDAP server? Perhaps you can confirm this for us. You say that it does not even attempt the LDAP bind unless you also provide the LDAPUSER and LDAPPWD attributes. Can you confirm whether it does do the client certificate validation if you provide both?
Cheers,
Morag
------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com
Original Message:
Sent: Mon October 11, 2021 08:05 AM
From: Colin Paice
Subject: is authinfo LDAP and certificate logon supported?
I can use an authinfo object with AUTHTYPE(IDPWLDAP), specify a userid and password and it works.
I can enable this to use TLS, and a LDAPUSER and LDAPPW.
Rather than have to specify a userid and password, can MQ logon with the certificate, and pickup the userid from this (as it does with MQ channels).
I set up the racf mapping of certificate to userid with
RACDCERT MAP ID(ADCDA ) -
SDNFILTER('CN=ADCDA,O=YOUR COMPANY') -
WITHLABEL('ADCDA')
But I dont think it is getting that far. Is this configuration supported?
If I dont specify the LDAPUSER and LDAPPWD , it does not try the QM bind to the LDAP server.
The LDAP client coding book says
Certificate authentication
The identity from the client certificate sent to the LDAP server on an SSL/TLS socket connection is
used to establish who is contacting the LDAP server for information. SSL or TLS must be configured on
the LDAP server. Certificate authentication is also referred to as SASL EXTERNAL bind and is provided
by the ldap_sasl_bind() and ldap_sasl_bind_s() routines.
Colin
------------------------------
Colin Paice
------------------------------