Securing Queue Manager for Client Connection: Part 2 – Using SSL with CHLAUTH

Welcome to the 2nd Part of this Securing Queue Manager for Client Connection blog series. In the first part Part 1 – Using SSL we focused on enabling SSL communication between client (MQExplorer) and Queue Manager. But it provided complete administrative access for connections on the server-connection channel created for the purpose. We had disabled CHLAUTH and CONNAUTH security features and at the same time by-passed authorization by setting the MCAUSER of the channel to mqadmin (a privileged user belonging to mqm group).

Now, in this second part, we will enable CHLAUTH security and use it to restrict connections from client based on SSL Certificate DN and the Issuer’s DN as well as provide the client with different kind of security access depending on it.

For the illustration purpose, we will try to implement the below mentioned security access for the different purposes identified –> Administration / Monitoring / Application Usage. In this blog, we will configure for Administration and Monitoring purposes.

For recreating these steps, pre-required softwares are

  • OpenSSL to sign the certificates
  • MQ v8 or later installed on the Server (Linux machine)
  • MQ Explorer installed on client machine (For only MQ Explorer installation use SupportPac MS0T)
  • Part-1 of this blog series is completed

QM-access-types

1. Creating Groups & Users on MQ Linux Server

We are going to create 3 groups and users for this purpose as provided below

access-setup

Note: Although for set of group / user we need to provide full administration access, we are going to do it without making the user as privilege user, that is without making him  a member of mqm group

  • Logon to the MQ server and switch to root account
  • Create the groups as per above table
# groupadd mqsupp
# groupadd mqmon
  • Create the users and add them to appropriate groups as per above table
# useradd -g mqsupp yuvaraj
# useradd -g mqmon monusr1
  • Exit from root account

2. Generating SSL Certificate for the different Clients (Administrative / Monitoring )

  • Setting up the directory for storing the keys
# cd /ssl
# mkdir mqsupp mqmon
  • Create a key database for the different user account, using the following command
# runmqckm -keydb -create -db /ssl/mqsupp/yuvaraj.jks -pw admin 
     -type jks -stash
# runmqckm -keydb -create -db /ssl/mqmon/monusr1.jks -pw admin 
     -type jks -stash
  • Create Certificate Signing Request (CSR) for the respective user account’s using the following command
# runmqckm -certreq -create -db /ssl/mqsupp/yuvaraj.jks -pw admin 
    -type jks -label yuvaraj 
    -dn "CN=Yuvaraj C P,O=NA ,OU=Training,OU=MQ Support,C=IN" 
    -size 2048 -sig_alg SHA256_WITH_RSA 
    -file /ssl/mqsupp/yuvaraj_csr.arm

# runmqckm -certreq -create -db /ssl/mqmon/monusr1.jks -pw admin 
    -type jks -label monusr1 
    -dn "CN=Monitoring User 1 ,O=NA,OU=Training,OU=MQ Mon,C=IN" 
    -size 2048 -sig_alg SHA256_WITH_RSA 
    -file /ssl/mqmon/monusr1_csr.arm
  • Sign the respective user account’s CSR using the Intermediate CA’s private key to generate the certificate for the CSR and when prompted for pass phrase of Intermediate CA’s private key, use the value provided while creating it.
# cd /ssl/ca
# openssl ca -config intermediate/openssl.cnf -extensions usr_cert 
    -days 375 -notext -md sha256 -in /ssl/mqsupp/yuvaraj_csr.arm 
    -out /ssl/mqsupp/yuvaraj_cert.arm
# openssl ca -config intermediate/openssl.cnf -extensions usr_cert 
    -days 375 -notext -md sha256 -in /ssl/mqmon/monusr1_csr.arm 
    -out /ssl/mqmon/monusr1_cert.arm
  • Receive the Intermediate CA signed certificate into the respective user account’s key database using the following command
# runmqckm -cert -receive -file /ssl/mqsupp/yuvaraj_cert.arm 
     -db /ssl/mqsupp/yuvaraj.jks -pw admin -type jks -format ascii
# runmqckm -cert -receive -file /ssl/mqmon/monusr1_cert.arm 
     -db /ssl/mqmon/monusr1.jks -pw admin -type jks -format ascii
  • Add the Intermediate & Root CA’s certificate to the respective user acc0unt’s key database using the following command
# runmqckm -cert -add -db /ssl/mqsupp/yuvaraj.jks -pw admin 
       -label nebula-intermediate 
       -file /ssl/ca/intermediate/certs/intermediate.cert.der -format ascii
# runmqckm -cert -add -db /ssl/mqsupp/yuvaraj.jks -pw admin 
       -label nebula-root -file /ssl/ca/certs/ca.cert.der -format ascii
