IDPWOS—identity password operating system repository—is the IBM MQ AUTHINFO type that stores connection passwords in a queue-manager-local repository maintained by MQ tooling rather than in your corporate LDAP. When ALTER QMGR CONNAUTH points at an AUTHINFO defined with AUTHTYPE(IDPWOS), client applications must present a userid and password that the queue manager validates against that repository before MQOPEN succeeds. IDPWOS is ideal for training labs, proof-of-concept queue managers, disaster-recovery fallback when directory services are unavailable, and small integrations with a handful of service accounts. It is a poor primary store for thousands of human passwords that already live in Active Directory. This tutorial explains DEFINE AUTHINFO IDPWOS, pairing with CONNAUTH, adding and removing users per platform procedures, password policy limitations compared to LDAP, CHCKCLNT interaction, migrating from IDPWOS to LDAP, security cautions about file permissions on the repository, and troubleshooting “invalid userid/password” when OAM grants were never the problem.
The flow is linear: client MQCONNX with optional security credentials, queue manager reads CONNAUTH name, loads AUTHINFO IDPWOS definition, compares presented password to stored hash or secret in the repository, returns success or connection error. No LDAP network hop occurs—latency is low but operational burden of password rotation falls on MQ administrators unless scripted. After success, ADOPTCTX and CHLAUTH determine the OAM principal.
| Aspect | IDPWOS | IDPWLDAP |
|---|---|---|
| Credential store | MQ OS repository file | Corporate LDAP |
| Scale | Small user count | Enterprise directories |
| Password policy | MQ admin discipline | Directory lockout/expiry |
| Network dependency | None for auth | LDAP reachability |
| Typical use | Lab, DR fallback | Production clients |
12345DEFINE AUTHINFO('QM1.IDPWOS') AUTHTYPE(IDPWOS) + DESCR('Local password repository for lab') ALTER QMGR CONNAUTH(QM1.IDPWOS) DISPLAY AUTHINFO('QM1.IDPWOS') ALL DISPLAY QMGR CONNAUTH
DESCR is documentation only. No LDAP CONNAME appears on IDPWOS objects. After ALTER QMGR, existing connections may continue until disconnect; new connections use IDPWOS. Add users using IBM's platform-specific password command before testing—empty repository rejects all logins.
On Linux distributed MQ, administrators traditionally use the mqpasswd utility or successor documented for the release to add, change, and delete users in the repository. Windows has parallel tooling. Procedures differ from setmqaut: password commands manage authentication identity; setmqaut manages authorization after identity is known. Document which team owns each. Rotating a password requires updating both client configuration and repository entry—missing the client side looks like intermittent failure after successful admin update.
MQRC_NOT_AUTHORIZED at connect with authentication comments in AMQ logs often means wrong password or unknown user in IDPWOS—not missing +put. MQRC_Q_MGR_NOT_AVAILABLE is different—queue manager down. Client API must pass security connection fields—Java and .NET have explicit flags; missing flag sends no password while server expects one. Channel MCAUSER does not substitute for client password on SVRCONN when CONNAUTH requires it.
IDPWOS is a notebook at the door listing allowed names and secret handshakes. LDAP is calling headquarters to verify every visitor. The notebook is fast for a small club but impossible for a stadium.
IDPWOS is when the treehouse guard keeps their own list of secret passwords in a notebook instead of calling parents to check.
Write MQSC to create IDPWOS AUTHINFO and enable CONNAUTH.
When would you keep IDPWOS as DR fallback while LDAP is primary?
Connect fails—prove whether failure is IDPWOS or OAM in three steps.
1. IDPWOS AUTHTYPE means:
2. IDPWOS is activated via:
3. Enterprise scale often prefers:
4. Lab use case for IDPWOS: