Jump to content

Recommended Posts

Posted (edited)

64273-gpo-security-group-type-941152187cd2b608e51b1e30cfa523d6.jpg?stc=1

I've taken the task of going through our AD and giving it a sort of rewrite. Non of our groups are set up in an obvious, easy to understand way for delegation and access, and very few of them use the correct best practice method of PC/User > Global Grp > Domain Local Grp > Permission/Access.

 

GPO security filtering wise, does it matter what group scope I use? Many of our security filtered GPOs have groups on them, but they're all Global and work fine for policyscoping. I want to change them to DL groups for neatness and good habits, but is there a technical reason here too for things like replication? I would assume yes?

 

Do many of you use things like PaperCut or other third part apps that tie in to AD? Would you use G or DL groups there?

 

Thanks!

941152187cd2b608e51b1e30cfa523d6.jpg

Edited by Planehazza
Posted (edited)

LOL. Universal groups all the way baby!

 

I really can't remember why GG-DL group nesting was the recommended way of doing things in the training back in 2000, but I'm pretty sure unless you are running a multi-site with multiple domains in multiple forests there isn't any need to use global/domain local any more.

 

 

I used to implement local groups on servers to control access to resources on that server (members being groups from the domain)... however it became relatively straightforward swap groups on ACLs in the middle of last decadefifteen or so years ago, so I haven't bothered since, and using Universal Groups in ACEs certainly made the migration to SharePoint Online very straight forward - the permissions just came straight across!

 

 

FWIW we use "role" groups for each role their might be in school. A DH JD is a large collection of roles.

Some roles nest inside of each other.

access to resources are controlled via "resource" groups.

Resource Groups only contain "role" groups as members. (print permissions, file/share access, mailbox access, certain bits of SharePoint/ Office 365, MS 365 Licences etc etc)

Distribution groups also only contain "role" groups.

 

When someone joins or changes or gains a role, we made one change in AD and everything else just flows.

 

 

We prefix the groups so we know what type they are, and for each resource we might have three groups - _read, _write _fullcontrol. The terminology used matches the target resource nominclature. Each team (department etc) would have four role groups, _admin _leader _2ic/PostHoldeTitle, all nested in _member (because each of those roles is a member of the wider team role). Departmental _leader groups are members of the Head of Department distribution group, and the relevant budget group (for papercut reporting). _members groups are members of teh relevetn departmental budget group for print/photocopy charging. Since those in the _admin group have dotted line management to the Business Manager's team, they also are members of a support staff group. etc etc etc.

 

It keep permission neat while allowing a great deal of flexibility, and thanks to a reasonable pro-active HR team, the whole thing is basically seamless to users.

Edited by psydii
  • Thanks 1

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...