Author |
Message
|
csmith28 |
Posted: Sun Oct 03, 2004 2:17 pm Post subject: Resolved (2035 Not Authorized from APPMQUSR) |
|
|
 Grand Master
Joined: 15 Jul 2003 Posts: 1196 Location: Arizona
|
The situation has changed um,....somewhat. See the bottom of this thread.
Quote: |
so today I decided to do some investigation to see if I couldn't resolve an issue that has been plaguing me for some time.
PLEASE READ THIS POST CAREFULLY BEFORE POSTING A RESPONSE.
I have two new Applications that want to use my MQManager as Clients to pass data back and forth.
Application_A is Visual Basic/Active X Application on a W2K Server that is trying to connect as a Client to my AIX 5.1.0.0/WMQ 5.3.0.6 MQManager.
The goal is that this W2K Client Application_A will be able to put messages on a Qlocal on my MQManager from which Client Application_B will get . Then Client Application_B will put a response on a differnent Qlocal that Client Application_A will then get.
From the beginning W2K MQClient Application_B using Java code has been able to connect to my MQManager without any problems. Application_B has been able to connect put and get since I created the two SRVCONN Channels, two QAliases and QLocals. No special authentication was set up when these objects were created.
Application_A using Visual Basic/ActiveX has not ever been able to connect to my MQManager. Application_A keeps getting 2035 MQRC_NOT_AUTHRORIZED.
I suspected that the VB/ActiveX application was sending the Developers ID to my MQManager by default so I asked her to specify mqm as the user. Per her she got the same result.
So I suggested that she have an application ID (appmqusr) created on my local AIX MQServer so she could pass the appmqusr to my MQManager using her code. I thought I could then use the setmquat command to specifically assign authority to the objects I created for this application. I specifically told her and her Project Manager that this ID should not be a member of the mqm group.
So then this Project manager runs off and submits a request to the Security Group. Mr. PM requests two new UNIX ID’s, vbprogrammer and APPMQUSR not appmqusr. He goes on to request that both of these new users be members of the mqm group.
Ever so helpful and vigilant the Security Group, without question created both ID’s on my AIX MQServer. <sighs>
He went on to request that the APPMQUSR be created on the Microsoft Domain. But when they created APPMQUSR on the Microsoft Domain they set it up so that APPMQUSR could not log on directly log on to any of the servers in that domain.
Now it should be understood that I do not have access to the W2K Server in question so I am a little handicapped in my ability to trouble shoot this issue but since I have no life I spent most of this morning invesigating this issue. I guess that is why I make the moderate bucks.
So from my perspective I am dealing four users:
$groups mqadmin (hehe this is me)
sysadmin vrtsadm mqm
$groups vbprogrammer (her)
audit mqm
$groups APPMQUSR
mqm
$groups mqm
mqm staff was
All four of these users can log on locally on the MQServer and they have all the authority one would expect as members of the mqm group. I simulated this by logging on as KEON root and su – to assume the ID of each of these users. The “dspmqaut –m QMGRNAME –t qmgr –p user” command shows that all four of these users have inq, set, connect, altusr, crt, dlt, chg, dsp, setid and setall authority.
Now mqm, mqadmin, vbprogrammer and APPMQUSR can successfully place a message to the MQManager using the “/usr/mqm/samp/bin/amqsput QUEUE.NAME” command when logged on to the MQServer.
Further more mqm, mqadmin and vbprogrammer can successfully use the “/usr/mqm/samp/bin/amqsputc QUEUE.NAME” command from the local MQServer and and an AIX Client AIX 5.1.0.0 Server that I was testing from.
But oddly enough APPMQUSR can not successfully run the “/usr/mqm/samp/bin/amqsputc QUEUE.NAME command to place a message on the mqmanager from the local MQServer or my AIX Client Server. It fails every time with 2035 MQRC_NOT_AUTHORIZED.
Indeed vbprogrammer can log on as herself on to the W2K Client Application Server and pass her credentials to my MQManager using her Visual Basic/ActiveX code successfully. She can also use the ampqsputc command successfully from her W2K server but still when she logs on as vbprogrammer and attempts to pass the APPMQUSR credentials we get continue to get the 2035 MQRC_NOT_AUTHORIZED.
What should I do. Should I have Security Delete vbprogrammer and APPMQUSR and start over?
I am not sure of the relavance of this but we use BOKS and KEON for auditing and security. When I log on I do not use a password I use a passcode that is generated by a Token.
When I su - mqm I assume mqm identity without further challenge because I am a member of mqm but when I su - I do not enter a password I once again enter a Token Generated Passcode. So then I am KEON root not true root.
When vbprogrammer telnets to my MQServer she is prompted for a password.
When APPMQUSR telnets to my MQServer it is prompted for a password.
BTW, I have been an MQAdmin on Unix Platforms for a long time. I am stumped.
I am not an MQ Application programmer. I am not a Visual Basic Programmer and you I could not fill a thimble with my knowledge of ActiveX.
I do know a bit about MQ Security and I can assure you all that I have not set up any special authenticaiton for the objects defined for this particular application. |
_________________ Yes, I am an agent of Satan but my duties are largely ceremonial.
Last edited by csmith28 on Wed Oct 06, 2004 9:21 am; edited 2 times in total |
|
Back to top |
|
 |
