Business Connectivity Services In SharePoint 2013

Business Connectivity Services is an infrastructure in SharePoint 2013  that is centralized. It supports data solutions that are integrated. This enables the use of both SharePoint 2013 and Office 2013 clients for the interface with various forms of data. This external data can be in a database for example that is accessed with out of the box Business Connectivity Services.

It can also be in reference to data that is accessed through a web service or published in OData. Business Connectivity Services is able to accomplish this through out of the box customized connectors. These connectors allow the communication to be bridged between SharePoint 2013 and an external system that is hosting that external data.

There are several options found in SharePoint 2013 for access to external data. The most popular method though is to have it presented from an external list. This looks and feels just like the regular SharePoint lists. However, they are only going to display the external data. In order to successfully integrate that with other data in a library or a list, you will need to use an external data column.

The external data column offers information that you can use to create and add to a SharePoint list. This is the same as the process for adding Date, Group, Person and Time.

The difference though is that it displays external data only. With the use of SharePoint 2013  and Business Data Web Parts, it is possible to successfully interact with external data and apps. Once the external data is available, there are different operations that can be performed with that data.

 They include Create, Delete, Query, Read, and Update.

What can be used depends on the operations that have been enabled. Changes can be made in SharePoint 2013 or Office 2013  so that they can be automated and synchronized to the external data source. SharePoint Search can assist you with locating external data.

Every company faces unique challenges and different forms of data that is accessed. That data is also used for different purposes. While some of the data stems from SharePoint 2013, a large amount of it doesn’t. In many regards, a business may not have control over some of the data that is in a file and in databases. There is also the need to secure some files such as sensitive information about employee records. Other data will be more freely accessible by all in the business and even 3rd parties.

The use of Business Connectivity Services should be set up to give the business the control it needs in various areas of data. At the same time, they should be able to use the data to successfully accomplish the overall goals of the business. The data that a business uses may be both structured and unstructured. The ability to make both types accessible through customized interfaces is done in house. It does involve some level of overhead and development as well as ongoing maintenance.

 The use of Business Connectivity Services allows a company to easily integrate external data to SharePoint 2013 and Office 2013. The type of solution you are looking for will help you to decide how to control the data and how to update it in the external system. You can also set it up to work both online and offline. This allows work to be shared within SharePoint 2013  and Office 2013 .


Strategize Kerberos Authentication In SharePoint 2013

With Kerberos protocols, there is support for an authentication method using tickets that have been trusted as source providers. Kerberos tickets allow the network of credentials for a user that is associated with a given client computer to be authenticated. The Kerberos protocol defines how these users will interact with a network service to gain access to the various network resources.

The Kerberos Key Distribution Center (KDC) will issue a Ticket Granting Ticket (TGT) for a client computer. This is done on behalf of a given user. With Windows, the client computer is a member of an AD DS domain. The TGT is proof that the domain controller has authenticated the credentials of a given user.

Prior to establishing a network connection to a network service, the client computer must show TGT to the KDC and the request for a service ticket must occur. The previously issued TGT will confirm that the client computer has been authenticated. The KDC will issue a service ticket to the client computer.

The client computer will then submit the service ticket to the network service. The service ticket has to contain an accepted Service Principal Name (SPN) which is able to identify the service. To be able to enable Kerberos authentication, the client and server computers have to have a trusted connection to the KDC. The client and server computers also have to be able to successfully access AD DS.

There are many reasons why you should consider Kerberos authentication. They include:

  1. Kerberos protocol is the strongest of all Integrated Windows authentication protocols.
  2. It supports advanced security features including Advanced Encryption Standards (AES), encryption, and mutual authentication of clients and servers.
  3. It is designed for the delegation of client credentials.
  4. Kerberos requires the least amount of network traffic to AD DS domain controllers of the currently available secure authentication methods.
  5. It can reduce page latency in certain scenarios.
  6. It can increase the number of pages for front end web servers in certain scenarios.
  7. Kerberos is able to reduce the loan on domain controllers.
  8. This open protocol is supported by a variety of vendors and platforms.

Kerberos authentication isn’t always right though in the following scenarios:

  1. This authentication can require plenty of additional configuring to the infrastructure and environment. The domain administrator permission will be required for such configuration to be completed. This can be difficult to set up and hard to manage. If Kerberos isn’t configured correctly then the request to authenticate websites will fail.
  2. This authentication will require client computer connectivity to KDC and to AD DS domain controller. With Windows, SharePoint deployment relies on the KDC as the AD DS domain controller. This is a common network configuration for an organization in regards to their intranet. However, it isn’t usually the configuration for an internet facing deployment.

