| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Alternative user ID to run an execution group |
« View previous topic :: View next topic » |
| Author |
Message
|
| mqjeff |
 Posted: Thu May 15, 2014 9:16 am Post subject: |
 |
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Dave Ziegler wrote: |
| Maybe I'm missing something or not doing a very good job explaining. Basically, my sysadmins don't want to manage 20 DSNs on a box with stored passwords, nor do they want to manage passwords in mqsisetdbparms along with AD. They want all user passwords managed in AD only. I can do this now, but only per-broker instance. |
Yes, I do think I understand that.
But what I'm saying is that if IIB gets the ability to launch each EG under a different user, IIB will need to store the user credentials in order to do that - at least the username. And then the IIB main process will have to run as Administrator, or otherwise with sufficient elevated privileges to be able to launch processes as alternate users.
That is, I don't think the solution you're asking for does what you want, not really.
But that's just me, just my opinion.
And, again, you can do what you want today by putting more than one broker on the same box. It won't affect your licensing costs. |
|
| Back to top |
|
 |
| Dave Ziegler |
| Posted: Thu May 15, 2014 10:03 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2014
Posts: 118
|
Yes, understood. For my own greedy purposes, I only care about this from the SQL login side. I would totally expect to store at least a user name somewhere, no problem with that. We just have some password policy hurdles to get over with our infrastructure teams.
Out of curiosity, and knowing nothing about how z/OS works... how does this drive on that platform? Wouldn't this be a similar deal only in Windows?
Thanks for the discussion, Jeff. |
|
| Back to top |
|
|
| Tibor |
| Posted: Thu May 15, 2014 10:50 pm Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
| mqjeff wrote: |
| And, again, you can do what you want today by putting more than one broker on the same box. It won't affect your licensing costs. |
+1
Besides the broker process has very small memory overhead and minimal CPU consumption. |
|
| Back to top |
|
|
| Dave Ziegler |
| Posted: Fri May 16, 2014 6:02 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2014
Posts: 118
|
| Tibor wrote: |
Besides the broker process has very small memory overhead and minimal CPU consumption. |
...but still won't quite get me where I want to be in the end  |
|
| Back to top |
|
|
| Tibor |
| Posted: Fri May 16, 2014 6:14 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
| Dave, there is no message broker on Windows box here, so I cannot test this situation. My assumption would be that ODBC (with user DSN) can login with its own credential, but I have never tried it. |
|
| Back to top |
|
|
| Dave Ziegler |
| Posted: Fri May 16, 2014 6:18 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2014
Posts: 118
|
| Tibor wrote: |
| Dave, there is no message broker on Windows box here, so I cannot test this situation. My assumption would be that ODBC (with user DSN) can login with its own credential, but I have never tried it. |
Yeah, so what I've tried is configuring the ODBC connection with Windows auth vs. storing a uid/pwd. That works! But it is per-integration node and not per-server as we desire.
Thanks! |
|
| Back to top |
|
|
| zpat |
| Posted: Fri May 16, 2014 6:47 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5867
Location: UK
|
| Tibor wrote: |
| mqjeff wrote: |
| And, again, you can do what you want today by putting more than one broker on the same box. It won't affect your licensing costs. |
+1
Besides the broker process has very small memory overhead and minimal CPU consumption. |
Setting up a new QM and broker for full HA/CMP with separate SRDF filesystems, Qpasa, backups and all the rest takes significant effort.
It's not just about a quick crtmqm and mqsicreatebroker command as it might be in a lab environment.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri May 16, 2014 6:58 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Dave Ziegler wrote: |
| Tibor wrote: |
| Dave, there is no message broker on Windows box here, so I cannot test this situation. My assumption would be that ODBC (with user DSN) can login with its own credential, but I have never tried it. |
Yeah, so what I've tried is configuring the ODBC connection with Windows auth vs. storing a uid/pwd. That works! But it is per-integration node and not per-server as we desire.
Thanks! |
Again, you can put as many integration nodes on one box as you want.
And you can run them all as separate users.
But I agree that this can be significantly resource intensive.
especially compared to storing passwords in the windows ODBC control designed to store passwords...
Oh, and if you're feeling really experimental, you might see if you can play around with the server(eg) level profile to see if you can get that to alter the process id. I make no claims either way as to whether this *can* work. But it might. |
|
| 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
|
|
|
|
