SharePoint 2013 Notes: On using the Everyone group for SharePoint User Groups

Which AD group should the SharePoint administrator use for populating a SharePoint Visitors user group? In this Notes posting, I examine three security principals that  are often used for populating SharePoint "Visitors" user groups: Everyone, NT AUTHORITY\AUTHENTICATED USERS and [DOMAIN]\DOMAIN USERS.  At the end of this article, I provide my recommendation on which one is the best to use.  I would like to thank Tim MacLaughlin, a senior systems administrator, for providing helpful comments and insights on Active Directory concepts while drafting these Notes.

Background

The situation is, you are creating the security structure for a new SharePoint-based enterprise content management (ECM) system to be deployed in your customer company A.  You have a set of site collections, and each site collection corresponds to a customer organization within the customer's company A.  Each portal page of the site collection should be visible to everyone authenticated into the company A network, which is comprised of a single domain in a forest having trust relationships with several other forests among partner companies B, C and D that are all members of the same holding company E. You have developed a security architecture that entails each site collection having the standard SharePoint user groups: Owners, Designers, Contributors and Visitors with commensurate permission levels.  You want the Visitors group, which has SharePoint permission level Read, to be populated with a single AD group that will allow all company A users to view the portal of the site collection.  The same AD group should be used for all site collection visitor user groups.

You create the respective Visitors groups for each site collection.  You know there is an Everyone group that you can see appearing as you type it.  You're not sure about what other AD user groups that there might be and which AD group might be the best and/or most appropriate one to use.

Discussion

There are several groups that you can choose from.  Which one to use will likely depend on the direction of your systems administrators and security officer.  Let's look at what each one entails.

The Everyone Group

The Everyone security principal is frequently referred to as a "group" for convenience sake even in TechNet literature but is not actually a user group in the sense of being able to add and remove user accounts from it. It is one of the Windows special identities that:

...[does] not have specific memberships that can be modified.
(see Understanding Group Accounts)

The Everyone security principal is defined and managed by the Windows operating system and represents...

... all current network users, including guests and users from other domains. Whenever a user logs on to the network, the user is added automatically to the Everyone group
(see Understanding Group Accounts)

This security principal previously included...

...all users, even anonymous users and guests..[including] authenticated and unauthenticated users. In essence, every user who accesses the system is a member of the Everyone group...
(see Microsoft Windows 2000 Security Configuration Guide: Appendix D - User and Group Accounts)

However, this was changed for Windows 2003 and greater (see Understanding Group Accounts: Special Identities), where the Anonymous Logon group was no longer a member of the Everyone security principal by default.  You can still add it to Everyone, but this must now be done through security policy setting.

The Everyone security principal also includes a number of builtin accounts that you might not normally want to have authorized to connect to a site collection, such as:

• Guest
• SERVICE
• LOCAL SERVICE
• NETWORK_SERVICE
• SYSTEM

which exist independently on each Windows machine in the domain.   For a complete listing see: Windows Built-in Users and Default Groups and Default local groups. It also includes the  NT AUTHORITY\AUTHENTICATED USERS security principal, which encompasses users not only in the home domain, but also other domains in the forest trusted by the target domain and even in domains in other forests having inter-forest trust relationships with the forest of the home domain. Thus, the membership of the Everyone security principal is not centrally manageable at the domain level. Consider it as a superset of local security principals - one containing other local security principals and the NT AUTHORITY\AUTHENTICATED USERS principal.  As its name implies, its membership includes everything (except, by default, anonymous).  Thus, this security principal is not centrally manageable.

One additional note.  The Anonymous and Guest accounts in the context of SharePoint can be a bit confusing.  The reason being that SharePoint rests on top of IIS, and, if IIS is serving to Internet users, IIS must be configured to allow anonymous access. Now, if anonymous access is tied to a dedicated service account, there won't be any immediate problems. However, if you tie IIS anonymous access to the builtin Anonymous account, you've now opened up your system to everyone on the internet.

The AUTHENTICATED USERS Group

