There are numerous Microsoft suggestions for good practise, but the one I tend to remember is U-G-DL-P.
The idea is to assign users to Global 'Role based' groups, which are typically descriptive of the role that those users have e.g. 'All Staff' or 'Senior Managers' .
When securing resources, you create Domain Local 'Resource' groups specifically for that resource and the permission levels you want to assign e.g. 'PoliciesFolder_Read' or 'PoliciesFolder_Modify'. These groups are then assigned the appropriate permissions on the resource in question.
Finally, the Global 'Role' groups are added as members of the Domain Local 'Resource' groups.
This seems complex but has the advantage that it is self-documenting. Separating the groups out in this way means that it is always a simple job to find out what a user has access to, or who has access to a particular resource.
There will be occasions when it makes sense to add individual user accounts to the Resource groups, but this does not break the model.
The key thing is never to use the 'Role' groups to directly assign permissions on resources. If you do this, there is no way of tracking what resources a user has access to.
The one notable exception to this rule would be permissions on a user's home and roaming profile folders.
An extensions to this (for understanding and certs rather than what happens in real life):
I have several nested folders with default inheritance enabled. I assign
Folder2 - Deny: Read for user John (all other permissions are removed)
Folder3 - Allow: Read for user John (Deny: Read for user John is inherited but all other permissions are removed)
Folder4 and subsequent folders and files have inherited Deny: Read for user John and inherited Allow: Read for user John.
If John tries to read a text file in Folder5, he will be allowed to do so, even though both Allow: Read and Deny: Read are inherited. I realise that the interaction of explicit and inherited permissions at Folder3 come into play and makes the "Deny trumps Allow" rule fail.
Question: Is there any easy was to determine exactly where the inherited permissions were applied which affect files in Folder5? I know that I can look at the properties of each of the folders in turn but I wondered if there's (maybe a command line) utility that would tell me exactly where the Allow: Read and Deny: Read permissions for user John were applied.
I realise that, in real life, the number of nested folders should be kept as low as possible so I'm not really interested (at the moment) in best practice, just if it's possible to get the information easily from, say, 10 or 20 nested folders.
I hope that I've explained the question adequately. Thanks for everyone's time (and patience!).
There are currently 1 users browsing this thread. (0 members and 1 guests)