{"id":541,"date":"2016-09-15T20:03:46","date_gmt":"2016-09-15T19:03:46","guid":{"rendered":"https:\/\/marketaylor.synology.me\/?p=541"},"modified":"2019-11-24T20:37:57","modified_gmt":"2019-11-24T20:37:57","slug":"ibm-mq-using-active-directory-for-authorisation-in-unix-queue-managers","status":"publish","type":"post","link":"https:\/\/marketaylor.synology.me\/?p=541","title":{"rendered":"IBM MQ – Using Active Directory for authorisation in Unix queue managers"},"content":{"rendered":"

Permissions for accessing MQ functions have traditionally relied on using operating system definitions for users and groups. That could mean you having a requirement to define those users and groups on each system individually, which is challenging enough in a static topology, but becomes even worse in a dynamic environment such as a cloud where systems may be being defined and deleted regularly. And so some central definition of the identities becomes essential.
\n
\nFor Windows systems, the standard way of sharing identities is Active Directory (AD).<\/p>\n

For Unix systems, one way of sharing user and group information is through the configuration of services in the PAM<\/a> and nsswitch<\/a> interfaces. Perhaps the most common mechanism for sharing on those systems is to configure nsswitch to use of the NIS (or NIS+) services; implementations also exist for storing the information in LDAP among other stores. Using those nsswitch and PAM services means that MQ does not know how the users or groups are stored; it can treat them as if they were locally defined in \/etc\/passwd<\/code> or \/etc\/group<\/code>. All of the operating system services such as getpwnam<\/em>() behave transparently, hiding the underlying source of the data.<\/p>\n

An alternative now exists in MQ, which can directly access LDAP servers instead of relying on OS services. A common store can be used not just within an operating system family, but across all the MQ Distributed platforms. MQ V8 added the ability to authenticate users against an LDAP directory. Fixpack 8.0.0.2<\/a> on Unix and System i extended that to allow authorisations<\/strong> to be managed using LDAP-defined users and groups; the equivalent Windows support for LDAP authorisation arrived in V9. Using LDAP explicitly means that users do not actually need to be defined or available on the operating system where MQ is running. The OS userid that is running an application program has no direct relationship to the identity used for authorisation checks.<\/p>\n

This article shows how MQ can be configured to have LDAP refer to users and groups defined in a Windows Active Directory system, even though the queue manager is not running on Windows. In this exercise, the whole environment was running on AWS, using an Amazon-provided AD server, removing the need to configure such a server myself.<\/p>\n

MQ supports the use of any LDAP server, including AD and IBM Directory Server, but one thing I was particularly interested in testing here was the use of “standard” Windows accounts in AD, instead of simply using it as a generic LDAP server, where users and groups may be defined in a separate part of the directory tree.<\/p>\n

The architecture<\/h2>\n
    \n
  1. AWS Directory Service is used to run an Active Directory instance.<\/li>\n
  2. A Windows 2012 server image which is used to administer the directory, including definitions of users and groups.<\/li>\n
  3. A Linux image where MQ is installed and runs the queue manager. This was also where MQ applications were run for these tests. I used the packer JSON files and procedures shown in Arthur’s article<\/a> as the starting point for this image.<\/li>\n<\/ol>\n

    Configuring the directory service<\/h2>\n

    All that was needed was to provide a domain name (‘mq.hursley.ibm.com<\/strong>‘) and a password for the administrator. You may want to set a VPC and some subnet information to control networking, but I left this to default. Once created, two IP addresses are available which are needed for access to the directory.<\/p>\n

    Configuring Windows<\/h2>\n

    When I created the Windows 2012 instance, I did not initially join the domain. I left that until later. Once the instance is running, and you have logged on as the administrator, then you need to enable the feature that allows you to administer the directory.<\/p>\n

    \"\"<\/p>\n

    Next, the system must be configured to point at the DNS addresses created for the directory service:<\/p>\n

    \"\"<\/p>\n

    Finally, we can join the domain:<\/p>\n

    \"\"<\/p>\n

    Administering AD from Windows<\/h3>\n

    The “Administrative Tools” panel should now contain an item for “Active Directory Users and Computers”. That gives a UI for inspecting, defining and modifying users and groups. Much of MQ’s LDAP configuration relies on knowing details of the directory schema and where objects are located in the directory. This is most easily done by selecting the “Advanced Features” of the program as it turns on some additional items when you drill into directory entries.<\/p>\n

    \"\"<\/p>\n

    In particular you can now use the Attribute Editor to see all of the attributes of an entry, including the full Distinguished Name and the field names associated with other data. As well as the DN, you need to identify a field in the entry that can be used as a unique short identifier for the user. Looking at the properties of this entry, it seems that employeeID<\/strong> might be a good candidate here. The short name is used in MQ to fill in the 12 character MQMD UserIdentifier field, and will also appear in the output of commands such as DISPLAY CONN, showing who is using a queue manager.<\/p>\n

    \"\"<\/p>\n

    Users and groups<\/h3>\n

    I created several users and groups to which I could then grant different levels of access.<\/p>\n

    The first new user, mqmldap<\/strong>, is intended to be used by the queue manager for its connection to the directory. This user does no MQ work itself, and is purely there to be able to search the directory for identities. Once created, and a password has been set (you will need to know the password later, I used “MQpassw0rd<\/strong>‘”), the user needs to be granted read authority on the directory. No further authorities are needed here.<\/p>\n

    \"\"<\/p>\n

    I also created an MQUser group and an MQAdmin group, along with a few test ids that were made members of one or both of these groups.<\/p>\n

    Configuring MQ<\/h2>\n

    Once the directory is configured, with suitable identities, we can turn to the queue manager configuration. In this MQSC command, we are giving several sets of information:<\/p>\n