SharePoint world of ECM and Information Management : Security

SharePoint Tip #36. Do you know “a cause of HTTP 400 Bad Request error when login to site” ?

Michael — Mon, 08 Jun 2009 14:15:07 GMT

Sometimes, you may find that you get “HTTP 400 Bad Request” error, or “HTTP 401.1 - Unauthorized: Logon Failed” error when navigate to local SharePoint sites and asked for credentials tree times.

This mostly happens for Web sites that use Integrated Authentication and have a name that is mapped to the local loopback address. More details in KB896861.

Such situation is “behavior-by-design” and caused by Windows security updates, when authentication fails if the FQDN (fully qualified SND name) or the custom host header does not match the local computer name.

Solution: run REGEDIT and create DWORD “DisableLoopbackCheck” equal “1” in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.

PS: I actually had all my sites inaccessible after bunch of security updates on Windows 2008 before and after installing SharePoint SP2.

Source

Have anything to add?! Send your tips to be published via this form.

SharePoint Tip #32. Do you know “which identity is used when you deploy WorkFlow from Visual Studio and SharePoint Designer”?

Michael — Sun, 03 May 2009 01:30:00 GMT

SharePoint provides you two approaches to design and deploy WorkFlows - via SharePoint Designer(SPD) and using Visual Studio. But you should be aware that deployment of WorkFlows has some differences in the security model that might cause you permissions issues.

SharePoint has its own security model to resolve the user's windows identity for all activities. It uses either IIS application pool user or the WSS Timer user for scheduled stimulations. Such behavior is the same for both Visual Studio and SharePoint Designer workflows, when actual windows identity doesn't matter.

There are two differences in the resolving SPUser name, when you deploy WF from Visual Studio and SharePoint Designer:

Visual Studio developed Workflows are deployed at the server level, run under the System Account. They do not require any permissions by the user/initiator of the workflow.Also these workflows are strong named and placed in the GAC. The actual SPUser user name come from SPWorkflowActivationProperties, which is System Account.
SharePoint Designer developed workflows (or usually called ‘Declarative’ workflows) have only the permissions that the initiator has. Any actions that the workflow needs to perform will inherit the permissions of the initiator and NOT the System account. The SPUser get from the WorkflowContext.Site object, that impersonated to the workflow's author, the user who started the workflow.

Sources: 1, 2

Have anything to add?! Send your tips to be published via this form.

SharePoint Tip #28. Do you know “that Limited Access permission used to traverse access to items”?

Michael — Sun, 29 Mar 2009 02:04:00 GMT

SharePoint provides different levels of permissions, from the “Full Access” to “Limited Access”. Last one is not documented clearly and designed to cover some side-effects of item’s hierarchy.

Cite from “Permission levels and permissions” article:

“The Limited Access permission level is designed to be combined with fine-grained permissions to give users access to a specific list, document library, item, or document, without giving them access to the entire site. However, to access a list or library, for example, a user must have permission to open the parent Web site and read shared data such as the theme and navigation bars of the Web site. The Limited Access permission level cannot be customized or deleted”

"Limited Access" allows no direct access to site content at all, but is intended to allow users to traverse the site in order to access the items within it that they have explicit permissions to see.

For example, the user might have access only to one page of a site, but still need access to style sheets and other supporting site infrastructure in order to view it. In that case the user would need "Limited Access" permissions on the site and "Restricted Access" to the page.

Current "SharePoint Tips and Tricks" series has been moved to its own "SharePoint SandBox" site, to leave the place for others SharePoint posts on this blog

SharePoint Tip #13. Do you know “that people picker selects disable account by default”?

Michael — Mon, 16 Feb 2009 14:36:20 GMT

People Picker is a nice feature of SharePoint which allows search for a user/group when assigning permissions for example. But it has one issue, selecting accounts and groups which are “disabled” by default. To do this you need to apply LDAP filters via STSADM command

stsadm -o setproperty -pn peoplepicker-searchadcustomfilter -url ">">http://<site> –pv (!userAccountControl=514)

Source

Have anything to add?! Send your tips to be published via this form

SharePoint Tip #2. Do you know “why OOTB Roles must be customized”?

Michael — Tue, 27 Jan 2009 20:00:00 GMT

SharePoint has predefined set of OOTB permissions level, such as: Full Control, Contributor, Designer, and etc. But those permissions not always provide you desired functionality – its either too wide or very narrow.

Start out with a small set of users who have the fewest permissions possible, to avoid [Your_Headache = Number_of_Users X User_Permissions] because out-of-the-box permissions levels either too liberal or they are too limiting

The most commons scenario of role customization you can meet is Design role in publishing sites. When you have an approval workflow and assigned specific user to “Design” role as approver you need to take into account that “Design” role has delete permissions. So, what actually happens, sooner or later, is that your approver accidently deletes what he needs to approve :) It’s not what you expect from him.

The solution for this is to edit OOTB permissions for Designer roles and to prohibit “delete items” action, or create new role. And pay attention to roles you are using in production system just to avoid such cases.

“Have anything to add?! Send your tips to be published via this form“