Introduction
The ability to authenticate users with LDAP instead of OS credentials has been available since MQ v8, allowing MQ administrators to require any users attempting to connect to MQ, either locally or through a client, to provide LDAP credentials for authentication. A new AUTHINFO object type has been added to MQ to allow this to be configured – AUTHTYPE IDPWLDAP – which holds the necessary LDAP server information and uses it to connect to and authenticate with a LDAP server.
In this scenario, we will be sending messages to the Queue Manager (with LDAP authentication) from an application using the AMQP protocol, via the MQ Light messaging client. For this, we will need to create an MQ Light application, set up an LDAP server, define our Queue Manager CONNAUTH rules and create two Listeners on the Queue Manager.
Create the MQ Light Application and connect to Queue Manager via AMQP Channel
In order to connect an MQ Light Application with a Queue Manager via an AMQP channel, we first of all need to ensure our queue manager is running at least command level 801. Detailed instructions on how to do this and how to set up the AMQP channel manually can be found here.
For the sake of simplicity, we will be using a sample script provided with MQ in order to set up our environment. This script is located in directory and conducts the following procedures – creates a new queue manager, starts the AMQP service, creates a new channel called SAMPLE.AMQP.CHANNEL, and starts the channel. The script is called SampleMQM.sh on Linux, or SampleMQM.bat on Windows.
After running the script, install the MQ Light Node.js client by running the following command:
npm install mqlight
More information about the command can be found here.
Navigate to node_modules/mqlight/samples directory and run the sample receiver application:
node recv.js
In case you’ve configured your AMQP channel to use a different port number from default (5672 for AMQP 1.0), you can run the command:
node recv.js -s amqp://localhost:6789
A successful connection to the default channel displays the following message:
Connected to amqp://localhost:5672 using client-id recv_e79c55d
Subscribed to pattern: public
For clarity this scenario assumes that security has been temporarily turned off, but it is, of course, possible to configure it to suit your needs.
The application is now connected to the queue manager and is waiting to receive messages. Note that the client-id is generated automatically unless specified earlier with the -i parameter.
In a new command window, navigate to the node_modules/mqlight/samples directory and run the sample sender application:
node send.js
In the command window for the receiver application, the “Hello World!” message is displayed.
For more information and additional optional configurations, refer to the following articles in the IBM MQ Knowledge Center:
MQ Light and other AMQP clients communicating over IBM MQ
Creating and using AMQP channels
Connect Queue Manager to OpenLDAP server
Initially, we must create an AUTHINFO of type IDPWLDAP for the Queue Manager. During the creation process, the following fields must be completed:
- CONNAME = The IP/hostname for the LDAP server. This should also include the port number if the LDAP server operates on a non-standard port (389 or 636).
- SHORTUSR = The LDAP field we should use if we adopt the LDAP user as the user to use for future checks.
In addition, the following fields could be filled in to ensure that MQ can contact and communicate with the LDAP server:
- ADOPTCTX = Whether we should start using the LDAP user supplied as our user for future checks (for example Authorisation checks) or not.
- BASEDNU = This specifies the base distinguished name that should be appended to any credentials that does not supply them.
- CLASSUSR = This is the object class of the records you want to authenticate against.
- LDAPUSER = The LDAP User to connect to the server with. These credentials are only required if the LDAP server requires credentials when you connect to it.
- LDAPPWD = The Password for the above user
- SECCOMM = Whether we should connect to the LDAP server via SSL/TLS or not (This will be covered in more detail in another blog post)
- USRFIELD = This specifies the User field that should be added to any credentials that does not supply one.
- CHCKLOCL = Whether a user connecting via local bindings should supply credentials.
- CHCKCLNT = Whether a user connecting via a client connection should supply credentials.
For this task, the LDAP server used will be grana (grana.v6.hursley.ibm.com).
In the runmqsc console, define AUTHINFO:
DEFINE AUTHINFO(‘USE.LDAP’) AUTHTYPE(IDPWLDAP) CONNAME(IP ADDRESS OF LDAP SERVER) SHORTUSR(‘cn’) ADOPTCTX(NO) USRFIELD(‘cn’) BASEDNU(‘ou=users,o=mqst’) CHCKCLNT(OPTIONAL) CHCKLOCL(OPTIONAL) CLASSUSR(‘person’) SECCOMM(NO)
Restart Queue Manager. Tell Queue Manager to use it:
ALTER QMGR CONNAUTH( ‘USE.LDAP’ )
Refresh Queue Manager security to bring the new AUTHINFO object into effect:
REFRESH SECURITY
We can test connectivity with LDAP server by issuing command:
We do not need any specific configuration of the AMQP client or channel, as the
authentication should be applied by default.
You can now run your AMQP listener and the connection will be authenticated.
Authenticating using AD (Active Directory)
Authenticating using an Active Directory is quite similar to authenticating using an LDAP server except
a few minor differences. The first difference is the setup of the AUTHINFO object, as it requires more details to be supplied in order to make an AD connection compared to LDAP connection.
Run the commands:
ALTER QMGR CONNAUTH(‘USE.LDAP’)
REFRESH SECURITY
Set up the listeners and try to run the amqscnxc command from
C:\Program Files\IBM\WebSphere MQ\Tools\c\Samples\Bin64.
Enter the AD password. If connection successful, you should see the following message:
Connection established to queue manager AMQP_SAMPLE_QM2.
All error logs are stored in .