upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect attempts get 2035

[David Awerbuch (BLOOMBERG/ 120 PARK)]

I am hoping some one out there has already seen this issue during their upgrade cycle.

We upgraded a host with existing queue managers from 7.0.1.4 to 7.5.0.1. Our client applications are not able to connect to the queue managers using the existing svrconn channels and authorization records - 2035 errors.

1. User Application

Checked queue manager log, I see:

AMQ8077: Entity 'dbaseuser ' has insufficient authority to access object 'NEWSQMGR'.
AMQ9557: Queue Manager User ID initialization failed.

'dbaseuser' is an existing unix userid. until the upgrade to 7.5, the access through this srvconn was not an issue.
Note - the mcauser() field on the svrconn has always been and is blank.
I believe in the previous release (7.0.1.4) that this user would connect as user 'mqm'; thus no issues with connectivity and object access.

Now with 7.5.0.1 it looks like the real userid from the client connection header is being exposed to the authorization module. is this a correct assessment? Is there a way to restore this processing, or am I looking at a moving-forward series of changes to my application svrconns?

Note -- 7.5.0.1 queue manager has CHLAUTH(DISABLED)


2. WMQ Administration tool - web-based service

Checked queue manager log, I see this series of error messages; these are all generated by the same pid.tid:

AMQ9780: Channel to remote machine '1.2.3.4' is ending due to an error.
EXPLANATION:
Channel 'ADMIN.SVRCONN' between this machine and the remote machine
'1.2.3.4' encountered an error and will now end. In some cases the
channel name can not be determined and so is shown as '????'.

AMQ9519: Channel 'ADMIN.SVRCONN' not found.
EXPLANATION:
The requested operation failed because the program could not find a definition
of channel 'ADMIN.SVRCONN'.

AMQ9999: Channel 'ADMIN.SVRCONN' to host 'windowshost(1.2.3.4)'
ended abnormally.
EXPLANATION:
The channel program running under process ID 8392 for channel
'ADMIN.SVRCONN' ended abnormally. The host name is 'sysnyweb03
(1.2.3.4)'; in some cases the host name cannot be determined and so is
shown as '????'.

AMQ5653: The user 'windowshost$' is not defined.
EXPLANATION:
The system call getpwnam("windowshost$") failed with errno 2.

AMQ9557: Queue Manager User ID initialization failed.
EXPLANATION:
The call to initialize the User ID failed with CompCode 2 and Reason 2035.


Previous to the upgrade, this worked just fine.
Note - also in this case - the mcauser() field on the svrconn has always been and is blank.
so, the same premises and belief exists as above - in the previous release (7.0.1.4) this user would connect as user 'mqm'; thus no issues with connectivity and object access.

Now with 7.5.0.1 it looks like the machine name from the client connection header is being exposed to the authorization module; or the header contains the machinename with the appended '$'. Is this a correct assessment? Again, is there a way to restore this processing, or am I looking at a moving-forward series of changes to my admin svrconns?


Thanks.
Dave


------------------------------------------------------------
-------------------------------------------------------------------
David Awerbuch -- Systems Architect -- Middleware Infrastructure
email: ***@bloomberg.net || ==== Bloomberg LP ==== ||
phone: + 1 646 324 2868 || Making Financial ||
WMQ support mq-***@bloomberg.com || Markets Transparent ||
-------------------------------------------------------------------
For all Trading Systems issues, please contact the TSCI 24-hour helpdesk.
- Americas - New York +1+212-318-2000
- Europe - London [phone]
- Asia - Tokyo [phone]
- Singapore [phone]

<< {IS} May you and yours be inscribed in the Book Of Life for health and happiness >>

[T.Rob]

If the old connection attached as mqm, then set the MCAUSER('mqm') on the new channel. The old behavior of not sending a user ID in many cases was due to an insecure-by-default posture. It always allowed anonymous admin access, and was easily spoofed to be blank or mqm. The only connections using an actual valid ID were the very people you don't need to worry about. Setting MCAUSER('mqm') does not increase the exposure in the least, but it *does* make it more apparent that the QMgr leaks anonymous admin access. By reducing that false sense of security, people tend to be more aware of how exposed the thing is and thus act accordingly. Or somewhat more accordingly.

Note -- 7.5.0.1 queue manager has CHLAUTH(DISABLED)

Dave, you're KILLING me here. I have availability coming up if you want to actually fix this debacle, enable CHLAUTH and secure a few things. J



-- T.Rob







From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of David Awerbuch (BLOOMBERG/ 120 PARK)
Sent: Wednesday, September 11, 2013 16:22 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect attempts get 2035



I am hoping some one out there has already seen this issue during their upgrade cycle.



We upgraded a host with existing queue managers from 7.0.1.4 to 7.5.0.1. Our client applications are not able to connect to the queue managers using the existing svrconn channels and authorization records - 2035 errors.



1. User Application



Checked queue manager log, I see:



AMQ8077: Entity 'dbaseuser ' has insufficient authority to access object 'NEWSQMGR'.

AMQ9557: Queue Manager User ID initialization failed.



'dbaseuser' is an existing unix userid. until the upgrade to 7.5, the access through this srvconn was not an issue.

Note - the mcauser() field on the svrconn has always been and is blank.

I believe in the previous release (7.0.1.4) that this user would connect as user 'mqm'; thus no issues with connectivity and object access.



Now with 7.5.0.1 it looks like the real userid from the client connection header is being exposed to the authorization module. is this a correct assessment? Is there a way to restore this processing, or am I looking at a moving-forward series of changes to my application svrconns?



Note -- 7.5.0.1 queue manager has CHLAUTH(DISABLED)





2. WMQ Administration tool - web-based service





Checked queue manager log, I see this series of error messages; these are all generated by the same pid.tid:





AMQ9780: Channel to remote machine '1.2.3.4' is ending due to an error.

EXPLANATION:

Channel 'ADMIN.SVRCONN' between this machine and the remote machine

'1.2.3.4' encountered an error and will now end. In some cases the

channel name can not be determined and so is shown as '????'.





AMQ9519: Channel 'ADMIN.SVRCONN' not found.

EXPLANATION:

The requested operation failed because the program could not find a definition

of channel 'ADMIN.SVRCONN'.





AMQ9999: Channel 'ADMIN.SVRCONN' to host 'windowshost(1.2.3.4)'

ended abnormally.

EXPLANATION:

The channel program running under process ID 8392 for channel

'ADMIN.SVRCONN' ended abnormally. The host name is 'sysnyweb03

(1.2.3.4)'; in some cases the host name cannot be determined and so is

shown as '????'.





AMQ5653: The user 'windowshost$' is not defined.

EXPLANATION:

The system call getpwnam("windowshost$") failed with errno 2.





AMQ9557: Queue Manager User ID initialization failed.

EXPLANATION:

The call to initialize the User ID failed with CompCode 2 and Reason 2035.









Previous to the upgrade, this worked just fine.

Note - also in this case - the mcauser() field on the svrconn has always been and is blank.

so, the same premises and belief exists as above - in the previous release (7.0.1.4) this user would connect as user 'mqm'; thus no issues with connectivity and object access.





Now with 7.5.0.1 it looks like the machine name from the client connection header is being exposed to the authorization module; or the header contains the machinename with the appended '$'. Is this a correct assessment? Again, is there a way to restore this processing, or am I looking at a moving-forward series of changes to my admin svrconns?







Thanks.

Dave











