CONNAUTH is the queue manager switch that turns on structured connection authentication for IBM MQ. Before CONNAUTH became central to security guidance, many estates allowed anonymous or implicit OS-user connections that auditors now reject. Today ALTER QMGR CONNAUTH(name) points at an AUTHINFO object—IDPWOS for a managed password file, IDPWLDAP for directory bind, or configurations your release supports—that validates userid and password or complements certificate presentation. CONNAUTH runs at connect time: failed authentication means MQCONNX never reaches MQOPEN, which is different from 2035 after a successful bind. This tutorial explains how CONNAUTH relates to AUTHINFO, ADOPTCTX and user adoption, CHCKCLNT interaction with TLS, enabling CONNAUTH in lab and production, rolling migration without locking out batch jobs, common AMQ errors in logs, and how CONNAUTH hands identity to OAM and CHLAUTH for the next layers.
DEFINE AUTHINFO creates the ruleset; ALTER QMGR CONNAUTH selects which ruleset is active. Only one CONNAUTH name is active per queue manager at a time. Switching CONNAUTH from OS to LDAP changes behavior for every new connection—schedule change windows. AUTHINFO attributes include CONNAME for LDAP host and port, LDAPUSER and LDAPPWD for the queue manager's bind account to the directory, CHCKCLNT for whether client certificates are required or optional, and AUTHTYPE that must match the intended mechanism.
| Attribute | Role | Beginner note |
|---|---|---|
| CONNAUTH | Names active AUTHINFO | Required for explicit auth policy |
| ADOPTCTX | Adopt client user ID | Affects OAM principal |
| CHCKCLNT | On AUTHINFO—client cert policy | REQUIRED vs OPTIONAL vs ASQMGR |
| SSLCAUTH | Channel TLS client auth | Related but channel-level |
| CERTLABL | Certificate label for QM | TLS with CONNAUTH certs |
123456DEFINE AUTHINFO('LAB.IDPWOS') AUTHTYPE(IDPWOS) DESCR('Lab passwords') ALTER QMGR CONNAUTH(LAB.IDPWOS) DISPLAY QMGR CONNAUTH ADOPTCTX * Add test user per IBM IDPWOS admin procedure for your release * Client: connect with userid/password on SVRCONN * Verify failed password rejected before MQOPEN
Create a dedicated test queue manager—never experiment on production. Add at least one known-good application user before enforcing CONNAUTH in production. Document the break-glass admin path: how operators connect if LDAP is down. Some sites maintain a local IDPWOS AUTHINFO as fallback with CONNAUTH switch procedure in the runbook.
DEFINE AUTHINFO AUTHTYPE(IDPWLDAP) with corporate LDAP URL, service bind DN, and optional TLS to directory. Clients present application userid and password; queue manager binds to LDAP to validate. Lockout and password expiry policies flow from the directory. See ldap-authentication tutorial for attribute detail and firewall rules between MQ hosts and directory tiers.
When ADOPTCTX(YES), successful authentication may cause subsequent OAM checks to use the client-asserted user ID—useful when each application has its own ID and grants. When NO, SVRCONN MCAUSER or CHLAUTH mapping may override. Mismatch between developer expectation and ADOPTCTX produces “LDAP said yes but puts use mqsvc” confusion. Align CONNAUTH, ADOPTCTX, CHLAUTH USERMAP, and setmqaut on the same principal in design documents.
Mutual TLS can authenticate the client by certificate while CONNAUTH still enforces password policy if CHCKCLNT and AUTHINFO require it. Some designs use certificate-only with CHLAUTH SSLPEERMAP and minimal password use. Cipher and protocol version must match on SVRCONN and listener. Certificate expiry without renewal surfaces as connection failures mistaken for CONNAUTH password errors—check GSKit and label configuration.
CONNAUTH is mandatory check-in at the lobby desk. Without it, visitors might walk to floors unchallenged. CHLAUTH is the elevator bank that only goes to approved floors after check-in.
CONNAUTH is the rule that everyone must tell the guard a password before using the treehouse ladder—even if they know which box they want.
Write MQSC to point CONNAUTH at a new LDAP AUTHINFO.
Explain ADOPTCTX YES versus NO for a shared SVRCONN.
List differences between connect failure and 2035 after connect.
1. CONNAUTH names:
2. CONNAUTH handles:
3. CHLAUTH handles:
4. ALTER QMGR CONNAUTH changes: