Category Archives: Permission

ViewFormPagesLockDown feature

ViewFormPagesLockDown feature Unable to setup uniquely secured permission

I remembered once faced an error where user having Contribute permission to folder in the library but getting access denied. This issue in entire site collection. User with unique permission to list, folders are not able to view the page. The issue resolved by changing ViewFormPagesLockDown feature to Disable. Below article describes all about the information about ViewFormPagesLockDown feature Unable to setup uniquely secured permission.

Configure anonymous access

For content to be available for anonymous access, the following must be configured:
1. The site or site collection must be configured to allow anonymous access.
2. At least one zone in the Web application must be configured to allow anonymous access.
Enable anonymous access only for Web applications that require unauthenticated access. If you want to use authentication for personalization, implement forms authentication by using a simple database authentication provider

Advertisements

ViewFormPagesLockDown SharePoint Feature:

  • Allows anonymous users to only view the Publishing pages, not any of the form or view pages (DispForm.aspx, AllItems.aspx). if your portal wasn’t born as a publishing portal, all anonymous users will have access to AllItems.aspx, DispForm.aspx and other pages that you don’t want outside users to see.
  • Disallows anonymous access to pages in the “_layouts” directory that inherit from LayoutsPageBase.
  • By default, all publishing sites have the feature called “ViewFormPagesLockDown” activated, but not on the Collaboration Portal site or Team sites’ definition. Without this Feature active on anonymous public sites, any users – including search engines like Google will be able to view (and crawl) SharePoint out-of-box pages which are tied to lists and webs that allow viewing by anonymous users.
  • Yes, these users might not have the ability to do anything, but you may not want anonymous users to view the form pages.
  • If you still get the Form pages visible for the end users, try: With the ViewFormPagesLockDown feature Enabled, disable Anonymous Access in the site, then re-enable it. MSDN Link: http://technet.microsoft.com/en-us/library/cc263468(office.12).aspx
  • So this lockdown feature is useful if a site collection that is configured for Anonymous access on a Publishing site and you want to lock it down so Anonymous users don’t have access to the Forms page (e.g. http://ServerName/Pages/Forms/AllItems.aspx)
  • If a library or subsite that has broken permission inheritance, and permission is given to user or group to only that library or site. In this case to view the contents, user/group must have some access to root web else user/group cannot access although they have permission.
  • One more scenario where Publishing Portal configured for Anonymous access where users are unable to post comments (which are stored in a List) on a blog site then the lockdown feature can be disabled, which will result in allowing Anonymous users to post comments. Normally, people won’t have problem posting comments on a blog site unless it is a Publishing site, in which case they will get a prompt to enter user credentials. In such a scenario you can disable the lockdown feature.
  • If you want to place your custom application pages inside the _layouts directory, which anonymous users must hit, there’s the UnsecuredLayoutsPageBase class you can use as the base class of your page, and there’s always just the Page class as in a standard ASP.Net application page.
  • When enabled permissions for users with limited access permissions, such as anonymous users, are reduced, preventing access to application pages including item properties or list views.
  • If a document, folder, or library has unique permission, those users will not able to 1. Use the drag and drop feature to upload documents 2. Brows to the affected folder 3. Use the shared with feature 4. Open document in the office client 5. Some call out features on documents and folders will not render as expected.
Advertisements

How to check site has ViewFormPagesLockDown feature Enabled or Disabled

Run the below commands to get the status of ViewFormPagesLockDown feature 

Get-SPFeature -site http://Site Collection URL
How to turn lockdown mode to off
$lockdown = Get-SPFeature viewformpageslockdown
Disable-SPFeature $lockdown -url http://Site Collection URL
Advertisements

SharePoint search result not found from specific document library

Advertisements

Advertisements

SharePoint search result not found from specific document library

I came across a situation where user is trying to search documents selecting the option "search in same site" instead of "all sites" from  search box and getting no result where as can find documents from other library with in same site. SharePoint search result not found from specific document library

Why such happens ?

The first point comes to mind for search error is  content not crawled, indexing not done for this situation.

Yes , its true but we need to think why  ?

As per my investigation I found the setting of the library as below

Draft-items-are-not-crawled-in-SharePoint

By default SharePoint only crawls major versions of files and draft items are only viewable by their creators. SharePoint is behaving as expected out of box.Draft items are not crawled in SharePoint

Resolution :

This behavior can be altered in Document Library Settings -> Versioning Settings -> Draft Item Security

Select the option "Any user who can read items".

This will allow all users to see draft items including the crawling account.

* Else you need to select "Create major versions" option or can publish the documents as major versions if want to get those documents in search result as per client wish.

https://support.microsoft.com/en-us/help/2304855/draft-items-are-not-crawled-in-sharepoint

Advertisements

Advertisements

Access Denied Error after migrating to SharePoint 2013

Access Denied Error after migrating to SharePoint 2013

Access Denied Error after migrating to SharePoint 2013

Scenario:

We were working for a client, they had many groups and we had to build a collaboration portal for all the groups. Key thing was few sites of some groups were already present in SharePoint 2010 in different standalone servers. Migration was a key thing here as the existing sites has huge data, and huge user base.

The Requirement was to build a portal /web application which will have migrated sites and new set of sites as per agreed site structure. According to the agreed architecture and design we created a new web application and started building the site hierarchy.

As part of this we followed the regular approach database detach –attach method and migrated the existing SharePoint 2010 site .Migration was successful and we were able to access the site  with the system account. Later we tried with couple of site admin accounts, to our surprise we were getting “ACCESS DENIED” with any other user id.

Background:

By default when we create a web application in SharePoint 2013, it gets created with Claims authentication. When we migrate the content DB to 2013, it recognizes the user account only in this format i:0#.w|domainusername . Though it’s an AD account it no more recognizes the DomainUserName format.

SharePoint assumes all users to be claim users and renders them so. Therefore, a normal windows user – “DomainUserName” appears as “i:0#.w|DomainUserName”. Moreover, it uses the username in this same format to check for its permissions but does not find a matching entry for the user as the database has windows users – “DomainUserName”. So, the site will give you an access denied.

Note that the System Account will work since its “DomainUserName” is never used and System Account is a keyword used by SharePoint for the application pool identity. Therefore, it remains unaffected.

Solution:

In brief the share point 2010 site which needs to be migrated should be converted to claims format and then migrate it to 2013. But a word of caution , do not directly change the SP 2010 site to claims format in a production environment as it will not allow existing windows accounts to login and existing SharePoint 2010 site will be no more operational.

Below power shell script converts classic mode site to claims mode:

Power shell script

This script converts user accounts to claims format:

Script for converting user accounts to claims format

On executing the first script (to enable claims authentication) the SharePoint Content Database is made ready for claims based authentication but the already existing site users were windows users, are not “migrated” to be understood by claims authentication.

We use the second script to “migrate” the users. MigrateUser($true) will convert all user accounts to claims format. After running this script user accounts are converted in the database to claims format, therefore, user names are read correctly by SharePoint therefore, permissions for users are associated correctly by SharePoint hence the site permissions work correctly.

Note:

By any chance if you execute these scripts directly in productions, by executing $webapp.MigrateUsers($false) will not convert user accounts to windows mode, rather it will throw an exception. Make sure you have a temporary environment built where you execute the above scripts. Also note that these scripts are running on Web Applications so they will affect all site collections in that web application