Permissions in SCCM are quite straight forward if used properly, but can easily become complex.
In Multi domain environment, the best practice is to use the Domain security Grups to delegate user to SCCM roles.
The key to understanding the security model is to review the elements that make up SCCM’s security model :
| Element |
SCCM definition |
| User |
Users are ‘user object’ entries from Active Directory. When adding a user to SCCM, you’re provided with an Active Directory object search prompt. Users are added to SCCM and are being granted access. In SCCM there are no group objects, so users cannot be grouped together |
| Permission |
Permissions are basically a ’level of access’. Access to an element could be ‘read’, ‘modify’, etc. |
| Right |
A right is a set of permissions that can be granted to a user object |
| Object class |
An object is any managable element in SCCM. Examples are packages, collections and advertisements |
| Instance |
A specific package for i.e. Microsoft Office 2007 is called an instance of a package. its specific advertisement is called an instance of an advertisments. So it’s safe to say every advertisement, package, collection, etc. are instances of their respective object classes |
Here is example of the basic groups that should be created in AD:
| Purpose |
Group Name |
Right description |
| View access |
SG_SCCM_View |
Can only view basic object classes |
| Retrieve asset intelligence |
SG_SCCM_Reporter |
Can design and run reports and queries in order to retreive system information |
| Patch management |
SG_SCCM_PatchMgr |
Is granted access to the software update module nodes (incl. required permissions to inherited object classes) |
| Software management |
SG_SCCM_SoftwareMgr |
Can manage packages, advertisements, collections |
| Operating system mgt |
SG_SCCM_OSDMgr |
Can manage operating system settings and additional object classes |
| Delegatees |
SG_SCCM_PowerUsers |
Power users can modify most of the object classes, except “site” |
| Site administrator |
SG_SCCM_Admin |
All rights |
It’s good habit not to assign explicit rights to users
Explicit rights assignments do not neccesarily take precedence over group inherited rights. Adding rights to users in SCCM adds up to the inherited rights. There are no explicit deny rights in SCCM, so you don’t have to worry about having conflicting rights.
It’s good habit not to assign explicit rights to users
Explicit rights assignments do not neccesarily take precedence over group inherited rights. Adding rights to users in SCCM adds up to the inherited rights. There are no explicit deny rights in SCCM, so you don’t have to worry about having conflicting rights.
Important Tip:
For these SCCM rights to be effective, the user must be a member of the SMS Admins local group on the SMS Provider computer. Adding user rights through the Object Class Security Right Properties dialog box or the Object Instance Security Right Properties dialog box does not give the user or group the necessary membership in SMS Admins
|
|