Simple Concept: PowerShell: The local farm is not accessible.

[Question]: What permissions should I have to run PowerShell against SharePoint 2010?
How can I fix following issues:
 - The local farm is not accessible. Cmdlets with FeatureDepedencyId are not registered
 - Cannot access the local farm
 - Object reference not set to an instance of an object?

[Answer]:
Remember, when using the SharePoint 2010 Management Shell and its Windows PowerShell cmdlets, you need both:


  the rights  granted via the Add-SPShellAdmin cmdlet and 


 local administrator rights on the server on which you’re running the management shell


(From Hey, Scripting Guy! Tell Me About Permissions and Using Windows PowerShell 2.0 Cmdlets with SharePoint 2010)

P.S. Do you need a fast tour on PowerShell And SharePoint 2010?

PowerShell and SharePoint: What, Why and How - gives you an overview what's PowerShell and how to use it for SharePoint 2010

SharePoint 2010: PowerShell and Stsadm - explains why you want to use PowerShell instead of stsadm in SharePoint 2010

Simple concept: How to use SharePoint cmdlets in PowerShell ISE - shows you how to user PowerShell in SharePoint 2010

PowerShell: Add-SPSolution -force when wsp is already deployed - a PowerShell replacement for stsadm -o addsolution and deploysolution

"SharePoint 2007 to 2010 Upgrade" online project (part 9) : SharePoint service accounts

Here is a bare minimum of the service accounts that I have used for the SharePoint 2010 farm:


SQL Server service account
Setup user account
Application pool account
Service managed account
Default content search access account
SSRS




Automating SharePoint 2010 with Windows PowerShell 2.0 sheds the light on what service accounts are necessary to build a 2010 farm:

"Farm account" - (also reffered to by the SharePoint Configuration Wizard as the Database Connection Account). will be used as the central administration site Application Pool identity as well as the SharePoint Timer Service (SPTimerV4) identity.

Gary Lapointe strongly suggests to user another "Setup SharePoint" account which should be in the Web server local group "Administrators" and should have "dbcreator" and "securityadmin" roles on the SQL server.

You may need to modify the group membership for the farm account in order to start User Profile Synchronization Service


UPDATE: Todd Klindt has an excellent article where he presents his view on what accounts are needed for SP Farm 2010: Service Account Suggestions for SharePoint 2010

Integrated Windows authentication: NTLM or Kerberos?

Recently, I have been studied the topic "Kerberos: Why do I need it?"


Here is a quick explanation (from Configuring Kerberos Authentication for Microsoft SharePoint 2010 Products)what is Integrated Windows Authentication and relation to NTLM and Kerberos:

Integrated Windows authentication enables Windows clients to seamlessly authenticate with SharePoint Server without having to manually provide credentials (user name/password). Users accessing SharePoint Server from Internet Explorer will authenticate by using the credentials that the Internet Explorer process is running under — by default the credentials that the user used to log on to the desktop. Services or applications that access SharePoint Server in Windows integrated mode attempt to authenticate by using the credentials of the running thread, which, by default, is the identity of the process.

NTLM

