| Author |
Message
|
| mqseries0209 |
 Posted: Wed Aug 24, 2011 7:33 am Post subject: MQ security on Windows, domain account |
 |
|
Voyager
Joined: 30 Mar 2006
Posts: 90
|
Hi all,
I have the requirement to establish a security profile for some of the MQ application users on windows domain machines for View and Support role (able to delete messages of the queue and view channels)
The MQ Queue Manager is installed on about 50 individual windows servers all on one domain, lets call it DOMAINA
Here is what I am planning to do after I read about the security on windows here and would need your comments.
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=/com.ibm.mq.csqzas.doc/fa12800_.htm
1. Create two local groups on each windows machine in domain, one for View role and one for Support role, lets call it groups LVIEW and LSUPP
2. Create two domain groups one for View and one for Supp specific, lets call them DOMAINA/DVIEW and DOMAINA/DSUPP
Note that the domain view and supp group names are not the same as per the information from above link and do not want to complicate things
"The OAM first checks the local security database, then the database of the primary domain, and finally the database of any trusted domains. The first user ID encountered is used by the OAM for checking. Each of these user IDs might have different group memberships on a particular computer."
3. Ask the MQ App support team to add the specific domain users to thier specific profile groups DOMAINA/DVIEW and DOMAINA/DSUPP
4. Add domain groups DOMAINA/DVIEW and DOMAINA/DSUPP to respective local view and supp groups LVIEW and LSUPP
5. Run setmqaut on local groups with apropriate view and support authorities.
With the above solution, I need not set up security for each individual domain user on each queue manager, I can just run security at LOCAL group level and app team would
take care of adding domain users to thier respective domain accounts, which are part of local groups where security is run.
I am familiar with security for UNIX, but as this Windows is new to me, I would appreciate responses.
thanks...
_________________
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Integration Developer V6.0 |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Aug 24, 2011 7:45 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
And if one of the users has local admin on their machine and creates a user named "mqm"?
Or if they run a java program that does not pass their windows SID? |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 24, 2011 7:48 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
And if one of the users has local admin on their machine and creates a user named "mqm"?
Or if they run a java program that does not pass their windows SID? |
I think what my most worthy associate is getting at is that the scenario you've described ably controls legitimate, well-behaved users but doesn't provide an entirely secure WMQ estate. Additional measures to prevent (including but not limited to) the scenarios he mentions are required to fully protect WMQ assets.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Aug 24, 2011 9:32 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| Vitor wrote: |
| mqjeff wrote: |
And if one of the users has local admin on their machine and creates a user named "mqm"?
Or if they run a java program that does not pass their windows SID? |
I think what my most worthy associate is getting at is that the scenario you've described ably controls legitimate, well-behaved users but doesn't provide an entirely secure WMQ estate. Additional measures to prevent (including but not limited to) the scenarios he mentions are required to fully protect WMQ assets. |
Like specific channels for the roles, setting an MCAUserid on the channel and setting SSL with SSLPEER information.
Each user in the group can now receive an SSL cert and the PEER values will need to map to one of the groups / channels.
No need to shell out $$$ to a CA authority. Talk to your security group, most corporations have an internal CA authority...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 24, 2011 9:39 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fjb_saper wrote: |
| Like specific channels for the roles, setting an MCAUserid on the channel and setting SSL with SSLPEER information. |
 All the old familiar faces....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqseries0209 |
