User ID and Password Authentication

User ID and password authentication is how most distributed IBM MQ client applications prove who they are before the queue manager allows MQOPEN, MQPUT, or MQGET. Unlike mainframe RACF logons that happen outside MQ, the queue manager receives credentials on the connect path—typically through MQCSP on MQI clients or SecurityParms on JMS—and validates them against an AUTHINFO repository configured by CONNAUTH. When authentication succeeds, OAM later decides what that identity may do. When it fails, the connection never reaches useful messaging APIs. Beginners often enable TLS and still see anonymous-looking behavior because the client never sent a password, or they fix passwords but hit 2035 on put because grants were never added. This tutorial explains the end-to-end connect flow, how userid/password differs from channel MCAUSER, IDPWOS versus LDAP backends, client configuration patterns, ADOPTCTX interaction, common failure modes, and how to test authentication separately from authorization.

Where Authentication Happens in the Connect Flow

An application calls MQCONNX (or equivalent) with connection options that include security parameters. The queue manager listener accepts TCP, negotiates TLS if configured, then runs connection authentication if CONNAUTH is set. The AUTHINFO object named by CONNAUTH defines whether validation uses the local OS password file (IDPWOS) or LDAP (IDPWLDAP). Only after a successful bind does the queue manager associate a user context for subsequent OAM checks. Channel-initiated flows on SVRCONN use the same CONNAUTH path when clients supply passwords; batch jobs using bindings may use the OS user without MQCSP depending on platform and configuration.

MQCSP and Client Configuration

MQCSP (MQ Connection Security Parameters) is the MQI structure that carries AuthenticationType, UserId, and Password. JMS applications set user and password on the connection factory. .NET clients set equivalent properties on MQCSP or connection properties per IBM documentation for the release. If the client library omits CSP while the queue manager requires CONNAUTH, connect fails or falls back to behavior documented for your version—never assume silent success. Enable client tracing to confirm the userid sent matches what security administrators granted in OAM—case and domain suffix mismatches are frequent.

1
2
3
4
5
6
7
* Queue manager side (conceptual lab):
DEFINE AUTHINFO('CONN.AUTH') AUTHTYPE(IDPWOS)
ALTER QMGR CONNAUTH('CONN.AUTH')
ALTER QMGR CHLAUTH(ENABLED)
* Application must connect with MQCSP user/password matching IDPWOS entry
* After connect succeeds, grant OAM separately:
setmqaut -m QM1 -n APP.IN -t q -p myapp +put +connect

IDPWOS Versus LDAP for Password Checks

IDPWOS stores passwords in an MQ-maintained repository on the queue manager host—suitable for labs, break-glass accounts, or small estates. IDPWLDAP delegates validation to corporate directory; MQ does not store end-user passwords, only the service bind for directory queries. Production userid/password authentication almost always means LDAP plus TLS to the directory and to MQ. Password policy—length, rotation, lockout—lives in the directory for LDAP and in operational runbooks for IDPWOS. See the IDPWOS and LDAP authentication tutorials for attribute-level DEFINE AUTHINFO detail.

Explainer: Showing ID at the Security Desk

Think of CONNAUTH as the security desk at the building entrance. Userid and password are your badge check. OAM on each floor is a separate guard who checks whether your badge level allows you into a specific room. Passing the lobby does not automatically let you open every door.

ADOPTCTX and the Effective User ID

ALTER QMGR ADOPTCTX(YES) tells the queue manager to use the authenticated client userid for OAM after successful CONNAUTH. ADOPTCTX(NO) may leave authority evaluation on MCAUSER from the channel definition—common when all clients share one SVRCONN but map to different users via CHLAUTH USERMAP rules. Misalignment between the userid you authenticated and the userid OAM checks produces “LDAP said yes but puts run as mqsvc” incidents. Document ADOPTCTX, CHLAUTH mapping, and setmqaut principals on one architecture diagram per environment.

SVRCONN Channels and Password Authentication

• DEFINE CHANNEL(... ) CHLTYPE(SVRCONN) TRPTYPE(TCP) — clients connect here.
• MCAUSER on SVRCONN may be a default service ID when ADOPTCTX is NO.
• CHCKCLNT and CHCKCLNTLOCAL on AUTHINFO control whether the client must supply a password.
• TLS on the channel protects the password on the wire; CONNAUTH validates it.

Sharing one SVRCONN among many applications with a single MCAUSER defeats per-user auditing unless CHLAUTH maps certificates or usernames to distinct principals. Userid/password authentication shines when each application connects with its own ID and receives least-privilege OAM grants.

Troubleshooting Authentication Failures

1. Confirm ALTER QMGR CONNAUTH is not blank and AUTHINFO exists.
2. Verify client sends MQCSP (trace or sample program).
3. Test the same userid/password with ldapsearch or platform tools from the MQ host for LDAP.
4. Read AMQERR01 on the queue manager at connect time for auth service errors.
5. After connect works, use dspmqaut if 2035 appears on MQOPEN or MQPUT.
6. Check account lockout in the directory after repeated failed tests.

Security Practices for Password Authentication

Never transmit passwords without TLS on production networks. Rotate service bind passwords for LDAP on the same schedule as other infrastructure credentials. Avoid embedding passwords in source code—use secret stores and connection factories configured at deploy time. Separate human operator IDs from application service IDs in OAM grants. Audit CONNAUTH and AUTHINFO changes through change management. For z/OS, userid/password at the MQ layer may integrate with RACF; distributed concepts still apply but commands differ—coordinate with the mainframe security team.

Explain Like I'm Five: User ID and Password

Before you can play in the MQ playground, you tell the guard your name and secret word. The guard checks a list. If the word is wrong, you never get in. If the word is right, you still need a ticket for each ride—that is authorization.

Practice Exercises

Exercise 1

Draw a sequence diagram: MQCONNX with MQCSP, CONNAUTH, AUTHINFO, OAM on MQOPEN.

Exercise 2

List three differences between authenticating appuser and using MCAUSER mqbridge on a sender channel.

Exercise 3

Your team sees 2035 at connect. Write five checks before opening an OAM ticket.

Frequently Asked Questions

Test Your Knowledge