The question of the day comes from Linda:
I’m having an ‘urban sprawl’ problem with my permission groups. As it stands now, I have 70 (yeah 70) groups in ADUC for 7 pages of Sharepoint content. Oy vey. My security guys have me using ADUC, but you need to use Domain Local groups in Sharepoint, and Global groups in the Domain local groups, so I’m looking at 6 groups per ‘page’ – admins, users, and viewers. Is that normal I wonder?
Response from Paul Grenier
I think you may be in one of those Traps Mark warns us of. SharePoint allows users to take control of their Intranet environment through a system of permission inheritance. By closely coupling ADUC (Active Directory Users and Computers) groups to SharePoint groups, your IT team has started a tug of war over permissions with you in the middle.
Active Directory works well as a tool for grouping resources in a way that resembles the organizational hierarchy. But we know the knowledge needs to flow through an organization and rarely follows the organizational chart. IT usually creates broad groups in AD and uses individual permissions to authorize access based on user needs, roles, and experience. IT needs to understand that the users of SharePoint, like any other application, will have all levels of access–sometimes in the same AD group. But unlike other single-purpose systems, SharePoint could represent thousands of disparate business functions and millions of information nodes.
For instance, let’s say I work for a software company where the database server holds all customer databases. We have a database server for design and production. As a consultant, I need the ability to log into my customers’ databases. IT wants to limit access on an as-needed basis to ensure the best level of security for all customers. The DBA (DataBase Administrator) sets up three levels of access for each customer database (10 customers x 3 levels x 2 environments = 60 groups). And, since the DBA is a busy guy, IT sets up 60 AD groups to mirror those security levels and offers to manage the profiles in each group. Since the number of databases stays small and user roles rarely change, the solution works great.
Now apply the same security model to the phone book. Each phone number represents a household where the members of the household and their immediate family can edit the entry. They can identify anyone else in the phone book to add to their "readers" group–people who will know the current phone number. Now you have to administer the phone book. Try to keep up with the minute-by-minute changes to the phone records and access groups whether someone uses their access or not.
SharePoint allows item-level security with 33 different permissions. If you try to manage AD groups for each site, list, library, and document, you will overload yourself. And if you can not respond to new requests quickly enough, your users will not use the system. Users must be able to do their jobs better and faster with SharePoint or the implementation will fail.
I suggest training content and process owners to manage small islands of permissions through the use of SharePoint groups. These "mini-admins" will have the ability to manage the Readers and Contributors groups for their island but not allow them to make true administrative changes to the site or site security settings. This will ensure permissions are granted appropriately but remain agile enough to keep up with the pace of your business and the growth of your SharePoint site collection. — Paul