When creating groups and assigning permissions to resources, put in the extra time initially to use the A-G-(U)-DL-A model - it will make future administration easier. Basically you put user accounts into global groups (based on their role) and then put global groups into domain local groups (based on the level of access required) and then assign permissions to the domain local group.
Example: Many different global groups need full access to the Quickbooks share. Create a group called "DL-Quickbooks-RW" and put all of the global groups (eg. "G-Accounting" and "G-Management") that need read/write access to the share within this group. In the ACL of the Quickbooks share, assign read/write permission to the DL-Quickbooks-RW group.
Best Practise: Even if only one user or group requires access to the resource, follow this model. It still carries all of the benefits and allows for future expansion and ease of maintenance.
This will allow you (or the next admin after you're gone) to say, with confidence, "I can know by looking at the resource (actually the security group that has permissions to the resource) which users have what permissions to the resource".
Example: You may want to know exactly what Bob has access to. Open his account and you'll see he's a member of G-Sales. Open G-Sales and you'll see a list of all the other sales staff, who have the exact same access as bob. You'll then be able to see that the G-Sales group is a member of DL-GeneralFiles-RO, DL-Sales-RW, DL-Drafts-RW, etc.
On the other hand, if you just apply permissions willy-nilly, after some time you'll end up with a morass of resources and permissions, and no understanding of how it all works. You will not be able to tell any auditors or management that you are in control of this fairly basic level of security.
Example: Under this scenario, you would have to check which groups Bob belongs to, and then open each file share and check it's ACL, probably missing something in the process. There may even be files which Bob alone has been granted access to. Without a documented list, this would be near impossible.
In multi-domain environments, Universal groups fit in between global and domain local.
