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:-
Whether connectivity to the LDAP server should be done 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.
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.
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?
Hi Morag,I've done a big more digging into this.If I do a certificate logon using LDAP_SEARCH, the LDAP trace hasINFO process_sasl_bind()1722: Processing request for the 'EXTERNAL' SASL mechanismACL 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=0If I try an MQ logon I get in the traceLDAPBE srv_process_bind_request()374: do_bindv_process_bind_request()939: do_return_bind msgID=1, connID=6, bindDN='', safUserID=''0x0, grpList=0x0, rc=0This 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.CheersColin