| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| 2035 on SVRCONN channel for UserID in mqm group |
« View previous topic :: View next topic » |
| Author |
Message
|
| PeterPotkay |
 Posted: Wed Nov 12, 2003 5:48 am Post subject: 2035 on SVRCONN channel for UserID in mqm group |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
rb99999 is in the mqm group on the server
dspmqaut shows the following:
| Quote: |
E:\>dspmqaut -m HIGIDGL1 -t qmgr -p rb99999
Entity rb99999 has the following authorizations for object HIGIDGL1:
inq
set
connect
altusr
crt
dlt
chg
dsp
setid
setall
|
The MCAUSER field of the SVRCONN channel is blank.
The error log shows this:
| Quote: |
11/12/2003 08:42:16
AMQ8077: Entity 'rb99999' has insufficient authority to access object
'HIGIDGL1'.
EXPLANATION:
The specified entity is not authorized to access the required object. The
following requested permissions are unauthorized: connect
ACTION:
Ensure that the correct level of authority has been set for this entity against
the required object, or ensure that the entity is a member of a privileged
group.
----- amqzfubn.c : 380 --------------------------------------------------------
|
???????
Now if that is not confusing enough, if I change the MCAUSER ID of the SVRCONN channel to be rb99999, he gets in fine!
Whats going on?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| emiranda |
| Posted: Wed Nov 12, 2003 5:59 am Post subject: |
|
|
Disciple
Joined: 21 Nov 2002
Posts: 196
Location: Dublin, Ireland
|
Is it an Windows box? I have experienced some delay time in security issues regarding to MQSeries on Windows boxes, even after a REFRESH SECURITY command.
If it's a test environment, a system restart could resolve... 
_________________
Warm Regards,
EM |
|
| Back to top |
|
|
| JasonE |
| Posted: Wed Nov 12, 2003 6:37 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
Do a refresh security and see if the problem persists. If it does, is the userid local or domain? Is there a userid with the same name in the opposite? How is membership to the mqm group acheived?
It does sound very odd. I could possibly take a look it you want me to - Contact me via a personal message if the problem persists, time permitting. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Nov 12, 2003 6:48 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I had refreshed security a bunch of times.
It is a Windows box. It must have something to do with domains.
My ID is defined on the box as part of a Global Group that is itself in the mqm group. That Global Group is prefixed with the domain I am in.
So I am guessing that the client is flowing over the Domain / ID (and not just the ID). Since rb9999 is defined on the box locally, it must not match?
And when I stick it on the MCAUSER, MQ treats it as a local ID, hence the match?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqonnet |
| Posted: Wed Nov 12, 2003 6:55 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Peter, this sure is very odd one.
Since you did not mention, let me add this note here.
On a Connect, authentication is done based on the userid that starts the listener, at least in this case. Because the MCA inherits the authorizations or rather uses the authority of the userid that started the listener. May be this could help, or may not.
Userid in MCAUSER does NOT come into picture until you do a put/get. At least thats how i understand this and thats what the manuals say too. So, it makes me wonder how everything works fine when the only thing that changes is "adding the user to MCAUSER".
This one got me for sure... :).
In any case, if you do get around this, please make sure to post your solution. I am really curious!!!
I havent worked much with domains, so i might be missing something that i am not aware of.
But i still doubt that would be the case.
I would suggest, you run a trace while you do this experiment and post it here. Lets see whats going on. Only if time permits, though. :)
Cheers
Kumar |
|
| Back to top |
|
|
| JasonE |
| Posted: Wed Nov 12, 2003 7:00 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
Can you expand on this:
| Quote: |
| My ID is defined on the box as part of a Global Group that is itself in the mqm group. That Global Group is prefixed with the domain I am in |
Is your machine a domain controller, a server in a domain or a standalone machine? Is the ID defined on this machine or on the domain controller?
| Quote: |
| So I am guessing that the client is flowing over the Domain / ID (and not just the ID). Since rb9999 is defined on the box locally, it must not match? |
How is the client flowing in the userid - Is it signed on as that id and picking it up? Dont forget it flows in the SID of the signed on user and uses that in preference.
What does dspmqaut ... -p rb9999@domain give compared to -p rb9999 |
|
| Back to top |
|
|
| mrlinux |
| Posted: Wed Nov 12, 2003 7:58 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
This maybe a case issue with the userid, If possible try creating the same userid with uppercase on the unix box
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Nov 13, 2003 7:05 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Well we got ol' rb99999 working and learned something in the process.
The Queue Manager in question is in domain ABC, while user rb99999 is in domain DEF. We have many domains here, not just these 2. An interesting thing I found was that I could run the dspmqaut command against any user in any domain from this one Queue Manager. The command sometimes took a little while to come back, but as long as the user I supplied was valid in some domain, it worked. If I put in a bogus ID, the dspmqaut command immediately errored. This server is not a Domain Controller. This domains are trusted between themselves.
All users in all domains came back with no authorities, except for the users that were defined as Admins on their PCs. In these case, dspmqaut showed that they had full authority for everything.
Nothing special for the users that came back with no authorities, they couldn't use MQExplorer over SYSTEM.ADMIN.SVRCONN that had a blank MCAUSER, and their MQ app couldn't connect over a regular SVRCONN channel with a blank MCAUSER.
But, for the users that were Admins on their PCs but were not defined locally on this server (but did show all authority), the access was a bit different. They were able to use MQExplorer, yet their apps still did not work. The Sys Admin Guide says that if a user of MQExplorer is himself an Admin on the machine running MQExplorer, they can get in regardless. It is interesting that the MQ apps still fail even though the UserID shows full authority. I guess its a good thing, otherwise any user with Admin rights would have 100% authority on all QMs everywhere. I think that dspmqaut command should not display full authority though. And I think just because a user is an Admin they shouldn't get access for MQExplorer autmatically.
Back to rb99999. Since he was in a different domain, his ID was flowing across as domain / ID, but was defined on the box as just ID only (local to the box). No match from MQ's perspective. If you fill in the MCAUSER with rb99999, it overrides the flowed domain / rb99999 with just plain rb99999, and MQ matches.
I got rid of rb99999 as a local user on the machine. I then added rb99999 to the global group (MyMQAdmins) that is prefixed with the domain. This global group is for domain DEF. rb99999 is in DEF. DEF / MyMQAdmins was already in the mqm group. At this point, rb99999 still could not connect. I ran the Refresh Security command on the QM, and finally rb99999 was able to connect as an app (since he was an Admin, he was able to use MQExplorer all along.)
The app in question was the MO71 Support pac, as well as the WatchQ Support pac. rb99999 is a fellow MQ Admin.
Kumar,
Authority checking is performed when a channel is connecting to the QM.
On a SVRCONN channel, if MCAUSER is blank, it is the ID of the client that is used for checking, unless a Security Exit overrides it, or the app is Java, in which case the ID of process that started the channel is used (mqm).
On all other channel types, if the MCAUSER is blank, then the ID of the process that started the channel is used, unless the PUTAUT is set to Context, in which case it will be the ID from the MQMD.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