# runmqckm -cert -add -db /ssl/mqmon/monusr1.jks -pw admin 
       -label nebula-intermediate 
       -file /ssl/ca/intermediate/certs/intermediate.cert.der -format ascii
# runmqckm -cert -add -db /ssl/mqmon/monusr1.jks -pw admin 
       -label nebula-root -file /ssl/ca/certs/ca.cert.der -format ascii
  • FTP the directory containing the key databases we created for different user account’s under /ssl/ to the respective client machine using suitable ftp client.

3. Enabling Client Connection for Privileged User Account 

Pre-requisites: MQ v8 server or above is installed in the linux machine and user account mqadmin (member of mqm group) is setup with home directory as /home/mqadmin. Part-1 of this blog series is completed.

All the below steps are to be executed in the scripting window (using runmqsc) of the queue manager

  • Create and start the listener object to specify the port on which the queue manager is to listen for client connections (if not created already)
DEFINE LISTENER(TCP.LISTENER) TRPTYPE(TCP) +
   CONTROL(QMGR) PORT(1909)
START LISTENER(TCP.LISTENER)
  • Modify the queue manager property to enable CHLAUTH and disable CONNAUTH security features and to specify the location of the SSL key database that is to be used by the QM for SSL Communication, as shown below
ALTER QMGR CERTLABL('secureqm') +
    SSLKEYR('/home/mqadmin/ssl/secureqm/key') +
    CHLAUTH(ENABLED) CONNAUTH(' ')
  • Create a new Server Connection channel that is to be used only by privileged user account for administering queue manager. By default block all connections on this channel and hence the MCAUSER attribute of this channel is set to ‘nobody’. We will be overriding this value using the appropriate Channel Authentication record depending on the specific value of client’s SSL DN and Issuer DN.
DEFINE CHANNEL(PRIV.ADMIN.SVRCONN) CHLTYPE(SVRCONN) + 
  MCAUSER('nobody') SSLCIPH(TLS_RSA_WITH_AES_256_CBC_SHA256)
  • Create a Channel Authentication Rule as Back-stop rule (refer CHLAUTH – the back-stop rule (IBM Developerworks Blog)) to block everyone connecting to the queue manager. The CHLAUTH rule created by default with QM only blocks privileged user account, where as the new rule that we are creating is to block everyone.
SET CHLAUTH('*') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS) + 
    DESCR('Back-stop rule to block everyone') WARN(NO) ACTION(ADD)
  • Create a new CHLAUTH record to override the existing default rule that blocks all connections by privileged user account
SET CHLAUTH('PRIV.ADMIN.SVRCONN') TYPE(BLOCKUSER) +
  USERLIST('anyuser') + 
  DESCR('Rule to override blocking of privilege user account') + 
  WARN(NO) ACTION(ADD)
  • Create  a new Channel Authentication Rule to allow only administrator’s to connect to our queue manager for administration purpose. In our case, the user account of administrator is mqadmin
SET CHLAUTH('PRIV.ADMIN.SVRCONN') TYPE(SSLPEERMAP) + 
SSLPEER('CN=nebula-mqexplorer, OU=Training, O=NA') + 
USERSRC(MAP) MCAUSER('mqadmin') DESCR('SSL Auth for privilege user') + 
SSLCERTI('CN=Nebula Intermediate CA, OU=Training, O=Nebula Academy') + 
ACTION(ADD)
  • Refresh the security using the command
REFRESH SECURITY
  • Connect to SECUREQM from MQ Explorer on the client machine.Follow the steps provided in section 5 of Part-1 of this blog series, and using the server-connection channel PRIV.ADMIN.SVRCONN
  • On successful connection from MQ Explorer, check the channel status on MQ Linux server for the SECUREQM as shown below. Check the SSLPEER, SSLCERTI, SECPROT and MCAUSER attribute values on the channel status output
DIS CHS(PRIV.ADMIN.SVRCONN) ALL

AMQ8417: Display Channel Status details.
 CHANNEL(PRIV.ADMIN.SVRCONN) CHLTYPE(SVRCONN)
 BUFSRCVD(66) BUFSSENT(69)
 BYTSRCVD(17652) BYTSSENT(41280)
 CHSTADA(2017-03-08) CHSTATI(13.01.21)
 COMPHDR(NONE,NONE) COMPMSG(NONE,NONE)
 COMPRATE(0,0) COMPTIME(0,0)
 CONNAME(192.168.203.1) CURRENT
 EXITTIME(0,0) HBINT(300)
 JOBNAME(000022C300000004) 
 LOCLADDR(::ffff:192.168.203.143(1909))
 LSTMSGDA(2017-03-08) LSTMSGTI(13.01.23)
 MCASTAT(RUNNING) MCAUSER(mqadmin)
 MONCHL(OFF) MSGS(67)
 RAPPLTAG(MQ Explorer 8.0.0) SECPROT(TLSV12)
 SSLCERTI(E=reachnebula@gmail.com,CN=Nebula Intermediate CA,OU=Training,O=Nebula Academy,ST=TamilNadu,C=IN)
 SSLKEYDA( ) SSLKEYTI( )
 SSLPEER(SERIALNUMBER=10:01,CN=nebula-mqexplorer,OU=Training,O=NA,C=IN)
 SSLRKEYS(0) STATUS(RUNNING)
 STOPREQ(NO) SUBSTATE(RECEIVE)
 CURSHCNV(1) MAXSHCNV(10)
 RVERSION(08000002) RPRODUCT(MQJB)

4. Granting Requisite Access to User Account

  • We are not going to add the user accounts that was created for queue manager administrative purpose to mqm group. Instead we are going to create Access Control List (ACL) for administrative access using setmqaut command
  • Copy the scripts grantAdminAccess.odt & grantReadAccess.odt attached in the appendix section of this blog as /home/mqadmin/grantAdminAccess.sh/home/mqadmin/grantReadAccess.sh respectively

grantAdminAccess.sh

#!/bin/sh
## These commands give group 'mqsupp' full administrative access 
## for the QM to specified group
## Usage:
## grantAdminAccess.sh <QM Name> <Group>
## 
## <QM Name> : Name of the queue manager for which admin access is required
## <Group> : Group to which administrative access is to be granted

