service class/host[:port[/service name]]

Today I will be talking about port. Port number is an optional qualifier that you can use to ensure that the SPN is unique in the forest.

The default port number for a http request is 80 (and 443 for https). If you are using the default port number for you application, then you don't need to add the port number when you are registering SPN because Internet Explorer knows that the port number should be ignored when requesting a Kerberos ticket.

On the other hand, if you are using a different port number, e.g. 82, then everything becomes a bit trickier.

Let us for a moment ignore the fact that there is really no need for a special port on the HRWeb application because Internet Information Server can use host name in the binding and allow many applications to use port 80 side by side. Instead, let us assume that we are listening on port 82 and that we have registered the following two SPN's for the application (both are pointing to the correct domain account for the application pool and the web site is configured to not use Kernel mode authentication).

http/hrweb:82
http/hrweb.mydomain.com:82

Next the user (Joe) is opening Internet Explorer on a domain joined Windows client to view his current salary. 

Sorry, but that doesn't work. At least not out of the box.

If you try, you will see the following error in the Failed RequestTracing on IIS:

The reason is that the default configuration for Internet Explorer does not include the port number when it is requesting a Kerberos ticket.

There is several ways to solve this, but you need to select the option that works best for you:

• Register the SPN without port number. Share application pool account.  Example:
  • HRweb:82 is assigned application pool A (using mydomain\hrwebact as application pool identity)
  • HRweb:83 is assigned application pool B (also using mydomain\hrwebact as application pool identity)
• Use a load-balancer that translate hostname into port number. Use a dedicated hostname for each application. Register the SPN without port number. Example:
  • HRweb:80 is translated by the load-balancer to *:82 on the web server (replace * with the actual IP address)
  • Training:80 is translated by the load-balancer to *:83 on the web server (replace * with the actual IP address)
• Configure the Internet Explorer to use port number when requesting a Kerberos ticket

The last option is described in kb 908209  (does also apply to IE8 and IE9) as a registry key. You need to think twice before doing this because it is an all-or-nothing change, you cannot specify that this change does only apply to some applications.

The name consists of two mandatory parts (service class and host) and two optional parts (port and service name).

The full syntax is:

service class/host[:port[/service name]]

Today I will  be talking about service class and host.

Host name is reasonable obviously: it is the host name that the client is using when accessing the service.

In the simples form, host name is the name of the server, e.g.

• MYSERVER
• MYSERVER.MYDOMAIN.COM

While servername appears to be an attractive choice, it has a major disadvantage when it comes to the scalability (or high-availability) of your application: you can only host the application on a single server.

Scaling the application to multiple servers can be achieved in many ways, e.g. using DNS Round robin, a hardware load balancer or using Network Load Balancing (NLB). In all cases the client is resolving a hostname to an IP-address and is then initiating a conversation with that IP address. The client does not know what server it is connected to - it could be a server with more than one IP-address or it could be a random server in a huge web farm with many hundreds servers. In all case you need a virtual hostname that is shared between all the servers.

The name resolution from the virtual hostname to IP-address is managed by the DNS server where you can make either an A-record (one or more fixed IP-addresses) or a CNAME (an alias for a hostname). If possible you should always use an A-record, as some applications (e.g. older Internet Explorer versions) does not like the combination of Kerberos and CNAME.

To prepare for scalability in the future where the demand of the HRWEB application exceeds one server you must therefore register (in DNS) an A-record for the HRWEB application

• HRWEB.MYDOMAIN.COM

and tell the users to access the application using the url https://hrweb.

It is recommended to register the SPN for both the NetBIOS name of the server (HRWEB) and the  Fully Qualified Domain Name (FQDN) of the server (HRWEB.MYDOMAIN.COM) to ensure that the client can get a ticket no matter what syntax the client is using.

Service class is trickier to understand.

If you search for SPN registration you may find many examples where the service class is HTTP, but in reality the service class is just a random name that you chose when you are designing your client/server application. 

If your client is a web browser, then the developer of the web browser made that choice for you, and yes - in that case the service class it is always HTTP.

Other well-known samples is MSSQLSvc that is used by SQL Server and HOST that is a common service class used by many Windows services like File and Print.

For solutions where you are writing both the client and server applications (e.g. using WCF) you will have more freedom to choose the Service class name. The only limitation is that you must ensure that the combination of service class and hostname is unique in the Active Directory forest.

I will come back to service class in a future post about constrained delegation.

One probably reason could be an error in the SPN registration.

During installation of SQL Server you need to decide what service account you are going to use for the SQL Server service. If you are using one of the built-in accounts (Local System, Local Service, Network Service) then the SQL Server service is able to maintain the SPN registration on your behalf because the SPN is registred on the computer account.

If you are using a service account (e.g. MYDOMAIN\SqlUser) for the SQL Server service, then the SPN must be registered on that account. If the SQL Server is installed by the domain administrator, then the installation will make that registration for you. But if you are installing the SQL Server as a local administrator on the Windows Server, then SPN registration may not work.

Start SQL Server Configuration manager to view the account name used for MSSQLSERVER:

Next check if there is registrered a SPN for that account. You can use either of the following two tools:

• Command line tool: SetSPN.exe mydomain\sqluser
• ADSI Edit: Open ADSIEdit.msc, connect to the domain, navigate to the account in Active Directory, view properties, select the servicePrincipalName attribute

In both cases you should find the following 3 registered SPN

MSSQLSvc/MYSQLSERVER
MSSQLSvc/MYSQLSERVER.mydomain.com
MSSQLSvc/MYSQLSERVER.mydomain.com:1433

Replace servername (MYSQLSERVER) and domain name (mydomain.com) with your own value.

Pay attention to not having duplicate SPN - you can check with setspn.exe -X. If the SPN is registered on the computer account and the SQL Server service is executed in the context of a user account, then remove the SPN on the computer account before you are registering on the user account. You may need to restart both web server and SQL server after changing the registration.

Start by ensuring that your web.config does not include impersonation:

<system.web>
   <authentication mode="Windows"/>
   <identity impersonate="false"/>
</system.web>

Next modify the section of your code where you are accessing ressources on behalf of the end-user.

The concept to the solution is described here but to make the sample more relevant for the described scenario I have extended the sample with a few more lines of code:

String connectionString = WebConfigurationManager.ConnectionStrings["HrWeb"].ConnectionString;
WindowsIdentity wi =  (WindowsIdentity)HttpContext.Current.User.Identity;
WindowsImpersonationContext ctx = null;
using (SqlConnection connection = new SqlConnection(connectionString))
{
   try
   {
     ctx = wi.Impersonate();
     connection.Open();

     // use the connection to the database on behalf of the end-user

     connection.Close();
    }
    finally
    {
     ctx.Undo();
     ctx.Dispose();
     ctx = null;
     }
}

(Make sure that you are completing the errorhandling before going into production with this code.)

To make the solution as secure as possible you should seek to limit the scope where you impersonating the end-user, and you should also ensure that any input from the end-user is properly validated to avoid SQL Injection.

Without doing anything, your connection will be made by the application pool account - in the described scenario that would be the mydomain\hrwebact account.

That was not what you wanted. The business requirement were that "all authorization should be managed on the SQL Server", and that would require that the connection to SQL Server is made with the end-user credentials.

To fix this, you need to ensure that the application is impersonating the end-user when the connection to the SQL Server is made.

If you search for "ASP.NET" and "impersonation" in your favorite search engine, then it is likely that you would find guidance on how to enable ASP.NET impersonation in this way:

<system.web>
  <authentication mode="Windows"/>
  <identity impersonate="true"/>
</system.web>

Before going into explaining why this is not the correct answere, just be warned that this will not work in IIS 7.0 or IIS 7.5 where you you will get a HTTP Error 500.24:

ModuleName ConfigurationValidationModule
Notification 1
HttpStatus 500
HttpReason Internal Server Error
HttpSubStatus 24
ErrorCode 2147942450
ConfigExceptionInfo 
Notification BEGIN_REQUEST
ErrorCode The request is not supported. (0x80070032)

You can solve this in two ways, either by adding the following parameter to the web.config:

<system.webServer>
   <validation validateIntegratedModeConfiguration="false"/>
