MQ

  • 1.  is authinfo LDAP and certificate logon supported?

    Posted Mon October 11, 2021 08:05 AM
    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
    ------------------------------


  • 2.  RE: is authinfo LDAP and certificate logon supported?

    Posted Tue October 12, 2021 01:46 AM

    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
    ------------------------------



  • 3.  RE: is authinfo LDAP and certificate logon supported?

    Posted Wed October 13, 2021 11:28 AM

    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
    ------------------------------



  • 4.  RE: is authinfo LDAP and certificate logon supported?

    Posted Thu October 14, 2021 03:57 AM
    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
    ------------------------------



  • 5.  RE: is authinfo LDAP and certificate logon supported?

    Posted Thu October 14, 2021 07:55 AM
    Hi Mark,

    Thanks for your reply.  It is as I expected.
    I'll document making the ldapuser a nologon userid,  and remind people to change the password regularly (perhaps not every 28 days).

    Openldap does mention it 
    • OpenLDAP clients and servers are capable of using the () framework to provide integrity and confidentiality protections and to support LDAP authentication using the EXTERNAL mechanism.
    • TLS uses certificates to carry client and server identities. All servers are required to have valid certificates, whereas client certificates are optional. Clients must have a valid certificate in order to authenticate via SASL EXTERNAL.
    If there had been a lot of demand for this, it would have been implemented by now.
    regards

    Colin


    ------------------------------
    Colin Paice
    ------------------------------