| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| RFHUtil 2035 Not authorized (Open) z/OS |
« View previous topic :: View next topic » |
| Author |
Message
|
| Rinku |
 Posted: Tue Jun 11, 2013 3:57 am Post subject: |
 |
|
Newbie
Joined: 07 Jun 2013
Posts: 5
|
Hi All...
Thank you again to all of you!!!!!
I played a little with batch script and had fun with it 
This is what I have done to stop passing my windows id and use the one ZOS understand. I wrote a small script to run RFHutil using my ZOS id.
== > contact admin /env /user:rasji0 "C:\ih03\rfhutilc.exe"
My Zos id is rasji0 and Ofcourse I had to create a dummy account rasji0 in my PC. But I run the tool under my current user id using this batch script.
This allows to run RFHutil under the user name rasji0...
And Guess what  it went through fine ...no more authorization issue....wolha
Again I appreciate all your time... Your information made me to think this way |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Tue Jun 11, 2013 4:56 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
| PeterPotkay wrote: |
| fjb_saper wrote: |
Most likely RFHUtilc flows a user id and MQExplorer does not...
|
MQ Explorer flows the User ID from the client machine up to the queue manager. |
One of these days, I'll have to take the time and check that. I always thought that if you did not specify a client ID, MQExplorer flowed a "blank" user id, thus giving the unsuspecting the power of the channel's agent Id (usually mqm or GOD) if no MCAUser was set on the channel...
|
I actually needed to test it before I replied originally. I wasn't sure and nothing in the Info Center that I could find.
I think what you are thinking of is something Roger posted here a while back. If you supply a dummy Security Exit on the client side it causes the UserID to be blanked out in which case it causes the connection to be started using the ID of the process that started the MQ Listener, which is usually an ID in the mqm group on Windows / *nix systems.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Rinku |
| Posted: Tue Jun 11, 2013 5:27 am Post subject: |
|
|
Newbie
Joined: 07 Jun 2013
Posts: 5
|
Ok to be more clear on this I did nothing means no setting changes for RFHUtil nor any security changes at ZOS qmgr end ( like adding my windows id to the channel)
I have access to ZOS and I can access the queue on ZOS.
All did I created a new windows user account ( username same as my zos id). And using the script I allowed the RFHUtil to run under new user account.
Originally RFHUTIL was sending the user name as RAMAKANT but now it sends the new user name.
And It has no problem at all to access to queue. All I did replace user ID RAMAKANT to rasji0 using the script.
Hope this explains well!!! |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 11, 2013 5:45 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| PeterPotkay wrote: |
| fjb_saper wrote: |
| PeterPotkay wrote: |
| fjb_saper wrote: |
Most likely RFHUtilc flows a user id and MQExplorer does not...
|
MQ Explorer flows the User ID from the client machine up to the queue manager. |
One of these days, I'll have to take the time and check that. I always thought that if you did not specify a client ID, MQExplorer flowed a "blank" user id, thus giving the unsuspecting the power of the channel's agent Id (usually mqm or GOD) if no MCAUser was set on the channel...
|
I actually needed to test it before I replied originally. I wasn't sure and nothing in the Info Center that I could find.
I think what you are thinking of is something Roger posted here a while back. If you supply a dummy Security Exit on the client side it causes the UserID to be blanked out in which case it causes the connection to be started using the ID of the process that started the MQ Listener, which is usually an ID in the mqm group on Windows / *nix systems. |
Actually, I think FJ is just remembering the old days when the Java client would not populate a windows userid if one was available. MQExplorer v6, IIRC, would not do this. Changes in the client in v7 made it easier and so MQExplorer started doing it, because it's more secure. |
|
| 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
|
|
|
|
