User authen­ti­ca­tion is anoth­er aspect of secu­ri­ty that is often over­looked and many think it only applies to human users.

Quite the con­trary! User authen­ti­ca­tion, albeit with a few twists, is an essen­tial aspect for secur­ing appli­ca­tions’ access to resources.

IBM MQ can be con­fig­ured to force users and appli­ca­tions to sup­ply a user­name and a pass­word before being allowed to access any of its objects.

Before MQ 8.0, secu­ri­ty authen­ti­ca­tion was imple­ment­ed using secu­ri­ty exit pro­grams. These are spe­cial pro­grams you can write with a spe­cif­ic set of input para­me­ters, and spe­cif­ic out­put values.

But 8.0 brought us the abil­i­ty to ver­i­fy a username/password pair against a user repos­i­to­ry, either man­aged by the oper­at­ing sys­tem or an exter­nal LDAP directory.

NOTE: IBM MQ ver­sions 8.0 and lat­er have two authen­ti­ca­tion meth­ods: an old one, called the com­pat­i­bil­i­ty mode and a new one, called MQCSP authen­ti­ca­tion. In com­pat­i­bil­i­ty mode, pass­words and user­names are lim­it­ed (and trun­cat­ed, if longer) to 12 char­ac­ters. In order to user user­names or pass­words longer than 12 char­ac­ters, the client appli­ca­tion has to use MQCSP authen­ti­ca­tion (dis­able the Enable Com­pat­i­bil­i­ty mode check­box in the MQ Explor­er Userid con­fig­u­ra­tion window).

Operating system authentication

This authen­ti­ca­tion method relies on the under­ly­ing oper­at­ing sys­tem’s ser­vices to val­i­date users and pass­words. To use it, you just have to cre­ate an AUTHINFO object of type IDPWOS. The MQSC com­mand is as follows:

DEFINE AUTHINFO(USE.OS) AUTHTYPE(IDPWOS) CHCKLOCL(OPTIONAL) CHCKCLNT (REQDADM) REPLACE

The CHCKLOCL and CHCKCLNT apply to local and client (remote) con­nec­tions, respec­tive­ly. Both can take the fol­low­ing values:

• NONE: No authen­ti­ca­tion will be enforced or ver­i­fied. If any con­nec­tion attempt has authen­ti­ca­tion infor­ma­tion, it will be ignored.
• OPTIONAL: No authen­ti­ca­tion will be enforced. How­ev­er, if a con­nec­tion attempt has authen­ti­ca­tion infor­ma­tion, the user must be valid, and if it is suc­cess­ful, the spec­i­fied user has to have the cor­rect per­mis­sions to con­nect to the queue manager.
• REQDADM: Authen­ti­ca­tion will be enforced if the user belongs to the MQ admin­is­tra­tion oper­at­ing sys­tem group (mqm in Win­dows, Lin­ux or UNIX, OR Admin­is­tra­tors in Windows).
• REQUIRED: Authen­ti­ca­tion will be enforced all the time.

After defin­ing the AUTHINFO for this type of authen­ti­ca­tion, con­fig­ure the queue man­ag­er to use it:

ALTER QMGR CONNAUTH(USE.OS)

To use it, either restart the queue man­ag­er or issue the command:

REFRESH SECURITY TYPE(CONNAUTH)

LDAP Authentication

In the fol­low­ing exam­ple, I’ll demon­strate con­fig­ur­ing LDAP authen­ti­ca­tion against Microsoft­’s Active Direc­to­ry. It’s a bit more com­pli­cat­ed than oth­er LDAP servers, but the com­mands can be eas­i­ly adapt­ed to others.

Note: LDAP authen­ti­ca­tion is only sup­port­ed from MQ 8.0 onwards. Regard­less, if you have MQ 8.0 and want to use Active Direc­to­ry, you have to raise the com­mand lev­el of MQ to 802. To do this, just fol­low the fol­low­ing steps:

1. Stop the queue manager:
   end­mqm MQ01
2. Raise the CMDLEVEL of the queue manager
   str­mqm ‑e CMDLEVEL=802 MQ01
3. Start the queue manager
   str­mqm MQ01

So, just define an AUTHINFO object of type IDPWLDAP.

DEFINE AUTHINFO(USE.LDAP) AUTHTYPE(IDPWLDAP) DESCR(‘LDAP Authen­ti­ca­tion’) CHCKCLNT(REQUIRED) CHCKLOCL(NONE) ADOPTCTX(YES) FAILDLAY(10) LDAPUSER(‘tests.mq’) LDAPPWD(‘Tm@1234’) CONNAME(‘adserver’) SECCOMM(YES) SHORTUSR(‘sn’) CLASSUSR(‘user’) BASEDNU(‘ou=users,dc=addomain, dc=local’) USRFIELD(‘sAMAccountName’) GRPFIELD(‘cn’) CLASSGRP(‘group’) BASEDNG(‘ou=groups,ou=users,dc=addomain, dc=local’) FINDGRP(‘member’) AUTHORMD(SEARCHGRP) REPLACE

As you can see, there are lots more options in the IDPWLDAP authen­ti­ca­tion type. Lets go through all these parameters:

• ADOPTCTX: Whether to use the pre­sent­ed cre­den­tials as the con­text for this appli­ca­tion. This means that they are used for autho­riza­tion checks, shown on admin­is­tra­tive dis­plays, and appear in messages. 
  • YES
    The user ID pre­sent­ed in the MQCSP struc­ture, which has been suc­cess­ful­ly val­i­dat­ed by pass­word, is adopt­ed as the con­text to use for this appli­ca­tion. There­fore, this user ID will be the cre­den­tials checked for autho­riza­tion to use IBM MQ resources. If the user ID pre­sent­ed is an LDAP user ID, and autho­riza­tion checks are done using oper­at­ing sys­tem user IDs, the SHORTUSR asso­ci­at­ed with the user entry in LDAP will be adopt­ed as the cre­den­tials for autho­riza­tion checks to be done against.
  • NO
    Authen­ti­ca­tion will be per­formed on the user ID and pass­word pre­sent­ed in the MQCSP struc­ture, but then the cre­den­tials will not be adopt­ed for fur­ther use. Autho­riza­tion will be per­formed using the user ID the appli­ca­tion is run­ning under.
• FAILDLAY: spec­i­fy the delay used by MQ to noti­fy the appli­ca­tion of any failed authen­ti­ca­tion. This is to pre­vent the appli­ca­tion from ham­mer­ing MQ with failed con­nec­tion attempts.
• LDAPUSER: spec­i­fy the user for con­nect­ing to the Active Direc­to­ry (or LDAP) server.
• LDAPPWD: spec­i­fy the pass­word for the LDAPUSER.
• CONNAME: address of the Active Direc­to­ry (or LDAP) server
• SECCOMM: if this set­ting has an attribute of YES, SSL is used to con­nect to the Active Direc­to­ry (or LDAP) serv­er and also spec­i­fy the TCP port as being 636 (LDAPS); if it has the val­ue NO, no SSL will be used to con­nect and the TCP port is set to 389 (LDAP).
• SHORTUSR: spec­i­fy the LDAP attribute that con­tains the “short” user­name. This is nec­es­sary because MQ has a lim­it of 12 char­ac­ters on user­names. If you do not spec­i­fy this option, user­names longer than 12 char­ac­ters will be truncated.
• CLASSUSR: LDAP object class to use for user entries.
• BASEDNU: The base DN of the LDAP tree to use when search­ing for users.
• USRFIELD: The LDAP attribute to be used by MQ when search­ing for users; in Active Direc­to­ry, this is typ­i­cal­ly sAMAccountName.
• GRPFIELD: The LDAP attribute that con­tains the short group name. If this option is miss­ing, the full group DN must be used when spec­i­fy­ing groups in the set­mqaut com­mand line util­i­ty and the SET AUTHREC MQSC com­mand (more on these in anoth­er blog post — stay tuned). Typ­i­cal­ly, this must hasve the val­ue cn.
• CLASSGRP: The LDAP object class of groups.
• CLASSUSR: The LDAP object class of users. In Microsoft Active Direc­to­ry, this is typ­i­cal­ly user; for oth­er LDAP servers is typ­i­cal­ly inetOrg­Per­son.
• BASEDNG: The base DN of the LDAP tree to use when search­ing for groups.
• FINDGRP: The name of the attribute used with­in an LDAP entry to deter­mine group mem­ber­ship. The default val­ue depends on the val­ue of AUTHORMD.
  When AUTHORMD = SEARCHGRP, the FINDGRP attribute is typ­i­cal­ly set to mem­ber or unique­Mem­ber.
  When AUTHORMD = SEARCHUSR, the FINDGRP attribute is typ­i­cal­ly set to mem­berOf.
  When AUTHORMD = SRCHGRPSN, the FINDGRP attribute is typ­i­cal­ly set to mem­berUid. This only applies to MQ ver­sions 9.0.5 and above.
  When the FINDGRP attribute is left blank:
  • If AUTHORMD = SEARCHGRP, the FINDGRP attribute defaults to mem­berOf.
  • If AUTHORMD = SEARCHUSR, the FINDGRP attribute defaults to mem­ber.
  • If AUTHORMD = SRCHGRPSN, the FINDGRP attribute defaults to mem­berUid. This only applies to MQ ver­sions 9.0.5 and above.
• AUTHORMD: See expla­na­tion of the FINDGRP parameter.

Keep in mind that for an authen­ti­ca­tion of type IDPWLDAP, REQDADM and OPTIONAL are equiv­a­lent, as MQ makes no dis­tinc­tion between admin­is­tra­tive users and nor­mal ones. An user­name and pass­word are always request­ed and val­i­dat­ed, and are required to be cor­rect, that is, authen­ti­ca­tion must succeed.

Again, to use this authen­ti­ca­tion con­fig­u­ra­tion, issue the run­mqsc command:

ALTER QMGR CONNAUTH(USE.LDAP)

and restart the queue man­ag­er or issue the run­mqsc command:

REFRESH SECURITY TYPE(CONNAUTH)

That’s it. The next thing to do is to autho­rize users to use MQ by set­ting per­mis­sions (autho­riza­tions). This will be shown in part 3 of this arti­cle series.