Home » Posts tagged 'Kerberos'

Tag Archives: Kerberos

Advertisements

Kerberos: Troubleshooting Diagram

In the past year I’ve become more and more interested and familiar with Kerberos authentication. While I’m not saying that you should “Kerberize” everything, I think everyone installing and configuring apps on the Windows platform should have a basic understanding of it.

Below is a decision-based workflow I created to counter some simple pitfalls. Although some of it might seem easy, it gets forgotten a lot. In the example a user is browsing a web-based application which is reachable at “webapp.contoso.com”. In fact this website is hosted on a server called web01.contoso.com.

Important to note that ending up in the orange field (“client uses NTLM”) isn’t necessarily bad, but it might be when your web app does some form of delegation afterwards. On the other hand, if you end up in the “authentication impossible”, you will never-ever get granted access to the application.

This example is based on a web-based application, but the reasoning is exactly the same when the IE browser is a SQL client and the application pool for the website is a SQL Server service.

Perhaps the most common one to be encountered is the one where someone uses a service account for an application pool instead of the network service. If you then try to access the website with the name of the machine, you will always end up in the “authentication impossible”.

Any feedback or comments is highly appreciated. The chart, click the picture for a clearer view:

[image[16].png]

Source: http://setspn.blogspot.com.es/2010/05/kerberos-troubleshoot-workflow.html

Advertisements

Updating a server’s security group membership without rebooting

At TEC I had a conversation with someone asking me how they could flush the Kerberos tickets of a computer account without rebooting. In the past they used some trick which launched a task in the Local System context and executed “klist –purge” but that didn’t seem to work no longer for 2008 (R2?).

There is actually something which is much easier: you can execute “klist –li 0x3e7” to target the logon session of the computer account.

image

And if you want to purge them, just execute “klist –li 0x3e7 purge”.

image

This will work on any system, client or server, regardless the OS version. The 0x3e7 is an identifier which always points to the computer account logon session. Using logonsessions.exe from the Sysinternals tools, you can actually try to find out id’s for other active sessions. You could use this to get the session id of a service account, and then retrieve it’s current Kerberos tickets. Cool eh! Besides using logonsessions.exe, you can also try to find these IDs in the security event log.

Flushing the Kerberos tickets of a computer can be useful if you want to force the computer having the latest group membership in its token. This way your newly configured GPO’s (with security filtering based on a group) will be applied immediately (after running gpupdate).

Source: http://setspn.blogspot.com.es/2010/10/updating-servers-security-group.html

Understanding Kerberos Authentication Setup

FIM 2010: Understanding Kerberos Authentication Setup

This is in fact a double post. I posted this article to the TechNet Wiki for which I originally wrote this article. Link: TechNet Wiki: FIM 2010: Understanding Kerberos Authentication Setup

The goal of this article is to provide some background information regarding the Kerberos related configuration steps of the FIM Portal and FIM Service. The article has been written in such a way so that most of the points can in fact be used for any application requiring Kerberos.

This article will not discuss the various possible FIM Topologies. All information should be valid regardless whether all roles are combined on a single server or split across multiple servers.

Throughout the article a demo domain will be used. The domain which will be referenced as an example is contoso.com (NetBIOS name: CONTOSO).

Table of Content:

  1. Identify Services
  2. Identify Service Identities
  3. Name Services
  4. Configure DNS
  5. Configure Service Principal Names (SPN’s)
  6. Configure IIS for Kerberos
  7. Identify Delegation Requirements
  8. Configure Delegation
  9. Enforce Kerberos (FIM Specific)

1. Identify Services top

Before we can start configuring SPN’s (Service Principal Names) we have to determine what services we want to enable for Kerberos authentication. A typical FIM Portal deployment has the following services:

  • Database for the FIM Service (SQL Service)
  • FIM Service
  • FIM Portal (Windows Sharepoint Services (WSS))

note Note

In the above overview we’re leaving the FIM Synchronization Service and the databases for the WSS aside. They don’t bring any added value to this article.