</system.weSserver>

or by changing the application pool to use the "Clasic" Managed Pipeline Mode.

Howerver, the answer is still not correct. ASP.NET impersonation will only allow your application to access ressources locally on the web server in the context of the end-user. This could be a local instance of a SQL Server or it could be the file system. If the ressource is located on a different server - and we must assume that this is the case, otherwise we had no reason to enable delegation - then the database connection will still be made in the context of the application pool account.

We need to do something else. That is the topic for the next blog post.

• The client application (e.g. a web browser) is requesting a Kerberos ticket from the Domain Controller (KDC). As part of the communication with the DC, the client is sending the SPN for the service
• The DC find the domain account that matches the SPN, and create a ticket for the user.
• The ticket is encrypted with the password for the domain account of the receiving application. (To be more accurate: encrypted with the hash of the password for the domain account).
• The encrypted ticket is then sendt back to the client
• The client is sending the ticket to the web application in the authentication header to prove the identity of the user
• IIS is decrypting the ticket to get the identity of the user

To decrypt the ticket, the IIS must know to the password of the domain account. The password is stored (encrypted) in the applicationHost.config, e.g.

<applicationPools>
   <add name="HRWeb">
     <processModel identityType="SpecificUser" userName="mydomain\hrwebact" password="[enc:IISWASOnlyAesProvider:qu/80DmhQaUFn4DnDWsFF/uVty+WVR8WapGLJ77clKE=:enc]" />
  </add>
</applicationPools>

That should therefore not be a problem. But a change were made in IIS 7.0 (and later) that in some cases breaks the Kerberos configuration when the IIS is trying to decrypt the ticket using the password of the computer account. Read here for more info: https://blogs.msdn.com/b/sudeepg/archive/2009/02/08/iis-7-kernel-mode-authentication.aspx

In our HRWeb application the application pool account is configured to use a domain account as identity with a matching SPN.

When a user is visiting the page he will be prompted for username and password, but even if he enters the corect credentials, the request will still fail with HTTP Error 401: Not Authorized.

A Failed Request Tracing log will show the following error:

ModuleName IIS Web Core
Notification 2
HttpStatus 401
HttpReason Unauthorized
HttpSubStatus 2
ErrorCode 2147942405
ConfigExceptionInfo 
Notification AUTHENTICATE_REQUEST
ErrorCode Access is denied. (0x80070005)

To make this work in IIS 7.5 you have two choices:

1. Disable Kernel-mode authentication for this application, or
2. Configure IIS to use the application pool account when the the ticket is decrypted in Kernel mode

You can easily disable Kernel-mode autentication in the GUI. Select the application in the IIS Manger, open the authentication feature, select Windows authentication, select Advanced Settings in the right panel, and uncheck Kernel-mode authentication:

While this configuration will fix the issue, it may not be the best option. A better approach would be to keep Kernel-mode autentication but tell IIS to use the password of the application pool account to decrypt the ticket.

I wish that there were a GUI for changing that parameter but it does not exist.

Instead you have to tweak the applicationHost.config file that usually is located in c:\windows\system32\inetsrv\config, and you need to add the attribute: useAppPoolCredentials="true" to the windowsAuthentication node of the configuration for the application.

See sample:

 You can also use the Appcmd.exe command tool to set this parameter instead of tweaking the xml by hand. I have used the following command line a couple of time where the customer wanted this parameter to be default for all applications on the server::

%windir%\system32\inetsrv\appcmd.exe set config -section:windowsAuthentication /useAppPoolCredentials:"True" /commit:apphost

It should also be possible to do the a change for a single application, but I don't have a working sample to show you.

For that reason, delegation is not enabled by default in Active Directory. You - or more likely the domain administrator - must explicit make the decision that this particular application is trusted for delegation. This is also a partial answer to the quiz in the previous post: no, the list of task was not sufficient to satisfy the business requirements because the list did not include any task related to Kerberos delegation.

The Kerberos Delegation is configured as a property for the domain account that is used by the application as a service account. For an IIS application that is the application pool account configured for that particular application. That is the also the same domain account that you used when you configured the SPN.

