One of my customers had problems with certain users being member of a lot of Active Directory groups. This resulted in several client side issues. There’s an easy and well-known “fix” for that: raise the MaxTokenSize registry key on all Windows operating systems in your domain. On Windows 8(.1) / 2012 (R2) the MaxTokenSize is already at its maximum (advised) value out of the box. That value is 48.000 bytes. In order to mitigate these users their access problems we raised the MaxTokenSize to 48.000 bytes on all clients and servers that are running Windows 7/ Windows 2008 R2. After this change the typical issues were gone. However new ones came up:

From time to time, when HTTP is involved, issues were encountered:

• Opening the Direct Access management console (depends on WinRM)
• Open the FIM Portal
• Streaming App-V packages over HTTP
• …

Typically the user would receive several authentication prompts and even after specifying valid credentials another prompt would reappear. Example browser based issue:

As you can see the browser gives an HTTP 400 Bad Request error. Using a network trace we can easily see why it’s considered bad:

And the packet details:

The details clearly state that The size of the request headers is too long.

The problem here is that the token is allowed to be up to 48.000 bytes where it used to be 12.000 bytes. The http subsystem of a windows server has several parameters that are supposed to protect the server from oversized requests. However, as the token can now be a lot larger, the maximum request size has to be tuned as well:

From: KB820129

Below: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters there are two interesting values:

And from: KB2020943 we can find a formula to calculate the MaxFieldLength to set based on the MaxTokenSIze.

If MaxToken is 48.000 bytes (default in Windows 2012 and configure by GPO for 2008 R2/ Win7):

• (4/3 * 48000) + 200 = 64200

We’ll use the maximum allowed value of MaxFieldLength 65534 (=~ 64200) to allow tokens up to 48000 bytes. We’ll also use this value for MaxRequestBytes.

• MaxFieldLength: we can take the maximum allowed value: 65534
• MaxRequestBytes:  65534

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters

Other useful information:

• http://blogs.msdn.com/b/ashishsingh/archive/2010/04/03/windows-authentication-for-accounts-with-large-kerberos-tickets-may-not-work-despite-having-maxtokensize-in-place.aspx
• http://www.grouppolicy.biz/2013/06/how-to-configure-iis-to-support-large-ad-token-with-group-policy/

I specifically wanted to post this information as in many other only articles/posts I always see people just using the maximum allowed value for MaxRequestBytes and I don’t feel 100% comfortable with that. Second,  in my opinion it’s advised to have these values pushed out to all your server systems. Especially now that Windows 2012 and up have a MaxTokenSize of 48.000 by default. If you don’t push these HTTP.sys parameters, you’ll end up troubleshooting the same phenomena multiple times from different angles. Why waste time?

Ok, I’ve gone through my mailbox and I’ve got quite some little neat tricks I want to share and most of all never forget myself. So I’ll put them here for future reference.

Tip #1 (Network):

Remember “Network Tracing Awesomeness” If you’d only want to have traffic captured which involves a specific IP you can start the trace like this:

netsh trace start capture = yes ipv4.address=10.90.101.41

This can be very convenient if your server is a domain controller or a file server and communicates with a lot of clients all the time.

Tip #2 (IIS):

In various IIS Kerberos configuration howto’s you are instructed to set useAppPoolCredentials to true. I Always hate editing XML’s directly as it’s quite easy to make errors. Using the following command you can easily set this parameter from a command prompt:

appcmd set config "Default Web Site" /section:windowsauthentication
/useAppPoolCredentials:true /commit:MACHINE/WEBROOT/APPHOST
(the command is supposed to be on one line)

The Default Web Site is the name of the site as it appears in the IIS management console. Remember, you might need to have something like Default Web Site/vDir If you have to configure this for sublevels of the site.

Tip #3 (Kerberos):

If you enable an account to be trusted for delegation to a given service, you might have to wait some time before the service itself notices this. This is often noticed as: I changed something, it didn’t work and magically the next day it started working. If I’m not mistaken, this might have to do with the Kerberos S4U refresh interval which is at 15’ by default. At least that was the value at Windows 2003… See also: KB824905: Event ID 677 and event ID 673 audit failure messages are repeatedly logged to the Security log of domain controllers that are running Windows 2000 and Windows Server 2003

Tip #4 (PowerShell):

From: MSDN: Win32_PingStatus class

When you use PowerShell to perform remote tasks on a server, such as WMI queries, it might be way more efficient to do a quick ping before actually trying to talk WMI to the server. This way you can circumvent those nasty timeouts when the server you are trying to talk to is down.

$server = "server01"
$PingStatus = Gwmi Win32_PingStatus -Filter "Address = '$Server'" |Select-Object StatusCode

Tip #5(Tools):

Every once in a while I need a tool from the Sysinternals Utilities set. Mostly I go to google, type in the name, get to the Microsoft site hosting the utility and click launch. However, it seems you easily access all of the tools using this webdav share: \\live.sysinternals.com just enter it in a file explorer or your start-> run. The utilities we all know so well are located in the Tools folder. Or if that doesn’t works, just use http://live.sysinternals.com/ 

Thanks to a colleague for this last tip!

-Stay tuned for more!-

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
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.

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
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.

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.

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

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
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

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

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.

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

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
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.

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.

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.

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

And the resulting Delegation tab for the sa_wss acocunt:

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
The delegation tab on a user is only visible when an SPN has been registered for that account.

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.

Happy Kerberizing

To be completely honest this subject has been blogged a lot in the past. However just this Friday I helped a colleague which was having issues setting up DNS aliases for SQL. He seemed to have troubles connecting his Management Studio to SQL. And today I could use the information again when working at a customer which was having issues authenticating to his webserver. So I believe this is still solid information to spread.

So if you hit google with "disableloopbackcheck windows 2008 R2” you get quit some results. And if you search the official KB articles, this registry setting is referenced a lot when dealing with Access Denied errors locally on a machine. All these scenario’s have one thing in common: someone or some service is trying to access a service under an alias and this from on the machine itself.

Simple example scenario: you set up Active Directory Certifcate Services and you choose “pki.contoso.com” as an alias for your Certificate Authority server. After configuring this record in DNS, you try to access this website http://pki.contoso.com/certsrv on the CA itself in vain. After trying to provide correct credentials multiple times it just fails. You are getting that nasty “HTTP Error 401.1 – Unathorized You do not have permission to view this directory or page using the credentials that you supplied”.  Accessing this from a remote workstation using the same credentials works just fine.

If this is your problem, are it sounds similar, then this is your solution:

• kb926642: You receive error 401.1 when you browse a Web site that uses Integrated Authentication and is hosted on IIS 5.1 or a later version
• kb926642: Error message when you try to access a server locally by using its FQDN or its CNAME alias after you install Windows Server 2003 Service Pack 1: "Access denied" or "No network provider accepted the given network path"
• kb887993: Users experience authentication issues when they access a Web page in IIS 6.0 or query Microsoft SQL Server 2000 after you install Windows Server 2003 Service Pack 1
• kb914060: A logon window appears in Windows Server 2003 Service Pack 1 NLB when you try to browse the virtual NLB cluster name
• kb971382: Errors when crawling content sources in SharePoint Server 2007: "Event ID 2436" and "Access is denied"

And the list goes on. The workaround is very easy and active immediately: just create a REG_DWORD called DisableLoopbackCheck below HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa and give it a value of 1

One of the articles actually references the DisableStrictNameChecking registry key. I remember setting this one when accessing a share didn’t worked when using an alias. Must but it’s older brother. Here’s an explanation: kb281308: Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name The reason we’re probably hearing this one a lot less is because since SMB 2.0 (Windows 2008 and up)  this is no longer required.

A while ago I wanted to view the event log of a server. For this task there is no need to log in using remote desktop. However when I fired up the event log viewer and tried to connect to the NetBIOS name of my server I got the following error:

Using remote desktop I could connect just fine to the server. At least that’s what it looked like. Locally I could open the event log without issues. But I saw events which couldn’t possibly be logged on this server. And then it came clear, there was an IP conflict! To be honest it’s a lab environment so these things can happen occasionally.

The reason this fails is because my client (my administration pc) asks AD for a Kerberos Ticket for server x whilst when connecting I’m actually presenting this Kerberos Ticket to server y. This results in a server receiving a ticket encrypted with a password other than it’s own. Result: the above error.

Thomas, we should have updated the CMDB, Vuylsteke

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.

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

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).

[Update 21/12/2010] This topic was discussed on the FIM TechNet Forums as there’s some official Technet Documentation out there now, I would like to reference here. For a fully supported Kerberos enabled CAS array, Exchange 2010 SP1 is required, and you can follow this guide: http://technet.microsoft.com/en-us/library/ff808313.aspx

One of the problems I had with FIM 2010 in the past is the configuration of the RPS URI in the FIM Active Directory Management Agent (AD MA) configuration. When you want FIM to provision mailbox’ for you, or when using FIM for GALsync (provision contacts) you have to provide the URL to the exchange PowerShell webservice (http://webmail.contoso.com/powershell):

A lot of Exchange environments have more than one CAS server, typically these are combined with a NLB solution. So ideally you just point FIM to the CAS URL (like webmail.contoso.com) and thus ensuring FIM will not be dependent on the uptime of one specific CAS server. Because the MA only uses Kerberos to connect to that URL, there is a problem. Out of the box the CAS array URL is not kerberos enabled. As such the provisioning of mailbox’ will fail. When targeting a specific CAS server Kerberos authentication goes just fine. Because all required SPN’s are registered for each CAS server by the exchange setup and thus Kerberos authentication against a CAS server works.

From Exchange 2010 RU3 (Or RU4, not quit sure) there is a way to enable the CAS array for Kerberos. The word is out that this would officially be supported from Exchange 2010 SP1. The following steps are required:

1. Create a service account in Active Directory: svc_exchange
2. Register the SPN’s on this account (I always register both FQDN and short):
   • setspn -F -S exchangeMDB/webmail.contoso.com CONTOSO\svc_exchange
   • setspn -F -S exchangeRFR/webmail.contoso.com CONTOSO\svc_exchange
   • setspn -F -S exchangeAB/webmail.contoso.com CONTOSO\svc_exchange
   • setspn -F -S HTTP/webmail.contoso.com CONTOSO\svc_exchange
   • setspn -F -S exchangeMDB/webmail CONTOSO\svc_exchange
   • setspn -F -S exchangeRFR/webmail CONTOSO\svc_exchange
   • setspn -F -S exchangeAB/webmail CONTOSO\svc_exchange
   • setspn -F -S HTTP/webmail CONTOSO\svc_exchange
3. The following steps have to be executed on each CAS server
   • $cred = get-credential "CONTOSO\svc_exchange"
   • Set-clientaccessserver -Identity CASserver -AlternateServiceAccountCredential $cred
   • iisreset
   • restart-service MSexchangeAB
   • restart-service MSexchangeRPC
4. To verify the setting, execute the following on each CAS server
   • Get-ClientAccessServer -Identity CASserver -IncludeAlternateServiceAccountCredentialStatus |fl AlternateServiceAccountConfiguration

From now on, if you use outlook to connect to the CAS array, or just when provisiong with FIM and using HTTP, Kerberos will be used. You can eassily verify this with Klist (Windows 2008 and up built-in) or with Kerbtray. Or just in the security eventlog of a CAS server.

The actual procedure I used comes from the following blog:  TUTORIEL: Exchange 2010 SP1 (Beta) - Activer Keberos pour un pool de serveurs CAS (Client Access Array) As it’s French, I think it’s justified to have some English alternative.

Technet help for the set-clientaccessserver command: http://technet.microsoft.com/en-us/library/bb125157.aspx

This week will be a short tip about how to enable Kerberos logging. As per KB262177 (How to enable Kerberos event logging), Kerberos logging can be enabled by creating the following registry key:

• HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
• Registry Value: LogLevel
  Value Type: REG_DWORD
  Value Data: 0x1

To disable it, simply delete the value or set it to 0. After enabling the logging you will receive Kerberos error event entries in the System event log. The setting will become effective immediately on Windows Server 2008, on Windows Vista, on Windows Server 2003, and on Windows XP. For Windows 2000, you must restart the computer.

When searching for Kerberos debug options, the registry keys “KerbDebugLevel” and “LogToFile” (also below the Lsa\Kerberos\Parameters hive) might come up. It is to my understanding that these do not have any effect on Windows 2008 and up. I asked this a while back on ActiveDir.org: Kerberos debug logging on Windows 2008

What events will be logged? The following is a short summary of the most common entries:

• KDC_ERR_PRINCIPAL_UNKNOWN: SPN not registered in AD, or service is being accessed under the wrong name
• KDC_ERR_PREAUTH_FAILED: can be safely ignored, is due to the way Kerberos works and how some Kerberos client compose their first request
• KRB_AP_ER_MODIFIED: bad error! someone is presenting a ticket for a service to a service while the ticket was encrypted with an account not responsible for the service. Wow what a line, bottom line: authentication is failing, no fallback to NTLM either!
• …

This MS document is a reference for the above (and other errors), contains many useful troubleshooting hints: Troubleshooting Kerberos Errors

Whereas the previous tip was mostly targeted at SQL related stuff, this one will go back to the basics. 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

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

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

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

• 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

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?

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.

This second Kerberos Basic Troubleshooting post will try to provide some tips and knowledge when setting up Kerberos authentication for SQL services. For starters I will explain which Service Principal Names (SPN’s) can be registered and when they will be called for.

There are three known forms of SPN’s which can be registered for a SQL service account. This service account can either be a user (service account) or a computer (local system) (MSDN: Service Principal Name (SPN) Support in Client Connections)

• MSSQLSvc/FQDN
• MSSQLSvc/FQDN:InstanceName
• MSSQLSvc/FQDN:Port

And here is where the confusion starts: depending on the protocol used to to connect to SQL, other SPN’s are built by the client and being queried to AD. In my line of work I hardly ever encounter the use of “named pipes” or “shared memory”. In 100% of the cases (mostly SQL services for Infrastructure Apps) I see TCP/IP being used. Although I provided 3 options for SPN’s, only one will be used for TCP/IP:

• MSSQLSvc/FQDN:Port

This is also explained in the MSDN: Registering a Service Principal Name article:

User-specified SPNs are supported in client drivers. However, if an SPN is not provided, it will be generated automatically based on the type of a client connection. For a TCP connection, an SPN in the format MSSQLSvc/FQDN:[port] is used for both the named and default instances.

I would just forget the other formats, unless you are using named pipes/shared memory.

Whenever you are using a dynamic port you got a problem. Because each time SQL Services get started, the TPC/IP port can change and hence the SPN can be incorrect. There are two options for this problem, in my opinion the second option is the preferred one:

• Alter the permissions on the service account so it can update it’s own SPNs: grant “SELF” the “Write servicePrincipalName” permission.

• Configure a static port for the SQL Service. A static port can still be combined with the SQL Browser Service. So for applications which do not support entering a fixed SQL Port should be fine as well. An example is shown below: the FIM Portal & Service setup asks for a server and optional Instance, but no port is asked for. You could fool the setup perhaps by providing it anyway using a comma or double point. But having a static port configured and the browser service started will do just fine.

Although I just said to forget the other SPN’s, you might actually use them in some cases. The new SQL 2008 native client has a new feature which allows you to actually configure which SPN the client will query for during authentication. So the client it self will no longer just build the SPN by using FQDN:Port. In this case I does not matter which port SQL is using, you can simply register the SPN MSSQLSvc/FQDN:InstanceName (or something else you like) as long as you provide it in the ODBC connection settings.

I’m quit sure if the ODBC configuration allows this feature It won’t take long for the application installers to allow it. It would be nice to provide an optional SPN when configuring a SQL connection during a regular application setup. This would definitely provide more flexibility.

And now some diagnostic stuff. So you got your new shiny SQL configured, you registered the SPN and installed your application. But who can tell whether your using Kerberos or not? Here are some options:

• Wireshark: the wire never lies. However this requires you to install Wireshark, capture a trace, …
• Security event log: It’s all in there, however there is a lot in there…
• SQL query: It’s just easy!

Start the SQL Management Studio, select the SQL Server in the left pane and click New Query

Provide the following code, select it and press F5 (execute)

The code itself:

SELECT DB_NAME(dbid) AS DatabaseName, loginame AS LoginName, sys.dm_exec_connections.auth_scheme as AuthMethod
FROM sys.sysprocesses
JOIN sys.dm_exec_connections
ON sys.sysprocesses.spid=sys.dm_exec_connections.session_id
WHERE dbid > 0
GROUP BY dbid, loginame, spid,sys.dm_exec_connections.auth_scheme

And as a result the following information is provided: you can clearly see some of the connection are NTLM and some of them are Kerberos. The connections to the master/msdb being NTLM is just because those are connections on the machine itself. Remote connections will properly use Kerberos when the required SPN’s are registered.

Another reference on the topic: MSDN: How to Implement Kerberos Constrained Delegation with SQL Server 2008

I intended to write a single entry about Kerberos Basic Troubleshooting, but it would have grown way to long. So instead I decided to write one tip a week. The tips should help you out with simple Kerberos issues. Keep in mind that anyone can run into Kerberos issues whilst not specifically enabling a service for Kerberos. Since Windows 2000 Kerberos is the default authentication mechanism and as such can cause trouble to you. So perhaps I should say “Authentication Basic Troubleshooting tips”.

The tip of today will be KLIST (and Kerbtray).

Klist can list or purge tickets for a given session and is available in W2008 and up. For W2003 or lower klist is available in the resource kit tools. Some sample usage scenario’s:

Usage 1: “klist”: list the tickets of the current user . You can clearly see the difference between the “Ticket Granting Tickets” and the “Service Tickets”. Mostly the Service Tickets are the ones of interest.

Pitfall: you have to run klist from a non UAC elevated prompt. If you run klist in an UAC elevated prompt, you will get a list of tickets your user has inside that specific session. When doing a “run as administrator” for the cmd prompt, a new logon session is made.

Usage 2:”klist purge”: throw away all tickets of the current user

Usage 3: “klist –li 0x3e7” and “klist –li 0x3e7 purge”: allows you to list the tickets of a logon session specified as 0x3e7.

Why is this so special? On each machine 0x3e7 is the session of the machine (“Local System”) itself. How can this be interesting? Use the purge option and you have a way to refresh the group membership of a machine without having to reboot it! Which in turn can be useful for refreshing group policies based on group security filtering. Some references for this topic: topic at activedir.org and Picking up Computer Group Membership Changes without a Reboot.

An example of some tickets of a machine:

As an alternative Kerbtray can be used which is graphical. However it can only be used to show the tickets of the current logged in user. It is available through the Windows 2003 resource kit tools. I like this one on an USB stick when troubleshooting Kerberos issues on Windows XP workstations. Here you can see it on a Windows 2008 R2 server, still works without issues.

You can right click it and choose “List Tickets” or “Purge Tickets”. List Tickets show you the following:

So that’s it for today, next week another Tip will be posed.

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:

Mostly when I have issues logging on to a server, it's due to DNS problems. Sometimes the secure channel is messed up, but the last time it was actually quit simple: there was no SPN for the server in Active Directory.

The error: "The security database on the server does not have a computer account for this workstation trust relationship."