Several years ago I wrote about using Active Directory (AD) with MQ-specific authentication and authorisation options on a Unix queue manager. In that scenario, AD serves as an LDAP server. The MQ CONNAUTH attribute points at an IDPWLDAP format of AuthInfo object.
There is another approach to using Active Directory with MQ on Linux, where the directory is much more integrated with the operating system. I have seen enough confusion between these two options that I thought it was worth writing something to explain. I’ve had several apparently independent streams of notes on this topic in the last month alone (not to mention the person who seems to have asked everyone they know in the hope of at least one of them giving the answer they want to hear even if it’s wrong).
Where the confusion starts
A typical question that comes in starts something like “My Linux queue manager is using AD …”. From that introduction, I have seen support teams assume that that means the queue manager is using the IDPWLDAP configuration described in my older post. Because that really is the only situation where AD or LDAP is directly relevant to MQ. In turn, that understandably leads to providing information about the attributes such as BASEDNU or SEARCHGRP. Which might be completely irrelevant to the question.
But quite frequently these days, AD is used as a provider of identities to the whole operating system, not something that is specific to MQ. So you should not expect anything about this approach in any MQ documentation. Here, MQ will use the IDPWOS mechanism for authentication and authorisation. It’s very similar to having NIS as a centralised identity mechanism. The AD component uses interfaces like NSS and PAM to fill in responses to the standard library calls such as getpwent or getgroups that MQ calls to find out about “local” users and groups.
So whenever a question or support ticket mentions using AD with MQ on a Linux queue manager, the first requirement is to clarify the meaning. Do you mean “as an LDAP server” or do you mean “as an integrated OS identity provider”?
Using sssd with Active Directory
Simple integration of identities with AD at a Linux operating system level originally came only with 3rd-party commercial products. And there was Samba which did something, but was more about file/printer sharing. Although some of these tools still exist, and can offer additional flexibility, I’m mostly going to talk about the “free” option available with Linux today.
The sssdservice is the key piece. It provides a link between Linux applications requesting security services and a variety of backend providers. In our case, what we are interested in is the Active Directory module. When configured, AD gives a transparent extension to the local lists of users and groups. It’s as if additional lines were added to /etc/passwd and /etc/group.
Most of the time that you will be working in this environment, the configuration of both Windows AD services and Linux will already have been done, or is someone else’s responsibility. But I’m going to write a few notes here on what I had to do for a test environment in case you want to try it yourself.
Configuration of Active Directory
There is not really much to do in the AD configuration. I provisioned a Windows Server 2019 machine, and made it a domain controller for a new forest/domain. The Windows machine knows nothing about Linux or sssd; it is just a standard AD environment. I then created a few users and groups that could be used for running MQ applications:
The only thing that I had to be careful about when defining the domain was to NOT change the machine’s fully-qualified hostname so that networking and certificates would have the cloud-assigned names, resolvable in DNS by other machines.
In a real environment, I would expect that all of the AD setup has already been done – the whole point is that the Linux machine is integrating with an existing enterprise directory.
Configuration of Linux and sssd
Connecting my Linux system to the domain was mostly a matter of running the realm command.
The only unexpected aspect was I had to use the hostname of the controller, not the Windows domain in the joinsub-command. That wasn’t obvious from the documentation which seems to assume the Windows domain and the machine’s DNS name are the same. Perhaps additional discovery probes might have found it.
[root@rh9]# realm join autotype1.fyre.ibm.com Password for Administrator: [root@rh9]# realm list mq.met.com type: kerberos realm-name: MQ.MET.COM domain-name: mq.met.com configured: kerberos-member server-software: active-directory client-software: sssd required-package: oddjob required-package: oddjob-mkhomedir required-package: sssd required-package: adcli required-package: samba-common-tools login-formats: %U@mq.met.com login-policy: allow-realm-logins
The main problem I had was ensuring the secure communication worked: update-crypto-policies DEFAULT:AD-SUPPORT seemed to be the key to solving that.
There are a bunch of other commands that can be useful in looking at status or doing debug: sssctl domain-status, systemctl status sssd, adcli all had their place. The only other configuration I made was in /etc/sssd/sssd.conf, followed by restarting the sssd service:
use_fully_qualified_names = false
This option tells Linux to use the base name everywhere instead of the name+domain. So I can choose to refer to user1 intead of user1@mq.met.com although the fully-qualified version still works in the OS:
[root@rh9]# id user1 uid=456201110(user1) gid=456200513(domain users) groups=456200513(domain users),456201106(group1),456201108(group0) [root@rh9]# id user1@mq.met.com uid=456201110(user1) gid=456200513(domain users) groups=456200513(domain users),456201106(group1),456201108(group0)
All the MQ controls like setmqaut will assume (require) use of this short unqualified format. There are a number of other configuration options for the security service, but I only made the minimum changes to get a working environment.
MQ Installation and Configuration
Where this all becomes important for MQ is in the installation process and using privileged identities. Note that anything in the product documentation referring to Active Directory is going to be related to running on Windows – the queue manager there is aware of things like domains and SIDs. So you can ignore all of that for a Linux environment.
Installing MQ on a Linux system from rpm or debformat files requires that there must be an mqm user and group available. You cannot change those identities; they own resources such as the binary programs and files making up a queue manager. Scripts execute during the installation that check for the existence of the user and group. If they do not already exist, then the installation automatically creates them.
The container images for MQ use a different mechanism; the MQ code comes in a simple tar image unpacked into an arbitrary directory and has a different security and resource ownership model. I’m not going to consider that further here as it is not at all affected by, or relevant to, the AD integration.
If I have not already created the ids, I see them being defined when I run the MQ install process:
[root@rh9]#./mqlicense.sh -accept
Licensed Materials - Property of IBM
5724-H72
(C) Copyright IBM Corporation 1993, 2023
US Government Users Restricted Rights - Use, duplication or disclosure
restricted by GSA ADP Schedule Contract with IBM Corp.
Agreement accepted: Proceed with install.
[root@rh9]# rpm -i *.rpm
Creating group mqm
Creating user mqm
Licensed entitlement 'advanced' set for installation at '/opt/mqm'.
[root@rh9]# grep mqm /etc/passwd
mqm:x:983:1000::/var/mqm:/bin/bash
[root@rh9]# grep mqm /etc/group
mqm:x:1000:
You can see the local definition of the user and group. But what if we do not want to have them local?
One fundamental problem with using AD is that you are unable to have users and groups of the same name in the directory. So you cannot have both the mqm user and the mqm group defined in AD. You MUST define at least one of them locally.
I reset from the previous test where the installation created both accounts. What I chose to do this time was to have a local user definition but to have a central AD mqm group. Having the group makes it easier to add other users to the group globally. So I let the MQ installation process create the mqm user. But I also created an mqadmin user in AD that will be useful later on.
This time, only the user gets created by the installation:
[root@rh9]#./mqlicense.sh -accept
Licensed Materials - Property of IBM
5724-H72
(C) Copyright IBM Corporation 1993, 2023
US Government Users Restricted Rights - Use, duplication or disclosure
restricted by GSA ADP Schedule Contract with IBM Corp.
Agreement accepted: Proceed with install.
[root@rh9]# rpm -i *.rpm
Creating user mqm
Licensed entitlement 'advanced' set for installation at '/opt/mqm'.
[root@rh9]# grep mqm /etc/passwd
mqm:x:983:1000::/var/mqm:/bin/bash
[root@rh9]# grep mqm /etc/group
[root@rh9]#
There should never need to be a need to logon as the mqm user provided you have other users with the right group membership. So you can set that installation-created id to not be available for login and any other disabling that you want. This might be an acceptable compromise in organisations that would otherwise like to prohibit any local definitions.
One thing to be careful of is the group membership. In particular, the primary group associated with any users. By default, AD reports the primary group as “Domain Users” which is not suitable for Unix systems – the space in the name is a problem. And that led at first to a bunch of security issues producing FDCs when I wanted to create a queue manager. Instead I explicitly set the primary group for the mqadmin user to be mqm:
Once all of that was in place, I was able to switch to the mqadminuser and create a queue manager:
[root@rh9]# su - mqadmin Last login: Thu Feb 16 11:02:06 GMT 2023 on pts/0 [mqadmin@rh9]$ id uid=456201121(mqadmin) gid=456201120(mqm) groups=456201120(mqm),456200513(domain users) [mqadmin@rh9]$ crtmqm QM1 IBM MQ queue manager 'QM1' created. Directory '/var/mqm/qmgrs/QM1' created. The queue manager is associated with installation 'Installation1'. Creating or replacing default objects for queue manager 'QM1'. Default objects statistics : 83 created. 0 replaced. 0 failed. Completing setup. Setup completed.
You can see the gid entry for primary group now refers to mqm.
I also needed to do similar group membership settings for “application” users. If the primary group does not look like a Unix groupname, then commands such as setmqaut will fail. If a user is never going to need to use the account on a Windows machine, it might be convenient to explicitly remove the id from the “Domain Users” group and any other similarly-named groups.
Changes to users and group membership sometimes took a little while to propagate from the server. Running sssctl cache-expire -E helped to bring the updates down faster.
Is there any way to have both mqm user and group defined in AD?
Not with the sssd service that I could find. The constraint of users and groups sharing the same namespace is fundamental in AD. And sssd doesn’t seem to have any documented mapping options.
There are additional paid-for products that might give further configuration. For example, the Safeguard (originally Vintela) documentation suggests that you might be able to apply a more complex mapping between AD names and local names. So you might have an AD definition of mqmGroup and mqmUser and then apply a local mapping. But it’s not something I’ve been able to try.
Queue manager configuration
You do not need any special queue manager configuration. All of the authentication and authorisation controls behave as if the users and groups are local to the OS. Password checking is delegated via PAM to the AD server; group membership for authorisations is delegated via NSS. So the CONNAUTH configuration points at an Authentication Object of type IDPWOS with AUTHENMD(PAM). We do not need to setup for LDAP checking. We could choose to do that, and treat the AD server as a general LDAP server, but it’s not necessary.
Summary
Using Active Directory as an identity provider on Linux is mostly transparent to MQ. But you do have to decide about where to define the mqmuser and group. Once you have done that, MQ just considers the centralised accounts to be part of the operating system. Which is of course the goal.
I hope this helps to sort out any confusion about using AD with MQ.
This post was last updated on February 19th, 2023 at 11:16 am