SharePoint 2010 Cross-Farm Services And External Data Sources

There are several steps involved in the process of deploying cross farm services. Each step is very important to gain the overall results you are after.

Configuration of trusted farms ensures all of the farms that use exchanges can trust each other. Certificates have to be exported to a file. Make sure you back up that file before you connect to any of the cross farm services. Publishing service applications must be done before you will be able to successfully share it across farms. Connecting cross farm service applications provides a connection must be made to a service that is published by a remote farm. This will require the URL to be entered of the published service. This is going to be displayed when you publish it. The connection on the local farm has to be created so that it can be connected successfully to a service application for a remote farm.

Should there be two domains where the server farms are located, the User profile service application will require both of them to trust each other. With the Business Data Connectivity and Secure Store Service the domain of the publishing farm has to trust that of the consuming farm. None of the cross farm service applications are going to work if there isn’t a trust requirement in place for the two domains.

It is possible for certain service applications to access external data sources. This occurs through the access of a delegated Windows identity that will place some additional requirements on a given environment. These types of service applications have to be in the same domain as the SharePoint Server 2010 farm. This is where the service applications are housed. The other option is for the service application to be configured using the Secure Store Service.There are plenty of different service applications that can be found across the external data. They use a delegated Window identity. This includes:

  • Excel Services
  • InfoPath Forms Services
  • PerformancePoint Services
  • Visio Services

The service applications used to access external data sources must have a delegated Windows identity. Otherwise it has to be configured for the use of the Secure Store Service. This will store and maintain the credentials of a user or a service. When service applications are used to store credentials, they have to be authenticated before the data can be accessed.

If the external data sources aren’t within the same domain then authentication for the external data sources will fail unless you use the Secure Store Service. Farm servers can be split between two different domains but the application servers have to be found in the same domain as the external data sources.

There are several service applications and products that don’t have those requirements. They include:

  • Access Services
  • Business Data connectivity Services
  • Microsoft Business Connectivity Services
  • Microsoft Project Server 2010
  • Microsoft SQL Server PowerPivot for Microsoft SharePoint
  • Microsoft SQL Server Reporting Services

Excel Services Security Best Practices Authentication And Accounts

When you use Excel Calculation Services to open up Excel workbooks, they should be stored in the SharePoint Sever 2010 content database. This is due to the fact that the SharePoint Foundation 2010 will maintain the access control list for the files. You can also open workbooks from UNC paths or HTTP websites with the use of Excel Calculation Services. However, it is best if you use the SharePoint Server 2010 content database when you want to store workbooks. The authentication for user access for any SharePoint portal site has to be performed with the  SharePoint Foundation 2010. This is the default that will be used for the Integrated Windows authentication too. Excel Services Applications also support generic forms based authentication. Yet you will need to configure SharePoint Foundation 2010 if you want to use such generic forms based authentication.

Through claims authentication you will be able to improve security so that you can authenticate your farms, Office Business Applications, and Share Point services from various environments. With the use of Excel Service Application you can use claims based authentication for the various scenarios relating to deployment. It doesn’t matter if you are using a single server or a farm environment. Plus, the authorization and authentication of users in regards to content and resources is going to be better secured within in SharePoint Server 2010 when you have claims based authentication in place.

There can be embedded data in the workbooks that connects and links to other files. All of that information is stored in the data connection libraries. When you refresh the embedded direct data connection may be used as a method of sending a query for data to the data connection library. It can also be used to get a query to the .odc file. This contains information for the connection as well. If you want to configure the Excel Services Application to external data sources you have to choose a setting in the External Data section of the Excel Services Add Trust file Location page. This is on the SharePoint Central Administration web application.

In order to configure administrative settings for Excel Services Application you need to refer to the Manage Excel Services Authentication. The deployments of farms that are intertwined with connections are going to use SharePiont Server 2010 claims based authentication. The Excel Calculation Services will retrieve the connecting information. There are credentials in place to store or integrate the data. All of those connections have credentials that can be used with claims based authentication. The deployments can be scaled when you have multiple servers in place.

If you are talking about deployment for a standalone server, then you need to rely on claims based authentication. When you have a data connection associated with a workbook that is opened in Excel Calculation Services it is best to used stored credentials. That will result in Excel Calculation Services to retrieve the credentials it needs for validation. From there those credentials will be used to authenticate the data source. Only then will the data connection be successfully established.

There are three types of data authentication that are supported by Excel Services Applications. They include:

  • Integrated Windows
  • Secure Store Service
  • None

It is recommended that you use Kerberos for the security configuring with Integrated Windows authentication. This is because SharePoint Server 2010 relies on a claims based authentication. All of the Excel Services Applications are also claims based. You will find that Integrated Windows authentication is exclusively in place for SharePoint Server 2010 and IIS Authentication Settings. With the use of Secure Store Service authentication a user is able to access multiple resources from various systems. They are able to do so without the need for providing their credentials to be authenticated more than once. With SharePoint 2010 the Secure Store Service includes a Window service and a database of secured credentials. The use of the plug in functions for the Secure Store Service, there is the ability to introduce the Secure Store Service provider of your choice with the Excel Services Application. It is important to note that the SharePoint Server 2010 also includes a Secure Store Service provider that is able to successfully work with Excel Services Application.

With any Secure Store Services though that you select to use with Excel Services Application, there will be credentials in place. The credential type should be in place with both Windows and other alternatives. That will allow the Excel Services Application to successfully use the Secure Store Service data base in order to authenticate before connecting and to be able to retrieve credentials. Individual mapping as well as group mapping is supported through SharePoint Server 2010. The Secure Store Service offers a set of credentials that will be used for the Application ID’s for all of the resources in the SharePoint Server 2010 Secure Store Service database.

