wow, I think this is probably the longest title I ever used over here, but I wanted to draw attention to it anyway…
I will try to explain here (since I went for the public forum without much useful info) some issues I had when implementing the security model in a very strict environment
let’s start by describing the environment first:
the environment (all in the same AD dom & forest) consists of a central branch and about 15 other branches. most of the content and the overall structure and management of the environment will be done centrally, but in each branch you will have people that can also add new content, create collections and so on
we will stick with 1 Primary site with only DPs for the branches
we have a good naming convention where the branch name is put first in every collection and content, so eg: CET package 1 would be a package that must be available for everyone, whereas 100 package 1 would be a package that will be only available to the people of branch 100 (i’m trying to explain as basic as I can) – so this is useful to define scopes in cm12!
the content they get to see can thus be: centralized content accessible for everyone and their own content (so if I am the It guy in branch 100, I cannot see (or worse: delete) content that was made in branch 200
so basically security wise in cm12 this comes to creating 2 new custom roles : 1 for helpdesk people of the branch and 1 for the IT guys of the branch
then I created a scope for the central branch and one for each branch.
issue 1: how to use collection limiting in this environment?
remember: the branch guys must see the central collections AND their own collections.
I cannot give them access to the all systems collection, that would break things
solution: I created a new empty collection, lets say GLOBAL with limiting collection set to all systems.
then for every collection I want everyone to see/manage, I set the GLOBAL collection as limiting and not the all systems (this can be done with powershell)
(so the administrative user will get access to the global collection and his own decentral systems collection, thats all)
issue 2: how to use scoping in this environment?
remember: the branch guys must see the central content AND their own content.
solution: each branch scope must be set on ALL content you want them to see (do not give someone two security scopes)
by doing it this way, if the decentral guy creates new content, the proper security for his location will be added directly
issue 3: how to import a computer if one doesn’t have the default scope?
security wise in cm12 for this to happen the user must have the collection: read, modify and modify resource permissions and also the site: read and import computer information permissions (those were set in one of the new security roles)
BUT: since the decentral guys will not have the default scope, they CANNOT import a device!
solution: you need to give on the administration/site node also access to the non standard security scopes
issue 4: decentral IT guys cannot distribute content to a dp
the users security role already has the necessary permissions DP: copy to distribution point, DP Group: copy to distribution point group, but they do not see ANY DP
(also because they don’t have the default security scope)
solution: you must go to administration/distribution point and add the non standard scope (next to the default one which was already there) to one or more DPs.
issue 5: delegating the create collection privilege
the users security role already has the necessary permissions collection: CREATE but still he/she could not create a new collection?
solution: it seems you also need the permission MANAGE Folder
nice but this one creates a new hurdle to overcome: the user will be able to create new folders but also delete existing ones (so I cannot use this)
workaround: we created a device collection “_template collections” with one empty collection for each branch (where already the limiting collection is set). so all they have to do is copy their own template collection (they will probably only see one because of the collection limiting), rename it and move it to the appropriate folder, done!
Conclusion: if you are trying to accomplish some advanced security privileges in CM12, don’t give up too soon!
Ps: this is also a subject in one of my advanced SCCM 2012 trainings that should go on schedule later this year