The following picture provides an overview of these services.

0.Servers

2. Identify Service Identities top

Kerberos is all about authenticating principals to a service. Each principal is represented by an account in AD. This can either be a computer or a user account. Before Kerberos can take place, each service should be represented by an account in AD. Again this can either be a computer or a user account. Therefore it’s important to determine which account represents a given service.

note Note

A typical Windows Service has its identity configured in the Services MMC. A website however has its identity configured in the IIS Management Console (below the Application Pools section)

The list below provides an overview of our services and their associated identities.

  • Database for the FIM Service: the user account running the sqlservr.exe process of the SQL Instance hosting that database
  • FIM Service: the user account running the FIM Service service
  • FIM Portal: Application Pool identity in IIS for the FIM Portal site

This information is displayed in the following picture.

1.ServiceAccounts

3. Name Services top

Besides the principal representing a service, we also need to determine a name to access the service. Choosing names can be rather important when actual people are involved. Check the following examples:

  1. The FIM Service is configured to access its database on SPRDL2FIMSQL01B.contoso.com
  2. Users visit the FIM Portal by browsing to SPRDL3FIMPOR01.contoso.com

The first one is in fact not a problem at all. Nobody will mind that a name, for which IT probably has an explanation, is configured for a service to use. In the second example your users will by no means be able to remember the URL. Something like fimportal.contoso.com is way more feasible.

note Important

Choose your service names carefully and always keep in mind whether end-users will use them.

2.NameServices

In the picture above several client-server communication arrows have been pictured. In our example we will go with the following names to access the services:

  1. Database for the FIM Service: fimsql.contoso.com
  2. FIM Service: fimsvc.contoso.com
  3. FIM Portal: fimportal.contoso.com

note Note

There’s nothing wrong with choosing the actual server name of the SQL server to associate with your SQL service.

4. Configure DNS top

Clients have to be able to resolve the names for these services. We can register these records in DNS. It might seem convenient to use an alias (CNAME) record for some of the services. However this is a bad idea as explained in the following paragraph.

Using a CNAME record would ensure that updating the server its IP has no influence on the service name record. However CNAME records resolve in another way than A records. A client requesting a Kerberos ticket for a given service will ask AD a ticket for whatever the name resolves to. This is how a client will resolve those names:

  • fimsvc.contoso.com (CNAME) -> server01.contoso.com -> IP_of_FIM_Server
  • fimsvc.contoso.com (A) -> IP_of_FIM_Server

In bold the names are shown for which a Kerberos authentication attempt will be performed. In the first example you can clearly see that our client will request a Kerberos ticket for the wrong service as our service is coupled to fimsvc.contoso.com. So things will go wrong. For more information check Kerberos Basic Troubleshooting: Tip 3: SPNS and CNAME Records

note Important

Register A records to ensure the correct service name is used in the Kerberos authentication attempt

5. Configure Service Principal Names (SPN’s) top

So we got a name and an identity for our service. How do we tell AD that these belong together? Ahah! Now we get to the Service Principal Names (SPN’s). Whenever someone wants to use Kerberos to authenticate to a given service, they contact the Key Distribution Centre (KDC) and ask for a service ticket. The KDC is running on each domain controller. It knows which ticket to hand out because the client specified the service it wants a ticket for. The service was in fact specified by its name. More particularly by using the Service Principal Name (SPN).

An SPN is based upon the following format <service>/<fqdn>:<port>

In our example we will execute the following commands:

  • Setspn –S MSSQLsvc/fimsql.contoso.com:1433 sa_sqlsvc
  • Setspn –S MSSQLsvc/fimsql:1433 sa_sqlsvc
  • Setspn –S FIMService/fimsvc.contoso.com sa_fimsvc
  • Setspn –S FIMService/fimsvc sa_fimsvc
  • Setspn –S HTTP/fimportal.contoso.com sa_wss
  • Setspn –S HTTP/fimportal sa_wss

