CHLAUTH Maps a Service to mqm After an Audit
SECURE.QM has CHLAUTH enabled and uses TLS on channel CLAIMS.SVRCONN. The channel has SSLCAUTH(REQUIRED) and a certificate with CN=claimsapp. A legacy rule maps every client that presents a certificate to MCAUSER('mqm'): SET CHLAUTH(CLAIMS.SVRCONN) TYPE(USERMAP) SSLPEER('CN=*') USERSRC(MAP) MCAUSER('mqm'). The new application service account svc_claims connects with a client certificate and user ID svc_claims, and currently works only because it inherits mqm authority. An audit requires removing all mqm mappings and giving the service only put and inquire on CLAIMS.IN plus browse on CLAIMS.ERROR. The application team cannot change its user ID or certificate before the next release. The queue manager is shared by 12 other applications, so you cannot disable CHLAUTH or stop it. You must preserve connectivity and meet least privilege. The change must be reversible in minutes.
1. What does the legacy rule do, and why can you not simply remove it without a replacement?
Read the worked answer
DIS CHLAUTH(*) on SECURE.QM will show the legacy rule. The rule is dangerous because SSLPEER('CN=*') matches any certificate and MCAUSER('mqm') gives every matching client full administrative authority. The application works only because it is silently running as mqm. Removing the rule without a replacement will break connectivity and produce 2035, but leaving it fails the audit. Also check the rule order: a broad rule earlier in the list can pre-empt a later specific rule, so the fix must be validated with DIS CHLAUTH(CLAIMS.SVRCONN) after the change.
2. How do you replace the mqm mapping with least-privilege access for svc_claims?
Read the worked answer
Create a specific rule for the application certificate and map it to the service ID, not mqm: SET CHLAUTH(CLAIMS.SVRCONN) TYPE(USERMAP) SSLPEER('CN=claimsapp') USERSRC(MAP) MCAUSER('svc_claims'). Remove or narrow the legacy CN=* rule so no client inherits mqm. Then grant only the required object authority: setmqaut -m SECURE.QM -t q -n CLAIMS.IN -p svc_claims +put +inq and setmqaut -m SECURE.QM -t q -n CLAIMS.ERROR -p svc_claims +browse +inq. Refresh the authorization service with REFRESH SECURITY(*) TYPE(AUTHSERV). If CONNAUTH is enabled, confirm whether the channel uses adopted or verified user IDs; do not add a password requirement the client cannot meet before the next release. Keep CHLAUTH enabled throughout.
3. How do you verify the change and keep a safe rollback that does not restore mqm authority?
Read the worked answer
Test with the application's certificate from a controlled client, then check DIS CHLAUTH(*) and dspmqaut -m SECURE.QM -t q -n CLAIMS.IN -p svc_claims to prove the effective authority. Confirm that svc_claims cannot browse a queue it should not see, and that no rule maps it to mqm. For rollback, keep the exact previous rule text, but do not re-enable mqm mapping as the rollback; instead have a second specific rule ready or a temporary dedicated ID with the same limited authority. Record the change in the runbook and add a periodic check that no CHLAUTH rule uses MCAUSER('mqm') with a wildcard SSLPEER.