Kerberos Delegation comes in different flavors. The first implementation of Kerberos delegation that was introduced in Windows 2000 was an all or nothing implementation: you allowed that the domain account could use your credentials to connect to any server in the world. (Or more exactly at least any server that were reachable in the current Domain, the current Forrest or any domain in any forest with a forest trust).

When you are configuring Active Directory in Windows Server 2003, the default Domain Functional Level is Windows 2000 mixed mode. In that mode, the configuration of delegation is different for a computer account (Local System) compared to a user account.

To configure the delegation for a Local System account, put a check mark in "Trust computer for delegation" on the General tab page.

For user account, you must put a checkmark on the "Account is trusted for delegation" option on the Account tab for the account.

If you have raised the Domain Functional level to Windows Server 2003, the Delegation property is moved for both computer accounts and user accounts to a dedicated tab page "Delegation" and you are also giving more options to control the scope of the delegation. I will come back to constrained delegation in a future post.

The delegation tab is only visible on the user account when you have created a SPN for that account.

As mentioned, the delegation was only a partial answer to the question from the last post. In addition to that, you must also configure Kernel mode authentication in IIS 7.x. That is a topic for my next post.

After reading the article in MSDN I didn't feel better. What is a ServicePrincipalName?

The way I usually think now (and I apologize for you that don't know the DNS lingo) is that it is conceptually the same as a CNAME record.

A SPN is nothing more fancy than an alias (or pointer) for a domain account, e.g.

HTTP/HRWeb is an alias for the domain account  MyDomain\HRWebAct

You can have more than one SPN pointing to the same domain account:

HTTP/HRWeb2 is also an alias for the domain account MyDomain\HRWebAct

In fact, the SPN: "HTTP/HRWeb" is an entry in the attribute servicePrincipalName for the account HRWebAct in the Windows Active Directory Domain MyDomain.com §

The next obviously question would be: why do you need an alias?

The answer to that is a bit longer, and this is the beginning of the journey into the mystery of Kerberos.

Let me start with a little quiz that illustrates the complexity of Kerberos and the reason why people shy away from using Kerberos. The quiz is based on a real customer experience but sanitized to protect the customer identity.

 (The following could also be a question in a certification test in Windows and Kerberos).

• You have a Windows Server 2008 R2 server called MyWebServer that is member of the Active Directory domain MyDomain.com
• The Active Directory is configured on Windows Server 2003 server using the default options during installation.
• On the web server you have several web sites including an HR Application: HRWeb
• You prefer that your users is navigating to the application using a simple url like https://HRWeb 
• The HRWeb application need to connect to a SQL Server 2008 R2 database using "Integrated Security=SSPI" in the connection string
• Only authorized people may use the HRWeb application
• You want to manage permission on the database

Then (as usual for this kind of certification test) a list of what you are doing to solve this requirement:

• Create a DNS Alias for HRWeb that refer to MyWebServer.MyDomain.com
• Configure binding for the site with hostname HRWeb and port 80
• Create an application pool with the identity of a domain account MyDomain\HRWebAct
• Configure the web site to use impersonation
• Create a SPN using the command line to setspn.exe with the following parameters: HTTP/HRWeb MyDomain\HRWebAct
• Grant users the appopriate permissions on the SQL Server to access the HRWeb database

Will this list of action satisfy the requirement? [Yes / No ] 

I will supply the answer and explanations to the question in my next post. Feel free to comment with your answer and explanation.

§ I am very well aware that you can use Kerberos in other environment that Windows. I may come back to that topic another day.

Finally got around to setting up my blog.

For those who don't know me - I'm Per Nygaard, an Architect in Microsoft Services, Denmark. I joined Microsoft in 1999 as consultant, and I have assisted many customer with both platform related areas (e.g. Windows, IIS and Active Directory) as well as developer related areas (e.g. .NET, WCF and SQL Server).

During my time as consultant I have helped IT Professionals to configure and understand Kerberos and other authentication/authorization related stuff on Windows and IIS.

Some of these people have had a really hard  time searching for meaningfull documentation on how to configure and troubleshoot Windows authentication, and the idea to start a blog with this content have emerged.

Now I'm here ....

/Per