MQSeries.net :: View topic - Help with empty ApplIdentityData field of the MQMD

MQSeries.net

Tech Exchange

Education

Certifications

Library

Info Center

SupportPacs

FAQÂ Â

Usergroups

RSS Feed - WebSphere MQ Support

RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » Help with empty ApplIdentityData field of the MQMD

Goto page Previous 1, 2

Help with empty ApplIdentityData field of the MQMD

« View previous topic :: View next topic »

Author

Message

bruce2359

Posted: Wed May 18, 2011 1:39 pm Post subject: Re: Help with empty ApplIdentityData field of the MQMD

Poobah

Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.

LouML wrote:

By empty, I mean spaces

Code:

AMQSBCG0 - starts here
**********************
...
ApplIdentityData : ' '
...

and by not empty, I mean data we were expecting, in this case, username and password for an Exit on the Remote Queue Manager

Code:

AMQSBCG0 - starts here
**********************
...
ApplIdentityData : 'UsernamePassword '
...

I should add, that when I say 'empty', the following fields are space filled:

UserIdentifier, PutDate, PutTime, ApplOriginData

and when I say 'not empty', or 'it worked', those same fileds have valid data. Which seems to point to the suggestions Peter made earlier.

Are you saying that the ApplIdentityData field of the MQMD contains liteerally 'UsernamePassowrd' ?

If this is the case, then the creating application asked for, and was granted, MQPMO_SET_IDENTITY_CONTEXT and/or MQPMO_SET_ALL_CONTEXT authority.

If the app is executing with mqm authority OR without OAM, then there will be no check to see if the app has authority to set these fields in the MQMD.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.

PeterPotkay

Posted: Wed May 18, 2011 3:17 pm Post subject: Re: Help with empty ApplIdentityData field of the MQMD

Poobah

Joined: 15 May 2001
Posts: 7723

This may smack of semantics, but we are dealing with subtle nuances here so it needs to be precise.

bruce2359 wrote:

If this is the case, then the creating application asked for, and was granted, MQPMO_SET_IDENTITY_CONTEXT and/or MQPMO_SET_ALL_CONTEXT authority.

Maybe not. I suspect that if the QM is running without OAM, then the app can set these values without the QM checking if the proper options were set. This is just a guess based on the OP's posts so far.

bruce2359 wrote:

If the app is executing with mqm authority OR without OAM, then there will be no check to see if the app has authority to set these fields in the MQMD.

If OAM is on, security will be checked, even for the mqm ID. It just so happens that mqm will be granted all access. But maybe if OAM is enabled, it also verifies if the correct MQPMO option was used, which maybe in this problem it is not?
_________________
Peter Potkay
Keep Calm and MQ On

mqjeff

Posted: Wed May 18, 2011 5:44 pm Post subject: Re: Help with empty ApplIdentityData field of the MQMD

Grand Master

Joined: 25 Jun 2008
Posts: 17447

PeterPotkay wrote:

But maybe if OAM is enabled, it also verifies if the correct MQPMO option was used, which maybe in this problem it is not?

This isn't an entirely unreasonable possibility. It's, perhaps, unlikely, however, as one would sort of think that the authority checks would happen in a separate piece of code - even if only by a few lines - than the options checking code.

Best bet, really, is to follow mvic's suggestion of using strmqtrc to examine what the MQGET sees on input and output in the failing case and in the working case.

Or just trout the developers until they provide the code and stop thinking that it's okay to turn OAM off in development "because it makes things easier".

LouML

Posted: Thu May 19, 2011 10:23 am Post subject:

Partisan

Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY

Latest tests.

I had the developer send the same message three different times.

1 - To the Production MQ Server (version 6.0.2.5 - confirmed OAM enabled), over a client channel with mcauser('mqm') and the 'ApplIdentityData' field was space filled.

2 - To a Development MQ Server (version 6.0.2.5 - confirmed OAM enabled), over a client channel with mcauser('mqm') and the 'ApplIdentityData' field was space filled.

3 - To a QA MQ Server (version 7.0.1.0 - confirmed OAM enabled), over a client channel with mcauser('mqm') and the correct data appeared in the 'ApplIdentityData' field.

Any attempt to use a channel without mcauser('mqm') results in a Reason Code of 2035 (security error). By 'confirmed OAM enabled', I mean I tried a connection test to a Queue Manager using a channel without mcauser('mqm') and one with.

Code:

bash-3.00$ /opt/mqm/samp/bin/amqscnxc -x 'dev1(1411)' -c CH.TEST.CLIENT QM.TEST.01
Sample AMQSCNXC start
Connecting to queue manager QM.TEST.01
using the server connection channel CH.TEST.CLIENT
on connection name dev1(1411).
MQCONNX ended with reason code 2035
bash-3.00$ /opt/mqm/samp/bin/amqscnxc -x 'dev1(1411)' -c CH.TEST.CLIENT QM.TEST.01
Sample AMQSCNXC start
Connecting to queue manager QM.TEST.01
using the server connection channel CH.TEST.CLIENT
on connection name dev1(1411).
Connection established to queue manager QM.TEST.01
Sample AMQSCNXC end
bash-3.00$

So, we've removed any use of a non-OAM enabled QM from the scenario.

The developer has stated that he is using the IBM Message Service Client for .NET and has the following MQPMO options:

sendDestination.SetBooleanProperty(XMSC.WMQ_MQMD_WRITE_ENABLED, true);
sendDestination.SetIntProperty(XMSC.WMQ_MQMD_MESSAGE_CONTEXT, XMSC.WMQ_MDCTX_SET_ALL_CONTEXT);

From what I can see, regardless of what MQPMO options the developer is using, his app works when pointing to MQ Version 7+ and not with MQ Version 6+.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude

bruce2359

Posted: Thu May 19, 2011 10:45 am Post subject: Re: Help with empty ApplIdentityData field of the MQMD

Poobah

Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.

PeterPotkay wrote:

This may smack of semantics, but we are dealing with subtle nuances here so it needs to be precise.

Are you anti-semantic?

_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.

exerk

Posted: Thu May 19, 2011 11:12 am Post subject:

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

LouML wrote:

Any attempt to use a channel without mcauser('mqm') results in a Reason Code of 2035 (security error). By 'confirmed OAM enabled', I mean I tried a connection test to a Queue Manager using a channel without mcauser('mqm') and one with.

Have you tried THIS on the non-MCAUSER test to see exactly what is coming down the channel in terms of any user name being passed? As it's Windows on the client end I'd expect it to be the user under which the client is running, and it may then be worth creating and authorising that user on your V6.0 queue manager server and seeing what it does then.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.

mvic

Posted: Thu May 19, 2011 11:27 am Post subject:

Jedi

Joined: 09 Mar 2004
Posts: 2080

LouML wrote:

From what I can see, regardless of what MQPMO options the developer is using, his app works when pointing to MQ Version 7+ and not with MQ Version 6+.

Get a trace like in my post.

I reckon you'll find the XMS classes have done something different. Or at least that's the only way the above makes sense.

LouML

Posted: Thu May 19, 2011 11:29 am Post subject:

Partisan

Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY

exerk wrote:

LouML wrote:

I had not tried this.

I have now added the following to the .bashrc file for mqm on the Dev server running MQ Server 6.0.2.5:

export MQS_REPORT_NOAUTH=TRUE
export MQSAUTHERRORS=TRUE

I have stopped and restarted the queue manager.

The developers may have gone for the night and I (thankfully!) have a day off tomorrow, so we'll see what happens with the next test either soon or next week
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude

LouML

Posted: Thu May 19, 2011 11:30 am Post subject:

Partisan

Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY

mvic wrote:

LouML wrote:

From what I can see, regardless of what MQPMO options the developer is using, his app works when pointing to MQ Version 7+ and not with MQ Version 6+.

Get a trace like in my post.

I reckon you'll find the XMS classes have done something different. Or at least that's the only way the above makes sense.

I did run a trace in Version 6+ Production and the Version 7+ Dev. Still need to sift through the results.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude

LouML

Posted: Mon May 23, 2011 4:16 am Post subject:

Partisan

Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY

exerk wrote:

LouML wrote:

I've tried your suggestion.

To test it on my own,
I set the environment variables.
I stopped and restarted the queue manager.
I logged into another Soalris server as my own personal id.
I ran the amqscnxc sample connection test to the channel without 'mqm'.
I got the 2035 and saw the AMQ8077 error with my userid in the queue manager error log, followed by an AMQ9209
I also saw the *.FMT file in the /var/mqm/errors directory with myuserid in it

Then, I had the developer try the same channel (again, his app is on a windows server)
He got the 2035 error but I do not see an AMQ8077 error in the queue manager error log but I see an AMQ9208
I do see the *.FMT file in the /var/mqm/errors directory with his userid in it
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude

exerk

Posted: Mon May 23, 2011 5:55 am Post subject:

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

AMQ9208 is a communications error according to the manual, although that may be how the authorities error is being 'interpreted', i.e. an abend on the channel.

The chances are that the Windows developer does not have his userid defined on Solaris so no AMQ8077 errors should appear in the log. The only other things I can think to ask is whether the application code base is the same in both environments, and to restate - did you try defining the developers userid on Solaris to see what effect that has?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.

LouML

Posted: Mon May 23, 2011 6:00 am Post subject:

Partisan

Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY

exerk wrote:

AMQ9208 is a communications error according to the manual, although that may be how the authorities error is being 'interpreted', i.e. an abend on the channel.

I did not try to define the userid on Solaris, as I do not have that authority.

The application is exactly the same. Thney are always running it from the production box. They just change where it points, from a Prod server, to a Dev Server.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude

LouML

Posted: Tue Jul 26, 2011 9:36 am Post subject:

Partisan

Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY

Update.

Spent a lot of time with IBM trying to figure this. PMR was sent to .NET level 3 support. Eventually, my management got tired of waiting and told me to just upgrade MQ to 7.0.1.5. So, the Production server that was running 6.0.2.5 has been upgraded to 7.0.1.5.

The application no longer has the problem.

IBM never found the problem. They worked with the app owners directly. Had them run traces from their desktops. I supplied traces from the MQ server. Once the upgrade happened and the app worked, no one cared anymore about this issue.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude

exerk

Posted: Tue Jul 26, 2011 9:52 am Post subject:

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

LouML wrote:

...Once the upgrade happened and the app worked, no one cared anymore about this issue.

I'd like to say "how unusual" but I can't. All too familiar I'm afraid.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.

Display posts from previous:

Goto page Previous 1, 2

Page 2 of 2

MQSeries.net Forum Index » General IBM MQ Support » Help with empty ApplIdentityData field of the MQMD

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Protected by Anti-Spam ACP