In regards to individual mapping, there is a secure layer that will validate the credentials of a user against multiple listings for Application ID’s. This type of mapping can be useful if you need to have the log in information for an individual before they can gain access to any types of resources which are shared.

Group mapping is more commonly used though. This includes a secure layer that checks for group credentials compared to those of multiple domains. However, each user has a set of credentials that can be unique with the Application ID’s. You will find that group maps are easier to maintain than those that are individual. You will also find that you get better overall performance.

If you want to enable the Secure Store Service function for SharePoint Server 2010 you will need to create a new Secure Store Service. This takes place in the SharePoint Central Administration website.

You have the option of selecting none as the type of authentication method you would like in place as you deploy the Excel Services Application. When this occurs an inbound connection will be used to connect to the database that has been specified in the string. It is important to understand that the connection strings are passed to the database provider. They aren’t part of the Excel Services Application. When you have connection strings in place, they can specify that a requirement that has to be present is Integrated Windows Authentication. These connection strings are also able to contain the specific password and user name for a given user. When that is the case Excel Services Application will require what is equivalent to an unattended service account for the authentication method.

Should the provider of the database make the determination that the string for the connection has Integrated Windows Authentication, then the database can authorize access for that user. The connection will be established through the use of a security context relating to an unattended account.

A type of privileged account that is encrypted for security is the Unattended Service Account. This has been discussed in several other posts. The Secure Store Service for it will have credentials that are found in Excel Calculation Services. This makes it possible to replicate what has been established for a secure data connection to be completed. This is the process when the environment isn’t one which is Windows based. If the Unattended Service Account isn’t configured, then the data connection will fail. This is because the Secure Store Service can’t be authenticated from such an environment and though this method for authentication. The process of replicating the Unattended Service Account protects what is found in the SharePoint Server 2010 database.

It can’t be accessed from unauthorized connections that are using Excel Calculation Services for the task of opening external data connections. An Unattended Service Account results in external data queries operating under a low permissions account for security. This is opposed to it operating from the security of the Excel Calculation Services. It is possible to configure the Unattended Service Account as a domain account or a local computer account. It is important to make sure the configuration is the same for all of the application servers that run Excel Calculation Services. These credentials will always be cached for each workbook session. When a workbook is loaded  through the data connection using an Unattended Service Account, the account will be obtained from the Secure Store that was used. The credentials won’t be cached globally. It is possible to restrict the permissions of the Unattended Service Account so that only logging in can be accomplished on a given network.


PerformancePoint Security Best Practices In SharePoint 2010 – A Primer

With PerformancePoint Services offered by Microsoft SharePoint Server 2010, the objects that get stored in lists and document libraries can be secure when used within a dashboarding / graphical application. This is accomplished by coupling through the Microsoft SharePoint Sever 2010 security model. There are additional products features that can be accessed for customizing that security. PerformancePoint Services are dependent upon the SharePoint Server 201 security model. However, there are special security considerations that need to be evaluated during the planning stages. That should also include how managing that security will take place. All of the security is managed within the SharePoint Sever Central Administration Website. This covers all of the shared resources as well as the user access.

You will find three different methods for source data Authentication with PerformancePoint Services. Custom Data allows for SQL Service Analysis Services to be able to authenticate a user through custom specs. The name of the user is considered a parameter of the custom data field for the connection string. The custom data option is only used for Analysis Service Data. It can be used with both the 2006 and 2008 servers. With Per User Identity authentication each of the users has individual accounts that are used to access all of the data sources. The use of Kerberos Delegation has to be incorporated. There is a domain administrator that configures the Kerberos Delegation between PerformancePoint Services and the data sources. The external data sources have to be within the same domain as the SharePoint Server 2010 farm or a failure will occur. Unattended Service Account are a shared user account that is used for access to all of the different data sources. This type of domain account is low privilege. It is stored in the Secure Store Service. In order to create an unattended service account, there has to be the proper access to the data sources. This is a requirement of the dashboard.

With PerformancePoint Services the data source connections are contained. This occurs with the data content and document libraries that are part of the document lists. The security of the content ensures that users aren’t able to run queries against those data resources when the query objects can’t be trusted. Therefore trusted locations within those libraries and lists are created. The Farm Administrator is able to set all of the locations for the farm to be trusted. They can also choose to identify specific locations to be trusted. The ability to define the locations in the farm that will be secure means that there is a great deal of flexibility. A Farm Administrator no longer has the responsibility of securing the entire farm when it isn’t absolutely necessary to do so. These trusted locations are able to offer additional layers of security. There are restrictions for the query to be executed in regards to various data sources and objects. The document library for a web application can be defined as being trusted. With PerformancePoint Services the configuration of trusted locations and settings are managed through the Central Administrator. The configuration can also be managed through the use of Microsoft PowerShell 2.0. When you are planning the security for PerformancePoint Services, you will need to decide if you want to secure your entire web application or only portions of it. There are often many locations found within a given farm that will be marked as trusted. They use the following hierarchy within the SharePoint Server for the data and data sources:

  • The use of trusted locations are disabled for various locations with data sources or content for the entire farm.
  • The web application contains trust lists and document libraries.
  • There is a collection site for the trust lists and document libraries.
  • Trust lists and document libraries placed in a site.
  • The farm has a trust list or document library in place.

The server will check if trusted locations are enabled when it is doing verifications. When it is enabled the server will check a list of trusted locations at the site collection. It will also look down the hierarchy to verify that all of the content is trusted. When items don’t use a data source they don’t have to be in a trusted location to be accessed. This includes KPI’s, dashboards, icons, and web pages. Trusted data source locations can’t be defined on a list or as a document library.