| Author |
Message
|
| jefflowrey |
 Posted: Mon Oct 17, 2005 9:22 am Post subject: WMB v6 Security confusion |
 |
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I'm going through and reading the security section of the new WMB v6 Info Center.
I am trying to understand how to configure the following setup.
- All workbenches will be on windows
- Configmgr and all brokers will be on Unix.
- Workbench users are all in the same Windows domain
- All unix machines are only using local unix security.
- For simplicity sake, a UNS is not in use, all pub/sub is unauthenticated
It seems like "domain awareness" has stopped being a property of the ConfigMgr, and is now only a property of a particular ACL. Is this true?
In order to get this to work, I guess I need to do the following: - Create a mirror user (same name) of each workbench user in on the ConfigMgr's machine.
- Add necessary users to local groups on configmgr machine OR Create ACLs for users, using -a to remove "domain awareness"
- Disable the Domain Awareness of all of the workbenchs, so that user names flow to configmgr without Windows domain name included
Is this accurate? Missing a step or three? Doing stuff extra?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
 |
| paustin_ours |
| Posted: Mon Oct 17, 2005 1:41 pm Post subject: |
|
|
Yatiri
Joined: 19 May 2004
Posts: 667
Location: columbus,oh
|
is there a ACL -a flag to remove domain awareness?
the documentation on ACL permissions for V5 doesn't talk about this, or is it found somewhere else? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Oct 17, 2005 2:04 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| paustin_ours wrote: |
is there a ACL -a flag to remove domain awareness?
the documentation on ACL permissions for V5 doesn't talk about this, or is it found somewhere else? |
Well, I think in v5 that domain awareness is still a property of the config mgr, not of an individual acl.
The change seems to be in v6, with all mention of domain awareness pointing to acls, and the -a and -m options on mqsicreateacl.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| paustin_ours |
| Posted: Tue Oct 18, 2005 10:03 am Post subject: |
|
|
Yatiri
Joined: 19 May 2004
Posts: 667
Location: columbus,oh
|
in V5 when i define ACL's i cannot do cancel deployments. is this possible in V6 ACL's,
does moving the domain awareness to ACL in V6 have any effect on this? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 18, 2005 10:08 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| paustin_ours wrote: |
in V5 when i define ACL's i cannot do cancel deployments. is this possible in V6 ACL's,
does moving the domain awareness to ACL in V6 have any effect on this? |
I don't know.
I'm at the point of reading the documentation. I haven't tried stuff with it.
Maybe you should look at the documentation too.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mqmatt |
| Posted: Tue Oct 18, 2005 11:54 pm Post subject: |
|
|
Grand Master
Joined: 04 Aug 2004
Posts: 1213
Location: Hursley, UK
|
| paustin_ours wrote: |
in V5 when i define ACL's i cannot do cancel deployments. is this possible in V6 ACL's,
does moving the domain awareness to ACL in V6 have any effect on this? |
In V6 there is an ACL on the Config Manager object that gives you access to the domain-wide cancel deployment function.
Also, it's possible in V6 to cancel deployment to a specific broker, and this only requires broker authority.
Jeff, I've forwarded your first question on to an expert in this area - hope to have a clear answer (well, more than I could hope to write) for you shortly.
-Matt |
|
| Back to top |
|
|
| _dave_ |
| Posted: Wed Oct 19, 2005 8:29 am Post subject: |
|
|
Apprentice
Joined: 08 Apr 2005
Posts: 33
Location: IBM Hursley
|
Hi,
I am assuming that all your workbenches are v6 of the Message Brokers Toolkit.
Your steps are almost correct, the following is how it *should* work ...
1) Your step is correct - alternatively if you don't want to create these users, you can set the MCAUser
of SYSTEM.BKR.CONFIG to a (local) user who has MQ auths to connect to the QM and put/get
SYSTEM.BROKER.CONFIG.QUEUE and SYSTEM.BROKER.CONFIG.REPLY.
This will mean that from an MQ point of view, any connections coming in via that channel will
be authorised as the user you set. This obviously has security implications, so if this is a
concern, you may wish to also use Security Exits/SSL to further secure the connection.
2) The ACL entries for each user need to be created. You can either use -a which will check only
the username or -m <machine or domain name>. If you have unique usernames, there is no real advantage
of using -m, but if you have the same username on different machines/domains then you can use -m to give
them different authorisations.
3) There is now no facility to disable the domain awareness, but by using -a on the CM machine, and
domain/machine information is effectively ignored.
However, there are two problems in the released level of code which affect this area;
a) The MQ userid is incorrectly set to 'user@machine' rather than 'user', so the only real way to
allow the initial request to be put is to use the MCAUSER method described above (or disable MQ security).
b) The toolkit is unable to correctly determine the domain name and therefore sends the machine name.
This can be worked around by starting the toolkit (wmbt.exe) from within an MQSI "Command Console" (it is
a path problem and the console sets up the path correctly).
We hope to fix both of these problems soon via a fix pack. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Oct 19, 2005 9:36 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| _dave_ wrote: |
| I am assuming that all your workbenches are v6 of the Message Brokers Toolkit. |
Well, this is actually a hypothetical situation, but yes that was the assumption I should have been explicit about.
Well, it's hypothetical only in the sense that I personally am not involved right now in an attempt to build it. But I'm quite sure there are a number of IBM customers out there who want to build exactly this (+/- UNS).
| _dave_ wrote: |
| Your steps are almost correct, the following is how it *should* work ... |
Tires aren't all the way down, ehh? 
| _dave_ wrote: |
1) Your step is correct - alternatively if you don't want to create these users, you can set the MCAUser
of SYSTEM.BKR.CONFIG to a (local) user who has MQ auths to connect to the QM and put/get
SYSTEM.BROKER.CONFIG.QUEUE and SYSTEM.BROKER.CONFIG.REPLY.
This will mean that from an MQ point of view, any connections coming in via that channel will
be authorised as the user you set. This obviously has security implications, so if this is a
concern, you may wish to also use Security Exits/SSL to further secure the connection.
|
Right. I forgot that mq permissions are different than toolkit permissions.
| _dave_ wrote: |
2) The ACL entries for each user need to be created. You can either use -a which will check only
the username or -m <machine or domain name>. If you have unique usernames, there is no real advantage
of using -m, but if you have the same username on different machines/domains then you can use -m to give
them different authorisations. |
Okay. This confuses me. If I don't create mirror users, how can I create ACLs for those users? Do acl users not actually need to exist in whatever security domain the configmgr is using (in this case, the Unix local user registry)?
| _dave_ wrote: |
3) There is now no facility to disable the domain awareness, but by using -a on the CM machine, and
domain/machine information is effectively ignored. |
Could you be more explicit about this? As I said, it seems that the only place to use -a is at the ACL level, and not at the CM level. That is, the current info center documentation for mqsicreateconfigmgr and mqsichangeconfigmgr don't mention domain awareness at all. But the planning and security setup stuff talks about domain awareness. And it documents the -DDomainAwareness vmarg for the Toolkit.
| _dave_ wrote: |
However, there are two problems in the released level of code which affect this area;
a) The MQ userid is incorrectly set to 'user@machine' rather than 'user', so the only real way to allow the initial request to be put is to use the MCAUSER method described above (or disable MQ security). |
| _dave_ wrote: |
b) The toolkit is unable to correctly determine the domain name and therefore sends the machine name.
This can be worked around by starting the toolkit (wmbt.exe) from within an MQSI "Command Console" (it is
a path problem and the console sets up the path correctly). |
| _dave_ wrote: |
| We hope to fix both of these problems soon via a fix pack. |
I hope you already have interim fixes (as opposed to workarounds as outlined above)... I can see both of these causing implementation projects to go off track by a month or more.
I appreciate you taking time to discuss this.
And believe me, I'm not harranguing you about the usual unavoidable bugs that don't quite get ironed out by release date...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| thebeach |
| Posted: Wed Dec 28, 2005 11:58 pm Post subject: |
|
|
Apprentice
Joined: 30 Mar 2004
Posts: 47
|
Any updates(or fixes from IBM) on this V6 WBIMB issue?
I get a BIP0889E error(toolkit communication error when connecting to the CFG MGR), this is a permissions issue I beleive.
If I attempted to create an ACL I get this:
mqsicreateaclentry configmgr6 -u DOM1\smith -x F -b BROKER1 -a
BIP8214E: Object not found
The Configuration Manager repository object for which this ACL is being createddoes not exist.
Ensure that you have specified the correct object name (for example broker name), type and that the object has been defined to the Configuration Manager.
Thanks all. |
|
| Back to top |
|
|
| thebeach |
| Posted: Thu Dec 29, 2005 9:50 pm Post subject: |
|
|
Apprentice
Joined: 30 Mar 2004
Posts: 47
|
And surely the 'mqsi command prompt' is only availble where the CFG MGR is installed, the option is no available with a toolkit install?
wmbt.exe -vmargs -DDomainAware=0 from a normal dos prompt still passes the domain info(server@username) to the CFG MGR queue manager.
How is domainawareness turned off? |
|
| Back to top |
|
|
| hal |
| Posted: Thu Jan 05, 2006 11:01 am Post subject: |
|
|
Acolyte
Joined: 07 Dec 2005
Posts: 67
Location: New York City, New York
|
I was also getting BIP0889E errors when attempting to create domain connections from my Windows XP toolkit to UNIX WebSphere Business Integration Message Broker V6 components. The mqsicreateaclentry command with the -p (Configuration Manager Proxy/"All resources" Access Control Entry) switch fixed the problem:
mqsicreateaclentry ConfigMgr -u UNIXaccountName -a -x F -p
The UNIX account must be in the mqm and mqbrkrs groups. On the Windows side my account name shown in the Configuration Manager Proxy trace file contains my Windows domain: domain\accountName. My colleague's trace file account name contains her Windows machine name: accountName@machineName.
The UNIX WebSphere MQ V6 SYSTEM.BKR.CONFIG server connection channel's MCA user id is automatically populated with the account that issues the mqsicreateconfigmgr command. This does not seem to be documented anywhere, but blanking out the MCA user field still allows us to connect remotely via our V6 toolkits.
Last edited by hal on Thu Jan 05, 2006 2:59 pm; edited 3 times in total |
|
| Back to top |
|
|
| thebeach |
| Posted: Thu Jan 05, 2006 2:13 pm Post subject: |
|
|
Apprentice
Joined: 30 Mar 2004
Posts: 47
|
Yes, that was the issue. Its not neccessary to grant ACL permissions to the config manager in V6.
Thanks! |
|
| Back to top |
|
|
| ydsk |
| Posted: Mon Jan 23, 2006 1:35 pm Post subject: |
|
|
Chevalier
Joined: 23 May 2005
Posts: 410
|
It is necessary to grant permissions thru ACLs in v6, from what the Hursley guys are saying.
When you create a configmgr, an ACL is created by default which grants FULL access to the id on the configmgr. If you have the same user-id on a machine where you open the toolkit, you can access the configmgr thru it without creating any ACL explicitly because the default ACL that is created permits it.
If you are migrating your configmgr from v5 to v6 ACLs are automatically created for you based on the access permissions of the user-ids in the v5 configmgr.
The bottom-line is ACLs are a must in v6 to access a configmgr thru toolkit, whether you create them manually or the system creates them for you by default.
Thanks.
ydsk. |
|
| Back to top |
|
|
| halbster |
| Posted: Tue Feb 14, 2006 7:33 pm Post subject: |
|
|
Newbie
Joined: 08 Feb 2005
Posts: 6
Location: Australia
|
We had this same issue attemping to connect the Broker toolkit from a Windows client to a v6 Config Manager on AIX.
The answer posted above fixed our problem:
mqsicreateaclentry ConfigMgr -u UNIXaccountName -a -x F -p
Prior to creating this ACL we attempted using the command:
'wmbt.exe -vmargs -DDomainAware=0'
from the Windows client to bypass the domain, however instead of passing the doamin it passed the localhost name of the windows client and therefore made no difference.
Thanks. |
|
| Back to top |
|
|
| wmqiadmin |
| Posted: Mon Feb 27, 2006 12:35 pm Post subject: |
|
|
Disciple
Joined: 19 Jun 2005
Posts: 163
Location: epping UK
|
We have same problem connecting Win2003 Toolkit to Win2003 Config Mgr. I tried to run mqsicreateaclentry cmd on configmgr, its giving me timeout error. "Config mgr unable to response in stipulated time."
Did any buddy had this problem. Please guide me.
thanks |
|
| Back to top |
|
|
|
|
