MQAUSX Explained or Better Explained

June 1, 2018 Roger Lacroix

Every once in a while, I get requests to explain what/how MQ Authenticate User Security Exit (MQAUSX) and/or MQ Authenticate User Security Exit for z/OS (z/MQAUSX) work.

    Client-side perspective:

  • If the client application is configured with the MQAUSX client-side security exit then the user credentials are encrypted and sent to the remote queue manager. This is the best level of security.
  • If the client application is not configured with the client-side security exit and both the client-side AND server-side are at MQ V8 or higher then MQ V8 (or higher) will encrypt the user credentials as they flow from the client application to the queue manager. Note: There has been a lot of discussions about the effectiveness of MQ encrypting the user credentials. Even IBM’s position has changed and they do not recommend using MQ user credential encryption for production environments.
  • If the client application is not configured with the client-side security exit then the user credentials are sent in plain text to the remote queue manager. This feature is available for Java/JMS, Java and C# DotNet client applications. For native applications (i.e. C/C++), then the application must use and populate the MQCSP structure with the UserID and Password.
  • If the MQAdmin sets the MQAUSX IniFile parameter NoAuth to Y then it functions just like MQSSX. MQSSX does not authenticate. It filters the incoming connection based on UserID, IP address, hostname and/or SSL DN.
    MQAUSX server-side can authenticate user credentials against the following targets:

  • Server’s native OS system (Local OS)
  • Remote LDAP server
  • Microsoft’s Active Directory
  • Quest Authentication Services* (QAS) aka Vintela Authentication Services* (VAS)
  • Centrify’s DirectControl*
  • PAM* (Pluggable Authentication Module)
  • An encrypted MQAUSX FBA file (similar to /etc/passwd file).

*Linux and Unix only.

Capitalware recommends disabling both CONNAUTH and CHLAUTH and using the features of MQAUSX to perform filtering, authentication and setting of the connection’s UserId (which will be used by MQ’s OAM to perform authorization).

The MQAdmin can have some channels authenticate the user credentials against an LDAP server and other channels, of the same queue manager, authenticate against the Local OS, AND even other channels go against other target authentication mechanisms. With CONNAUTH, you can only configure 1 target per queue manager.

    The sequence of events that MQAUSX server-side component goes through for each connection request:

  • Perform Maximum Connections per Channel (MCC) check if enabled
  • Perform AllowHostname, AllowHostByName, AllowIP & AllowSSLDN checks (that are enabled)
  • Perform RejectHostname, RejectHostByName, RejectIP & RejectSSLDN checks (that are enabled)
  • Request information from MQAUSX client-side security exit when in use or if no client-side security exit then wait for MQ to invoke the exit with user credentials
  • Perform Queue Manager Password check if enabled
  • Perform Self-Signed Certificate check if enabled
  • Perform Allowmqm & AllowBlankUserID checks if enabled
  • Perform AllowUserID check if enabled
  • Perform RejectUserID check if enabled
  • Perform Group check if enabled
  • If Credential Cache is enabled then check cache otherwise perform authentication (if cache entry has expired then perform authentication)

      • Setting the UserId for connection:

    • Set it to the UserId used for authentication (default)
    • Set it to the value in the channel’s MCAUSER field (see UseMCAUser)
    • z/OS only – If UseSSLCertUserID is set then the value in the channel’s SSLCertUserid field will be used
    • Set it to the UserId from the SSL Certifcate (see UseSSLUserIDFromDN)
    • Set it to the UserId from the LDAP ANR (see ExtractUserIDFromANR)
    • Perform Proxy look up if enabled and set it to the Proxy UserId (see UseProxy)

  • If CheckFinalUserID is enabled, recheck the UserID against Allowmqm, AllowUserID & RejectUserID

If everything is correct then MQAUSX server-side component will set the connection’s UserId and a log entry will be written to the LogFile. Here is an example of a successful connection:

Connection accepted for MCA_UID='tester' UserID='tester' UserSpecifiedServer='' QMgr='MQWT1' ChlName='TEST.EXIT' ConName='10.10.10.10' Server='' RemoteUserID='roger'
    where:

  • MCA_UID is the UserId that is set by MQAUSX and will be used for the connection
  • UserID is the UserId that was authenticated
  • UserSpecifiedServer is the MS AD server name specified by the user, if allowed**
  • QMgr is the queue manager name
  • ChlName is the channel name for this connection
  • ConName is the client IP address
  • Server is the MS AD server used for authentication**
  • RemoteUserID is the UserId that the client application is actually running under

** Windows only.

If the incoming connection fails any filter, authentication or other feature then MQAUSX server-side component will immediately close the channel and write log entry to the LogFile. Here is an example of a failed connection attempt:

Connection failed for UserID='tester' UserSpecifiedServer='' QMgr='MQWT1' ChlName='TEST.EXIT' ConName='10.10.10.10' Server='' RemoteUserID='roger'

Finally, Capitalware offers free 60-day trials of both MQAUSX and z/MQAUSX which includes free support (no strings attacehd). If you interesting in trying it out, please send an email to support@capitalware.com to request a trial of MQAUSX or z/MQAUSX.

Regards,
Roger Lacroix
Capitalware Inc.

This entry was posted in Capitalware, IBM i (OS/400), IBM MQ, Linux, MQ Authenticate User Security Exit, Security, Unix, Windows, z/OS.

Comments are closed.