if [ $# -lt 2 ]
 then
 echo "Incorrect number of arguments supplier"
 echo "Usage: grantAdminAccess.sh <QM Name> <Group>"
 exit 1
 else
 setmqaut -m $1 -t qmgr -g $2 +connect +inq +alladm
 setmqaut -m $1 -n "**" -t q -g $2 +alladm +crt +browse
 setmqaut -m $1 -n "**" -t topic -g $2 +alladm +crt
 setmqaut -m $1 -n "**" -t channel -g $2 +alladm +crt
 setmqaut -m $1 -n "**" -t process -g $2 +alladm +crt
 setmqaut -m $1 -n "**" -t namelist -g $2 +alladm +crt
 setmqaut -m $1 -n "**" -t authinfo -g $2 +alladm +crt
 setmqaut -m $1 -n "**" -t clntconn -g $2 +alladm +crt
 setmqaut -m $1 -n "**" -t listener -g $2 +alladm +crt
 setmqaut -m $1 -n "**" -t service -g $2 +alladm +crt
 setmqaut -m $1 -n "**" -t comminfo -g $2 +alladm +crt

## The following commands provide administrative access for MQ Explorer.
 setmqaut -m $1 -n SYSTEM.MQEXPLORER.REPLY.MODEL -t q -g $2 +dsp +inq +get
 setmqaut -m $1 -n SYSTEM.ADMIN.COMMAND.QUEUE -t q -g $2 +dsp +inq +put
fi

grantReadAccess.sh

#!/bin/sh
## These commands gives the specified group full administrative access to QM
## 
## Usage:
## grantReadAccess.sh <QM Name> <Group>
## 
## <QM Name> : Name of the queue manager for which admin access is required
## <Group> : Group to which administrative access is to be granted

if [ $# -lt 2 ]
 then
 echo "Incorrect number of arguments supplier"
 echo "Usage: grantReadAccess.sh <QM Name> <Group>"
 exit 1
 else
 
 setmqaut -m $1 -t qmgr -g $2 +connect +inq +dsp
 setmqaut -m $1 -n "**" -t q -g $2 +dsp +browse
 setmqaut -m $1 -n "**" -t topic -g $2 +dsp
 setmqaut -m $1 -n "**" -t channel -g $2 +dsp
 setmqaut -m $1 -n "**" -t process -g $2 +dsp
 setmqaut -m $1 -n "**" -t namelist -g $2 +dsp
 setmqaut -m $1 -n "**" -t authinfo -g $2 +dsp
 setmqaut -m $1 -n "**" -t clntconn -g $2 +dsp
 setmqaut -m $1 -n "**" -t listener -g $2 +dsp
 setmqaut -m $1 -n "**" -t service -g $2 +dsp
 setmqaut -m $1 -n "**" -t comminfo -g $2 +dsp

## The following commands provide administrative access for MQ Explorer.
 setmqaut -m $1 -n SYSTEM.MQEXPLORER.REPLY.MODEL -t q -g $2 +dsp +inq +get
 setmqaut -m $1 -n SYSTEM.ADMIN.COMMAND.QUEUE -t q -g $2 +dsp +inq +put
fi
  • Grant permission on these files to mqadmin and mqm group as shown below
# chmod 774 grant*.sh
  • Run the script files to create requisite ACL for mqsupp and mqmon groups to QM SECUREQM. The script files takes 2 parameters –> Queue Mangare name and group respectively
# cd /home/mqadmin
# ./grantAdminAccess.sh SECUREQM mqsupp
# ./grantReadAccess.sh SECUREQM mqmon

5. Enabling Client Connection for Non-Privileged User Account

All the below steps are to be executed in the scripting window (using runmqsc) of the queue manager

  • Create and start the listener object to specify the port on which the queue manager is to listen for client connections (if not created already)
DEFINE LISTENER(TCP.LISTENER) TRPTYPE(TCP) +
   CONTROL(QMGR) PORT(1909)
START LISTENER(TCP.LISTENER)
  • Modify the queue manager property to enable CHLAUTH and disable CONNAUTH security features and to specify the location of the SSL key database that is to be used by the QM for SSL Communication, as shown below (if not modified already)
ALTER QMGR CERTLABL('secureqm') +
    SSLKEYR('/home/mqadmin/ssl/secureqm/key') +
    CHLAUTH(ENABLED) CONNAUTH(' ')
  • Create a new Server Connection channel that is to be used for client connection to the queue manager for various purposes. By default block all connections on this channel and hence the MCAUSER attribute of this channel is set to ‘nobody’. We will be overriding this value using the appropriate Channel Authentication record depending on the specific value of client’s SSL DN and Issuer DN.
DEFINE CHANNEL(RMT.ADMIN.SVRCONN) CHLTYPE(SVRCONN) + 
  MCAUSER('nobody') SSLCIPH(TLS_RSA_WITH_AES_256_CBC_SHA256)
  • Create a Channel Authentication Rule as Back-stop rule (refer CHLAUTH – the back-stop rule (IBM Developerworks Blog)) to block everyone connecting to the queue manager. The CHLAUTH rule created by default with QM only blocks privileged user account, where as the new rule that we are creating is to block everyone (if not created already)
SET CHLAUTH('*') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS) + 
    DESCR('Back-stop rule to block everyone') WARN(NO) ACTION(ADD)
  • Create  a new Channel Authentication Rule to identify the client connection based on their SSL DN and Issuer DN and map it to appropriate access level user account on the server side.
SET CHLAUTH('RMT.ADMIN.SVRCONN') TYPE(SSLPEERMAP) + 
SSLPEER('CN=Yuvaraj C P, OU=Training, OU=MQ Support, O=NA') + 
USERSRC(MAP) MCAUSER('yuvaraj') + 
DESCR('SSL Auth for Administrative user') + 
SSLCERTI('CN=Nebula Intermediate CA, OU=Training, O=Nebula Academy') +
ACTION(ADD)

SET CHLAUTH('RMT.ADMIN.SVRCONN') TYPE(SSLPEERMAP) + 
SSLPEER('CN=Monitoring User 1, OU=Training, OU=MQ Mon, O=NA') + 
USERSRC(MAP) MCAUSER('monusr1') DESCR('SSL Auth for Monitoring user') +
SSLCERTI('CN=Nebula Intermediate CA, OU=Training, O=Nebula Academy') +
ACTION(ADD)
  • Refresh the security using the command
REFRESH SECURITY
REFRESH SECURITY TYPE(SSL)
  • Connect to SECUREQM from MQ Explorer on the client machine.Follow the steps provided in section 5 of Part-1 of this blog series, and using the server-connection channel RMT.ADMIN.SVRCONN. 
    • For Administrative access: Try using the key store yuvaraj.jks in MQ Explorer
    • For Read only access: Try using the key store monusr1.jks in MQ Explorer

Notice the kind the access you get on MQ Explorer in both the cases

  • On successful connection from MQ Explorer, check the channel status on MQ Linux server for the SECUREQM as shown below. Check the SSLPEER, SSLCERTI, SECPROT and MCAUSER attribute values on the channel status output

6. Appedix

7. References

CHLAUTH – the back-stop rule (Application Integration Middleware Support Blog)

CHLAUTH – Allow some privileged admins (Application Integration Middleware Support Blog)

Will be following up this blog to extend the client connectivity  with CONNAUTH security feature too.

For any corrections / suggestions / comments / query please do drop a note to reachnebula@learnibmesb.com (or) reachnebula@gmail.com

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s