| Posted: Wed Aug 24, 2011 10:05 am Post subject: |
|
|
Voyager
Joined: 30 Mar 2006
Posts: 90
|
thanks for your responses, you may not be familiar with my name ... but I know exactly who would be responding to my post before I posted it and I was same guys ... u guys are awesome .....
thanks for your time.
I will take into consideration the notes from mqjeff and fjb_saper, but my concern here is will the solution outlined will work?
Sorry I did not get a chance to experiment on the solution, as it involves multiple teams and effort, I want to make sure it is a valid solution before engage resources on it.
Will the MQ security service identify and authorize the domain users from the domain group which is part of the local group where the security is configured at?
-thanks.
_________________
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Integration Developer V6.0 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Aug 24, 2011 1:42 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| mqseries0209 wrote: |
Will the MQ security service identify and authorize the domain users from the domain group which is part of the local group where the security is configured at?
-thanks. |
In my opinion, too much work.
What is needed is:
- define 2 groups
- set authorizations to the groups (setmqaut)
- define 2 or 3 users (user1 member of group1, user2 member of group2, user3 member of both groups?)
- run refresh security for the qmgr to pick up the changed security...
- define 1 svrconn channel per mcauser/group with appropriate SSL PEER values
- have a single SSL cert created for the user (client) where the OU field or field combinations (multiple ous) map to one of the channels and groups
- If you have users part of both groups, either create a 3rd channel with appropriate SSL and have the mcauser be part of both groups.
The SSL PEER information as requested on the channel will be checked against the SSL PEER information as presented by the cert. This will be in lieu of authentication and give you authorization as the cert is particular to a specific user.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqseries0209 |
| Posted: Wed Aug 24, 2011 5:46 pm Post subject: |
|
|
Voyager
Joined: 30 Mar 2006
Posts: 90
|
thanks fjb_saper
| Quote: |
In my opinion, too much work.
What is needed is:
define 2 groups
set authorizations to the groups (setmqaut)
define 2 or 3 users (user1 member of group1, user2 member of group2, user3 member of both groups?)
run refresh security for the qmgr to pick up the changed security...
define 1 svrconn channel per mcauser/group with appropriate SSL PEER values
have a single SSL cert created for the user (client) where the OU field or field combinations (multiple ous) map to one of the channels and groups
If you have users part of both groups, either create a 3rd channel with appropriate SSL and have the mcauser be part of both groups.
The SSL PEER information as requested on the channel will be checked against the SSL PEER information as presented by the cert. This will be in lieu of authentication and give you authorization as the cert is particular to a specific user. |
That was my initial idea as well except for the SSL set-up in there.
The only concern with above solution is when MQ queue manager fails over (MSCS cluster controlled) to its passive node, we cannot guarantee that the security will work as the group id (UID) may not be similar on the cluster windows machines.
I have to investigate this, if we can guarantee the UID's on WINDOWS can be set up similar to UNIX machines and there fore not have to worry about it.
I could achieve the similar functionality mentioned above with defining two domain users and defining security for domain users and setting mca user as the domain user on new channels created (one channel for each profile).
The advantage being I don't have to request creating groups on each of the multiple windows server machines.
OR I can start directly giving security for each individual user, but we cannot entertain that, as the users will be changing over a period of time and we do not have resources to take care of their changing needs (want to keep it to minimum).
Let me know what you think ..
peace.
_________________
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Integration Developer V6.0 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Aug 24, 2011 7:49 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| mqseries0209 wrote: |
That was my initial idea as well except for the SSL set-up in there.
The only concern with above solution is when MQ queue manager fails over (MSCS cluster controlled) to its passive node, we cannot guarantee that the security will work as the group id (UID) may not be similar on the cluster windows machines.
I have to investigate this, if we can guarantee the UID's on WINDOWS can be set up similar to UNIX machines and there fore not have to worry about it.
I could achieve the similar functionality mentioned above with defining two domain users and defining security for domain users and setting mca user as the domain user on new channels created (one channel for each profile).
The advantage being I don't have to request creating groups on each of the multiple windows server machines.
OR I can start directly giving security for each individual user, but we cannot entertain that, as the users will be changing over a period of time and we do not have resources to take care of their changing needs (want to keep it to minimum).
Let me know what you think ..
peace. |
For this to work in the MSCS cluster the best bet is following:
- qmgr system id is a domain id
- all groups defined to the qmgr are domain groups
- all ids used are domain ids
- all qmgrs in the MSCS are on a domain server (same domain)
So qmgr 1 on host 1 (active) and host 2 (passive).
Domain controller for domain A is primary on host 1 and secondary on host 2
This should resolve your problems where the uids and gids aren't in sync.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Aug 25, 2011 2:10 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
In practice, I have not found MSCS to be an issue in regard to GUIDs and have not yet had to install MSCS-controlled queue managers on DCs. That said, I may have yet to be bitten. I know that for MI queue managers there is a SID issue, hence the requirement for them to be on DCs, but would be interested in you expanding on your preference for MSCS-controlled queue managers to be on DCs.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Aug 25, 2011 8:24 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| exerk wrote: |
| In practice, I have not found MSCS to be an issue in regard to GUIDs and have not yet had to install MSCS-controlled queue managers on DCs. That said, I may have yet to be bitten. I know that for MI queue managers there is a SID issue, hence the requirement for them to be on DCs, but would be interested in you expanding on your preference for MSCS-controlled queue managers to be on DCs. |
Just covering all the bases. If the domain controller is not needed all the better.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Aug 25, 2011 12:52 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
I've supported MSCS clustered QMs for years. None on Domain Controllers.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| k_anand2585 |
| Posted: Thu Nov 10, 2011 5:05 pm Post subject: |
|
|
Acolyte
Joined: 03 Nov 2011
Posts: 50
|
Hi Peter,
Thanks for the information however the IBM vendor has insisted on us for purchasing Domain controller
MQ HA on windows cluster and multi instance needs Windows DC (Domain
Controller).
Windows Cluster (MSCS) need a Domain controller(DC). MQ HA needs MSCS
services for fail over. That is the relation between MQ and Windows Cluster.
Domain role: All servers in the cluster must be in the same Active Directory domain.
Domain controllers: We recommend that your clustered servers be member servers. If they are, other servers will be the domain controllers in the domain that contains your failover cluster.
Any Comments? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Nov 10, 2011 6:28 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
| k_anand2585 wrote: |
Any Comments? |
Multi Instance QMs and QM under the control of MSCS are not the same thing.
Multi Instance QM were not mentioned in this thread until your post.
QMs under control of MSCS do not need to run on Domain Controllers.
In the current versions of MQ, Multi Instance QMs on Windows do have the Domain Controller requirement.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| k_anand2585 |
| Posted: Sun Nov 13, 2011 10:34 pm Post subject: |
|
|
Acolyte
Joined: 03 Nov 2011
Posts: 50
|
Thanks a lot Peter,
Will try to setup and see how the working goes. |
|
| Back to top |
|
|
|
|
