MQ

MQ

Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

  • 1.  mapping client user to local user

    Posted Wed April 09, 2025 05:47 AM

    Hello all

    I have an application that runs on a Windows App Server and uses a client channel. This app identifies itself in qmgr with the user running the app server, eg."wasserver". This "wasserver" does not exist on the windows box. Can I ignore this user, and use a CHLAUTH rule to map this user to an existing user, eg. "appuser"? With SSL certificates it would be possible, but for now I won't use it.

    Qmgr is using default  CONNAUTH('SYSTEM.DEFAULT.AUTHINFO.IDPWOS')

    Thanks!



    ------------------------------
    Joao Ramires
    ------------------------------


  • 2.  RE: mapping client user to local user

    Posted Wed April 09, 2025 12:43 PM
    Edited by Morag Hughson Wed April 09, 2025 12:43 PM

    Yes, you can assert a user id to be used using CHLAUTH based on three different things. You rightly point out that you can do this with with a certificate Distinguished Name (DN), but you can also do it based on an IP address or a client asserted user id (or both in fact).Doing this is just a mapping - nothing is being authenticated when you do this and so anyone with the same user ID could take advantage.

    You mention that you are using CONNAUTH too. The other way you can change the user ID, would be to use a user ID and password on your connection from machine with the wasserver user ID, where the user ID and password provided do exist on the Windows box, and make sure that the settings in SYSTEM.DEFAULT.AUTHINFO.IDPWOS are configured for ADOPTCTX(YES).

    Cheers,
    Morag



    ------------------------------
    Morag Hughson
    MQ Technical Education Specialist
    MQGem Software Limited
    Website: https://www.mqgem.com
    ------------------------------

    Original Message


  • 3.  RE: mapping client user to local user

    Posted Wed April 09, 2025 05:38 PM
    Thank you Morag,
    that's also my understanding, what I don't understand is the queue manager giving 2035 to the user wasserver.
    I don't have wasserver user defined on the windows box, but user joao is.
    i'm using ADOPTCTX(YES) , message I have is the one that follows. 
    AMQ9557E: Queue Manager User ID initialization failed for 'wasserver'.
    EXPLANATION:
    The call to initialize the User ID 'wasserver' failed with CompCode 2 and Reason
    2035. If an MQCSP block was used, the User ID in the MQCSP block was
    'joao'. If a userID flow was used, the User ID in the UID header was
    'wasserver' and any CHLAUTH rules applied prior to user adoption were evaluated
    case-sensitively against this value.


    ------------------------------
    Joao Ramires
    ------------------------------

    Original Message


  • 4.  RE: mapping client user to local user

    Posted Wed April 09, 2025 07:51 PM

    Hi Joao,

    Hmm, that's interesting.

    I can see that you are indeed sending a user ID and password in, since the error message says:-

    If an MQCSP block was used, the User ID in the MQCSP block was 'joao'.

    And I can see what I assumed was the case before, that the 'wasserver' user id is the logged on user id on the client side and is being flowed to the queue manager as part of the client protocol, since the error message says:-

    If a userID flow was used, the User ID in the UID header was 'wasserver'

    Ignoring the client flowed user ID is what the ADOPTCTX(YES) configuration is supposed to do.

    Is there any possibility that the ADOPTCTX(YES) setting was recently changed and the queue manager has neither been restarted nor refreshed since that changed was made?

    If you issue the following command:-

    REFRESH SECURITY TYPE(CONNAUTH)

    and retry the connection, is there any difference to the way it behaves?

    Cheers,
    Morag



    ------------------------------
    Morag Hughson
    MQ Technical Education Specialist
    MQGem Software Limited
    Website: https://www.mqgem.com
    ------------------------------

    Original Message


  • 5.  RE: mapping client user to local user

    Posted Thu April 10, 2025 04:41 AM

    I did several REFRESH SECURITY , no success 

    The 2035 is strange unexpected, it doesn't say why, what is failing: if a connect to the queue manager or other operation 

    I'll try the same test, defining 'wasserver' user as a local user on the windows box.



    ------------------------------
    Joao Ramires
    ------------------------------

    Original Message


  • 6.  RE: mapping client user to local user

    Posted Thu April 10, 2025 12:42 PM

    It is failing to look up that user id on the local box. That is what is failing.

    The queue manager needs to know the group memberships and the S-ID of the user ID. So it looks it up in the O/S. In your environment, the user Id doesn't exist so you get the error message you saw.

    The question though is, why did it need to look it up? Why is it not using the adopted MQCSP user ID?

    If you define it as a local user, then certainly this error message should go away, and perhaps then it will become clear where it is being used.

    Cheers,
    Morag



    ------------------------------
    Morag Hughson
    MQ Technical Education Specialist
    MQGem Software Limited
    Website: https://www.mqgem.com
    ------------------------------

    Original Message


  • 7.  RE: mapping client user to local user

    Posted Thu April 10, 2025 03:02 PM

    Hello!

    Yes, you can use a CHLAUTH rule to map the unknown user "wasserver" to a valid user like "appuser", even without SSL. Since your QMGR uses SYSTEM.DEFAULT.AUTHINFO.IDPWOS, MQ expects OS-level users, but CHLAUTH lets you bypass that.

    Example: SET CHLAUTH('Your.Channel.Name') TYPE(USERMAP) CLNTUSER('wasserver') USERSRC(MAP) MCAUSER('appuser')
    Just ensure "appuser" has the right permissions (setmqaut).



    ------------------------------
    Cadabyte
    Engineer, Modder
    Cadabyte
    Brandon FL
    (813) 657-2555
    ------------------------------

    Original Message


  • 8.  RE: mapping client user to local user

    Posted Fri April 11, 2025 08:03 AM

    The output of the server let's me think that the MQCSP structure is used but that the server does not use AdoptCTX(YES).

    Verify the connauth on the queue manager and the corresponding authinfo. Make sure that the authinfo is not the default one (Should not start with SYSTEM), then issue a refresh security type (connauth).

    If that doesn't work make sure you create a local user with the name being flowed on  the connection.



    ------------------------------
    Francois Brandelik
    ------------------------------

    Original Message


  • 9.  RE: mapping client user to local user

    Posted Fri April 11, 2025 11:43 AM
      |   view attached

    Thank you all tor you suggestions

    The original issue is solved, the app was trying to connect to que queue manager using username + password. This username is a domain user. After the app team change username to username@domain_name + password, the were able to connect. 

    I can't do more tests on that environment.

    I now trying to recreate the behavior in my homelab (no LDAP server...) but I found different behavior between MQ 9.3.1.0 and 9.4.0.7. Messages are on the attached pdf. 

    joao 



    ------------------------------
    Joao Ramires
    ------------------------------

    Attachment(s)

    pdf
    MQConnectionTests.pdf   54 KB 1 version
    Original Message


  • 10.  RE: mapping client user to local user

    Posted 28 days ago
    Edited by Francois Brandelik 28 days ago

    In Windows, in the same domain, you should not need to use user@domain, if you've set the corresponding GroupModel Security stanza and use a domain user as service user.



    ------------------------------
    Francois Brandelik
    ------------------------------

    Original Message