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.
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.
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:
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.
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.
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.
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.The Everyone security principal is defined and managed by the Windows operating system and represents...
(see Understanding Group Accounts)
... 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 groupThis security principal previously included...
(see Understanding Group Accounts)
...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...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.
(see Microsoft Windows 2000 Security Configuration Guide: Appendix D - User and Group Accounts)
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
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 domainThus, 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...
(see WindowsITPro: Understanding the Authenticated Users Group and
Microsoft Windows 2000 Security Configuration Guide: Appendix D - User and Group Accounts)
...all users with a valid user account on the computer or in Active Directory services.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.
(see Microsoft Windows 2000 Security Configuration Guide: Appendix D - User and Group Accounts)
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.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.
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)
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 |
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:
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
- Domain Users Group
- 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.
No comments:
Post a Comment