MQ multiplatform can use LDAP as a userid and group repository, so you can logon to any machine where MQ is running, and use your corporate userid and password.
I’ve logged on to MQ on my Linux machine, and used my z/OS userid and password. It was pretty easy to set up (I had prior experience of using LDAP) but although it didn’t quite behave as I thought it would – I thought this was pretty clever.
Once you have installed LDAP, started it, and created your directory structure, (user, groups) and access permissions, you can start to use it. I’ve documented some of the initial settup here. It covers some of the concepts referred to below.
I used LDAP (Tivoli Directory Server) on z/OS as my LDAP server.
- Using LDAP from MQ Multiplatform
- LDAP definition of my logon userid
- Check the LDAP configuration when things go wrong
- Setting up MQ connect authorities
- How do you set up a group in LDAP?
- Can I use LDAP to hold my setauth information?
- Giving userids access to MQ objects
- I’ve changed the definitions in LDAP – when will they get picked up?
I’ve also written using LDAP with MQ and nested groups (MQ NESTGRP).
Using LDAP from MQ Multiplatform
The IBM documentation for this is so-so. It gives examples, but the examples didn’t work for me, but they were enough go point me in the right direction.
I created a LDAP.MQSC file with
DEFINE AUTHINFO(MYLDAP) +
BASEDNG(‘o=Your Company’) +
BASEDNU(‘o=Your Company’) +
LDAPUSER(‘cn=adcda, o=Your Company’) +
ALTER QMGR CONNAUTH(MYLDAP)
REFRESH SECURITY TYPE (CONNAUTH)
* ALTER QMGR CONNAUTH(SYSTEM.DEFAULT.AUTHINFO.IDPWOS)
Where the key fields for connecting to LDAP are
- conname – the IP address of the LDAP server.
- ldapuser and ldappwd – userid and password to access LDAP.
- seccomm – use TLS/SSL to contact the LDAP server. I used “no” while setting this up.
the key fields for identifying users are
- basednu – the subtree to be used for userids, for example all users are one level under ou=user,o=myorg.
- classusr – is the objectclass attribute to identify the userid. The default is inetOrgPerson.
- shortusr – the dn identifiers are too long. MQ needs IDs with 12 characters or less. This attribute says which attribute to use.
the key fields for identifying which groups an id belongs to
- authormd – how to search for the authorisation.
- basedng – the subtree to be used for groups, for example ou=group,o=myorg.
- classgrp – the objectType which objects must have to be recognised as a group
- grpfield – the simple name of the group
- findgrp – what to filter for. For example ‘member’
Being a careful person, I started an interactive runmqsc session in one terminal, and used runmqsc … < LDAP.MQSC in another window. This way if there were problem I could use the interactive session to reset the QMGR CONNAUTH (as in the comment above). I know that the userid that started the queue manager, does not need a password; so if you issued strmqm qma you can use runmqsc qma without a userid and password. It gets harder if your id is not the id the queue manager is running under.
LDAP definition of my logon userid
The userid I wanted to use with MQ was defined
dn: cn=ibmuser, o=Your Company
st: cn=group,ou=groups,o=your Company
st: cn=mqadmin,ou=groups,o=your Company
The authinfo data has
BASEDNU(‘o=Your Company‘) +
When I try to logon with userid ibmuser, MQ issues an LDAP query for the record with
- with an object class = ‘ibm-nativeAuthentication (which provides the RACF support for userid and password)
- in the subtree o=Your Company
Check the LDAP configuration when things go wrong
It took me a few hours to determine why I could logon with one id, but not another id. Some LDAP entries worked, and some did not. It turned out to be an Access Control List (ACL) set up problem, where the LDAPUSER userid was not authorised to see some of the records. With the above AUTHINFO object, the query that MQ uses to check authorisation is like
ldapsearch -h 127.0.0.1 -D “cn=adcda, o=Your Company” -w ? -b “o=Your Company” “&(objectClass=ibm-nativeAuthentication)(sn=zadcdc)”
Where the parameters match up with the authinfo object above, and zadcdc is the userid trying to logon.
If you get no data back, get an authorised person (cn=ibmuser…) to issue the command for the user problem userid zadcdc:
ldapsearch -h 127.0.0.1 -D “cn=ibmuser, o=Your Company” -w ? -b “o=Your Company” “&(objectClass=*)(sn=zadcdc)”aclentry aclsource
The aclentry will give you the userids or groups who are authorised to use the entry, and the access they have.
The aclsource tells you which node in the tree the ACL was inherited from (for example aclsource=o=Your Company says it came from the root node). I had set up an ACL for my zadcdc which did not include my LDAPUSER.
Setting up MQ connect authorities
You can issue the command
setmqaut -m qml -t qmgr -p ibmuser +connect
to give ibmuser connect authority.
You can use LDAP groups for example
setmqaut -m qml -t qmgr -g “cn=mqadmin,ou=groups,o=your Company” +connect.
How do you set up a group in LDAP?
This is where it gets interesting. You can define a static group with its list of members, or create a dynamic group which is more flexible and “modern” (where modern is within the last 30 years).
Using a static group (with a list of members defined in it)
You can define a static group in LDAP using
dn: cn=mqstatic,ou=groups,o=your Company
member: cn=ibmuser,o=your Company
member: cn=adcdb,o=your Company
It has two members.
When the userid authenticates, the queue manager asks LDAP for the groups that the userid is in; using the AUTHINFO definitions CLASSGRP(‘groupOfNames’) + GRPFIELD(…) FINDGRP(‘…’) a query is done for the groups which have the userid id. For example with
BASEDNG(‘ou=groups,o=your Company’) +
and cn=ibmuser o=your Company. The query is
(&(objectClass=groupOfNames)(member=cn=ibmuser, o=Your Company) in subtree (ou=groups,o=your Company)
The ldap search asking to return the member attribute
ldapsearch … -b “ou=groups,o=your Company” “(&(objectClass=groupOfNames) (member=cn=ibmuser, o=Your Company)) ” cn
gave two group names –
This gives the information as to which groups a user is in. MQ then saves the userid and group information, and does not need to go to LDAP the next time the userid needs access checking.
Knowing which groups a userid is in, MQ can then decide on the access by comparing with the setmqaut definitions.
Using a dynamic group – or using a group attributer in the user record.
Instead of a group having a list of members, you can add information to the user’s record.
dn: cn=adcda, o=Your Company
group: cn=group,o=your Company
Unfortunately there is no “group” attribute defined in the LDAP schema, so I had to find another attribute to use. I used st for state. I used st: cn=group,o=your Company instead of group: cn=group,o=your company.
In my MQ AUTHINFO definition I had
BASEDNU(‘o=Your Company’) +
BASEDNG(‘ou=zzzzz,o=your Company’) +
MQ did an LDAP search using this information
ldapsearch… -b “o=Your Company” “&(objectClass=(ibm-nativeAuthentication)
Which is just a display of the userid information – and return the fields with the attribute you specified(st). It returned
cn=ibmuser, o=Your Company
This tells MQ to use the groups
cn=group,ou=groups,o=your Company and cn=mqadmin,ou=groups,o=your Company.
You can use the setmqaut command to give the group access
setmqaut -m qml -t qmgr -g “cn=mqadmin,ou=groups,o=your Company” +connect
Once this was done, the cn=ibmuser could connect to MQ using groups.
Can I use LDAP to hold my setauth information?
Only the group and userid information are held in LDAP, all the other information is held in the queue manager. You cannot use LDAP to have your setmqaut configuration in LDAP, and shared by multiple queue managers. You still have to use setmqaut to set up each queue manager access.
Giving userids access to MQ objects
You can use the setmqaut command or the set authrec runmqsc command to give principals or groups access to resources.
setmqaut -m qml -n CP0000 -t queue -g “cn=mqstatic,ou=groups,o=your Company” +inq
I’ve changed the definitions in LDAP – when will they get picked up?
Changes get picked up when
- the queue manager is restarted
- when the resfresh security, refresh security type(authserv) or the refresh security type(connauth) command is issued.