Using AD groups for permissions and security

Question

I have been researching the AD vs SharePoint group question and have found many conflicting answers.  We are beginning a SharePoint 2013 on-prem implementation for an intranet serving about 4000 users and I am trying to determine the best way to set Access Controls.  Currently, we are using WSS 3.0 and the permissions are handled completely through AD by our IT department.  We don't see any necessity for exposing users to other departments and will likely continue to go through IT to make permission changes.  Given this information, I wasn't able to find a definitive answer for the following questions:

1. I read that while possible, it is not a recommended practice to assign permission directly to AD groups without invoking SharePoint groups.  Why is this?
2. Nesting AD groups within SharePoint groups limits visibility of users that have access to a particular site.  Given that we likely do not want other departments to change permissions, is there any other functionality we would lose out on by using this model?  I read that there are some collaborative tools that we will not be able to use, such as people picker, Lync presence, something about mySite, but I wasn't able to find a definitive answer.  What are these tools that require adding users explicitly within SharePoint Groups?

Any help will be much appreciated.

Thanks.

Answer 1

1) Hard to keep track of permissions. Always 'nest' an AD group in a SharePoint group.

2) Nesting AD groups in SharePoint groups is identical to assigning permissions directly -- this is more of a management style and nesting is the preferred option.

Using AD groups you loose out on two things:

1) Instant update to permissions within SharePoint. It can take up to 24 hours, by default, for the user's ACL to change due to a group addition/removal due to SharePoint caching the group within the STS. More information about this, and how to adjust it to a lower time is available here - https://sergeluca.wordpress.com/2013/07/06/sharepoint-2013-use-ag-groups-yes-butdont-forget-the-security-token-caching-logontokencacheexpirationwindow-and-windowstokenlifetime/

2) You move 'control' and ultimately the management burden of the site to IT. My philosophy has always been "IT kills SharePoint". Or rather, the user's desire to use it due to strict IT control (in certain cases it makes sense, e.g. public website or company portal, but on general team sites I personally feel that IT shouldn't be involved in user management). Of course, you can delegate AD group management to end users, or use a product like FIM Portal, but that's expensive (I'm sure there are other cheaper 3rd party solutions that allow end users to manage AD security groups in a friendly way).

Using AD groups can/does have performance benefits:

http://blogs.msdn.com/b/kaevans/archive/2013/05/06/clarifying-guidance-on-sharepoint-security-groups-versus-active-directory-domain-services-groups.aspx

---

Trevor Seward

Follow or contact me at...

---

This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

Answer 2

So, to confirm, adding users directly to SharePoint groups provides flexibility in terms of managing permissions, but there aren't any other features that we would miss out on, correct? 

Dan Holme mentioned that we may lose collaboration functionality by directly nesting AD groups within SharePoint groups in one of his talks.  He recommended using a powershell script that takes the users in AD groups and enumerates them individually within SharePoint groups to get the best of both worlds.  I was trying to figure out what that 'collaboration functionality' is in addition to the permission flexibility since he did not elaborate on that, and if many organizations use this syncing approach instead of nesting the AD group directly within the SharePoint group.

Answer 3

My recommendation is to use AD Groups for major sites (think Departmental ones) where everyone needs to have "Read Access". You can certainly put those into SharePoint Groups which is cleaner (IMO) than assigning permission directly. However for team collaboration sites you are correct it's a much better practice to put users into the SharePoint groups. One example of functionality this would enable is a workflow that sends an e-mail to a SharePoint group. You need to have the individual members in the SharePoint Group in order for them to receive the e-mail. Otherwise you'd need to ensure that the AD Group is e-mail enabled which never seems to be the case.

Thanks,

-Jared

Answer 4

I don't think that adding users explicitly to a SharePoint group is a good idea purely from a performance perspective. 

Take a read of this blog post from Kirk Evans: http://blogs.msdn.com/b/kaevans/archive/2013/05/06/clarifying-guidance-on-sharepoint-security-groups-versus-active-directory-domain-services-groups.aspx