|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
Resolved (2035 Not Authorized from APPMQUSR) |
« View previous topic :: View next topic » |
Author |
Message
|
csmith28 |
Posted: Tue Oct 05, 2004 10:42 am Post subject: @ Peter |
|
|
 Grand Master
Joined: 15 Jul 2003 Posts: 1196 Location: Arizona
|
No, this Development MQManager is being used by over 20 Development groups. I suppose I could bounce it but it would result in a lot of screaming, crying, rending clothing and general mass hysteria.
I forgot to mention that after the successfull test while MCAUSER was still set to APPMQUSR I also had the developer try to connect using her vbprogammer id and it failed. _________________ Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Oct 05, 2004 10:48 am Post subject: Re: @ Peter |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7723
|
csmith28 wrote: |
I forgot to mention that after the successfull test while MCAUSER was still set to APPMQUSR I also had the developer try to connect using her vbprogammer id and it failed. |
Then it has nothing to do with IDs! If they are connecting over a SVRCONN channel with an MCAUSER set, and failing, and another app is working, then it is not an issue with the ID they are using, since that ID is ignored. (The MCAUSER is used) And since the other app is working over the same channel, it proves the ID on the MCAUSER is OK.
Unless the failing app is trying to do something that the hard coded MCAUSER is not set to, but the succesful app is not trying that function. But it looks like you gave that ID full authority anyway, so I doubt it. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Oct 05, 2004 10:56 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7723
|
Are you POSITIVE the programmer is getting a 2035? If yes, is it on the MQCONN (????, based on all the above), or is it on the MQPUT, because the MQOPEN was done incorrectly.
We found a problem where VB client apps were setting spaces for the alternate user ID field. At 5.1 and 5.2, the spaces were ignored, and no ID was assumed, and it worked. At 5.3, spaces in that field is treated as a valid value for an ID, and as such, an attempt to use an alternate ID, and thus the MQOPEN needed to specify that option. Check that they aren't doing this. This would give a 2035 even if it was running with an ID with full authority. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
csmith28 |
Posted: Tue Oct 05, 2004 11:50 am Post subject: Re: @ Peter |
|
|
 Grand Master
Joined: 15 Jul 2003 Posts: 1196 Location: Arizona
|
PeterPotkay wrote: |
Then it has nothing to do with IDs! If they are connecting over a SVRCONN channel with an MCAUSER set, and failing, and another app is working, then it is not an issue with the ID they are using, since that ID is ignored. (The MCAUSER is used) And since the other app is working over the same channel, it proves the ID on the MCAUSER is OK.
Unless the failing app is trying to do something that the hard coded MCAUSER is not set to, but the succesful app is not trying that function. But it looks like you gave that ID full authority anyway, so I doubt it. |
No no, wait....
With MCAUSER(APPMQUSER) set APPMQUSER was able to connect with from both the AIX with amqsputc and W2K client app as APPMQUSER. What I was trying to explain is that with MCAUSER(APPMQUSER) set I had the developer also attempt to connect with her application throwing the vbprogrammer ID and it failed.
Am incorrect in thinking that vbprogrammer failed to connect via that SVRCONN Channel because the MCAUSER(APPMQUSER) value was set?
The vbprogrammer ID works with MCAUSER( ) but we can't use vbprogrammer when the application is rolled out because vbprogrammer=the developers personal ID. _________________ Yes, I am an agent of Satan but my duties are largely ceremonial.
Last edited by csmith28 on Tue Oct 05, 2004 12:04 pm; edited 2 times in total |
|
Back to top |
|
 |
csmith28 |
Posted: Tue Oct 05, 2004 11:52 am Post subject: |
|
|
 Grand Master
Joined: 15 Jul 2003 Posts: 1196 Location: Arizona
|
PeterPotkay wrote: |
Are you POSITIVE the programmer is getting a 2035? If yes, is it on the MQCONN (????, based on all the above), or is it on the MQPUT, because the MQOPEN was done incorrectly.
We found a problem where VB client apps were setting spaces for the alternate user ID field. At 5.1 and 5.2, the spaces were ignored, and no ID was assumed, and it worked. At 5.3, spaces in that field is treated as a valid value for an ID, and as such, an attempt to use an alternate ID, and thus the MQOPEN needed to specify that option. Check that they aren't doing this. This would give a 2035 even if it was running with an ID with full authority. |
Yes, positive. I saw the error during a NetMeeting Session.
I'll have to talk to vbprogrammer about that. Like I said I don't have access to the W2k server unless we set up a NetMeeting. But if I recall it is failing on the MQCONN. _________________ Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
Back to top |
|
 |