The NT AUTHORITY\AUTHENTICATED USERS is also frequently referred to as a "group" but isn't one in actuality.  Instead, like the Everyone "group," it is a:

...special security principal that specifies any session that's been authenticated using some account, such as a local SAM account, domain account, or account from any trusted domain
(see WindowsITPro: Understanding the Authenticated Users Group and 
Microsoft Windows 2000 Security Configuration Guide: Appendix D - User and Group Accounts)

Thus, it too is not a group in the sense of being able to add and remove user accounts from it, but is simply referred to as a "group" for the sake of convenience. The AUTHENTICATED USERS security principal is effectively a subset of the Everyone security principal and includes...

...all users with a valid user account on the computer or in Active Directory services.
(see Microsoft Windows 2000 Security Configuration Guide: Appendix D - User and Group Accounts)

Note that this encompasses not only the builtin local accounts but also any other local account.  Note too that, as discussed previously, AUTHENTICATED USERS includes not just users authenticated into the home domain of the home forest hosting the SharePoint farm but any user authenticated into another domain within that forest trusted by the home domain or domains in external forests.  Thus the pool of users encompassed by authenticated users is dynamic and can fluctuate depending on active directory configuration (see What's the scope of the built-in Authenticated Users group in a multi-forest Active Directory (AD) environment?).  Thus, the membership of the NT AUTHORITY\AUTHENTICATED USERS security principal is not centrally manageable at the domain level.

The DOMAIN USERS  Group

The [DOMAIN]\DOMAIN USERS group is a true user group in the sense that user accounts can be added to and removed from this group.  The DOMAIN USERS group is defined and managed at the Active Directory domain level.  This group...

...includes all user accounts in a domain. When you create a user account in a domain, it is automatically added to this group.
 
By default, any user account that is created in the domain automatically becomes a member of this group. This group can be used to represent all users in the domain. For example, if you want all domain users to have access to a printer, you can assign permissions for the printer to this group (or add the Domain Users group to a local group on the print server that has permissions for the printer).
 
The Domain Users group applies to versions of the Windows Server operating system listed in the Active Directory default security groups by operating system version.
 
This security group has not changed since Windows Server 2008.
(see Windows Server 2012: Active Directory Security Groups)

The DOMAIN USERS group is a true group.  It contains only users (not computers) that have authenticated to the local domain, and it does not include any user accounts from outside the domain. This group is updated automatically whenever a new user account in the local domain is created, modified, disabled or removed.

Since DOMAIN USERS includes all user accounts in the domain, it will also include all application service domain accounts, including those service accounts provisioned for your farm.  All of these application service accounts will potentially have data access to the SharePoint farm, at least at the View or Read level, if you use the DOMAIN USERS group to populate SharePoint site Visitors user groups like I do.  If you then use regular domain groups to populate SharePoint site Contributor and Member user groups (having Contribute and Edit permission levels respectively), the fact that application service accounts may have View or Read access to content may not be a significant security risk.

Another thing to bear in mind is that if a public-facing website is using anonymous access tied to a domain service account, if that domain account is broken, that account could then be used for unauthorized access to a site.

Lastly, rather than using the default DOMAIN USERS group for capturing all users authenticated into the domain, you may also wish to consider creating a custom regular domain group that you add all of your user accounts to. A regular domain group is completely manageable and it has the added benefit of enabling you to include users from other domains and forests having a trust relationship with the home domain.  It can also allow you to restrict access to a subset of domain users within the home domain rather than having to include all of them, such as, for example, excluding all application service domain accounts.  While populating this group may seem onerous when considering an environment of many thousands of users, it actually isn't.  The knowledgeable systems administrator can easily accomplish this using PowerShell and a CSV file of the users to be added; and some references for this are listed below.  Many more can be found through appropriate searches.

Review

Let's review what has been discussed thus far.  The table below lists the characteristics of the three security principals discussed in this article for ease of comparison.

Characteristic	Everyone	AUTHENTICATED USERS	Domain Users
Includes all users in external forests	Capable	Capable	No
Includes all computers in external forests	Capable	Capable	No
Includes all users in external domains	Capable	Capable	No
Includes all computers in external domains	Capable	Capable	No
Includes all computers in domain	Yes	Yes	No
Includes all users in domain	Yes	Yes	Yes
Includes all application service accounts in domain	Yes	Yes	Yes
Includes Windows builtin accounts	Yes	Yes	No
Includes local user accounts	Yes	Yes	No
Includes Guest account	Yes	Yes	No
Includes Anonymous	No	No	No
Centrally manageable at domain level	No	No	Yes

Of these three security principals, only the DOMAIN USERS AD group presents a static, well-defined, centrally manageable true user group that only includes authenticated domain users.  It is only this security principal that enables you (through your systems administrator) to have granular control over the membership of the group you use to assign all users a specific SharePoint permission level.  Of the three user "groups" discussed in these notes, only the DOMAIN USERS group would meet the requirement in the scenario presented in these notes of restricting access to the new ECM to users in the Company A domain.  If possible, an even better alternative is to use a regular domain group and populate that group only with user accounts of your actual users.  There are risks associated with all of these approaches, with the Everyone and AUTHENTICATED USERS security principals introducing the most risk, the DOMAIN USERS security principal introducing considerably less risk, and a regular domain group introducing the least risk.

Recommendation

When needing to assign a SharePoint permission level to all users, don't use the Everyone or AUTHENTICATED USERS "groups."  Instead, use the DOMAIN USERS Active Directory group appropriate to the domain in which your SharePoint farm resides.  Use this AD group when needing to, for example, assign the SharePoint Read permission level to all users in your organization.

You will need to assess the relative benefits of using this group against the potential risks of providing data access to your farm by:

• application service accounts and
• broken domain accounts tied to IIS Anonymous access

An even better approach, if your systems admin team will allow it, or if they have already implemented it, is to use a regular domain group populated only with accounts of your actual users.

References

• Authenticated Users Security Principal
• What's the scope of the built-in Authenticated Users group in a multi-forest Active Directory (AD) environment?
• KB143474: Restricting information available to anonymous logon users
• WindowsITPro: Understanding the Authenticated Users Group
• Everyone Group
• WindowsITPro: The Everyone Group
• SharePoint StackExchange: What is the Everyone Group in SP2013
• Domain Users Group
• See Active Directory Security Groups
• Active Directory Bulk Import
• Step-by-Step Guide to Bulk Import and Export to Active Directory
• Creating Bulk Users in Active Directory Using PowerShell
• Active Directory 2012 Tip: how to import users in bulk from a CSV
• General
• Microsoft Windows 2000 Security Configuration Guide: Appendix D - User and Group Accounts
• Understanding Group Accounts
• Well-known security identifiers in Windows operating systems
• Active Directory Security Groups
• Authorization, users, groups, and the object model in SharePoint
• Windows Built-in Users and Default Groups
• Default local groups

Notes

• Here's an example scenario that implements this recommendation:

  Scenario
   
  You need the portal page to your home organizational SharePoint-based itranet ECM solution to be accessible by all users across the home organization and only to users in the home organization.  The home organization is comprised of a single domain having some trust relationships with some other domains in the larger organization containing the home organization.  All users in the home organization should be able to at least read content at the portal page and download any files.
   
  Solution
   
  First, engage your systems administrators to verify that the Domain Users group is actively being used for the domain in which your farm resides or if there is another domain group they would rather have you use.  Verify with them too that all users having accounts in the domain also have their accounts added to this group. Once you have verified this, create a SharePoint user group Visitors in the site collection. Assign this SharePoint user group the Read permission level.  Populate this user group with a single member, [HOME DOMAIN]\Domain Users.  If you have activated Publishing for the site collection, also ensure that all users have Read permission to the Style and the Site Collection Images libraries, as Publishing pages will pull content from these document libraries.

• You may wish to consider including in your governance plan direction to your site collection administrators on the appropriate group to use when wanting to provide "everyone" access to some SharePoint site or resource.