| Author |
Message
|
| oli |
 Posted: Mon Jan 15, 2007 2:03 am Post subject: Security for Development Environment for V6 |
 |
|
Acolyte
Joined: 14 Jul 2006
Posts: 68
Location: Germany
|
Hi all,
we want to set up a development runtime environment with a broker and configmgr V6 on a windows maschine that is not in a domain. The developers' message broker toolkits are installed on windows domain machines. The question is if it's possible to setup security in a way, that we do not need to create users on the configmgr/broker machine with ACL entries and stuff like that, so that any developer can connect to the configmgr.
In V5 we simply used an MCA User on the SYSTEM.BKR.CONFIG channel and all works fine without any additional effort.
This seems not to work with V6 any longer.
Does anybody how to setup such an environment?
Thanks,
Oli |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Mon Jan 15, 2007 3:20 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Did you set an ACL for the MCAUSER to grant it full access to configmgr?
The only ACL that exists with a new v6 configmgr initially is for the configmgr service user. Everything else has to be created with mqsicreateaclentry - and it has to be run as that configmgr service user.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| oli |
| Posted: Mon Jan 15, 2007 4:04 am Post subject: |
|
|
Acolyte
Joined: 14 Jul 2006
Posts: 68
Location: Germany
|
Hi jefflowrey,
I used the service user as MCA user and mqsilistaclentry shows
- USER - F - ConfigManagerProxy - ConfigManagerProxy
for that user.
Any ideas?
Thamk,
Oli |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jan 15, 2007 5:13 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
hrm. I guess I knew that wasn't sufficient. 
You do need to grant ACLs for each individual user, but with the MCA, those users do NOT have to exist on the box itself.
If you want to grant ACLS for a group, then you do need to create local users to put into the local group.
Your best bet, honestly, is to use the domain, and set up a domain group for the developers (or use an existing domain group - perhaps... "Domain Users").
Then for production, you can use local security and only grant acls to particular admin users.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| oli |
| Posted: Mon Jan 15, 2007 6:20 am Post subject: |
|
|
Acolyte
Joined: 14 Jul 2006
Posts: 68
Location: Germany
|
Hi jefflowrey,
setting up a domain group is not that easy 
But using the MCA User and creating an ACL entry for the user works even if the user does not exist on the ConfigMgr machine. At the moment that seems to be the best way for us to manage our development environment.
Thanks for your help.
Oli |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jan 15, 2007 6:39 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| oli wrote: |
| setting up a domain group is not that easy |
Yeah - that's why I suggested there might be an existing one that already had all the users you wanted in it - like the generic "Domain Users" group...
But that would require putting the server in the domain and creating the configmgr svc user in the domain or granting it priviledges to query the domain... And those might be just as difficult as creating a domain group..
In general, for dealing with Windows domains - I would put the dev environment in the domain and UAT and PROD using local security.
In general, for any kind of distributed authorizations, I'd do the same - dev using the global user store and UAT and prod using local user stores - it's much less prone to mistakes and creep.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
