| Author |
Message
|
| Dave Ziegler |
 Posted: Wed May 14, 2014 12:48 pm Post subject: Alternative user ID to run an execution group |
 |
|
Centurion
Joined: 15 Apr 2014
Posts: 118
|
We are a Windows/.NET shop and use Active Directory to manage users and passwords. Typically, our services connect to SQL Server via trusted connections.
There appear to be three options, and only two are currently supported:
1) One integration node, one AD account. All flows connect to SQL Server as this user.
2) Multiple integration nodes, each flow deployed under that node connects as the same AD user. More segregation here, but still not quite what we are after.
3) RFE 53622: each server (execution group) is configured with a separate AD account.
This would aid the debugging process when determining what flow or process can't connect or is having issues, will make our security team happy since we don't have one all-powerful AD account that can access any database, and will make our sysadmins happy since they won't have to maintain credentials and password expiration policies, etc. in multiple locations.
Please cast a vote for 53622 if you would find this useful!
http://www.ibm.com/developerworks/rfe/execute?use_case=submittedRFEs&SORT_BY=CREATE_DATE&SORT_ORDER=DESC&BRAND_ID=181&PROD_ID=532
Last edited by Dave Ziegler on Thu May 15, 2014 8:22 am; edited 1 time in total |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu May 15, 2014 3:31 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I'm really confused.
Why would you need this, when you can just use mqsisetdbparms to create an ID tied to the JDBC or ODBC DS, and can create as many ODBC/JDBC DS that point to the same database as you want?
Then you can assign a different DSN to each node that accesses any database, and you'll know which user it uses. |
|
| Back to top |
|
|
| Dave Ziegler |
| Posted: Thu May 15, 2014 5:06 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2014
Posts: 118
|
| Because we use trusted connections and don't want to manage uid and pwd in a separate store. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu May 15, 2014 5:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
OK.
So the broker is running on Windows, and you are talking to SQLServer, so you can again use standard SQLServer ODBC settings to store the userid/password that is used to connect - in the ODBC control panel.
Your RFE seems to be going a long way around a couple of easy solutions.
Among other things, it's easy enough to just spawn up lots of individual brokers, each with a single EG. It doesn't change licensing at all. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu May 15, 2014 5:41 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| mqjeff wrote: |
Among other things, it's easy enough to just spawn up lots of individual brokers, each with a single EG. It doesn't change licensing at all. |
nice idea Jeff. I knoe of a few sites where trying to implement such a solution would be impossible. The licensing police would be down on you like a ton of bricks. To them, 1 license means only one instance of the product running.
Trying to tell them that the IBM license is not like that is a complete waste of time.
That's life I'm afraid.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Dave Ziegler |
| Posted: Thu May 15, 2014 6:26 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2014
Posts: 118
|
| mqjeff wrote: |
use standard SQLServer ODBC settings to store the userid/password that is used to connect - in the ODBC control panel. |
I'm not storing this in the ODBC applet, just setting up the system DSN and specifying "With Windows NT authentication using the network login ID".
| mqjeff wrote: |
Your RFE seems to be going a long way around a couple of easy solutions.
|
It isn't mine, so at least one other person desires this. I just called attention to it because we would find it useful.
| mqjeff wrote: |
Among other things, it's easy enough to just spawn up lots of individual brokers, each with a single EG. It doesn't change licensing at all. |
Yep, that's what I was trying to suggest with option 2) in my original post. This is probably what we will have to do in the meantime, but we were cautioned to keep this to 5-6 instances at most (in our case on our hardware). |
|
| Back to top |
|
|
| zpat |
| Posted: Thu May 15, 2014 7:24 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Having different ids per execution group would provide better isolation for access to queues as well.
Currently any EG can access any queue, even ones that don't belong to that application, which is a security exposure, or at least an accident waiting to happen.
_________________
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 |
|
|
| Dave Ziegler |
| Posted: Thu May 15, 2014 7:27 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2014
Posts: 118
|
I believe it is already supported in z/OS... just nowhere else  |
|
| Back to top |
|
|
| zpat |
| Posted: Thu May 15, 2014 7:31 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Yes, I have mentioned it more than once in the last few years during WMB discussions with IBM at Hursley and was slightly disappointed that it only came out for the mainframe.
_________________
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 |
|
|
| Dave Ziegler |
| Posted: Thu May 15, 2014 7:34 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2014
Posts: 118
|
I mentioned it at Impact this year. It made it up on a white board and then got lost in the shuffle, so that was a little disappointing.
The Hursley guys I have been speaking to suggested I officially vote for this RFE, so they're aware that at least a few of us need it now. Hopefully this gains some momentum... |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu May 15, 2014 7:45 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Ok, so the link you posted didn't point to a specfic RFE, it pointed to a search result which included many RFEs.
Let's pretend for a moment that this is now possible, immediately, in v10. (Here's a hint, v10 is an Open Beta, subject to lots of feedback and potentially rapid response to customer requirements...)
You then want to configure a specific EG to run as a specific User. How do you expect to do that without storing the userid/password in some configuration somewhere?
The Broker main process is going to need to do an exec or contact admin or etc to launch the DFE process under the alternate credentials. Which means it needs to store those alternate credentials somewhere.
Again, in currently shipping versions of the product you can achieve your actual need using either mqsisetdbparms or the panels in the ODBC control panel. And this is then done on a *per DSN* basis, which gives you a lot more control over which ID is used where.
So I'm really not convinced that what you're asking for is a) any better, b) any more secure compared to the options available.
but I probably already voted for that RFE, if it's not a new one.
| smdavies99 wrote: |
nice idea Jeff. I knoe of a few sites where trying to implement such a solution would be impossible. The licensing police would be down on you like a ton of bricks. To them, 1 license means only one instance of the product running.
Trying to tell them that the IBM license is not like that is a complete waste of time. |
In this condition, I beat these people over the head with IBM sales reps.
but it's a waste of resources to do it this way, when again there are several other perfectly reasonable ways to do it. |
|
| Back to top |
|
|
| Dave Ziegler |
| Posted: Thu May 15, 2014 7:50 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2014
Posts: 118
|
| mqjeff wrote: |
| Ok, so the link you posted didn't point to a specfic RFE, it pointed to a search result which included many RFEs. |
Yeah, that's how it was provided to me by David Hardcastle. I listed the number at the start of this thread: 50726
| Quote: |
You then want to configure a specific EG to run as a specific User. How do you expect to do that without storing the userid/password in some configuration somewhere? |
Not my expectation at all, we use Active Directory accounts to manage uid/pwd and rely on trusted connections for database access from our applications. I want to try and do the same thing here. So what I've done so far is set up a system DSN, set it to Windows auth vs. storing uid/pwd there, reference the DSN in my database node, set up a SQL account pointed to the related AD account, and my trusted connection seems to work. I don't recall using mqsisetdbparms at all to add a password anywhere...? |
|
| Back to top |
|
|
| Dave Ziegler |
| Posted: Thu May 15, 2014 7:52 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2014
Posts: 118
|
Bummer... I just asked if I was voting for this in unix or Windows and unix since the RFE mentions unix specifically. Sounds like I have to open another RFE just for Windows  |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu May 15, 2014 7:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Dave Ziegler wrote: |
| Quote: |
You then want to configure a specific EG to run as a specific User. How do you expect to do that without storing the userid/password in some configuration somewhere? |
Not my expectation at all, we use Active Directory accounts to manage uid/pwd and rely on trusted connections for database access from our applications. I want to try and do the same thing here. So what I've done so far is set up a system DSN, set it to Windows auth vs. storing uid/pwd there, reference the DSN in my database node, set up a SQL account pointed to the related AD account, and my trusted connection seems to work. I don't recall using mqsisetdbparms at all to add a password anywhere...? |
Right, that's the alternative I mentioned, of essentially storing the userid/password in the DSN in the ODBC control panel. instead of putting it in the ODBC control panel store, you could store it using mqsisetdbparms. The odbc control panel store only works for SQLServer, last I knew. I could be wrong on that, though.
My point is, if the broker is given the ability to say "start this EG as User XYZ", it's going to need to store "User XYZ" somewhere. |
|
| Back to top |
|
|
| Dave Ziegler |
| Posted: Thu May 15, 2014 8:02 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2014
Posts: 118
|
| mqjeff wrote: |
Right, that's the alternative I mentioned, of essentially storing the userid/password in the DSN in the ODBC control panel. instead of putting it in the ODBC control panel store, you could store it using mqsisetdbparms. The odbc control panel store only works for SQLServer, last I knew. I could be wrong on that, though. |
But I don't want to store a password in either... I set up an ODBC system DSN with user ABC and set it to use Windows auth (no pwd stored there), then configure my broker instance to connect as user ABC which is also a SQL user (no pwd stored in SQL either) referencing the AD account.
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. |
|
| Back to top |
|
|
|
|
