| Author |
Message
|
| PeterPotkay |
 Posted: Thu Jul 07, 2005 1:18 pm Post subject: MQ Authorities not cached? |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Yay!!! Another 2035 question.....
Windows 2000 MQ 5.3.0.8
I have a SVRCONN channel (CHANNEL.1), that has a hardcoded MCAUSER, ID1. ID1 is a domain ID, it does not exist locally on this server. setmqaut commands were run months ago for this ID, and the app has been using it fine.
Using amqscnxc from my desktop to connect to this QM over this channel takes up to 10 seconds to complete. Sometimes a couple seconds, but always slower than it should.
I have another SVRCONN channel (CHANNEL.2) with a hardcode MCAUSER, ID2, that is in the mqm group. If I use amqscnxc to connect to it, it snaps back instantly with a valid connection every time.
The application area that uses CHANNEL.1 says they get sporadic 2035s, and I do see these errors in the error log, which makes no sense. The error log says ID1 has not authority to connect to the QM, but it clearly does, and works 99% of the time. My theory is sometimes the authentication takes so long, MQ gives up, and throws the 2035.
What's up with that? Why is the MQCONN taking so long if the ID in question is a domain ID that has been authorized for months? I though MQ cached all its authorities at QM start up. Funny thing is if I try running the amqscnxc utility over and over in quick succession, it seems the MQCONNs complete faster. If I wait 10 minutes in between, they are slow. ????? I ran REFRESH SECURITY for ha-has, but that made no difference.
No FDCs.
Any ideas?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Jul 07, 2005 1:41 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I'd check the network connection to your domain controller.
MQ is authorizing the user against the domain. If it can't connect to that, or the performance is slow, then it will take longer to return back with a valid connection.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Jul 07, 2005 1:50 pm Post subject: Re: MQ Authorities not cached? |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| PeterPotkay wrote: |
| Any ideas? |
I thought anything that is either mqm or in the mqm group was excluded from any security routines that could throw some dirt on any access...
remember mqm is the one to rule them all ...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jul 07, 2005 1:52 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
He explicitly said "setmqaut", so I'm assuming the user is NOT in mqm.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Jul 07, 2005 1:54 pm Post subject: Re: MQ Authorities not cached? |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| PeterPotkay wrote: |
I have another SVRCONN channel (CHANNEL.2) with a hardcode MCAUSER, ID2, that is in the mqm group. If I use amqscnxc to connect to it, it snaps back instantly with a valid connection every time.
|
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jul 07, 2005 1:59 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
  
So he should remove ID2 from mqm, and use setmqaut to give it all the perms it needs, and then see the difference between the two.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jul 07, 2005 2:23 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Or assign the permissions to a local group and add the domain id to the group.
This might gain some speed against domain checking...
Enjoy  |
|
| Back to top |
|
|
| Tibor |
| Posted: Thu Jul 07, 2005 3:05 pm Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
Switch on the Autority Event and connect again. After any RC=2035 you can analyze the message(s) in the queue SYSTEM.ADMIN.QMGR.EVENT. I usually do it with MO71...
Tibor |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jul 07, 2005 4:30 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Tibor wrote: |
Switch on the Autority Event and connect again. After any RC=2035 you can analyze the message(s) in the queue SYSTEM.ADMIN.QMGR.EVENT. I usually do it with MO71...
Tibor |
I expect all that will show me is what the Windows MQ error log says "ID1 does not have "connect" authority to QM1.
I will create a local dummy ID, give it the setmqauts, and run the test against that, to see if its any better.
I wil also try fjb_saper's idea off adding the domain ID to a new local group, and seeing if that helps.
Still, I should not have to do this. Would any logs at the O/S level show some O/S activity where the server is trying to find out who ID1 is from the domain? MQ is simply waiting for the OS to validate the ID maybe?
(By the way to make matters a bit more complicated, the server is in DomainA, and the ID is defined in DomainB, and both Domains are trusted to each other. But before we jump on that, there are 6 other servers in this DomainA that have no problems at all with ID1 authenticating with MQ real quick like.)
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jul 08, 2005 3:37 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| PeterPotkay wrote: |
| Would any logs at the O/S level show some O/S activity where the server is trying to find out who ID1 is from the domain? MQ is simply waiting for the OS to validate the ID maybe? |
That's what I think.
Something like Ethereal will give you a good view of the network traffic while you're trying to authenticate, to see what's what.
I don't know if you can configure the Security Event log to trace this stuff.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bower5932 |
| Posted: Fri Jul 08, 2005 4:20 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| You could also try running a trace to see where the big delay is. It might shed some light on what is wrong. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jul 08, 2005 4:34 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
strmqtrc -t all -t detail ?
I would have to ship to IBM though, correct?
I created a local ID, no groups, and gave it setmqaut. It consistently works fast, but the original domain ID is still slow.
Is it OK to create a local group called XYZ, give XYZ the needed auths, and add the domain ID into that group? Like fjb said, maybe that would solve it. This is how we do it on Unix, but I though (maybe incorrectly?) that on Windows it was preferred (required?) to do it at the ID level.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jul 08, 2005 11:32 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Peter --
The individual level (usr) is never my preferred level. There is always some changes going on and you are never done with the maintenance....
Create a group and have them assign users to the group...
Change of usr ==> group maintenance (OS level) but no maintenance in MQ....
at worst a REFRESH SECURITY !
Enjoy |
|
| Back to top |
|
|
|
|
