IBM Support

IT20275: USERMAP CHLAUTH rules and ChlauthEarlyAdopt do not map to the correct user

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

 

APAR status

  • Closed as program error.

Error description

  • If ChlauthEarlyAdopt is enabled and the AUTHINFO ADOPTCTX
    attribute is set to YES then any USERMAP channel authentication
    rules is ignored and the final adopted MCAUSER is the user
    supplied by connecting client applications in the MQCSP
    structure.
    

Local fix

  • None available
    

Problem summary

  • ****************************************************************
    USERS AFFECTED:
    Any users using USERMAP channel authentication rules while
    ADOPTCTX is set to YES and CHLAUTHEARLYADOPT is enabled.
    
    
    Platforms affected:
    MultiPlatform
    
    ****************************************************************
    PROBLEM DESCRIPTION:
    Certain combinations of ADOPTCTX, USERMAP and EARLYADOPT
    settings would cause an incorrect MCAUSER to be used.
    
    The MQ code for adopting users based on the ADOPTCTX, USERMAP
    and EARLYADOPT settings was incorrectly adopting the wrong user.
    

Problem conclusion

  • The MQ code has been corrected to adopt the correct user for
    each combination of ADOPTCTX, USERMAP and ChlAuthEarlyAdopt
    settings where it was incorrect. This has brought LTS releases
    behaviour in line with the MQ v9.0.5 continuous delivery release
    behaviour.
    
    The following scenarios are changed:
    
    ------------------------------------------
    
    USERMAP channel authentication rules
    
    For example:
    - The following rule is configured: SET CHLAUTH(CHANNEL.NAME)
    TYPE(USERMAP) CLNTUSER('cspuser') MCAUSER('mapuser')
    - ChlAuthEarlyAdopt is set to Y in the qm.ini file
    - AdoptCTX is set to YES on the active CONNAUTH AUTHINFO object
    - The connecting client application provides cspuser as client
    user ID (in the MQCSP flow) to be evaluated by CONNAUTH
    
    Before this change, "cspuser" was adopted incorrectly. After
    this change "mapuser" is adopted as expected.
    
    To revert to the previous behavior, set ChlAuthEarlyAdopt=N in
    the qm.ini file.
    
    ------------------------------------------
    
    ADDRESSMAP/SSLPEERMAP channel authentication rules
    
    For example:
    - The following rule is configured: SET CHLAUTH(CHANNEL.NAME)
    TYPE(ADDRESSMAP) ADDRESS('*') MCAUSER('mapuser') [ or
    TYPE(SSLPEERMAP) ]
    - ChlAuthEarlyAdopt is set to Y in the qm.ini file
    - AdoptCTX is set to YES on the active CONNAUTH AUTHINFO object
    - The connecting client application provides "cspuser" as client
    user ID (in the MQCSP flow) to be evaluated by CONNAUTH
    
    Before this change, "cspuser" was adopted incorrectly. After
    this change "mapuser" is adopted as expected.
    
    To revert to the previous behavior:
    - set ChlAuthEarlyAdopt=N in the qm.ini file.
    OR
    -  Specify USERSRC(channel) instead of the MCAUSER attribute on
    the chlauth rule. This is functionally equivalent to removing
    the rule if ChlAuthEarlyAdopt=Y
    
    ------------------------------------------
    
    BLOCKUSER  channel authentication rules (multiple scenarios are
    affected)
    
    Scenario 1
    For example:
    - The following rule is configured: SET CHLAUTH(CHANNEL.NAME)
    TYPE(BLOCKUSER) USERLIST('user')
    - There is no MCAUSER value set on the SVRCONN channel
    definition
    - ChlAuthEarlyAdopt is set to N in the qm.ini file
    - AdoptCTX is set to YES on the active CONNAUTH AUTHINFO object
    - The connecting client application is running as "user" (the
    user ID supplied in the MQCSP flow is not relevant)
    
    Before this change, "user" was adopted incorrectly. After this
    change, the connection is blocked.
    
    To revert to the previous behavior:
    - set ChlAuthEarlyAdopt=Y in the qm.ini file.
    OR
    - Remove the CHLAUTH BLOCKUSER rule.
    
    -
    
    Scenario 2
    For example:
    - The following rule is configured: SET CHLAUTH(CHANNEL.NAME)
    TYPE(BLOCKUSER) USERLIST('user')
    - MCAUSER('channeluser') is set on the SVRCONN channel
    definition
    - ChlAuthEarlyAdopt is set to Y in the qm.ini file
    - AdoptCTX is set to NO on the active CONNAUTH AUTHINFO object
    - The connecting client application is running as "user" (the
    user ID supplied in the MQCSP flow is not relevant)
    
    Before this change, "channeluser" was adopted incorrectly. After
    this change, the connection is blocked.
    
    To revert to the previous behavior:
    - set ChlAuthEarlyAdopt=N in the qm.ini file.
    OR
    - Define a rule of TYPE(USERMAP) to map "user" to "channeluser"
    
    -
    
    Scenario 3
    For example:
    - The following rule is configured: SET CHLAUTH(CHANNEL.NAME)
    TYPE(BLOCKUSER) USERLIST('cspuser')
    - MCAUSER('channeluser') is set on the SVRCONN channel
    definition
    - ChlAuthEarlyAdopt is set to Y in the qm.ini file
    - AdoptCTX is set to NO on the active CONNAUTH AUTHINFO object
    - The connecting client application is running as "user"
    - The connecting client application provides "cspuser" as client
    user ID (in the MQCSP flow) to be evaluated by CONNAUTH
    
    Before this change, "channeluser" was adopted incorrectly. After
    this change "user" is adopted as expected.
    
    To revert to the previous behavior:
    - set ChlAuthEarlyAdopt=N in the qm.ini file.
    OR
    - Define a rule of TYPE(USERMAP) to map "user" to "channeluser"
    
    ---------------------------------------------------------------
    The fix is targeted for delivery in the following PTFs:
    
    Version    Maintenance Level
    v8.0       8.0.0.10
    v9.0 LTS   9.0.0.5
    
    The latest available maintenance can be obtained from
    'WebSphere MQ Recommended Fixes'
    http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006037
    
    If the maintenance level is not yet available information on
    its planned availability can be found in 'WebSphere MQ
    Planned Maintenance Release Dates'
    http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006309
    ---------------------------------------------------------------
    

Temporary fix

Comments

APAR Information

  • APAR number

    IT20275

  • Reported component name

    IBM MQ BASE M/P

  • Reported component ID

    5724H7261

  • Reported release

    902

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2017-04-19

  • Closed date

    2018-06-20

  • Last modified date

    2018-06-20

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

  • Fixed component name

    IBM MQ BASE M/P

  • Fixed component ID

    5724H7261

Applicable component levels

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"902","Edition":"","Line of Business":{"code":"LOB36","label":"IBM Automation"}}]

Document Information

Modified date:
20 June 2018