I’m often chasing one SharePoint rabbit or another down a rabbit hole and spending hours there when I only wanted to ask the rabbit one simple question. In this case the question was who is “Everyone” and are they related to “NT AUTHORITY\Authenticated Users”. A simple question, or so I had thought. In this rabbit hole I found all kinds of interesting accounts, so I thought that I’d take a few notes while I was there. As to “Everyone”, I’ll follow up with another blog article. I also got distracted by two Office 365 users hanging around the hole named “Guest Contributor” and “Guest Reader” that will also get their own article.
If you would like to dive into the rabbit hole, here’s a few tools to investigate user accounts:
- PowerShell on prem:
$site = Get-SPSite http://yourDomain/sites/yourSite
$site2.RootWeb.AllUsers | FT –AutoSize - PowerShell for Office 365:
Get-SPOUser -Site http://yourDomain/sites/yourSite | Select DisplayName, LoginName - In the browser:
- Go to Settings (gear), Site Settings, People and Groups
- Edit the URL and change the GroupId to 0 (“?MembershipGroupId=0”)
- Click any interesting user name. If the user has a User Profile you will probably be redirected to their profile page. If not, you will be redirected to userdisp.aspx where you can see the user name and their internal Account property as listed in the table below.
- Third party security and auditing tools.
Claims Based Authentication SharePoint 2013 and later uses Claims Based Authentication which can support more than one authentication source. This slightly complicates the UserLogin property as it must have both the user name and the claims source data in the property value. In a non-Claims system the user name might be as simple as contoso\msmith. In a Claims system you need to know where the user was authenticated, so you end up with UserLogins that might look like i:0#.w|contoso\msmith for a Windows AD user or i:0#.f|ContosoFBA|susan for a Forms Based Authentication user.
If you would like to learn more about the Claims identity codes (“c:0!.s”, etc.) see: http://social.technet.microsoft.com/wiki/contents/articles/13921.sharepoint-2013-claims-encoding-also-valuable-for-sharepoint-2010.aspx
and
http://www.wictorwilen.se/Post/How-Claims-encoding-works-in-SharePoint-2010.aspx
The Users 
Who are all of these users? Well… I’m still negotiating with the rabbit for more details, but I’ll soon add these articles with what I have discovered:
SharePoint: All Users vs. Everyone vs. Everyone But External vs. NT AUTHORITY\AUTHENTICATED USERS SharePoint Online “Guest Contributor” and “Guest Reader” - Who’s Guest Contributor,
and what are they doing in my library? SharePoint internal and hidden accounts hiding in your Site Collection For now:
- NT AUTHORITY\AUTHENTICATED USERS represents all of the users in your Active Directory, on prem or in the cloud.
- Everyone at the AD level is NT AUTHORITY\AUTHENTICATED USERS plus the Guest account. The Guest is disabled both by default and as a best practice. (You don’t see this one in SharePoint, but it is often listed as being the same as the SharePoint “Everyone”.)
- Everyone is defined at the SharePoint level and includes all users authenticated to SharePoint.
- Everyone except external users is found in SharePoint Online / Office 365 and is as named. External users are people not in your Active Directory, most likely not employees, who got their access from site members clicking the SHARE buttons.
- All Users (<somename>) is SharePoint defined and represents all of the users from a selected authentication provider. (If I created a Forms Based Authentication provider named “Vendors” then I would have “Everyone (Vendors)”
- All Users (windows) is SharePoint defined and is same as NT AUTHORITY\AUTHENTICATED USERS. After adding “All Users (windows)” to a site it is displayed as “All Users (windows)” in 2013 on prem and 2016 on prem, but is displayed as NT AUTHORITY\AUTHENTICATED USERS in Office 365.
- Guest Contributor and Guest Reader are at this time only found in SharePoint Online / Office 365 and represent users with anonymous / link access.
Best Practices
I was reviewing some training materials recently and ran across a statement to the effect you should put NT AUTHORITY\AUTHENTICATED USERS in all of your site Visitors groups so everyone can find content in SharePoint. Should you do this? Should everything in your SharePoint be freely accessible to everyone who can logon to your network? Contractors, vendors, summer co-ops, part timers? If you don’t already have a policy or governance on this, then you should be working on it.
SharePoint does not give us any way to prevent the use of the “Everyone” accounts, so you will need to deal with this through education and auditing.
UPDATE! Anders Rask responded to this post with info about a SharePoint Online cmdlet that can hide these “everyone” options in the people pickers. Turns out there are three options:
Set-SPOTenant -ShowEveryoneClaim $false
Set-SPOTenant -ShowEveryoneExceptExternalUsersClaim $false
Set-SPOTenant -ShowAllUsersClaim $false
The Set-SPOTenant cmdlet: https://technet.microsoft.com/en-us/library/fp161390.aspx
Blog: https://blogs.office.com/2015/07/16/new-it-management-controls-added-to-onedrive-for-business/
Here’s a short list of best practices. The term “everyone” used here includes NT AUTHORITY\AUTHENTICATED USERS and any account that starts with “Everyone” or “All Users”.
- Educate your users on security, including the use of the “everyone” accounts.
- Do not use “everyone” accounts if a site contains non-public data.
- Document who “everyone” is. There’s more than one “everyone” group in SharePoint.
- Perform regular audits using PowerShell or 3rd party tools to track the usage of “everyone” groups.
- Document, audit and enforce your SharePoint content policies. Document what is allowed, and what is not allowed to be stored in SharePoint.
- If you do encourage the use of the “everyone” groups, add a banner to the top of every page that declares “Do not post confidential data in this SharePoint site! It can be seen by everyone with network access.”
The Built-In Accounts
While your SharePoint may vary… see the Notes column… here’s a list of the accounts that may include users other than those who you were expecting. This is not complete, so if you discover others please post a comment to this article.
DisplayName UserLogin or SystemUserKeyProperty Notes c:0!.s|forms%3amembership Only O365 c:0!.s|windows Same as NT AUTHORITY\ authenticated users All Users (yourFBAMembershipProviderName) c:0!.s|forms%3aYourFBAMembershipProviderName Form Based Authentication Everyone c:0(.s|true Everyone except external users c:0-.f|rolemanager|spo-grid-all-users/17b83262-5265-… Only O365 (ID will vary) NT AUTHORITY\ authenticated users c:0!.s|windows Guest Contributor SHAREPOINT\writer_9e8a77849f89425c9cff6a6af5175… ID varies with share Guest Reader SHAREPOINT\reader_cb6f6371456b4542ba0609638a4… _SPOCacheFull ylo001\_spocachefull Only O365. Visible only from PowerShell _SPOCacheRead ylo001\_spocacheread Only O365. Visible only from PowerShell _spocrawler_17_3910 ylo001\_spocrawler_17_3910 Only O365 (ID will vary) System Account SHAREPOINT\system Visible only from PowerShell System Account S-1-0-0 SystemUserKeyProperty Company Administrator s-1-5-21-1851826741-1401831065-3463747319-87287… Only O365 (ID will vary) Typical user (Sam Conklin) samc@yourDomain.onmicrosoft.com As seen in O365 PowerShell Typical user (Sam Conklin) i:0#.w|yourDomain\samc As seen in On Prem PowerShell Typical user (Sam Conklin) i:0).w|s-1-5-21-2499188511-2905385804-3446143336-… SystemUserKeyProperty Typical FBA user (Susan) i:0#.f|YourFBAMembershipProviderName|susan Form Based Authentication
.
SharePoint 2013 and later uses Claims Based Authentication which can support more than one authentication source. This slightly complicates the UserLogin property as it must have both the user name and the claims source data in the property value. In a non-Claims system the user name might be as simple as contoso\msmith. In a Claims system you need to know where the user was authenticated, so you end up with UserLogins that might look like i:0#.w|contoso\msmith for a Windows AD user or i:0#.f|ContosoFBA|susan for a Forms Based Authentication user.
If you would like to learn more about the Claims identity codes (“c:0!.s”, etc.) see: http://social.technet.microsoft.com/wiki/contents/articles/13921.sharepoint-2013-claims-encoding-also-valuable-for-sharepoint-2010.aspx
and
http://www.wictorwilen.se/Post/How-Claims-encoding-works-in-SharePoint-2010.aspx
Who are all of these users? Well… I’m still negotiating with the rabbit for more details, but I’ll soon add these articles with what I have discovered:
and what are they doing in my library?
For now:
- NT AUTHORITY\AUTHENTICATED USERS represents all of the users in your Active Directory, on prem or in the cloud.
- Everyone at the AD level is NT AUTHORITY\AUTHENTICATED USERS plus the Guest account. The Guest is disabled both by default and as a best practice. (You don’t see this one in SharePoint, but it is often listed as being the same as the SharePoint “Everyone”.)
- Everyone is defined at the SharePoint level and includes all users authenticated to SharePoint.
- Everyone except external users is found in SharePoint Online / Office 365 and is as named. External users are people not in your Active Directory, most likely not employees, who got their access from site members clicking the SHARE buttons.
- All Users (<somename>) is SharePoint defined and represents all of the users from a selected authentication provider. (If I created a Forms Based Authentication provider named “Vendors” then I would have “Everyone (Vendors)”
- All Users (windows) is SharePoint defined and is same as NT AUTHORITY\AUTHENTICATED USERS. After adding “All Users (windows)” to a site it is displayed as “All Users (windows)” in 2013 on prem and 2016 on prem, but is displayed as NT AUTHORITY\AUTHENTICATED USERS in Office 365.
- Guest Contributor and Guest Reader are at this time only found in SharePoint Online / Office 365 and represent users with anonymous / link access.
Best Practices
I was reviewing some training materials recently and ran across a statement to the effect you should put NT AUTHORITY\AUTHENTICATED USERS in all of your site Visitors groups so everyone can find content in SharePoint. Should you do this? Should everything in your SharePoint be freely accessible to everyone who can logon to your network? Contractors, vendors, summer co-ops, part timers? If you don’t already have a policy or governance on this, then you should be working on it.
SharePoint does not give us any way to prevent the use of the “Everyone” accounts, so you will need to deal with this through education and auditing.
UPDATE! Anders Rask responded to this post with info about a SharePoint Online cmdlet that can hide these “everyone” options in the people pickers. Turns out there are three options:
Set-SPOTenant -ShowEveryoneClaim $false
Set-SPOTenant -ShowEveryoneExceptExternalUsersClaim $false
Set-SPOTenant -ShowAllUsersClaim $false
The Set-SPOTenant cmdlet: https://technet.microsoft.com/en-us/library/fp161390.aspx
Blog: https://blogs.office.com/2015/07/16/new-it-management-controls-added-to-onedrive-for-business/
Here’s a short list of best practices. The term “everyone” used here includes NT AUTHORITY\AUTHENTICATED USERS and any account that starts with “Everyone” or “All Users”.
- Educate your users on security, including the use of the “everyone” accounts.
- Do not use “everyone” accounts if a site contains non-public data.
- Document who “everyone” is. There’s more than one “everyone” group in SharePoint.
- Perform regular audits using PowerShell or 3rd party tools to track the usage of “everyone” groups.
- Document, audit and enforce your SharePoint content policies. Document what is allowed, and what is not allowed to be stored in SharePoint.
- If you do encourage the use of the “everyone” groups, add a banner to the top of every page that declares “Do not post confidential data in this SharePoint site! It can be seen by everyone with network access.”
The Built-In Accounts
While your SharePoint may vary… see the Notes column… here’s a list of the accounts that may include users other than those who you were expecting. This is not complete, so if you discover others please post a comment to this article.
| DisplayName | UserLogin or SystemUserKeyProperty | Notes |
| c:0!.s|forms%3amembership | Only O365 | |
| c:0!.s|windows | Same as NT AUTHORITY\ authenticated users | |
| All Users (yourFBAMembershipProviderName) | c:0!.s|forms%3aYourFBAMembershipProviderName | Form Based Authentication |
| Everyone | c:0(.s|true | |
| Everyone except external users | c:0-.f|rolemanager|spo-grid-all-users/17b83262-5265-… | Only O365 (ID will vary) |
| NT AUTHORITY\ authenticated users | c:0!.s|windows | |
| Guest Contributor | SHAREPOINT\writer_9e8a77849f89425c9cff6a6af5175… | ID varies with share |
| Guest Reader | SHAREPOINT\reader_cb6f6371456b4542ba0609638a4… | |
| _SPOCacheFull | ylo001\_spocachefull | Only O365. Visible only from PowerShell |
| _SPOCacheRead | ylo001\_spocacheread | Only O365. Visible only from PowerShell |
| _spocrawler_17_3910 | ylo001\_spocrawler_17_3910 | Only O365 (ID will vary) |
| System Account | SHAREPOINT\system | Visible only from PowerShell |
| System Account | S-1-0-0 | SystemUserKeyProperty |
| Company Administrator | s-1-5-21-1851826741-1401831065-3463747319-87287… | Only O365 (ID will vary) |
| Typical user (Sam Conklin) | samc@yourDomain.onmicrosoft.com | As seen in O365 PowerShell |
| Typical user (Sam Conklin) | i:0#.w|yourDomain\samc | As seen in On Prem PowerShell |
| Typical user (Sam Conklin) | i:0).w|s-1-5-21-2499188511-2905385804-3446143336-… | SystemUserKeyProperty |
| Typical FBA user (Susan) | i:0#.f|YourFBAMembershipProviderName|susan | Form Based Authentication |
.
8 comments:
Nice permissions post, Mike. I had wondered about the Everyone group myself. Thanks for finding out!
Job well Done ... Thank you for all your continuing contributions to the SharePoint Community!
"SharePoint does not give us any way to prevent the use of the “Everyone” accounts, so you will need to deal with this through education and auditing."
This is not true. You can (and probably should) disable this on tenant level along with All Users (x):
Set-SPOTenant -ShowEveryoneClaim $false -ShowAllUsersClaim $false
This will prevent external users in AAD (for example external consultants that should only have a mail account but not access to your SPO sites) being listed in the people picker! Note that this is tenant wide, so it also affects picker in OD4B.
cheers
Anders
Anders,
Thanks for the info. Is there a way to do this for on-prem also?
Looks like there's a set of three of these for SharePoint Online:
Set-SPOTenant -ShowEveryoneClaim $false
Set-SPOTenant -ShowEveryoneExceptExternalUsersClaim $false
Set-SPOTenant -ShowAllUsersClaim $false
That cmdlet has a number of interesting options:
Set-SPOTenant
[-BccExternalSharingInvitations <$true | $false>]
[-BccExternalSharingInvitationsList ]
[-DisplayStartASiteOption <$true | $false>]
[-ExternalServicesEnabled <$true | $false>]
[-LegacyAuthProtocolsEnabled <$true | $false>]
[-MaxCompatibilityLevel ]
[-MinCompatibilityLevel ]
[-NoAccessRedirectUrl ]
[-OneDriveStorageQuota ]
[-ProvisionSharedWithEveryoneFolder <$true | $false>]
[-RequireAcceptingAccountMatchInvitedAccount <$true | $false>]
[-RequireAnonymousLinksExpireInDays ]
[-SearchResolveExactEmailOrUPN <$true | $false>]
[-ShowAllUsersClaim <$true | $false>]
[-ShowEveryoneClaim <$true | $false>]
[-ShowEveryoneExceptExternalUsersClaim <$true | $false>]
[-SignInAccelerationDomain ]
[-StartASiteFormUrl ]
[-UsePersistentCookiesForExplorerView <$true | $false>]
Mike
Yes, our customer was involved in getting these filters implemented in the Set-SPOTenant cmdlet through a support case.
The only feature that I know of in On-Premises is good old STSADM.EXE where you can do some filtering on AD.
https://technet.microsoft.com/en-us/library/gg602075.aspx
Hey Mike,
Great info about SharePoint. Is it possible for a SharePoint Admin to NOT have access to a document folder on SharePoint Online? A company I'm contracting for are reluctant to give me admin access because they have a financial information that they don't want many to have access to.
Thanks,
Christina
Short answer: no.
If you are asking about a Site Collection Administrator, they can always see all content in the entire site collection.
If you are asking about a tenant admin, it depends on the admin role:
Billing, Global, Password, Service, User management, Exchange administrator, SharePoint,Skype for Business. But for the ones you are probably asking about, Global and SharePoint, they can see all SharePoint content in the tenant.
As to why... if the site owner who locked down the library left the company, the admins need access to assign a new owner.
https://support.office.com/en-us/article/Assigning-admin-roles-in-Office-365-EAC4D046-1AFD-4F1A-85FC-8219C79E1504
The only way to isolate data is to have multiple Site Collections (to hide data from selected Site Collection Administrators) or multiple tenants (to hide data from selected tenant admins).
Mike
Very nice article. Thanks for sharing.
Post a Comment
Note to spammers...
Spammers, don't waste your time... all posts are moderated. If your comment includes unrelated links, is advertising, or just pure spam, it will never be seen.