SharePoint 2013 and SharePoint Online Built-In Accounts



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


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 


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
All Users (membership) 
Only O365
All Users (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



Tim Barrett said...

Nice permissions post, Mike. I had wondered about the Everyone group myself. Thanks for finding out!

Randel Hall - MCT, Cloud Engineer, Sharepoint MCSE, TEchnical Instructor New Horizons 5PE said...

Job well Done ... Thank you for all your continuing contributions to the SharePoint Community!

Anders Rask said...

"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.


Mike Smith said...


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:

[-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>]


Anders Rask said...

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.


Christina Harris said...

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.


Mike Smith said...

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.


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).


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.