fjb_saper |
Posted: Sun Oct 03, 2004 6:57 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
A few facts about security:
On the windows platform (NOT JAVA API) you are always sending the user that is running the process.
What you need in order to have anybody running the process allow access is to set the MCAUser on the svrconn channel. Then your authorization is that of the mcauser.
Enjoy  |
|
Back to top |
|
 |
csmith28 |
Posted: Mon Oct 04, 2004 6:35 am Post subject: |
|
|
 Grand Master
Joined: 15 Jul 2003 Posts: 1196 Location: Arizona
|
fjb_saper wrote: |
A few facts about security:
On the windows platform (NOT JAVA API) you are always sending the user that is running the process.
What you need in order to have anybody running the process allow access is to set the MCAUser on the svrconn channel. Then your authorization is that of the mcauser.
Enjoy  |
I'm not sure that is it. But I'll try to have a look at it today.
Like I said, yesterday when I was testing, I was testing from an AIX Server. mqadmin, vbprogrammer and mqm could use the amqsputc sample to send a message to the MQManager but APPMQUSR could not. It fails with MQRC 2035 every time. Even though APPMQUSR is a member of the mq group.
Further vbprogrammer has no problem connecting as herself from her W2K Server. I have also been assured that when they try to connect as APPMQUSR he code is calling a VB Module that is running as a Service under the APPMQUSR ID. _________________ Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
Back to top |
|
 |
clindsey |
Posted: Mon Oct 04, 2004 8:31 am Post subject: |
|
|
Knight
Joined: 12 Jul 2002 Posts: 586 Location: Dallas, Tx
|
Quote: |
Further more mqm, mqadmin and vbprogrammer can successfully use the “/usr/mqm/samp/bin/amqsputc QUEUE.NAME” command from the local MQServer and and an AIX Client AIX 5.1.0.0 Server that I was testing from.
But oddly enough APPMQUSR can not successfully run the “/usr/mqm/samp/bin/amqsputc QUEUE.NAME command to place a message on the mqmanager from the local MQServer or my AIX Client Server. It fails every time with 2035 MQRC_NOT_AUTHORIZED.
|
This is the part that is puzzling to me. It seems you must have some mqaut overrides that are specific to this id. Maybe you should do a dmpmqaut and see what may be in effect for APPMQUSR.
Charlie |
|
Back to top |
|
 |
csmith28 |
Posted: Mon Oct 04, 2004 11:10 am Post subject: |
|
|
 Grand Master
Joined: 15 Jul 2003 Posts: 1196 Location: Arizona
|
OK, I have an update. I finally got APPMQUSR removed from the mqm group.
Then as mqm on the MQServer I ran:
Code: |
$ setmqaut -m TEST01 -t qmgr -p APPMQUSR +all mqi
The setmqaut command completed successfully.
$ setmqaut -m TEST01 -n MR.APP.REQ.QA01 -t queue -p APPMQUSR +all mqi
The setmqaut command completed successfully.
$ setmqaut -m TEST01 -n MR.APP.REPLY.QA01 -t queue -p APPMQUSR +all mqi
The setmqaut command completed successfully.
$ dspmqaut -m TEST01 -t qmgr -p APPMQUSR
Entity APPMQUSR has the following authorizations for object TEST01:
inq
set
connect
altusr
crt
dlt
chg
dsp
setid
setall
$ dspmqaut -m TEST01 -n MR.APP.REPLY.QA01 -t queue -p APPMQUSR
Entity APPMQUSR has the following authorizations for object
MR.APP.REPLY.QA01:
get
browse
put
inq
set
crt
dlt
chg
dsp
passid
passall
setid
setall
clr
$ dspmqaut -m TEST01 -n MR.APP.REQ.QA01 -t queue -p APPMQUSR
Entity APPMQUSR has the following authorizations for object MR.APP.REQ.QA01:
get
browse
put
inq
set
crt
dlt
chg
dsp
passid
passall
setid
setall
clr
|
Still from my AIX MQ Client server when I run:
Code: |
/usr/mqm/samp/bin/amqsputc MR.APP.REQ.QA01 TEST01
|
I get 2035. But when I run:
Code: |
/usr/mqm/samp/bin/amqsput MR.APP.REQ.QA01 TEST01
|
locally on the MQServer it works. _________________ Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Mon Oct 04, 2004 1:29 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
If you turned on Authority events for the QM, the SYSTEM.ADMIN.QMGR.EVENT queue will have a record of exactly what ID is failing on what MQ API call.
Try setting APPMQUSR on the SVRCONN channel's MCAUSER, and try the amqsputc again. If it works, then you know the client is not sending exactly APPMQUSR (Authority Events). If it fails, but works with amqsput local to the QM, hmmmmmmmmmmmmm.
Also, I think you should be setting the setmqaut commands at the group level, and not the principal level. UNIX MQ autorities are group level, not individual. I don't know if this will specifically solve your problem, but its a good habit. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
csmith28 |
Posted: Mon Oct 04, 2004 2:42 pm Post subject: |
|
|
 Grand Master
Joined: 15 Jul 2003 Posts: 1196 Location: Arizona
|
Code: |
alter chl(MR.TEST01.APP.CL01) chltype(SVRCONN) MCAUSER(APPMQUSR)
|
Once I ran the above APPMQUSR was able to run amqsputc from my Client Server but if I am I am not mistaken only APPMQUSR can now use MR.TEST01.APP.CL01
Personally I am ok with this but vbprogrammer is not.
I suspect that there is something wrong with the APPMQUSR or the way it was created. I don't know.
In the meantime I am having an entirely new id created on the MQServer to see if I can make that one work because I actually did make it work with another userid that wasn't a member of mqm.
I found two users on my Client Server that were not mqm members. We can call them notmqm1 and notmqm2. As both I attempted to run amqsputc to the MR.APP.REQ.QA01 and fail with 2035. Then I ran the setmqaut against these id's on the MQServer and both notmqm1 and notmqm2 were able to successfully execute amqputc.
@ Peter --- Per your suggestion I did enable authority events on TEST01. Since doing so, no new messages have been placed on the SYSTEM.AUTH.DATA.QUEUE and I have been testing all day. I am not sure what that is about.
I would like to once again thank everyone for there input regarding this issue. _________________ Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Mon Oct 04, 2004 7:36 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Quote: |
Once I ran the above APPMQUSR was able to run amqsputc from my Client Server
|
OK, so this kinda proves there is nothing wrong with the APPMQUSR ID, whether it is used locally or comes across the channel. But it does imply that with a blank MCAUSER, the client app is not sending exactly APPMQUSR. We gotta figure out exactly what she is sending.
Quote: |
but if I am I am not mistaken only APPMQUSR can now use MR.TEST01.APP.CL01
|
It means that anyone that happens to use this SVRCONN channel will have the authority of APPMQUSR, whatever you set it to.
Quote: |
I suspect that there is something wrong with the APPMQUSR or the way it was created.
|
I dunno. If APPMQUSR works locally (you are 100% sure what ID you are using), and it works when you hardcode it in the MCAUSER (you are 100% sure what ID you are using), that tells me the ID is OK, but that is not the ID being sent by the client.
UNIX is case sensitive, Windows is not. What if the client is sending appmqusr, and not APPMQUSR? I would think that would fail, if the UNIX QM is not folding the sent appmqusr to the expected APPMQUSR, and why would it. Try defining appmqusr (in a group that does not already have conflicting authorities set on any of its members), and use setmqaut on it.
Quote: |
@ Peter --- Per your suggestion I did enable authority events on TEST01. Since doing so, no new messages have been placed on the SYSTEM.AUTH.DATA.QUEUE and I have been testing all day. I am not sure what that is about.
|
??? Works for me. Maybe the QM needs a restart to pick up the change. The EVENT queue is not inhibited or anything, is it? _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Oct 04, 2004 7:40 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Quote: |
??? Works for me. Maybe the QM needs a restart to pick up the change. The EVENT queue is not inhibited or anything, is it?
|
How about running systematically after an authorization change:
Code: |
runmqsc <qmgr>
refresh security
end
|
 |
|
Back to top |
|
 |
