Authentication Info Objects

Authentication information objects (AUTHINFO) are where IBM MQ stores the knobs for who may connect and whether partner TLS certificates are still trustworthy. Instead of scattering LDAP URLs, password policies, and CRL server names across dozens of channels, administrators DEFINE AUTHINFO once and wire the queue manager CONNAUTH or SSLCRLNL to those names. Beginners meet AUTHINFO during first secure client setup, MQIPT migrations, and certificate renewal projects. This page explains each major AUTHTYPE, how CONNAUTH adopts user IDs, how revocation namelists work, differences between IDPWOS and IDPWLDAP, operational DISPLAY commands, and mistakes that cause 2035 Not authorized or SSL handshake failures.

AUTHINFO in the Security Model

IBM MQ security has layers: transport (TLS), authentication (CONNAUTH / AUTHINFO), and authorization (OAM, AUTHREC, CHLAUTH). AUTHINFO belongs to authentication—proving identity at connect. After connect, the queue manager checks whether that principal may access the queue, channel, or topic. Skipping AUTHINFO while enabling CHLAUTH still leaves gaps if anonymous binds are possible on your platform. Modern hardening enables CONNAUTH on all queue managers, restricts ADOPTCTX behavior, and pairs with LDAP or OS authentication.

Explainer: CONNAUTH and ADOPTCTX

When a client connects with a user ID, CONNAUTH runs the AUTHINFO mechanism—bind to LDAP, verify password, or consult OS. CHCKCLNT and related attributes control whether the client must supply a password and whether the queue manager adopts the presented user as the connection identity (ADOPTCTX). Misunderstanding adoption causes classic 2035 errors: the client thinks it is user APP1 but the queue manager runs as mqm. DISPLAY QMGR CONNAUTH shows the active AUTHINFO name. Changing CONNAUTH is a controlled change: test in lower environments, plan for brief reconnects, and keep a break-glass admin path documented.

IDPWLDAP Attributes (Conceptual)

CONNAME holds the LDAP server host and port, for example ldap.corp.example.com(389) or ldaps port 636. LDAPUSER and LDAPPWD (or sealed credentials) bind the queue manager to the directory. BASEDN and attribute names map MQ user IDs to directory entries—exact attribute names vary by schema; follow IBM MQ examples for your directory type. SECCOMM(N) may allow simple binds on lab systems; production uses TLS to LDAP. Failed binds appear in AMQERR and LDAP server logs, not always in the client message.

IDPWOS

IDPWOS delegates authentication to the OS or external security manager familiar on single-server labs. Enterprise estates usually move to LDAP for central accounts. IDPWOS remains useful for isolated queue managers or when OS accounts mirror service IDs. Compare maintenance: OS local users scale poorly across hundreds of QMs; LDAP scales but adds network dependency.

CRLLDAP, OCSP, and SSLCRLNL

TLS without revocation checking accepts certificates that were valid when issued but later revoked. DEFINE AUTHINFO(AUTHTYPE(CRLLDAP)) with CONNAME pointing at the LDAP server that hosts CRLs lets MQ download revocation data. OCSP AUTHINFO types query responders for faster status. Place all revocation AUTHINFO names in a namelist; ALTER QMGR SSLCRLNL(namelist). During handshake, MQ checks the partner cert chain against those definitions. Missing CRL config can mean revoked certs still connect—auditors flag it. Overly aggressive CRL failure modes can stop all TLS if LDAP is down—design HA for directory and OCSP.

Tutorial: Lab CONNAUTH and CRL Namelist

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
DEFINE AUTHINFO('QM1.LDAP.AUTH') REPLACE +
  AUTHTYPE(IDPWLDAP) +
  CONNAME('ldap.lab.example.com(389)') +
  LDAPUSER('cn=mqbind,ou=svc,dc=lab,dc=example,dc=com') +
  LDAPPWD('secret') +
  CHCKCLNT(REQDADM) DESCR('Lab LDAP CONNAUTH')
ALTER QMGR CONNAUTH(QM1.LDAP.AUTH)
REFRESH SECURITY TYPE(CONNAUTH)
* CRL example (public CRL on LDAP):
DEFINE AUTHINFO('CORP.CRL1') REPLACE +
  AUTHTYPE(CRLLDAP) CONNAME('ldap.lab.example.com(389)')
DEFINE NAMELIST('SSL.CRL.LIST') NAMES(CORP.CRL1)
ALTER QMGR SSLCRLNL(SSL.CRL.LIST)
DISPLAY AUTHINFO(*) AUTHTYPE
DISPLAY QMGR CONNAUTH SSLCRLNL

Operational Commands

• DISPLAY AUTHINFO(name) ALL — verify attributes before go-live.
• ALTER AUTHINFO — rotate LDAP bind password during maintenance.
• REFRESH SECURITY TYPE(CONNAUTH) — apply CONNAUTH changes without restart where supported.
• DISPLAY QMGR CONNAUTH SSLCRLNL — confirm queue manager pointers.
• Test with amqscnc or client with wrong password — expect clear failure, not hang.

Explain Like I'm Five: AUTHINFO

Before you enter the building, security checks your badge (authentication info). The badge reader settings—which computer to ask, whether guest badges work—live in one configuration file (AUTHINFO), not taped to every door (channel). CHLAUTH is the list of which doors you may use after your badge works.

Practice Exercises

Exercise 1

Document steps to switch CONNAUTH from IDPWOS to IDPWLDAP with rollback plan.

Exercise 2

Two corporate CAs each publish CRLs to different LDAP paths. Draw DEFINE AUTHINFO and namelist structure.

Exercise 3

Clients get SSL handshake success but 2035 on MQOPEN. Why might CONNAUTH and CHLAUTH both be involved?

Frequently Asked Questions

Test Your Knowledge