EddieA |
Posted: Tue Oct 05, 2004 2:28 pm Post subject: |
|
|
 Jedi
Joined: 28 Jun 2001 Posts: 2453 Location: Los Angeles
|
OK, to add my 2 pence to this. I'm currently trying to work out what's going on with a very similar problem.
I've got MQ 5.3 running on an AIX box. There is a group set up called mqgroup. This group has MQCONN authority.
With mcauser left blank.
I only have a local user who is a member of mqgroup. From this user, I can run both amqsbcgc and also a Java application that either doesn't set MQEnvironment.userID or sets it to a valid user in mqgroup. It the MQEnvironment.userID is not in mqgroup, then I get a 2035. All as expected.
From a remote machine, where the user is NOT part of mqgroup, running amqscbgc gives me a 2035. The Java application runs the same as above. (Don't ya just love the security of this. )
Now, if I change the SVRCONN to have mcauser('mqgroup'), everything fails with a 2035. Both local, and remote. amqsbcgc and Java. And YES, I did double check the mcauser was set correctly in lower case. And also that the failure was on the MQCONN.
So, I have to agree that there is something strange going on here.
Just for grins, I changed to mcauser('mqm'), and guess what. Everything WORKED.
Cheers, _________________ Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
Back to top |
|
 |
csmith28 |
Posted: Tue Oct 05, 2004 2:50 pm Post subject: |
|
|
 Grand Master
Joined: 15 Jul 2003 Posts: 1196 Location: Arizona
|
EddieA wrote: |
Just for grins, I changed to mcauser('mqm'), and guess what. Everything WORKED.
Cheers, |
I have not tried that but, hmmmmm. I am thinking it would still fail with APPMQUSR because APPMQUSR is not a member of mqm even though I have specifically set APPMQUSR's authorities, but it would succeed with my id mqadmin and vbprogrammer's ID because they are members of mqm. _________________ Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
Back to top |
|
 |
EddieA |
Posted: Tue Oct 05, 2004 2:59 pm Post subject: |
|
|
 Jedi
Joined: 28 Jun 2001 Posts: 2453 Location: Los Angeles
|
OK, I solved my problem. You have to put a USERID in mcauser, not a GROUP.
I'd assumed, wrongly, because you can only set authorisation at the group level in UN*X that a group name would work here.
Hangs head in shame, _________________ Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
Back to top |
|
 |
csmith28 |
Posted: Tue Oct 05, 2004 3:09 pm Post subject: |
|
|
 Grand Master
Joined: 15 Jul 2003 Posts: 1196 Location: Arizona
|
EddieA wrote: |
OK, I solved my problem. You have to put a USERID in mcauser, not a GROUP.
I'd assumed, wrongly, because you can only set authorisation at the group level in UN*X that a group name would work here.
Hangs head in shame, |
But mqm is a user and a group. Hmmm........
You may bang your head on the floor until forgiven.
But take of the helmet first. Wouldn't want to screw up your HUD display or the Night Vision thingy.  _________________ Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
Back to top |
|
 |
csmith28 |
Posted: Wed Oct 06, 2004 9:36 am Post subject: |
|
|
 Grand Master
Joined: 15 Jul 2003 Posts: 1196 Location: Arizona
|
Ok finally it works. I still don't know why I was having so much trouble with APPMQUSR but at this point I don't really care.
Today the new user I requested "appusr" was created. appusr is not a member of the mqm group.
I ran the setmqaut against the appusr ID.
I ran amqsputc successfully from my AIX Client Server.
I called vbprogrammer. She changed the ID in her code. She placed two messages on my MQManager and then retrieved them.
And, the pickled eggs I ordered arrived today. =] _________________ Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
Back to top |
|
 |
|
|
|
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
|
|
|
|