PeterPotkay |
Posted: Mon Oct 04, 2004 7:45 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
refresh security would have no effect on whether autority events were being generated or not.
You only need to run refresh security if you have made changes to the OS's groups and or principles. When you add or delete IDs, the Queue Managers's OAM's cached info will not see this change, so you issue refresh security.
Anytime you run setmqaut, you are directly changing the QM's OAM's cache, so there is never a need to run refresh security just because you ran a setmqaut command.
refresh security is the same as bouncing the QM in respect to that cache, but obviously less intrusive. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
csmith28 |
Posted: Tue Oct 05, 2004 9:23 am Post subject: |
|
|
 Grand Master
Joined: 15 Jul 2003 Posts: 1196 Location: Arizona
|
fjb_saper wrote: |
Quote: |
??? Works for me. Maybe the QM needs a restart to pick up the change. The EVENT queue is not inhibited or anything, is it?
|
How about running systematically after an authorization change:
Code: |
runmqsc <qmgr>
refresh security
end
|
 |
Nope, PUT and GET are ENABLED.
I have run "refresh security" a few times. Mostly out of desperation, setmqaut updates the OAM dynamically or so I am told. _________________ Yes, I am an agent of Satan but my duties are largely ceremonial.
Last edited by csmith28 on Tue Oct 05, 2004 10:10 am; edited 1 time in total |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Oct 05, 2004 9:59 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Did you try defining the ID in lower case and running setmqaut against that? _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
csmith28 |
Posted: Tue Oct 05, 2004 10:01 am Post subject: @Peter |
|
|
 Grand Master
Joined: 15 Jul 2003 Posts: 1196 Location: Arizona
|
[guote]OK, so this kinda proves there is nothing wrong with the APPMQUSR ID, whether it is used locally or comes across the channel. But it does imply that with a blank MCAUSER, the client app is not sending exactly APPMQUSR. We gotta figure out exactly what she is sending. [/quote]
Ok, "without" the MCAUSER set to APPMQUSR I can run amqsput as that user locally. For example I log on as me su - to root then su - APPMQUSR. No problem.
Code: |
$ id
uid=****(APPMQUSR) gid=****(audit) groups=**(audit)
$ /usr/mqm/samp/bin/amqsput MR.APP.REQ.QA01 TEST01
Sample AMQSPUT0 start
target queue is MR.APP.REQ.QA01
test from local mqserver
Sample AMQSPUT0 end
$ /usr/mqm/samp/bin/amqsget MR.APP.REQ.QA01 TEST01
Sample AMQSGET0 start
message <test from local mqserver>
no more messages
Sample AMQSGET0 end
|
Then I log on to my AIX Client as me, su - to root then su - APPMQUSR.
Code: |
$ id
uid=****(APPMQUSR) gid=****(audit) groups=**(audit)
$ export MQSERVER=MR.TEST01.APP.CL01/TCP/hostname.domain.com
$ /usr/mqm/samp/bin/amqsputc MR.APP.REQ.QA01 TEST01
Sample AMQSPUT0 start
MQCONN ended with reason code 2035 |
Like I said yesterday, when I set the MCAUSER to APPMQUSR the amqputc was successfull from both my AIX Client and the W2K Client.
Then when I set MCAUSER back to ( ) the amqsputc failed from both the AIX and W2K Clients once again. So it is safe to assume that the W2K Application is throwing the correct ID.
Oh, and not sure why but there are still no new messages on my SYSTEM.AUTH.DATA.QUEUE. The depth has been 434 since I enabled "Authority Events" yesterday. I just double checked to make sure it is indeed enabled. _________________ Yes, I am an agent of Satan but my duties are largely ceremonial.
Last edited by csmith28 on Tue Oct 05, 2004 10:04 am; edited 2 times in total |
|
Back to top |
|
 |
csmith28 |
Posted: Tue Oct 05, 2004 10:03 am Post subject: |
|
|
 Grand Master
Joined: 15 Jul 2003 Posts: 1196 Location: Arizona
|
PeterPotkay wrote: |
Did you try defining the ID in lower case and running setmqaut against that? |
No but I have requested that a new/unique/lowercase ID be created as a member of the audit group, mqappusr as aposed to APPMQUSR.
I have to wait for out security group to create it and push it out from out Boks Master. _________________ Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Oct 05, 2004 10:20 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Quote: |
Then when I set MCAUSER back to ( ) the amqsputc failed from both the AIX and W2K Clients once again. So it is safe to assume that the W2K Application is throwing the correct ID.
|
I wouldn't say that. You still have no way of knowing exactly what ID that Windows MQ Client is sending. If it is sending knrkfnrkf, it will obviously fail with a blank MCAUSER, and be overidden with APPMQUSR if you have that hard coded in the MCAUSER.
I wish you're Authority Events were working, as this would give the ID. I just researched the Events Manual, and it does not say you have to, but did you restart the QM after turning on Authority Events? _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
|