Limited-access user permission lockdown mode Feature in SharePoint
What is limited-access user permission lockdown mode?
In SharePoint, users are automatically assigned to the “Limited Access” permission level when their account is granted exclusive access (unique permission) only to resources such as list/library/document, etc., within site, but not directly to the site itself. E.g., When you grant access to a List in SharePoint, they’ll be granted “Limited Access” permission at the site level.
When publishing a SharePoint site to the Internet, we need a mechanism for effectively locking down the SharePoint site. In this case, locking down SharePoint just means that users in a “limited access” role will be unable to access application pages, thus minimizing the attack surface on a SharePoint site. When this feature is enabled, users assigned to the Limited Access permission level will not have the ability to access pages within the environment. E.g., https://Intranet.SharePoint.com/_layouts/viewlsts.aspx page shows all content of the site, and lockdown mode can turn it off!
Limited Access User Permission Lockdown Mode feature is available in both SharePoint Server and SharePoint Online. By using this feature, you can allow your authenticated users to log on to a SharePoint site while still securing application pages in your environment.
Lockdown Application Pages in SharePoint:
SharePoint brought this feature in the interface via the site feature “Limited-access user permission lockdown mode feature”. To enable or disable the Limited-access user permission lock down mode feature, do the following:
- Go to Site Settings >> Site collection features
- Click on Activate or deactivate button next to “Limited-access user permission lockdown mode” feature to restrict/allow anonymous users to access application pages.
How to disable limited-access user permission lockdown mode using PowerShell?
To enable or disable the Limited Access User Permission Lockdown Mode feature from all site collections and via PowerShell, here is the script:
Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
#Site collection Variable
$WebAppURL="https://opera.crescent.com"
#Get all site collections on the web app and disable the feature
Get-SPWebApplication $WebAppURL | Get-SPSite | ForEach-Object {
Get-SPFeature -Site $_ | Where { $_.DisplayName -eq "ViewFormPagesLockDown"} | Disable-SPFeature -Url $_.Url -Confirm:$false; Write-host -f Green "Disabled the Feature on $($_.URL)"
}
Interesting article. Thanks for sharing.
I stumbled across it by searching for a solution to my problem.
I face a challenge around how SPO handles the rendering of PDF files (attempts to render direct via SPO and cannot because it does not have a native app, instead of handing off to the browser or browser plugin), specifically how in this scenario a specific “View Only” limited-access user group permission applied at file level (not library or site collection) is denied access whilst a more general access user group (that has read permission at library and site collection) is not denied access. Native documents such as Word/Excel/Visio etc. do not behave in this way for either user group, all is well there, this is a PDF (non-natively supported documents) issue only.
Based on my testing I have found that this behaviour comes down to the fact that when a PDF file is called, with the “Limited-access user permissions lockdown mode” enabled, the explicit “View-Only” access user group gets an access denied response, because SPO does not render the Document ID URL (e.g. 4UNTNPFY2WWX-913213895-999 hard-link to the file, to which the view-only users have access), instead SPO attempts to open the document directly, then fails and redirects the user to the root of the site collection (e.g.https://mydomain.sharepoint.com/sites/mysite1/default.aspx) to which the “View-Only” user does not have access, thus gets an access denied message.
Where it gets confusing for me is that when the “Limited-access user permissions lockdown mode” is disabled, with the same set of permissions in play, the behaviour changes and the PDF document is rendered in the browser directly by SPO when called, however, the option to “Open”>>>”In-Browser” on the Nav bar of the browser session is available and on action opens another browser tab with the same document, which tells me that the first session is not handing off to the browser/plugin to render the document, as referenced here: https://docs.microsoft.com/en-us/answers/questions/105439/how-to-open-a-pdf-file-in-directly-in-pdf-viewer-i.html
My requirement is to grand specific users, explicit file level access on an ad-hoc basis, for selected documents, but I do not wish to grant them access to the Site Collection level, the List/Library level and other document contained within to which they have not been granted explicit access to.
Currently achieving this by having a set of permissions Inheriting from the parent for the general access groups, then removing the inheritable permissions at file level for those documents where the “View-Only” limited access group need to be granted access and granting access at file level to this additional group, which works for all but the non native documents such as a PDF file.
Would you say that this behaviour is expected, with respect to Enabling/Disabling the “Limited-access user permissions lockdown mode” and how this changes how PDF’s are handled by SPO?