note Important

Never register a given service (<service>/<fqdn>:<port>) on multiple accounts. Whenever multiple accounts are responsible for the same service, AD cannot determine which account to use to hand out the Kerberos service ticket. As such Kerberos authentication breaks. This issue is called Duplicate SPNs. You can do a quick check in your domain for duplicate SPN’s by executing Setspn -X.

note Important

Always register both short and long (domain fqdn) for a service. This will ensure Kerberos is available at all times.

note Important

SQL always requires an SPN of the format MSSQLsvc/<fqdn>:<port>, even when using the default (1433) port. If your port is dynamic you have to configure it to be static or give the SQL Server service account permissions to update its own SPN’s.

note Note

A lot of guides will tell you to use Setspn –A instead of setspn –S. The advantage of using the –S option is that it will check the domain prior to adding the SPN. This will avoid setting duplicate SPNs.

6. Configure IIS for Kerberos top

When the above steps have been implemented, both the FIM Service and SQL will start accepting Kerberos. However IIS is slightly different. In fact skipping this particular step will often break your configuration all together. One of the symptoms when having a bad Kerberos implementation is the following: you type the URL of your website, you get presented with an authentication prompt, and no matter how many times you correctly enter your credentials, you keep getting prompted over and over again.

This issue occurs because by default IIS uses the account of the server to validate service tickets instead of the Application Pool identity. We can force IIS to use the identity of the application pool by configuring this in the applicationHost.config configuration file.

note Important

The applicationHost.config is typically located in c:\windows\system32\inetsrv\config\Remember to take a backup when modifying this file.

The following steps are required to configure Kerberos Authentication to work with a custom Application Pool Identity.

Launch an elevated command prompt and execute the following commands:

  1. cd c:\Windows\System32\inetsrv\config
  2. copy applicationHost.config applicationHost.config.dateOfToday.bak
  3. notepad applicationHost.config

Search for windowsAuthentication enabled="true" if you are below:

<location path="SharePoint - 80">

The above might actually be different in your environment. You need to locate the path of the IIS site which represent your FIM Portal WSS site.

Add useAppPoolCredentials="true" so the line looks like:

<windowsAuthentication enabled="true" useAppPoolCredentials="true">

Save the file and exit notepad

Execute the following command: iisreset

7. Identify Delegation Requirements top

Now that we got Kerberos authentication working for all of the involved services we have to determine whether additional configuration is required. Sometimes it’s obvious that Kerberos delegation has to be configured, sometimes it’s less obvious. Either way, it’s advised to check the product specific documentation to be sure. Kerberos delegation will allow a service to impersonate a visiting user and authenticate to another service as if it were the user himself who visits that service.

From the FIM Installation Guide we know that the following delegation scenarios are required:

  1. FIM Portal to FIM Service
  2. FIM Service to FIM Service

This is explained in the "Establish SPNs for FIM 2010" section of the installation guide.

3.Delegation

8. Configure Delegation top

To allow a given service to delegate to an other service, we have to configure delegation on the service its service account to the delegated service its SPN. Delegation can be configured using Active Directory Users & Computers (ADUC). As explained in the previous section we have to configure the following delegation scenario’s:

For the Portal to be able to delegate to the FIM Service we would have to:

  1. Open ADUC and locate the service account for the Portal (sa_wss)
  2. Open the properties of sa_wss and choose the delegation tab
  3. Check Trust this user for delegation to the specified services only
  4. Check Use Kerberos only
  5. Click Add…
  6. Click users or Computers…
  7. Type the name of your FIM Service service account: sa_fimsvc
  8. Click Check Names and Click Ok
  9. Select the FIMService entry and Click Ok
  10. Click Ok to close the account properties

Some screenshots to aid in the process: FIMService selection screen

4.Deleg_Select

And the resulting Delegation tab for the sa_wss acocunt:

5.Deleg_Configured