------------------------------------------------------------
-------------------------------------------------------------------
David Awerbuch -- Systems Architect -- Middleware Infrastructure
email: dawerbuch-AlFclGv/***@public.gmane.org || ==== Bloomberg LP ==== ||
phone: + 1 646 324 2868 || Making Financial ||
WMQ support mq-support-AlFclGv/***@public.gmane.org || Markets Transparent ||
-------------------------------------------------------------------
For all Trading Systems issues, please contact the TSCI 24-hour helpdesk.
- Americas - New York +1+212-318-2000
- Europe - London [phone]
- Asia - Tokyo [phone]
- Singapore [phone]



<< {IS} May you and yours be inscribed in the Book Of Life for health and happiness >>


To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Sailesh Krishnamurti (BLOOMBERG/ 120 PARK)]

Hi T.Rob, thanks for the response.

However, does an MCAUSER('') with a qmgr that has CHLAUTH(DISABLED) actually result in
Applications being denied access? I would think that CHLAUTH(DISABLED) the old access
Regime stayed in place.

thanks

----- Original Message -----
From: ***@LISTSERV.MEDUNIWIEN.AC.AT
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
At: Sep 11 2013 16:47:29


If the old connection attached as mqm, then set the MCAUSER('mqm') on the new channel. The old behavior of not sending a user ID in many cases was due to an insecure-by-default posture. It always allowed anonymous admin access, and was easily spoofed to be blank or mqm. The only connections using an actual valid ID were the very people you don't need to worry about. Setting MCAUSER('mqm') does not increase the exposure in the least, but it *does* make it more apparent that the QMgr leaks anonymous admin access. By reducing that false sense of security, people tend to be more aware of how exposed the thing is and thus act accordingly. Or somewhat more accordingly.

Note -- 7.5.0.1 queue manager has CHLAUTH(DISABLED)

Dave, you're KILLING me here. I have availability coming up if you want to actually fix this debacle, enable CHLAUTH and secure a few things. J

-- T.Rob




From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of David Awerbuch (BLOOMBERG/ 120 PARK)
Sent: Wednesday, September 11, 2013 16:22 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect attempts get 2035


I am hoping some one out there has already seen this issue during their upgrade cycle.



We upgraded a host with existing queue managers from 7.0.1.4 to 7.5.0.1. Our client applications are not able to connect to the queue managers using the existing svrconn channels and authorization records - 2035 errors.



1. User Application



Checked queue manager log, I see:



AMQ8077: Entity 'dbaseuser ' has insufficient authority to access object 'NEWSQMGR'.

AMQ9557: Queue Manager User ID initialization failed.



'dbaseuser' is an existing unix userid. until the upgrade to 7.5, the access through this srvconn was not an issue.

Note - the mcauser() field on the svrconn has always been and is blank.

I believe in the previous release (7.0.1.4) that this user would connect as user 'mqm'; thus no issues with connectivity and object access.



Now with 7.5.0.1 it looks like the real userid from the client connection header is being exposed to the authorization module. is this a correct assessment? Is there a way to restore this processing, or am I looking at a moving-forward series of changes to my application svrconns?



Note -- 7.5.0.1 queue manager has CHLAUTH(DISABLED)





2. WMQ Administration tool - web-based service


Checked queue manager log, I see this series of error messages; these are all generated by the same pid.tid:


AMQ9780: Channel to remote machine '1.2.3.4' is ending due to an error.

EXPLANATION:

Channel 'ADMIN.SVRCONN' between this machine and the remote machine

'1.2.3.4' encountered an error and will now end. In some cases the

channel name can not be determined and so is shown as '????'.


AMQ9519: Channel 'ADMIN.SVRCONN' not found.

EXPLANATION:

The requested operation failed because the program could not find a definition

of channel 'ADMIN.SVRCONN'.


AMQ9999: Channel 'ADMIN.SVRCONN' to host 'windowshost(1.2.3.4)'

ended abnormally.

EXPLANATION:

The channel program running under process ID 8392 for channel

'ADMIN.SVRCONN' ended abnormally. The host name is 'sysnyweb03

(1.2.3.4)'; in some cases the host name cannot be determined and so is

shown as '????'.


AMQ5653: The user 'windowshost$' is not defined.

EXPLANATION:

The system call getpwnam("windowshost$") failed with errno 2.


AMQ9557: Queue Manager User ID initialization failed.

EXPLANATION:

The call to initialize the User ID failed with CompCode 2 and Reason 2035.


Previous to the upgrade, this worked just fine.

Note - also in this case - the mcauser() field on the svrconn has always been and is blank.

so, the same premises and belief exists as above - in the previous release (7.0.1.4) this user would connect as user 'mqm'; thus no issues with connectivity and object access.


Now with 7.5.0.1 it looks like the machine name from the client connection header is being exposed to the authorization module; or the header contains the machinename with the appended '$'. Is this a correct assessment? Again, is there a way to restore this processing, or am I looking at a moving-forward series of changes to my admin svrconns?




Thanks.

Dave











------------------------------------------------------------
-------------------------------------------------------------------
David Awerbuch -- Systems Architect -- Middleware Infrastructure
email: ***@bloomberg.net || ==== Bloomberg LP ==== ||
phone: + 1 646 324 2868 || Making Financial ||
WMQ support mq-***@bloomberg.com || Markets Transparent ||
-------------------------------------------------------------------
For all Trading Systems issues, please contact the TSCI 24-hour helpdesk.
- Americas - New York +1+212-318-2000
- Europe - London [phone]
- Asia - Tokyo [phone]
- Singapore [phone]


<< {IS} May you and yours be inscribed in the Book Of Life for health and happiness >>
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

[David Awerbuch (BLOOMBERG/ 120 PARK)]

I thought there was a change to the security defaults in the new release (7.x vs. 7.0). I could not locate it, though, so i sought confirmation from my peers.


I'm killing you? I don't get it, why are you so ....

Oh ... I guess I forgot one teensie, tiny, little detail.


this is a development environment.


In our non-development environments,we are much better locked down, with mcauser, blockip2, etc.

Thanks!
Dave





--- Sent From Bloomberry Mobile MSG ---

---- Original Message ----
From: T.Rob <***@ioptconsulting.com>
At: 9/11/2013 16:47

If the old connection attached as mqm, then set the MCAUSER('mqm') on the new channel. The old behavior of not sending a user ID in many cases was due to an insecure-by-default posture. It always allowed anonymous admin access, and was easily spoofed to be blank or mqm. The only connections using an actual valid ID were the very people you don't need to worry about. Setting MCAUSER('mqm') does not increase the exposure in the least, but it *does* make it more apparent that the QMgr leaks anonymous admin access. By reducing that false sense of security, people tend to be more aware of how exposed the thing is and thus act accordingly. Or somewhat more accordingly.

Note -- 7.5.0.1 queue manager has CHLAUTH(DISABLED)

Dave, you're KILLING me here. I have availability coming up if you want to actually fix this debacle, enable CHLAUTH and secure a few things. J



-- T.Rob







From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of David Awerbuch (BLOOMBERG/ 120 PARK)
Sent: Wednesday, September 11, 2013 16:22 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect attempts get 2035



I am hoping some one out there has already seen this issue during their upgrade cycle.



We upgraded a host with existing queue managers from 7.0.1.4 to 7.5.0.1. Our client applications are not able to connect to the queue managers using the existing svrconn channels and authorization records - 2035 errors.



1. User Application



Checked queue manager log, I see:



AMQ8077: Entity 'dbaseuser ' has insufficient authority to access object 'NEWSQMGR'.

AMQ9557: Queue Manager User ID initialization failed.



'dbaseuser' is an existing unix userid. until the upgrade to 7.5, the access through this srvconn was not an issue.

Note - the mcauser() field on the svrconn has always been and is blank.

I believe in the previous release (7.0.1.4) that this user would connect as user 'mqm'; thus no issues with connectivity and object access.



Now with 7.5.0.1 it looks like the real userid from the client connection header is being exposed to the authorization module. is this a correct assessment? Is there a way to restore this processing, or am I looking at a moving-forward series of changes to my application svrconns?



Note -- 7.5.0.1 queue manager has CHLAUTH(DISABLED)





2. WMQ Administration tool - web-based service





Checked queue manager log, I see this series of error messages; these are all generated by the same pid.tid:





AMQ9780: Channel to remote machine '1.2.3.4' is ending due to an error.

EXPLANATION:

Channel 'ADMIN.SVRCONN' between this machine and the remote machine

'1.2.3.4' encountered an error and will now end. In some cases the

channel name can not be determined and so is shown as '????'.





AMQ9519: Channel 'ADMIN.SVRCONN' not found.

EXPLANATION:

The requested operation failed because the program could not find a definition

of channel 'ADMIN.SVRCONN'.





AMQ9999: Channel 'ADMIN.SVRCONN' to host 'windowshost(1.2.3.4)'

ended abnormally.

EXPLANATION:

The channel program running under process ID 8392 for channel

'ADMIN.SVRCONN' ended abnormally. The host name is 'sysnyweb03

(1.2.3.4)'; in some cases the host name cannot be determined and so is

shown as '????'.





AMQ5653: The user 'windowshost$' is not defined.

EXPLANATION:

The system call getpwnam("windowshost$") failed with errno 2.





AMQ9557: Queue Manager User ID initialization failed.

EXPLANATION:

The call to initialize the User ID failed with CompCode 2 and Reason 2035.









Previous to the upgrade, this worked just fine.

Note - also in this case - the mcauser() field on the svrconn has always been and is blank.

so, the same premises and belief exists as above - in the previous release (7.0.1.4) this user would connect as user 'mqm'; thus no issues with connectivity and object access.





Now with 7.5.0.1 it looks like the machine name from the client connection header is being exposed to the authorization module; or the header contains the machinename with the appended '$'. Is this a correct assessment? Again, is there a way to restore this processing, or am I looking at a moving-forward series of changes to my admin svrconns?







Thanks.

Dave











------------------------------------------------------------
-------------------------------------------------------------------
David Awerbuch -- Systems Architect -- Middleware Infrastructure
email: ***@bloomberg.net || ==== Bloomberg LP ==== ||
phone: + 1 646 324 2868 || Making Financial ||
WMQ support mq-***@bloomberg.com || Markets Transparent ||
-------------------------------------------------------------------
For all Trading Systems issues, please contact the TSCI 24-hour helpdesk.
- Americas - New York +1+212-318-2000
- Europe - London [phone]
- Asia - Tokyo [phone]
- Singapore [phone]



<< {IS} May you and yours be inscribed in the Book Of Life for health and happiness >>



<< {IS} May you and yours be inscribed in the Book Of Life for health and happiness >>

[T.Rob]

Hi Sailesh,



Let's walk through this. Dave said that




=====

'dbaseuser' is an existing unix userid. until the upgrade to 7.5, the access through this srvconn was not an issue.

Note - the mcauser() field on the svrconn has always been and is blank.

I believe in the previous release (7.0.1.4) that this user would connect as user 'mqm'; thus no issues with connectivity and object access.



Now with 7.5.0.1 it looks like the real userid from the client connection header is being exposed to the authorization module. is this a correct assessment? Is there a way to restore this processing, or am I looking at a moving-forward series of changes to my application svrconns?

=====



So, if the MCAUSER on the channel definition used to be blank, there are no exits involved, and if the connection was formerly completed such that channel status showed MCAUSER(mqm) or MCAUSER( ), then the only two possibilities are that



a) application was formerly either explicitly setting it or

b) the app was not setting anything and the ID resolved to blank.



Case A does not appear to apply because if the app had changed, Dave would have whacked a developer on the head.



However, we do know that ID resolved by and presented by the client *has* changed with recent releases. In cases where the client formerly sent a blank ID, it often now tries harder to resolve the ID that the client is running under and sends that instead. So if the client code was updated, then there's a good possibility that it is now presenting the ID of the owning PID where once it sent blanks. This results in 2035 errors if the ID received is not in an authorized group. Usually since the connection had formerly run with admin rights there are no authorizations defined for that ID and group and so we often see 2035 errors after an upgrade.



Another problem seen frequently is that the new QMgr is implemented on a new server that does not resolve the domain the client lives on. In the Windows world, the Security Identifier (SID) is transmitted along with the text value of the user ID on a connect request. The SID is used *if* it is present. SIDs are universally unique so the ID trob on the QMgr's server is NOT the same as the ID trob on the client server or domain. If the new server cannot resolve the SAM database where the presented SID lives, then the authorization fails. If the remote SAM database can be resolved but other AD permissions are different on the new server (for example, BypassTraverseChecking is not granted) then the lookup fails.



However, if the connection does not include a SID (for example, it originates from a Linux client) then the Windows QMgr uses the text value. In that case if the text value is 'trob' then the authorization is based on the *first* SAM database in which an ID called trob is resolved. This is why I said that adding MCAUSER('mqm') would not diminish security. The ID was easily spoofed anyway.



There is a bit of confusion as to what platforms are involved. Dave said the channel connection ran as mqm which *cannot* be a windows QMgr. On Windows mqm is a required group and since you can't have a group and user of the same name, we have MUSR_MQADMIN as the user. Dave didn't mention an error message with the value "'windowshost$" which suggests that Windows is involved somehow, it isn't clear exactly though. There is a Windows setting that you can use regedit to set SecurityPolicy to NTSIDsRequired. This setting makes a Windows QMgr refuse a connection that does not include a SID, for example one from a Linux host. Because it looks like a non-Windows QMgr, that also doesn't appear to apply.



So, to sum up, on a platform where mqm is the admin ID (i.e. *not* a Windows box) the QMgr uses the text value of an ID passed in or else uses mqm if the ID passed in is blank. After upgrading the non-Windows QMgr is no more or less sensitive to the ID sent in but the client *does* change the ID sent after upgrading from 7.0.x to 7.1 or higher. On any such QMgr, changing the ID presented form blank or mqm to an actual value causes authorization checks against that new value and introduces the possibility of those checks failing where previously they had always succeeded. Setting MCAUSER('mqm') restores the behavior of the checks always succeeding.



Does that help? Sorry for the prior terse reply but I was at the time sitting with a client waiting for him to get off the phone and typing a quick answer.



-- T.Rob







From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Sailesh Krishnamurti (BLOOMBERG/ 120 PARK)
Sent: Wednesday, September 11, 2013 17:00 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect attempts get 2035



Hi T.Rob, thanks for the response.



However, does an MCAUSER('') with a qmgr that has CHLAUTH(DISABLED) actually result in

Applications being denied access? I would think that CHLAUTH(DISABLED) the old access

Regime stayed in place.



thanks



----- Original Message -----
From: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
At: Sep 11 2013 16:47:29

If the old connection attached as mqm, then set the MCAUSER('mqm') on the new channel. The old behavior of not sending a user ID in many cases was due to an insecure-by-default posture. It always allowed anonymous admin access, and was easily spoofed to be blank or mqm. The only connections using an actual valid ID were the very people you don't need to worry about. Setting MCAUSER('mqm') does not increase the exposure in the least, but it *does* make it more apparent that the QMgr leaks anonymous admin access. By reducing that false sense of security, people tend to be more aware of how exposed the thing is and thus act accordingly. Or somewhat more accordingly.

Note -- 7.5.0.1 queue manager has CHLAUTH(DISABLED)

Dave, you're KILLING me here. I have availability coming up if you want to actually fix this debacle, enable CHLAUTH and secure a few things. J



-- T.Rob







From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of David Awerbuch (BLOOMBERG/ 120 PARK)
Sent: Wednesday, September 11, 2013 16:22 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect attempts get 2035



I am hoping some one out there has already seen this issue during their upgrade cycle.



We upgraded a host with existing queue managers from 7.0.1.4 to 7.5.0.1. Our client applications are not able to connect to the queue managers using the existing svrconn channels and authorization records - 2035 errors.



1. User Application



Checked queue manager log, I see:



AMQ8077: Entity 'dbaseuser ' has insufficient authority to access object 'NEWSQMGR'.

AMQ9557: Queue Manager User ID initialization failed.



'dbaseuser' is an existing unix userid. until the upgrade to 7.5, the access through this srvconn was not an issue.

Note - the mcauser() field on the svrconn has always been and is blank.

I believe in the previous release (7.0.1.4) that this user would connect as user 'mqm'; thus no issues with connectivity and object access.



Now with 7.5.0.1 it looks like the real userid from the client connection header is being exposed to the authorization module. is this a correct assessment? Is there a way to restore this processing, or am I looking at a moving-forward series of changes to my application svrconns?



Note -- 7.5.0.1 queue manager has CHLAUTH(DISABLED)





2. WMQ Administration tool - web-based service



Checked queue manager log, I see this series of error messages; these are all generated by the same pid.tid:



AMQ9780: Channel to remote machine '1.2.3.4' is ending due to an error.

EXPLANATION:

Channel 'ADMIN.SVRCONN' between this machine and the remote machine

'1.2.3.4' encountered an error and will now end. In some cases the

channel name can not be determined and so is shown as '????'.



AMQ9519: Channel 'ADMIN.SVRCONN' not found.

EXPLANATION:

The requested operation failed because the program could not find a definition

of channel 'ADMIN.SVRCONN'.



AMQ9999: Channel 'ADMIN.SVRCONN' to host 'windowshost(1.2.3.4)'

ended abnormally.

EXPLANATION:

The channel program running under process ID 8392 for channel

'ADMIN.SVRCONN' ended abnormally. The host name is 'sysnyweb03

(1.2.3.4)'; in some cases the host name cannot be determined and so is

shown as '????'.



AMQ5653: The user 'windowshost$' is not defined.

EXPLANATION:

The system call getpwnam("windowshost$") failed with errno 2.



AMQ9557: Queue Manager User ID initialization failed.

EXPLANATION:

The call to initialize the User ID failed with CompCode 2 and Reason 2035.





Previous to the upgrade, this worked just fine.

Note - also in this case - the mcauser() field on the svrconn has always been and is blank.

so, the same premises and belief exists as above - in the previous release (7.0.1.4) this user would connect as user 'mqm'; thus no issues with connectivity and object access.



Now with 7.5.0.1 it looks like the machine name from the client connection header is being exposed to the authorization module; or the header contains the machinename with the appended '$'. Is this a correct assessment? Again, is there a way to restore this processing, or am I looking at a moving-forward series of changes to my admin svrconns?





Thanks.

Dave











------------------------------------------------------------
-------------------------------------------------------------------
David Awerbuch -- Systems Architect -- Middleware Infrastructure
email: dawerbuch-AlFclGv/***@public.gmane.org || ==== Bloomberg LP ==== ||
phone: + 1 646 324 2868 || Making Financial ||
WMQ support mq-support-AlFclGv/***@public.gmane.org || Markets Transparent ||
-------------------------------------------------------------------
For all Trading Systems issues, please contact the TSCI 24-hour helpdesk.
- Americas - New York +1+212-318-2000
- Europe - London [phone]
- Asia - Tokyo [phone]
- Singapore [phone]



<< {IS} May you and yours be inscribed in the Book Of Life for health and happiness >>




_____


List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings <http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe <mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com <http://www.lsoft.com/resources/manuals.asp>


To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Potkay, Peter M (CTO Architecture + Engineering)]

I still don’t understand why Dave is having the problem he is.

From his description I assume both Case 1 and Case 2 are MQ Clients that were not themselves upgraded, therefore I assume any identifying data they were or were not sending to the QM has not changed. So why would upgrading only the queue manager server cause these 2035s all of the sudden?

Dave, are these clients Java based? Was the MQ Client upgraded as well, or just the MQ Server? What’s up with those channel not found errors – that makes even less sense if the only thing that changed was the QM’s MQ version.


Peter Potkay


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of T.Rob
Sent: Wednesday, September 11, 2013 4:47 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect attempts get 2035

If the old connection attached as mqm, then set the MCAUSER('mqm') on the new channel. The old behavior of not sending a user ID in many cases was due to an insecure-by-default posture. It always allowed anonymous admin access, and was easily spoofed to be blank or mqm. The only connections using an actual valid ID were the very people you don't need to worry about. Setting MCAUSER('mqm') does not increase the exposure in the least, but it *does* make it more apparent that the QMgr leaks anonymous admin access. By reducing that false sense of security, people tend to be more aware of how exposed the thing is and thus act accordingly. Or somewhat more accordingly.

Note -- 7.5.0.1 queue manager has CHLAUTH(DISABLED)

Dave, you're KILLING me here. I have availability coming up if you want to actually fix this debacle, enable CHLAUTH and secure a few things. ☺

-- T.Rob



From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of David Awerbuch (BLOOMBERG/ 120 PARK)
Sent: Wednesday, September 11, 2013 16:22 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect attempts get 2035

I am hoping some one out there has already seen this issue during their upgrade cycle.

We upgraded a host with existing queue managers from 7.0.1.4 to 7.5.0.1. Our client applications are not able to connect to the queue managers using the existing svrconn channels and authorization records - 2035 errors.

1. User Application

Checked queue manager log, I see:

AMQ8077: Entity 'dbaseuser ' has insufficient authority to access object 'NEWSQMGR'.
AMQ9557: Queue Manager User ID initialization failed.

'dbaseuser' is an existing unix userid. until the upgrade to 7.5, the access through this srvconn was not an issue.
Note - the mcauser() field on the svrconn has always been and is blank.
I believe in the previous release (7.0.1.4) that this user would connect as user 'mqm'; thus no issues with connectivity and object access.

Now with 7.5.0.1 it looks like the real userid from the client connection header is being exposed to the authorization module. is this a correct assessment? Is there a way to restore this processing, or am I looking at a moving-forward series of changes to my application svrconns?

Note -- 7.5.0.1 queue manager has CHLAUTH(DISABLED)


2. WMQ Administration tool - web-based service

Checked queue manager log, I see this series of error messages; these are all generated by the same pid.tid:

AMQ9780: Channel to remote machine '1.2.3.4' is ending due to an error.
EXPLANATION:
Channel 'ADMIN.SVRCONN' between this machine and the remote machine
'1.2.3.4' encountered an error and will now end. In some cases the
channel name can not be determined and so is shown as '????'.

AMQ9519: Channel 'ADMIN.SVRCONN' not found.
EXPLANATION:
The requested operation failed because the program could not find a definition
of channel 'ADMIN.SVRCONN'.

AMQ9999: Channel 'ADMIN.SVRCONN' to host 'windowshost(1.2.3.4)'
ended abnormally.
EXPLANATION:
The channel program running under process ID 8392 for channel
'ADMIN.SVRCONN' ended abnormally. The host name is 'sysnyweb03
(1.2.3.4)'; in some cases the host name cannot be determined and so is
shown as '????'.

AMQ5653: The user 'windowshost$' is not defined.
EXPLANATION:
The system call getpwnam("windowshost$") failed with errno 2.

AMQ9557: Queue Manager User ID initialization failed.
EXPLANATION:
The call to initialize the User ID failed with CompCode 2 and Reason 2035.


Previous to the upgrade, this worked just fine.
Note - also in this case - the mcauser() field on the svrconn has always been and is blank.
so, the same premises and belief exists as above - in the previous release (7.0.1.4) this user would connect as user 'mqm'; thus no issues with connectivity and object access.

Now with 7.5.0.1 it looks like the machine name from the client connection header is being exposed to the authorization module; or the header contains the machinename with the appended '$'. Is this a correct assessment? Again, is there a way to restore this processing, or am I looking at a moving-forward series of changes to my admin svrconns?


Thanks.
Dave





------------------------------------------------------------
-------------------------------------------------------------------
David Awerbuch -- Systems Architect -- Middleware Infrastructure
email: ***@bloomberg.net<mailto:***@bloomberg.net> || ==== Bloomberg LP ==== ||
phone: + 1 646 324 2868 || Making Financial ||
WMQ support mq-***@bloomberg.com<mailto:mq-***@bloomberg.com> || Markets Transparent ||
-------------------------------------------------------------------
For all Trading Systems issues, please contact the TSCI 24-hour helpdesk.
- Americas - New York +1+212-318-2000
- Europe - London [phone]
- Asia - Tokyo [phone]
- Singapore [phone]


<< {IS} May you and yours be inscribed in the Book Of Life for health and happiness >>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

[T.Rob]

Well, the last question seems obvious
 The only way to get channel not found is 1) Someone defined SYSTEM.ADMIN.SVRCONN on the new QMgr where ADMIN.SVRCONN was expected; or 2) it's connecting to a different QMgr than expected. To even get that message the client had to have found *some* QMgr so it's the right one with the wrong definitions or the wrong one. The differences in behavior are hard to explain if the *only* action was to upgrade the QMgr in place. So I'm guessing there is more here we don't know yet – such as the QMgr was built on a new machine and moved over, or that clients were updated, etc.





From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, September 12, 2013 8:02 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect attempts get 2035



I still don’t understand why Dave is having the problem he is.

Post by Potkay, Peter M (CTO Architecture + Engineering)
From his description I assume both Case 1 and Case 2 are MQ Clients that were not themselves upgraded, therefore I assume any identifying data they were or were not sending to the QM has not changed. So why would upgrading only the queue manager server cause these 2035s all of the sudden?

Dave, are these clients Java based? Was the MQ Client upgraded as well, or just the MQ Server? What’s up with those channel not found errors – that makes even less sense if the only thing that changed was the QM’s MQ version.





Peter Potkay



From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
Sent: Wednesday, September 11, 2013 4:47 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect attempts get 2035



If the old connection attached as mqm, then set the MCAUSER('mqm') on the new channel. The old behavior of not sending a user ID in many cases was due to an insecure-by-default posture. It always allowed anonymous admin access, and was easily spoofed to be blank or mqm. The only connections using an actual valid ID were the very people you don't need to worry about. Setting MCAUSER('mqm') does not increase the exposure in the least, but it *does* make it more apparent that the QMgr leaks anonymous admin access. By reducing that false sense of security, people tend to be more aware of how exposed the thing is and thus act accordingly. Or somewhat more accordingly.

Post by Potkay, Peter M (CTO Architecture + Engineering)
Note -- 7.5.0.1 queue manager has CHLAUTH(DISABLED)

Dave, you're KILLING me here. I have availability coming up if you want to actually fix this debacle, enable CHLAUTH and secure a few things. J



-- T.Rob







From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of David Awerbuch (BLOOMBERG/ 120 PARK)
Sent: Wednesday, September 11, 2013 16:22 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect attempts get 2035



I am hoping some one out there has already seen this issue during their upgrade cycle.



We upgraded a host with existing queue managers from 7.0.1.4 to 7.5.0.1. Our client applications are not able to connect to the queue managers using the existing svrconn channels and authorization records - 2035 errors.



1. User Application



Checked queue manager log, I see:



AMQ8077: Entity 'dbaseuser ' has insufficient authority to access object 'NEWSQMGR'.

AMQ9557: Queue Manager User ID initialization failed.



'dbaseuser' is an existing unix userid. until the upgrade to 7.5, the access through this srvconn was not an issue.

Note - the mcauser() field on the svrconn has always been and is blank.

I believe in the previous release (7.0.1.4) that this user would connect as user 'mqm'; thus no issues with connectivity and object access.



Now with 7.5.0.1 it looks like the real userid from the client connection header is being exposed to the authorization module. is this a correct assessment? Is there a way to restore this processing, or am I looking at a moving-forward series of changes to my application svrconns?



Note -- 7.5.0.1 queue manager has CHLAUTH(DISABLED)





2. WMQ Administration tool - web-based service



Checked queue manager log, I see this series of error messages; these are all generated by the same pid.tid:



AMQ9780: Channel to remote machine '1.2.3.4' is ending due to an error.

EXPLANATION:

Channel 'ADMIN.SVRCONN' between this machine and the remote machine

'1.2.3.4' encountered an error and will now end. In some cases the

channel name can not be determined and so is shown as '????'.



AMQ9519: Channel 'ADMIN.SVRCONN' not found.

EXPLANATION:

The requested operation failed because the program could not find a definition

of channel 'ADMIN.SVRCONN'.



AMQ9999: Channel 'ADMIN.SVRCONN' to host 'windowshost(1.2.3.4)'

ended abnormally.

EXPLANATION:

The channel program running under process ID 8392 for channel

'ADMIN.SVRCONN' ended abnormally. The host name is 'sysnyweb03

(1.2.3.4)'; in some cases the host name cannot be determined and so is

shown as '????'.



AMQ5653: The user 'windowshost$' is not defined.

EXPLANATION:

The system call getpwnam("windowshost$") failed with errno 2.



AMQ9557: Queue Manager User ID initialization failed.

EXPLANATION:

The call to initialize the User ID failed with CompCode 2 and Reason 2035.





Previous to the upgrade, this worked just fine.

Note - also in this case - the mcauser() field on the svrconn has always been and is blank.

so, the same premises and belief exists as above - in the previous release (7.0.1.4) this user would connect as user 'mqm'; thus no issues with connectivity and object access.



Now with 7.5.0.1 it looks like the machine name from the client connection header is being exposed to the authorization module; or the header contains the machinename with the appended '$'. Is this a correct assessment? Again, is there a way to restore this processing, or am I looking at a moving-forward series of changes to my admin svrconns?





Thanks.

Dave











------------------------------------------------------------
-------------------------------------------------------------------
David Awerbuch -- Systems Architect -- Middleware Infrastructure
email: dawerbuch-AlFclGv/***@public.gmane.org || ==== Bloomberg LP ==== ||
phone: + 1 646 324 2868 || Making Financial ||
WMQ support mq-support-AlFclGv/***@public.gmane.org || Markets Transparent ||
-------------------------------------------------------------------
For all Trading Systems issues, please contact the TSCI 24-hour helpdesk.
- Americas - New York +1+212-318-2000
- Europe - London [phone]
- Asia - Tokyo [phone]
- Singapore [phone]



<< {IS} May you and yours be inscribed in the Book Of Life for health and happiness >>



_____

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings <http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe <mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com <http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[David Awerbuch (BLOOMBERG/ 120 PARK)]

To reply to both of these posts -

1. Peter: "I still don’t understand why Dave is having the problem he is." -- Thank you!! I thought I was crazy, but Peter just reaffirmed I am not -- at least when it comes to the issue at hand.

2. None of the clients anywhere were upgraded. They are 7.0.1.4 - the user application (case 1) is Linux, the admin tool (case 2) is Windows. The only steps taken were to upgrade the server software and then the individual queue managers to 7.5.0.1; no other changes were made. That's how you are supposed to test new software - change only one component at a time and leave everything else alone; if the upgrade does some config updates, these must be accounted for -- which is the case here, I am not able to account for this change in authorization.

3. User application (Case 1) is c/c++; admin tool (Case 2) is apparently Java - lots of jar files - but I am verifying with the vendor.

4. channel not found errors were extracted from the AMQERR01.LOG as generated by the upgraded WMQ server. The channels exist, their definitions were not changed by us - I am also not able to account for these errors.

5. T.Rob, I changed the channel names (all names, actually) in my original note for security purposes. The real channels, however, are correct and continue to exist.

6. If I were connecting to a different queue manager than expected, than I would not see these errors in the correct queue manager, I would see them in a different queue manager.


To re-iterate:
1. queue manager upgraded in-place
2. clients not upgraded
3. no config or other hosting or infrastructure changes


I remain as perplexed as you do.

Dave

----- Original Message -----
From: ***@LISTSERV.MEDUNIWIEN.AC.AT
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
At: Sep 12 2013 09:43:27


Well, the last question seems obvious
 The only way to get channel not found is 1) Someone defined SYSTEM.ADMIN.SVRCONN on the new QMgr where ADMIN.SVRCONN was expected; or 2) it's connecting to a different QMgr than expected. To even get that message the client had to have found *some* QMgr so it's the right one with the wrong definitions or the wrong one. The differences in behavior are hard to explain if the *only* action was to upgrade the QMgr in place. So I'm guessing there is more here we don't know yet – such as the QMgr was built on a new machine and moved over, or that clients were updated, etc.



From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, September 12, 2013 8:02 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect attempts get 2035

I still don’t understand why Dave is having the problem he is.

From his description I assume both Case 1 and Case 2 are MQ Clients that were not themselves upgraded, therefore I assume any identifying data they were or were not sending to the QM has not changed. So why would upgrading only the queue manager server cause these 2035s all of the sudden?

Dave, are these clients Java based? Was the MQ Client upgraded as well, or just the MQ Server? What’s up with those channel not found errors – that makes even less sense if the only thing that changed was the QM’s MQ version.



Peter Potkay


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of T.Rob
Sent: Wednesday, September 11, 2013 4:47 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect attempts get 2035

If the old connection attached as mqm, then set the MCAUSER('mqm') on the new channel. The old behavior of not sending a user ID in many cases was due to an insecure-by-default posture. It always allowed anonymous admin access, and was easily spoofed to be blank or mqm. The only connections using an actual valid ID were the very people you don't need to worry about. Setting MCAUSER('mqm') does not increase the exposure in the least, but it *does* make it more apparent that the QMgr leaks anonymous admin access. By reducing that false sense of security, people tend to be more aware of how exposed the thing is and thus act accordingly. Or somewhat more accordingly.

Note -- 7.5.0.1 queue manager has CHLAUTH(DISABLED)

Dave, you're KILLING me here. I have availability coming up if you want to actually fix this debacle, enable CHLAUTH and secure a few things. J

-- T.Rob




From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of David Awerbuch (BLOOMBERG/ 120 PARK)
Sent: Wednesday, September 11, 2013 16:22 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect attempts get 2035


I am hoping some one out there has already seen this issue during their upgrade cycle.



We upgraded a host with existing queue managers from 7.0.1.4 to 7.5.0.1. Our client applications are not able to connect to the queue managers using the existing svrconn channels and authorization records - 2035 errors.



1. User Application



Checked queue manager log, I see:



AMQ8077: Entity 'dbaseuser ' has insufficient authority to access object 'NEWSQMGR'.

AMQ9557: Queue Manager User ID initialization failed.



'dbaseuser' is an existing unix userid. until the upgrade to 7.5, the access through this srvconn was not an issue.

Note - the mcauser() field on the svrconn has always been and is blank.

I believe in the previous release (7.0.1.4) that this user would connect as user 'mqm'; thus no issues with connectivity and object access.



Now with 7.5.0.1 it looks like the real userid from the client connection header is being exposed to the authorization module. is this a correct assessment? Is there a way to restore this processing, or am I looking at a moving-forward series of changes to my application svrconns?



Note -- 7.5.0.1 queue manager has CHLAUTH(DISABLED)





2. WMQ Administration tool - web-based service



Checked queue manager log, I see this series of error messages; these are all generated by the same pid.tid:



AMQ9780: Channel to remote machine '1.2.3.4' is ending due to an error.

EXPLANATION:

Channel 'ADMIN.SVRCONN' between this machine and the remote machine

'1.2.3.4' encountered an error and will now end. In some cases the

channel name can not be determined and so is shown as '????'.



AMQ9519: Channel 'ADMIN.SVRCONN' not found.

EXPLANATION:

The requested operation failed because the program could not find a definition

of channel 'ADMIN.SVRCONN'.



AMQ9999: Channel 'ADMIN.SVRCONN' to host 'windowshost(1.2.3.4)'

ended abnormally.

EXPLANATION:

The channel program running under process ID 8392 for channel

'ADMIN.SVRCONN' ended abnormally. The host name is 'sysnyweb03

(1.2.3.4)'; in some cases the host name cannot be determined and so is

shown as '????'.



AMQ5653: The user 'windowshost$' is not defined.

EXPLANATION:

The system call getpwnam("windowshost$") failed with errno 2.



AMQ9557: Queue Manager User ID initialization failed.

EXPLANATION:

The call to initialize the User ID failed with CompCode 2 and Reason 2035.





Previous to the upgrade, this worked just fine.

Note - also in this case - the mcauser() field on the svrconn has always been and is blank.

so, the same premises and belief exists as above - in the previous release (7.0.1.4) this user would connect as user 'mqm'; thus no issues with connectivity and object access.



Now with 7.5.0.1 it looks like the machine name from the client connection header is being exposed to the authorization module; or the header contains the machinename with the appended '$'. Is this a correct assessment? Again, is there a way to restore this processing, or am I looking at a moving-forward series of changes to my admin svrconns?





Thanks.

Dave











------------------------------------------------------------
-------------------------------------------------------------------
David Awerbuch -- Systems Architect -- Middleware Infrastructure
email: ***@bloomberg.net || ==== Bloomberg LP ==== ||
phone: + 1 646 324 2868 || Making Financial ||
WMQ support mq-***@bloomberg.com || Markets Transparent ||
-------------------------------------------------------------------
For all Trading Systems issues, please contact the TSCI 24-hour helpdesk.
- Americas - New York +1+212-318-2000
- Europe - London [phone]
- Asia - Tokyo [phone]
- Singapore [phone]


<< {IS} May you and yours be inscribed in the Book Of Life for health and happiness >>


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com


<< {IS} May you and yours be inscribed in the Book Of Life for health and happiness >>

[David Awerbuch (BLOOMBERG/ 120 PARK)]

followup -- based on your questioning why the 'channel not found' errors, I reviewed the queue manager logs and discovered that these error messages were positionally proximal to the other error messages I reported, but were for a different thread in the same process. So that error can be ignored, but the other 2035 issue continues to be an active problem.

Sorry for the confusion.

Dave

----- Original Message -----
From: ***@LISTSERV.MEDUNIWIEN.AC.AT
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
At: Sep 12 2013 09:43:27


Well, the last question seems obvious
 The only way to get channel not found is 1) Someone defined SYSTEM.ADMIN.SVRCONN on the new QMgr where ADMIN.SVRCONN was expected; or 2) it's connecting to a different QMgr than expected. To even get that message the client had to have found *some* QMgr so it's the right one with the wrong definitions or the wrong one. The differences in behavior are hard to explain if the *only* action was to upgrade the QMgr in place. So I'm guessing there is more here we don't know yet – such as the QMgr was built on a new machine and moved over, or that clients were updated, etc.



From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, September 12, 2013 8:02 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect attempts get 2035

I still don’t understand why Dave is having the problem he is.

From his description I assume both Case 1 and Case 2 are MQ Clients that were not themselves upgraded, therefore I assume any identifying data they were or were not sending to the QM has not changed. So why would upgrading only the queue manager server cause these 2035s all of the sudden?

Dave, are these clients Java based? Was the MQ Client upgraded as well, or just the MQ Server? What’s up with those channel not found errors – that makes even less sense if the only thing that changed was the QM’s MQ version.



Peter Potkay


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of T.Rob
Sent: Wednesday, September 11, 2013 4:47 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect attempts get 2035

If the old connection attached as mqm, then set the MCAUSER('mqm') on the new channel. The old behavior of not sending a user ID in many cases was due to an insecure-by-default posture. It always allowed anonymous admin access, and was easily spoofed to be blank or mqm. The only connections using an actual valid ID were the very people you don't need to worry about. Setting MCAUSER('mqm') does not increase the exposure in the least, but it *does* make it more apparent that the QMgr leaks anonymous admin access. By reducing that false sense of security, people tend to be more aware of how exposed the thing is and thus act accordingly. Or somewhat more accordingly.

Note -- 7.5.0.1 queue manager has CHLAUTH(DISABLED)

Dave, you're KILLING me here. I have availability coming up if you want to actually fix this debacle, enable CHLAUTH and secure a few things. J

-- T.Rob




From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of David Awerbuch (BLOOMBERG/ 120 PARK)
Sent: Wednesday, September 11, 2013 16:22 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect attempts get 2035


I am hoping some one out there has already seen this issue during their upgrade cycle.



We upgraded a host with existing queue managers from 7.0.1.4 to 7.5.0.1. Our client applications are not able to connect to the queue managers using the existing svrconn channels and authorization records - 2035 errors.



1. User Application



Checked queue manager log, I see:



AMQ8077: Entity 'dbaseuser ' has insufficient authority to access object 'NEWSQMGR'.

AMQ9557: Queue Manager User ID initialization failed.



'dbaseuser' is an existing unix userid. until the upgrade to 7.5, the access through this srvconn was not an issue.

Note - the mcauser() field on the svrconn has always been and is blank.

I believe in the previous release (7.0.1.4) that this user would connect as user 'mqm'; thus no issues with connectivity and object access.



Now with 7.5.0.1 it looks like the real userid from the client connection header is being exposed to the authorization module. is this a correct assessment? Is there a way to restore this processing, or am I looking at a moving-forward series of changes to my application svrconns?



Note -- 7.5.0.1 queue manager has CHLAUTH(DISABLED)





2. WMQ Administration tool - web-based service



Checked queue manager log, I see this series of error messages; these are all generated by the same pid.tid:



AMQ9780: Channel to remote machine '1.2.3.4' is ending due to an error.

EXPLANATION:

Channel 'ADMIN.SVRCONN' between this machine and the remote machine

'1.2.3.4' encountered an error and will now end. In some cases the

channel name can not be determined and so is shown as '????'.



AMQ9519: Channel 'ADMIN.SVRCONN' not found.

EXPLANATION:

The requested operation failed because the program could not find a definition

of channel 'ADMIN.SVRCONN'.



AMQ9999: Channel 'ADMIN.SVRCONN' to host 'windowshost(1.2.3.4)'

ended abnormally.

EXPLANATION:

The channel program running under process ID 8392 for channel

'ADMIN.SVRCONN' ended abnormally. The host name is 'sysnyweb03

(1.2.3.4)'; in some cases the host name cannot be determined and so is

shown as '????'.



AMQ5653: The user 'windowshost$' is not defined.

EXPLANATION:

The system call getpwnam("windowshost$") failed with errno 2.



AMQ9557: Queue Manager User ID initialization failed.

EXPLANATION:

The call to initialize the User ID failed with CompCode 2 and Reason 2035.





Previous to the upgrade, this worked just fine.

Note - also in this case - the mcauser() field on the svrconn has always been and is blank.

so, the same premises and belief exists as above - in the previous release (7.0.1.4) this user would connect as user 'mqm'; thus no issues with connectivity and object access.



Now with 7.5.0.1 it looks like the machine name from the client connection header is being exposed to the authorization module; or the header contains the machinename with the appended '$'. Is this a correct assessment? Again, is there a way to restore this processing, or am I looking at a moving-forward series of changes to my admin svrconns?





Thanks.

Dave











------------------------------------------------------------
-------------------------------------------------------------------
David Awerbuch -- Systems Architect -- Middleware Infrastructure
email: ***@bloomberg.net || ==== Bloomberg LP ==== ||
phone: + 1 646 324 2868 || Making Financial ||
WMQ support mq-***@bloomberg.com || Markets Transparent ||
-------------------------------------------------------------------
For all Trading Systems issues, please contact the TSCI 24-hour helpdesk.
- Americas - New York +1+212-318-2000
- Europe - London [phone]
- Asia - Tokyo [phone]
- Singapore [phone]


<< {IS} May you and yours be inscribed in the Book Of Life for health and happiness >>


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com


<< {IS} May you and yours be inscribed in the Book Of Life for health and happiness >>

[T.Rob]

This post might be inappropriate. Click to display it.

[Bill Johnson]

Anyone know where the Websphere MQ for zOS V7.1 doc is located?
 
TIA
Bill Johnson.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,

[Larry Parsons - IT]

http://publib.boulder.ibm.com/infocenter/wmqv7/v7r1/index.jsp

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Bill Johnson
Sent: Thursday, September 12, 2013 3:33 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Websphere MQ for zOS V7.1 Doc?

Anyone know where the Websphere MQ for zOS V7.1 doc is located?

TIA
Bill Johnson.

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Tim Zielke]

Hi Bill,

I access it from the InfoCenter -> http://publib.boulder.ibm.com/infocenter/wmqv7/v7r1/index.jsp

Where the z/OS documentation is different from the distributed documentation, they break it out in the sections with z/OS in the names.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Bill Johnson
Sent: Thursday, September 12, 2013 3:33 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Websphere MQ for zOS V7.1 Doc?

Anyone know where the Websphere MQ for zOS V7.1 doc is located?

TIA
Bill Johnson.

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[LM Demey (MQ)]

Post by Bill Johnson
Anyone know where the Websphere MQ for zOS V7.1 doc is located?

http://publib.boulder.ibm.com/infocenter/wmqv7/v7r1/index.jsp

HTH.

Post by Bill Johnson
TIA
Bill Johnson.
------------------------------------------------------------------------
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html>
- Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
Instructions for managing your mailing list subscription are provided
in the Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>

--
Luc-Michel Demey - Freelance WAS & WMQ Expert
http://www.demey-consulting.fr/ - lmd at demey-consulting dot fr


To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Potkay, Peter M (CTO Architecture + Engineering)]

Did you ever get any 2035s on this QM before this upgrade? Maybe you had OAM disabled because it’s a DEV server with lax rules, and somehow the upgrade reenabled the OAM? Really grasping at straws here




Peter Potkay


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of David Awerbuch (BLOOMBERG/ 120 PARK)
Sent: Thursday, September 12, 2013 2:26 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect attempts get 2035

To reply to both of these posts -

1. Peter: "I still don’t understand why Dave is having the problem he is." -- Thank you!! I thought I was crazy, but Peter just reaffirmed I am not -- at least when it comes to the issue at hand.


2. None of the clients anywhere were upgraded. They are 7.0.1.4 - the user application (case 1) is Linux, the admin tool (case 2) is Windows. The only steps taken were to upgrade the server software and then the individual queue managers to 7.5.0.1; no other changes were made. That's how you are supposed to test new software - change only one component at a time and leave everything else alone; if the upgrade does some config updates, these must be accounted for -- which is the case here, I am not able to account for this change in authorization.


3. User application (Case 1) is c/c++; admin tool (Case 2) is apparently Java - lots of jar files - but I am verifying with the vendor.


4. channel not found errors were extracted from the AMQERR01.LOG as generated by the upgraded WMQ server. The channels exist, their definitions were not changed by us - I am also not able to account for these errors.


5. T.Rob, I changed the channel names (all names, actually) in my original note for security purposes. The real channels, however, are correct and continue to exist.


6. If I were connecting to a different queue manager than expected, than I would not see these errors in the correct queue manager, I would see them in a different queue manager.




To re-iterate:
1. queue manager upgraded in-place
2. clients not upgraded
3. no config or other hosting or infrastructure changes




I remain as perplexed as you do.


Dave


----- Original Message -----
From: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
At: Sep 12 2013 09:43:27
Well, the last question seems obvious
 The only way to get channel not found is 1) Someone defined SYSTEM.ADMIN.SVRCONN on the new QMgr where ADMIN.SVRCONN was expected; or 2) it's connecting to a different QMgr than expected. To even get that message the client had to have found *some* QMgr so it's the right one with the wrong definitions or the wrong one. The differences in behavior are hard to explain if the *only* action was to upgrade the QMgr in place. So I'm guessing there is more here we don't know yet – such as the QMgr was built on a new machine and moved over, or that clients were updated, etc.


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, September 12, 2013 8:02 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect attempts get 2035

I still don’t understand why Dave is having the problem he is.

From his description I assume both Case 1 and Case 2 are MQ Clients that were not themselves upgraded, therefore I assume any identifying data they were or were not sending to the QM has not changed. So why would upgrading only the queue manager server cause these 2035s all of the sudden?

Dave, are these clients Java based? Was the MQ Client upgraded as well, or just the MQ Server? What’s up with those channel not found errors – that makes even less sense if the only thing that changed was the QM’s MQ version.


Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of T.Rob
Sent: Wednesday, September 11, 2013 4:47 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect attempts get 2035

If the old connection attached as mqm, then set the MCAUSER('mqm') on the new channel. The old behavior of not sending a user ID in many cases was due to an insecure-by-default posture. It always allowed anonymous admin access, and was easily spoofed to be blank or mqm. The only connections using an actual valid ID were the very people you don't need to worry about. Setting MCAUSER('mqm') does not increase the exposure in the least, but it *does* make it more apparent that the QMgr leaks anonymous admin access. By reducing that false sense of security, people tend to be more aware of how exposed the thing is and thus act accordingly. Or somewhat more accordingly.

Note -- 7.5.0.1 queue manager has CHLAUTH(DISABLED)

Dave, you're KILLING me here. I have availability coming up if you want to actually fix this debacle, enable CHLAUTH and secure a few things. ☺

-- T.Rob



From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of David Awerbuch (BLOOMBERG/ 120 PARK)
Sent: Wednesday, September 11, 2013 16:22 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect attempts get 2035

I am hoping some one out there has already seen this issue during their upgrade cycle.

We upgraded a host with existing queue managers from 7.0.1.4 to 7.5.0.1. Our client applications are not able to connect to the queue managers using the existing svrconn channels and authorization records - 2035 errors.

1. User Application

Checked queue manager log, I see:

AMQ8077: Entity 'dbaseuser ' has insufficient authority to access object 'NEWSQMGR'.
AMQ9557: Queue Manager User ID initialization failed.

'dbaseuser' is an existing unix userid. until the upgrade to 7.5, the access through this srvconn was not an issue.
Note - the mcauser() field on the svrconn has always been and is blank.
I believe in the previous release (7.0.1.4) that this user would connect as user 'mqm'; thus no issues with connectivity and object access.

Now with 7.5.0.1 it looks like the real userid from the client connection header is being exposed to the authorization module. is this a correct assessment? Is there a way to restore this processing, or am I looking at a moving-forward series of changes to my application svrconns?

Note -- 7.5.0.1 queue manager has CHLAUTH(DISABLED)


2. WMQ Administration tool - web-based service

Checked queue manager log, I see this series of error messages; these are all generated by the same pid.tid:

AMQ9780: Channel to remote machine '1.2.3.4' is ending due to an error.
EXPLANATION:
Channel 'ADMIN.SVRCONN' between this machine and the remote machine
'1.2.3.4' encountered an error and will now end. In some cases the
channel name can not be determined and so is shown as '????'.

AMQ9519: Channel 'ADMIN.SVRCONN' not found.
EXPLANATION:
The requested operation failed because the program could not find a definition
of channel 'ADMIN.SVRCONN'.

AMQ9999: Channel 'ADMIN.SVRCONN' to host 'windowshost(1.2.3.4)'
ended abnormally.
EXPLANATION:
The channel program running under process ID 8392 for channel
'ADMIN.SVRCONN' ended abnormally. The host name is 'sysnyweb03
(1.2.3.4)'; in some cases the host name cannot be determined and so is
shown as '????'.

AMQ5653: The user 'windowshost$' is not defined.
EXPLANATION:
The system call getpwnam("windowshost$") failed with errno 2.

AMQ9557: Queue Manager User ID initialization failed.
EXPLANATION:
The call to initialize the User ID failed with CompCode 2 and Reason 2035.


Previous to the upgrade, this worked just fine.
Note - also in this case - the mcauser() field on the svrconn has always been and is blank.
so, the same premises and belief exists as above - in the previous release (7.0.1.4) this user would connect as user 'mqm'; thus no issues with connectivity and object access.

Now with 7.5.0.1 it looks like the machine name from the client connection header is being exposed to the authorization module; or the header contains the machinename with the appended '$'. Is this a correct assessment? Again, is there a way to restore this processing, or am I looking at a moving-forward series of changes to my admin svrconns?


Thanks.
Dave





------------------------------------------------------------
-------------------------------------------------------------------
David Awerbuch -- Systems Architect -- Middleware Infrastructure
email: ***@bloomberg.net<mailto:***@bloomberg.net> || ==== Bloomberg LP ==== ||
phone: + 1 646 324 2868 || Making Financial ||
WMQ support mq-***@bloomberg.com<mailto:mq-***@bloomberg.com> || Markets Transparent ||
-------------------------------------------------------------------
For all Trading Systems issues, please contact the TSCI 24-hour helpdesk.
- Americas - New York +1+212-318-2000
- Europe - London [phone]
- Asia - Tokyo [phone]
- Singapore [phone]


<< {IS} May you and yours be inscribed in the Book Of Life for health and happiness >>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


<< {IS} May you and yours be inscribed in the Book Of Life for health and happiness >>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

[David Awerbuch (BLOOMBERG/ 120 PARK)]

Hi Peter,

Nope, never got a 2035 on this; all was working pre-upgrade. For instance, we have a package using the 7.0.1.4 wmq client that connects to each queue manager and retrieves the object definitions for recovery purposes. That package runs everyday, and generates exception reports. The first execution after the upgrade threw exceptions (2035) on the upgraded queue managers on that host.

as a rule, we do not disable OAM; we rely on it on dev to ensure that developers from different teams only have access to their queue objects, and can not accidentally put or get messages using queue objets that they do not own. Yes, there are some common userids as well for integration testing in DEV; we cover those with OAM as well.

we're racking our brains on this as well. Everything was working fine. we simply upgraded the software, which in turn upgraded the queue manager (at strmqm time). we changed nothing else - that's is our standard process in dev environment; each step is done individually in order to trap issues and isolate problems to the individual step. from lessons learned in DEV, we update our automated processes and prove them on UAT before they even go near PROD; odds are we learn new things in UAT and update the processes accordingly.

We are very specifically not implementing new features of 7.5 that need to be turned on and configured, we will do these at a later time again after experimenting in DEV and proving in UAT; at this point we want to take advantage of current code-base and some of the new multiple cluster channel features.

I've opened the PMR with IBM. Have to provide them with more info. I will try to keep everyone informed of the resolution and other important facts that come out of this PMR.

Thanks for your assist. It is always appreciated.

Dave

----- Original Message -----
From: ***@LISTSERV.MEDUNIWIEN.AC.AT
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
At: Sep 13 2013 10:47:26



Did you ever get any 2035s on this QM before this upgrade? Maybe you had OAM disabled because it’s a DEV server with lax rules, and somehow the upgrade reenabled the OAM? Really grasping at straws here





Peter Potkay




From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of David Awerbuch (BLOOMBERG/ 120 PARK)
Sent: Thursday, September 12, 2013 2:26 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect attempts get 2035


To reply to both of these posts -



1. Peter: "I still don’t understand why Dave is having the problem he is." -- Thank you!! I thought I was crazy, but Peter just reaffirmed I am not -- at least when it comes to the issue at hand.


2. None of the clients anywhere were upgraded. They are 7.0.1.4 - the user application (case 1) is Linux, the admin tool (case 2) is Windows. The only steps taken were to upgrade the server software and then the individual queue managers to 7.5.0.1; no other changes were made. That's how you are supposed to test new software - change only one component at a time and leave everything else alone; if the upgrade does some config updates, these must be accounted for -- which is the case here, I am not able to account for this change in authorization.


3. User application (Case 1) is c/c++; admin tool (Case 2) is apparently Java - lots of jar files - but I am verifying with the vendor.


4. channel not found errors were extracted from the AMQERR01.LOG as generated by the upgraded WMQ server. The channels exist, their definitions were not changed by us - I am also not able to account for these errors.


5. T.Rob, I changed the channel names (all names, actually) in my original note for security purposes. The real channels, however, are correct and continue to exist.


6. If I were connecting to a different queue manager than expected, than I would not see these errors in the correct queue manager, I would see them in a different queue manager.


To re-iterate:

1. queue manager upgraded in-place

2. clients not upgraded

3. no config or other hosting or infrastructure changes


I remain as perplexed as you do.


Dave


----- Original Message -----
From: ***@LISTSERV.MEDUNIWIEN.AC.AT
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
At: Sep 12 2013 09:43:27


Well, the last question seems obvious
 The only way to get channel not found is 1) Someone defined SYSTEM.ADMIN.SVRCONN on the new QMgr where ADMIN.SVRCONN was expected; or 2) it's connecting to a different QMgr than expected. To even get that message the client had to have found *some* QMgr so it's the right one with the wrong definitions or the wrong one. The differences in behavior are hard to explain if the *only* action was to upgrade the QMgr in place. So I'm guessing there is more here we don't know yet – such as the QMgr was built on a new machine and moved over, or that clients were updated, etc.



From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, September 12, 2013 8:02 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect attempts get 2035

I still don’t understand why Dave is having the problem he is.

From his description I assume both Case 1 and Case 2 are MQ Clients that were not themselves upgraded, therefore I assume any identifying data they were or were not sending to the QM has not changed. So why would upgrading only the queue manager server cause these 2035s all of the sudden?

Dave, are these clients Java based? Was the MQ Client upgraded as well, or just the MQ Server? What’s up with those channel not found errors – that makes even less sense if the only thing that changed was the QM’s MQ version.



Peter Potkay


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of T.Rob
Sent: Wednesday, September 11, 2013 4:47 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect attempts get 2035

If the old connection attached as mqm, then set the MCAUSER('mqm') on the new channel. The old behavior of not sending a user ID in many cases was due to an insecure-by-default posture. It always allowed anonymous admin access, and was easily spoofed to be blank or mqm. The only connections using an actual valid ID were the very people you don't need to worry about. Setting MCAUSER('mqm') does not increase the exposure in the least, but it *does* make it more apparent that the QMgr leaks anonymous admin access. By reducing that false sense of security, people tend to be more aware of how exposed the thing is and thus act accordingly. Or somewhat more accordingly.

Note -- 7.5.0.1 queue manager has CHLAUTH(DISABLED)

Dave, you're KILLING me here. I have availability coming up if you want to actually fix this debacle, enable CHLAUTH and secure a few things. J

-- T.Rob




From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of David Awerbuch (BLOOMBERG/ 120 PARK)
Sent: Wednesday, September 11, 2013 16:22 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect attempts get 2035


I am hoping some one out there has already seen this issue during their upgrade cycle.



We upgraded a host with existing queue managers from 7.0.1.4 to 7.5.0.1. Our client applications are not able to connect to the queue managers using the existing svrconn channels and authorization records - 2035 errors.



1. User Application



Checked queue manager log, I see:



AMQ8077: Entity 'dbaseuser ' has insufficient authority to access object 'NEWSQMGR'.

AMQ9557: Queue Manager User ID initialization failed.



'dbaseuser' is an existing unix userid. until the upgrade to 7.5, the access through this srvconn was not an issue.

Note - the mcauser() field on the svrconn has always been and is blank.

I believe in the previous release (7.0.1.4) that this user would connect as user 'mqm'; thus no issues with connectivity and object access.



Now with 7.5.0.1 it looks like the real userid from the client connection header is being exposed to the authorization module. is this a correct assessment? Is there a way to restore this processing, or am I looking at a moving-forward series of changes to my application svrconns?



Note -- 7.5.0.1 queue manager has CHLAUTH(DISABLED)





2. WMQ Administration tool - web-based service



Checked queue manager log, I see this series of error messages; these are all generated by the same pid.tid:



AMQ9780: Channel to remote machine '1.2.3.4' is ending due to an error.

EXPLANATION:

Channel 'ADMIN.SVRCONN' between this machine and the remote machine

'1.2.3.4' encountered an error and will now end. In some cases the

channel name can not be determined and so is shown as '????'.



AMQ9519: Channel 'ADMIN.SVRCONN' not found.

EXPLANATION:

The requested operation failed because the program could not find a definition

of channel 'ADMIN.SVRCONN'.



AMQ9999: Channel 'ADMIN.SVRCONN' to host 'windowshost(1.2.3.4)'

ended abnormally.

EXPLANATION:

The channel program running under process ID 8392 for channel

'ADMIN.SVRCONN' ended abnormally. The host name is 'sysnyweb03

(1.2.3.4)'; in some cases the host name cannot be determined and so is

shown as '????'.



AMQ5653: The user 'windowshost$' is not defined.

EXPLANATION:

The system call getpwnam("windowshost$") failed with errno 2.



AMQ9557: Queue Manager User ID initialization failed.

EXPLANATION:

The call to initialize the User ID failed with CompCode 2 and Reason 2035.





Previous to the upgrade, this worked just fine.

Note - also in this case - the mcauser() field on the svrconn has always been and is blank.

so, the same premises and belief exists as above - in the previous release (7.0.1.4) this user would connect as user 'mqm'; thus no issues with connectivity and object access.



Now with 7.5.0.1 it looks like the machine name from the client connection header is being exposed to the authorization module; or the header contains the machinename with the appended '$'. Is this a correct assessment? Again, is there a way to restore this processing, or am I looking at a moving-forward series of changes to my admin svrconns?





Thanks.

Dave











------------------------------------------------------------
-------------------------------------------------------------------
David Awerbuch -- Systems Architect -- Middleware Infrastructure
email: ***@bloomberg.net || ==== Bloomberg LP ==== ||
phone: + 1 646 324 2868 || Making Financial ||
WMQ support mq-***@bloomberg.com || Markets Transparent ||
-------------------------------------------------------------------
For all Trading Systems issues, please contact the TSCI 24-hour helpdesk.
- Americas - New York +1+212-318-2000
- Europe - London [phone]
- Asia - Tokyo [phone]
- Singapore [phone]


<< {IS} May you and yours be inscribed in the Book Of Life for health and happiness >>


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com


<< {IS} May you and yours be inscribed in the Book Of Life for health and happiness >>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


<< {IS} May you and yours be inscribed in the Book Of Life for health and happiness >>

[Firoz Kotta]

For Item 1.
After we upgraded to 7501 we had noticed similar issues.
Most of our connections were not setting mcauser by default and the upgrade
did change the behavior.
In our case, we resolved the issue by creating the missing ids and setting
OAM perms that was reported in the logs. Note we had enabled environment
variables to extract this information.

I am assuming the behavior exhibited was probably masked in older versions
and 7501 could have actually fixed it ?

For Item 2.
- The system call getpwnam("windowshost$") failed with errno -

Here it seems the id "windowshost$" being passed by the tool is being
checked for existence locally where the queue manager is hosted and it
fails during lookup.



Best regards,

Firoz Kotta
(Cell) 732.470.9049
(Email) firoz.kotta-***@public.gmane.org
(vcard) http://firozkotta.businesscard2.com/


On Fri, Sep 13, 2013 at 10:58 AM, David Awerbuch (BLOOMBERG/ 120 PARK) <

Post by David Awerbuch (BLOOMBERG/ 120 PARK)
Hi Peter,
Nope, never got a 2035 on this; all was working pre-upgrade. For instance,
we have a package using the 7.0.1.4 wmq client that connects to each queue
manager and retrieves the object definitions for recovery purposes. That
package runs everyday, and generates exception reports. The first execution
after the upgrade threw exceptions (2035) on the upgraded queue managers on
that host.
as a rule, we do not disable OAM; we rely on it on dev to ensure that
developers from different teams only have access to their queue objects,
and can not accidentally put or get messages using queue objets that they
do not own. Yes, there are some common userids as well for integration
testing in DEV; we cover those with OAM as well.
we're racking our brains on this as well. Everything was working fine. we
simply upgraded the software, which in turn upgraded the queue manager (at
strmqm time). we changed nothing else - that's is our standard process in
dev environment; each step is done individually in order to trap issues and
isolate problems to the individual step. from lessons learned in DEV, we
update our automated processes and prove them on UAT before they even go
near PROD; odds are we learn new things in UAT and update the processes
accordingly.
We are very specifically not implementing new features of 7.5 that need to
be turned on and configured, we will do these at a later time again after
experimenting in DEV and proving in UAT; at this point we want to take
advantage of current code-base and some of the new multiple cluster channel
features.
I've opened the PMR with IBM. Have to provide them with more info. I will
try to keep everyone informed of the resolution and other important facts
that come out of this PMR.
Thanks for your assist. It is always appreciated.
Dave
----- Original Message -----
At: Sep 13 2013 10:47:26
Did you ever get any 2035s on this QM before this upgrade? Maybe you had
OAM disabled because it’s a DEV server with lax rules, and somehow the
upgrade reenabled the OAM? Really grasping at straws here…
*Peter Potkay*
Behalf Of *David Awerbuch (BLOOMBERG/ 120 PARK)
*Sent:* Thursday, September 12, 2013 2:26 PM
*Subject:* Re: upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect
attempts get 2035
To reply to both of these posts -
1. Peter: "I still don’t understand why Dave is having the problem he
is." -- Thank you!! I thought I was crazy, but Peter just reaffirmed I am
not -- at least when it comes to the issue at hand.
2. None of the clients anywhere were upgraded. They are 7.0.1.4 - the user
application (case 1) is Linux, the admin tool (case 2) is Windows. The only
steps taken were to upgrade the server software and then the individual
queue managers to 7.5.0.1; no other changes were made. That's how you are
supposed to test new software - change only one component at a time and
leave everything else alone; if the upgrade does some config updates, these
must be accounted for -- which is the case here, I am not able to account
for this change in authorization.
3. User application (Case 1) is c/c++; admin tool (Case 2) is apparently
Java - lots of jar files - but I am verifying with the vendor.
4. channel not found errors were extracted from the AMQERR01.LOG as
generated by the upgraded WMQ server. The channels exist, their definitions
were not changed by us - I am also not able to account for these errors.
5. T.Rob, I changed the channel names (all names, actually) in my original
note for security purposes. The real channels, however, are correct and
continue to exist.
6. If I were connecting to a different queue manager than expected, than I
would not see these errors in the correct queue manager, I would see them
in a different queue manager.
1. queue manager upgraded in-place
2. clients not upgraded
3. no config or other hosting or infrastructure changes
I remain as perplexed as you do.
Dave
----- Original Message -----
At: Sep 12 2013 09:43:27
Well, the last question seems obvious… The only way to get channel not
found is 1) Someone defined SYSTEM.ADMIN.SVRCONN on the new QMgr where
ADMIN.SVRCONN was expected; or 2) it's connecting to a different QMgr than
expected. To even get that message the client had to have found **some**
QMgr so it's the right one with the wrong definitions or the wrong one.
The differences in behavior are hard to explain if the **only** action
was to upgrade the QMgr in place. So I'm guessing there is more here we
don't know yet – such as the QMgr was built on a new machine and moved
over, or that clients were updated, etc.
*On Behalf Of *Potkay, Peter M (CTO Architecture + Engineering)
*Sent:* Thursday, September 12, 2013 8:02 AM
*Subject:* Re: upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect
attempts get 2035
I still don’t understand why Dave is having the problem he is.
From his description I assume both Case 1 and Case 2 are MQ Clients that
were not themselves upgraded, therefore I assume any identifying data they
were or were not sending to the QM has not changed. So why would upgrading
only the queue manager server cause these 2035s all of the sudden?
Dave, are these clients Java based? Was the MQ Client upgraded as well, or
just the MQ Server? What’s up with those channel not found errors – that
makes even less sense if the only thing that changed was the QM’s MQ
version.
*Peter Potkay*
*On Behalf Of *T.Rob
*Sent:* Wednesday, September 11, 2013 4:47 PM
*Subject:* Re: upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect
attempts get 2035
If the old connection attached as mqm, then set the MCAUSER('mqm') on the
new channel. The old behavior of not sending a user ID in many cases was
due to an insecure-by-default posture. It always allowed anonymous admin
access, and was easily spoofed to be blank or mqm. The only connections
using an actual valid ID were the very people you don't need to worry
about. Setting MCAUSER('mqm') does not increase the exposure in the least,
but it **does** make it more apparent that the QMgr leaks anonymous admin
access. By reducing that false sense of security, people tend to be more
aware of how exposed the thing is and thus act accordingly. Or somewhat
more accordingly.

Note -- 7.5.0.1 queue manager has CHLAUTH(DISABLED)

Dave, you're KILLING me here. I have availability coming up if you want
to actually fix this debacle, enable CHLAUTH and secure a few things. J
-- T.Rob
*On Behalf Of *David Awerbuch (BLOOMBERG/ 120 PARK)
*Sent:* Wednesday, September 11, 2013 16:22 PM
*Subject:* upgrade from 7.0.1.4 to 7.5.0.1 - all SVRCONN connect attempts
get 2035
I am hoping some one out there has already seen this issue during their
upgrade cycle.
We upgraded a host with existing queue managers from 7.0.1.4 to 7.5.0.1.
Our client applications are not able to connect to the queue managers using
the existing svrconn channels and authorization records - 2035 errors.
1. User Application
AMQ8077: Entity 'dbaseuser ' has insufficient authority to access object
'NEWSQMGR'.
AMQ9557: Queue Manager User ID initialization failed.
'dbaseuser' is an existing unix userid. until the upgrade to 7.5, the
access through this srvconn was not an issue.
Note - the mcauser() field on the svrconn has always been and is blank.
I believe in the previous release (7.0.1.4) that this user would connect
as user 'mqm'; thus no issues with connectivity and object access.
Now with 7.5.0.1 it looks like the real userid from the client connection
header is being exposed to the authorization module. is this a correct
assessment? Is there a way to restore this processing, or am I looking at a
moving-forward series of changes to my application svrconns?
Note -- 7.5.0.1 queue manager has CHLAUTH(DISABLED)
2. WMQ Administration tool - web-based service
Checked queue manager log, I see this series of error messages; these are
AMQ9780: Channel to remote machine '1.2.3.4' is ending due to an error.
Channel 'ADMIN.SVRCONN' between this machine and the remote machine
'1.2.3.4' encountered an error and will now end. In some cases the
channel name can not be determined and so is shown as '????'.
AMQ9519: Channel 'ADMIN.SVRCONN' not found.
The requested operation failed because the program could not find a
definition
of channel 'ADMIN.SVRCONN'.
AMQ9999: Channel 'ADMIN.SVRCONN' to host 'windowshost(1.2.3.4)'
ended abnormally.
The channel program running under process ID 8392 for channel
'ADMIN.SVRCONN' ended abnormally. The host name is 'sysnyweb03
(1.2.3.4)'; in some cases the host name cannot be determined and so is
shown as '????'.
AMQ5653: The user 'windowshost$' is not defined.
The system call getpwnam("windowshost$") failed with errno 2.
AMQ9557: Queue Manager User ID initialization failed.
The call to initialize the User ID failed with CompCode 2 and Reason 2035.
Previous to the upgrade, this worked just fine.
Note - also in this case - the mcauser() field on the svrconn has always
been and is blank.
so, the same premises and belief exists as above - in the previous release
(7.0.1.4) this user would connect as user 'mqm'; thus no issues with
connectivity and object access.
Now with 7.5.0.1 it looks like the machine name from the client connection
header is being exposed to the authorization module; or the header contains
the machinename with the appended '$'. Is this a correct assessment? Again,
is there a way to restore this processing, or am I looking at a
moving-forward series of changes to my admin svrconns?
Thanks.
Dave
------------------------------------------------------------
-------------------------------------------------------------------
David Awerbuch -- Systems Architect -- Middleware Infrastructure
phone: + 1 646 324 2868 || Making Financial ||
-------------------------------------------------------------------
For all Trading Systems issues, please contact the TSCI 24-hour helpdesk.
- Americas - New York +1+212-318-2000
- Europe - London [phone]
- Asia - Tokyo [phone]
- Singapore [phone]
<< {IS} May you and yours be inscribed in the Book Of Life for health and happiness >>
------------------------------
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage
Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1>-
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************
------------------------------
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage
Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1>-
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
<< {IS} May you and yours be inscribed in the Book Of Life for health and happiness >>
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************
<< {IS} May you and yours be inscribed in the Book Of Life for health and happiness >>

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html