The authentication of Kerberos supports the delegation of client identity. This results in a service that can both impersonate and authenticate the identity of the client. With impersonation, it is possible for a service to pass the authenticated identity to other network services on behalf of the client. With claims based authentication, it can also be used to delegate client credentials. However, this also means the back end application will have to be claims aware.

With SharePoint 2013, Kerberos delegation will result in a front end service to authenticate the client and their identity to a back end system. The back end system is then able to perform with its own authentication. When a client uses Kerberos for front end service, then the delegation can be used to pass the identity of the client to a back end system. The Kerberos protocol is able to support 2 types of delegation:

  1. Basic Kerberos delegation (unconstrained)
  2. Kerberos constrained delegation

Basic Kerberos delegation can actually cross domain boundaries, but it has to be within the same forest. Kerberos constrained delegation isn’t able to cross domain or forest boundaries. Based on the service applications that belong to the SharePoint 2013 deployment, the implementation of Kerberos authentication with SharePoint 2013 can require the use of Kerberos constrained delegation.

In order to successfully deploy Kerberos authentication with any of the below mentioned service application, SharePoint Server 2013 and all of the external data sources have to reside in the same Windows domain:

  1. Excel Services
  2. Performance Point Services
  3. InfoPath Forms Services
  4. Visio Services

In order to deploy Kerberos authentication with any of the below service applications or products, SharePoint Server 2013 has to use either basic Kerberos Delegation or Kerberos Constrained Delegation:

  1. Business Data Connectivity Service
  2. Access Services
  3. SQL Server Reporting Services (SSRS)
  4. Project Server 2013 Preview

Any services that are enabled for Kerberos authentication can be delegated for identity multiple times. The identity will travel from service to service, and that delegation method can also change from basic Kerberos to Kerberos constrained but it isn’t possible to do it in the reverse order.

The delegation method can’t be changed from Kerberos constrained to basic Kerberos. With this in mind, it is very important to plan what you want your back end service to be and if it will require basic Kerberos delegation or not. Such information will play a role in the overall planning and design of the domain boundaries.

With Kerberos enabled service, you can use protocol transition to convert to a non-Kerberos identity into one that can be delegated to other Kerberos enabled services. This is an ability that can be used to delegate a non-Kerberos identity from a front end service to on that offers a back end service.

The protocol transition requires Kerberos constrained delegation. The protocol transition identities aren’t able to cross domain boundaries. The use of claims based authentication can be used as an alternate to Kerberos delegation. With claims based authentication, it is possible to pass it back and forth between the different services, but only if the following criteria are in place:

  1. Trust relationship between the services
  2. All services must be claims aware

SharePoint 2013 is able to support claims based authentication. This is built on the Windows Identity Foundation (WIF). This is a set of the .NET Framework classes used to implement claims based identity. This type of authentication requires standards including WS Federation and WS Trust.

When creating a SharePoint 2013 web application, the use of the Central Administration is necessary and you have to select 1 or more claims based authentication types. When you create SharePoint 2013 web applications from New-SP Web Application Windows PowerShell cmdlet, you get to specify either claims authentication or the types or class mode authentication.

All of the supported authentication types are available for web application and you can decide how to best use them for server to server authentication and app authentication. The following are service applications in the SharePoint Service 2013 that require translation of the claims based credentials to Windows credentials. This is a process done through the Claims to Windows Token Service (C2WTS). They include:

  1. Excel Services
  2. Performance Point Services
  3. Info Path Forms Services
  4. Visio Services

Any of the service applications that require C2WTS have to use Kerberos constrained delegation. This is due to the fact that C2WTS requires protocol transition that is only supported by Kerberos constrained delegation. The service applications in the above mentioned list allow the C2WTS to translate the claims within the farm to Windows credentials for outgoing authentication.

It is very important to realize that these service applications can use the C2WTS if they have incoming authentication from either Windows claims or Windows classic mode. Service applications that are going to be accessed through web applications or that use SAML or forms based authentication claims aren’t able to use C2WTS. They can’t be translated to Windows credentials.

When using Windows claims mode for user authentication, the web application needs to be configured to use only Kerberos authentication. It shouldn’t be set up to fall back to NTLM as that will prevent the authentication protocol from working.