For the FIM Service to be able to delegate to the FIM Service we would have to:

  1. Open ADUC and locate the service account for the Portal (sa_fimsvc)
  2. Open the properties of sa_fimsvc and choose the delegation tab
  3. Check Trust this user for delegation to the specified services only
  4. Check Use Kerberos only
  5. Click Add…
  6. Click users or Computers…
  7. Type the name of your FIM Service service account: sa_fimsvc
  8. Click Check Names and Click Ok
  9. Select the FIMService entry and Click Ok
  10. Click Ok to close the account properties

note Note

The delegation tab on a user is only visible when an SPN has been registered for that account.

note Note

The above procedure assumes your domain is in 2003 DFL or higher. Windows 2000 DFL only has unconstrained delegation available.

9. Enforce Kerberos (FIM Specific) top

Optionally you can configure the FIM Portal to only accept Kerberos. This is explained in the FIM Installation Guide  > Installing The FIM 2010 Server Components > Activating The Kerberos Protocol Only (link)

The following steps are required to force Kerberos Authentication for the FIM Portal.

Launch an elevated command prompt and execute the following commands:

  1. cd c:\inetpub\wwwroot\wss\VirtualDirectories\80
  2. copy web.config web.config.dateOfToday.bak
  3. notepad web.config

The above might actually be different in your environment. You need to locate the path of the IIS site which represent your FIM Portal WSS site.

Locate the element

<resourceManagementClient . . . />

Add requireKerberos=”true” so that it reads

<resourceManagementClient requireKerberos="true" . . . />

Save the file and exit notepad

Execute the following command: iisreset

Source: http://setspn.blogspot.com.es/2011/06/fim-2010-understanding-kerberos.html

Kerberos Basic Troubleshooting

Whenever you’re doubting Service Prinicpal Name (SPN) registration, you can start using setspn. With each new version of Windows the setspn command line utility has been extended. The options below are based on the Windows 2008 R2 setspn.

  • setspn –x: allows you to do a quick check for duplicate SPN’s in the domain. Which in turn might explain why you are falling back to NTLM

image

  • setspn –l: allows you to list the registered SPN’s for a given machine or user account

image

  • setspn –q: allows you to query for a given SPN

image

  • setspn –d: allows you to remove a given SPN from a given account

image

  • setspn –a: allows you to register a SPN for a given account: try to avoid this one,use setspn –s (and –f) instead.
  • setspn –s: allows you to regsiter a SPN for a given account after verifying no duplicates exist in the domain
  • setspn –f –s: allows you to regsiter a SPN for a given account after verifying no duplicates exist in the forest

image

Whenever registering SPN’s you have to carefully construct it: what service is it for, which name will be used to access it, and what port is it running at. For most services this is straightforward, but Internet Explorer as a web browsing client complicates this. IE6, IE7 and IE8 still ignore the port entered in the address bar. They even ignore the name if it is a CNAME record. Why is there a difference between a CNAME and A record?

image3_thumb[1]In the screenshot you can clearly see that in the first case (A record) the “alias.home.local” resolves to an IP address. However with a CNAME record, the “cname.home.local” resolves to the “dc01.home.local” and then to the IP address. If you are browsing with IE to cname.home.local, a SPN will be queried for using “dc01.home.local”.

Therefore it’s advised to always use A records for your web sites. And keep in mind that registering the port in the SPN for HTTP web sites is mostly in vain. You can alter this behavior according to KB908209: Internet Explorer 6 cannot use the Kerberos authentication protocol to connect to a Web site that uses a non-standard port in Windows XP and in Windows Server 2003 It says IE6 in the title but in the applies to section IE7 and IE8 are mentioned as well. In case you really aren’t getting where you want with the SPN’s if you can’t include the port number you could create the registry keys as described in the KB article.

So as a final tip for today, make sure to use ping whenever troubleshooting your SPN’s. It will show you how and if the name you registered the service under is reachable.

Source: http://setspn.blogspot.com.es/2010/06/kerberos-basic-troubleshooting-tip-3.html