{"id":1224,"date":"2014-06-10T08:08:15","date_gmt":"2014-06-10T07:08:15","guid":{"rendered":"http:\/\/blog.repsaj.nl\/?p=1224"},"modified":"2014-09-15T14:56:16","modified_gmt":"2014-09-15T13:56:16","slug":"sp201x-implementing-kerberos-delegation-in-sharepoint","status":"publish","type":"post","link":"http:\/\/blog.repsaj.nl\/index.php\/2014\/06\/sp201x-implementing-kerberos-delegation-in-sharepoint\/","title":{"rendered":"[SP201x] Implementing Kerberos delegation in SharePoint"},"content":{"rendered":"

Kerberos is often perceived as painful to setup and hard to debug. And to be honest: in my opinion it\u2019s not one of the most user friendly techniques out there. But once you get the hang of it, the bigger picture start becoming clear and things get easier. In this article I will explain how to use Kerberos in combination with Business Connectivity Services (BCS) to delegate a users\u2019 credentials to SQL Server. So let\u2019s get to it!<\/p>\n

An example case<\/h2>\n

Let\u2019s start with a short case description for some context. Suppose you\u2019re contacted by a business user, John, who wants to surface data from a SQL server database in SharePoint. The data in the database is of sensitive nature. Based on the logged on user, John wants the solution to filter the records so only the appropriate ones are shown. So there is a need for an additional layer of security, to make sure the correct data is visible for each user.<\/p>\n

There are some routes you may consider:<\/p>\n

    \n
  1. Create a web service which queries the database and adds a layer of security to make sure the user only sees the appropriate data. Connect your BCS entities to this web service, instead of directly to SQL.<\/li>\n
  2. Create views within SQL which use the current logged on user to pre-filter the table and return only relevant data. This is sometimes referred to as view-time <\/em>security.<\/li>\n
  3. Use reporting services to create a report which filters data based on the current user.<\/li>\n<\/ol>\n

    The real creative thinkers amongst you might think of more ways to do the same, but that\u2019s not the point here. The point is that SharePoint is not going to magically filter the data, so you need to make arrangements to make sure that your security requirements are met. And for that, you will need to be able to know which user is requesting the data, no matter which solution you choose.<\/p>\n

     <\/p>\n

    Kerberos authentication, the basics<\/h2>\n

    As the name implies, Kerberos will help us with authenticating the user. It\u2019s important to understand that authentication is not the same as authorization. Authentication will help you to identify the user, making sure their identity is validated. Authorizing is the process of granting a user access to resources, based on that same identity. I will not go into the details of authentication; it suffices to know that Kerberos implements a way of checking your credentials to validate your identity. In Microsoft Active Directory environments, Kerberos or NTLM is used as authentication method, where Kerberos is the more secure one.<\/p>\n

    In the mentioned case, our user\u2019s identity will be used in several places:<\/p>\n