NT LAN Manager (NTLM) is the default protocol type when Integrated Windows authentication is selected. This protocol takes advantage of a three-part challenge-response sequence to authenticate clients. For more information about NTLM, see Microsoft NTLM (http://go.microsoft.com/fwlink/?LinkId=196643).

Pros:

·         It is easy to configure and typically requires no additional infrastructure/environment configuration to function

·         It works when the client is not part of the domain, or is not in a domain trusted by the domain that SharePoint Server resides in

Cons:

·         It requires SharePoint Server to contact the domain controller every time that a client authentication response needs validation, increasing traffic to the domain controllers.

·         It does not allow delegation of client credentials to back-end systems, otherwise known as the double-hop rule. It is a proprietary protocol.

·         It is a proprietary protocol.

·         It does not support server authentication.

·         It is considered less secure than Kerberos authentication

Kerberos protocol

The Kerberos protocol is a more secure protocol that supports ticketing authentication. A Kerberos authentication server grants a ticket in response to a client computer authentication request, if the request contains valid user credentials and a valid Service Principal Name (SPN). The client computer then uses the ticket to access network resources. To enable Kerberos authentication, the client and server computers must have a trusted connection to the domain Key Distribution Center (KDC). The KDC distributes shared secret keys to enable encryption. The client and server computers must also be able to access Active Directory directory services. For Active Directory, the forest root domain is the center of Kerberos authentication referrals. For more information about the Kerberos protocol, see How the Kerberos Version 5 Authentication Protocol Works (http://go.microsoft.com/fwlink/?LinkId=196644) and Microsoft Kerberos. (http://go.microsoft.com/fwlink/?LinkId=196645)

Pros:

·         Most secure Integrated Windows authentication protocol

·         Allows delegation of client credentials

·         Supports mutual authentication of clients and servers

·         Produces less traffic to domain controllers

·         Open protocol supported by many platforms and vendors

Cons:

·         Requires additional configuration of infrastructure and environment to function correctly

·         Requires clients have connectivity to the KDC (Active Directory domain controller in Windows environments) over TCP/UDP port 88 (Kerberos), and TCP/UDP port 464 (Kerberos Change Password – Windows)

Long story short, I have decided that I am willing to spare time and configure Kerberos if I see the farm desperately needs following:

 1. Boost performance

 2. SSRS reports needs to pass a user credentials to external source like this one:

3. BDC uses Web services that needs to pass a user token to the external source

4. Any other type delegation (which is not present in my specific scenario but it might be in your case)

SharePoint 2010: Security Best Practices

Security Best Practices for Developers in SharePoint 2010 - some short highlights:

• Before rendering user data on the client, encode it by using the appropriate method from the SPHttpUtility class.  
•  Never Allow Contributor Users to Add Script to the Site (don't include "Add and Customize Pages" permission to their permission level)
• If the custom feature shows or downloads the user downloaded document - add to the header:X-Content-Type-Options: nosniff,X-Download-Options: noopen,Content-Disposition: attachment
• Always specify a charset in the Content-Type HTTP response header.(most common: Content-Type: text/html; charset=UTF-8)
• Validate the Form Digest Canary Before Processing a Postback (var canaryValue = document.getElementById('__REQUESTDIGEST').value;)
• Avoid AllowUnsafeUpdates where possible
• Use SPUtility to Redirect to a Different Page
• Check a SPSite created from user input URL with Microsoft.SharePoint.SPSite.ValidateDomainCompatibility
• Do not allow users to specify arbitrary URLs for SharePoint to connect to. Instead, allow farm administrators to configure a list of URLs that are safe. 

Sharepoint Permissions, Assigments and Level

To understand SharePoint Permissions need to know its language.

Terminology:

Securable object - web site,lists, libraries, folders, items, and documents

Permission    Authorization to perform specific actions such as viewing pages, opening items, and creating subsites.

Permission level - Each permission level has a specific set of individual permissions.

SharePoint groups -  at the site collection level contain the users. Groups have no permissions until they are assigned a permission level for a specific securable object.
All SharePoint groups are created at the site collection level and are available to any subsite in the site collection.  This means that all SharePoint groups are available to all sites within the site collection.

A permission assignment is created on a particular securable object. This permission assignment includes a user or SharePoint group and a permission level.

Permission inheritance 

You can configure subsites to inherit permissions from a parent site or break the inheritance and create unique permissions for a particular site. Inheriting permissions is the easiest way to manage a group of Web sites.


By default, permissions on lists, libraries, folders, items, and documents are inherited from the parent site. However, you can break this inheritance for any securable object at a lower level in the hierarchy by editing the permissions on that securable object (that is, creating a unique permission assignment) . For example, you can edit the permissions for a document library, which breaks the permissions inheritance from the site.

When you break the inheritance from the parent, the securable object from which you broke the inheritance receives a copy of the parent's permissions. You can then edit those permissions to be unique — meaning that any changes you make to the permissions on that securable object do not affect the parent.

When you enable anonymous access to a Web site, you allow anonymous users (and authenticated users who have not been granted access to the site) to browse the entire Web site, including any list, library, folder within a list or library, list item, or document that inherits its permissions from the Web site. More about it - here

Audience is NOT a security feature. It targets a content to  the specific group.

Tips:
. 1. Because permissions inheritance can be broken at any of several levels, it can be difficult to determine exactly which permissions a specific user or group has to an object such as a SharePoint site, list, or item.
       Microsoft SharePoint Administration Toolkit - a great tool to analyze SharePoint performance and also ships with check permissions tool which is handy in case you have a complicated permission logic with breaking inheritance. More about it here

  2. Instead of pure anonymous access you may consider more safe way - to add all AD users to the group - NT AUTHORITY\authenticated users

  3.When users are removed from a site's permission groups, they can no longer browse to the site (assuming they do not have individual rights to the site). They also no longer receive alerts on anything from the site. However, they still exist in the UserData table, and their alerts are still present. A site administrator can still see their alerts on the User Alerts page.

  To permanently delete a user from the UserData table and permanently delete all of the user's alerts, you need to delete the user from the site collection.

Reading:
Joe Oleson on SharePoint Groups, Permissions, Site Security
Joe Oleson on Web Application Policies

"No item exists" - Modifying a default permission level leads to a problem

As you can guess from the title - I have tried to modify a permission level on a sharepoint site and at some point it broke my securable objects.

Issue: The user can't see the item that he just created . The error- "No item exists..". The list item can have inherited permissions and it can have unique permissions with setup permissions level for a creator - it doesn't change behavior. "Manage permissions" shows user should have a permission on the item, Effective permission report (Microsoft SharePoint Administration Toolkit v4.0 x86 ) shows "No effective permission for the user".

If you ever seen this - you are lucky to have my answer, or unlucky - if it still drives you crazy and my solution doesn't work for you.

Solution: After a week of researching with a team of 3 people - we finally came to the point to blame the modified default permission level on the site.  Seems that at some point the modification of permission level on the web site mixed up the security on some lists (it didn't affect all objects! which I consider really strange!) . To fix the issue - I had to re-inherit the permission levels from the site collection.

!Attention  - Once you re-inherit the permission level, all unique permissions on the site will be destroyed!
Here is a note from Microsoft:

 Important   Inheriting permissions from the parent site permanently discards all custom permissions that you might have created on any securable object for this site. This means that all lists, libraries, folders within those lists and libraries, list items, and documents lose all their unique permission settings.

 Anyway, even I have a lots object to take care of ( I made a code to return the unique permission set back), I have reset the permission level - inherit and edit - It gave a nice non-modified permission levels, and I copied the permission level instead modifying the predefined one, and set permissions set that I like to see on my own permission level. Finally assigned this permission level to a particular group\users.
And now it works!!!

Be happy, breathe freely!

By the way, I spoke with a Microsoft support team - they don't recommend modifying the out-of-box permission levels.... even though they left such nice way to do it)