Ken Schaefer : Security

Microsoft DPM 2007 Install Error 811

Ken — Wed, 09 Sep 2009 17:00:00 GMT

Typically this error is database related however you can also get this error if the Secondary Logon service is not started. Your corporate security policy may disable this service. Temporarily enabling it will allow DPM install to proceed. It does not appear to be required to be running once installation has completed.

Denial of Service attach detailed against IIS 5 / IIS 6 FTP Service

Ken — Mon, 07 Sep 2009 15:39:00 GMT

Kingcope has published an exploit to the Bugtraq mailing list for IIS FTP service running on IIS5, IIS6 and IIS7 (when running FTP v6). Note that IIS 7 running FTP v7 and IIS 7.5 are not affected.

Microsoft has an official advisory, and some more details are available on the Secunia blog. My fellow MVPs are not reporting 100% results against every version of IIS FTP, but everyone is advised to follow work arounds on the Microsoft website, and keep an eye out for developments.

IIS and Kerberos Part 9 - Cross Forest Delegation scenario with UPN suffix routing

Ken — Thu, 26 Feb 2009 11:44:00 GMT

As an extension of the previous article on Cross Forest (or Cross Domain) Kerberos Authentication this article examines how to configure cross forest authentication and delegation when users are accessing an arbitrary website URL.

In this scenario we have the same two Forests as in Part 8. Forest A (domainA.local) contains our resource servers (web server and SQL server). Forest B (domainB.local) contains our users and client PC.

Users are going to access a web site at www.myCompany.com, a domain that has no direct relationship between either the resource domain or user domain. Companies might need to implement this type of setup when they wish to have a single URL that users on either the internal network or externally can access. Alternatively I have seen scenarios where companies what to have a portal address (e.g. intranet.company.com) that then reverse proxies a number of internal web applications, and Kerberos authentication and transparent delegation to the proxied web applications makes for a simplified user experience.

A diagram of the process involved:

Wireshark/Ethereal packet captures of the actual traffic are available for download (rename to .pcap). I’ll explain the packets to look for a bit further down in the blog post.

The configuration steps required for this setup are:

Determine some mechanism so that the users can resolve www.myCompany.com (DNS is a given, but if you are using a split-brain DNS then your internal DNS will need to have an appropriate zone as well as your public DNS)
Create an additional UPN (user principal name) suffix in your resource Forest (domainA.local). To do this:
- Open the Active Directory Domains and Trusts Administrative Tool
- Right-click on the top level "Domains and Trusts" node
- On the UPN suffixes tab add www.myCompany.com and click Add. Note: you can add myCompany.com and this will add all hosts under myCompany.com. Adding www.myCompany.com will also work (but will also permit hosts under www.myCompany.com such as www.www.myCompany.com)
Configure Name Suffix Routing across the Forest Trust. To do this:

Open the Active Directory Domains and Trusts Administrative Tool in DomainB.local (the user domain)
Right-click on your domain (domainB.local) and choose Properties
On the Trusts tab select DomainA.local under either options (Domains trusted by this domain or Domains that trust this domain) – it doesn’t matter which one. Click the Properties button
On the Name Suffix Routing tab select *.www.myCompany.com and click Enable
Click OK to exit all the dialogues

Steps 4 & 5 are generic Kerberos configuration steps that aren’t specific to cross-Forest scenarios: Add the requisite SPN (Service Principal Name). To learn about SPNs review Part 2 in this series. In this case we need to add an SPN for http/www.myCompany.com in domainA.local. If the web application pool is running under Network Service, Local Service or LocalSystem the SPN should be added under the computer account of the web server. If the web application pool is running under a custom user account, the SPN should be added under that user account in domainA.local. NOTE: if you are running IIS 7.0 and using kernel mode authentication (the default) then you should add the SPN under the machine account. See Part 6 on new features in IIS 7.0

After adding the SPN, you should see the following in Active Directory:
Add the website www.myCompany.com to the Intranet Security Zone of the user’s computer. Recall from Part 3 that IE will not attempt Kerberos authentication unless the website is in the Intranet Security Zone. This can be done manually, via the IEAK, or using Group Policy.

After this is all configured and replicated around the environment then the following should be observable in the packet capture. Note that this exchange is similar to that seen in the previous packet capture (some stuff is actually missing from this packet capture as the machines already have name resolution and some referals already established. It is worth reviewing Part 8 packet capture with more detailed descriptions if you are seeing this for the first time). The only real difference is that we can see the routing required for http/www.myCompany.com service ticket:

Packet 6 – HTTP request by client
Packet 9 – Initial 401 response from web server
Packet 18 – DomainA.local DC returns service ticket for http/www.myCompany.com to client
Packet 21 – new HTTP request by client including Kerberos ticket
Packets 47-50 – tickets granted to access backend SQL Server
Packet 59 – HTTP 200 response to client with data from backend SQL Server

For reference the machines in question are:

Machine	Domain	IP address	Role
svr03-r2-dc-1	DomainA	192.168.132.10	DC
svr03-r2-dc-2	DomainB	192.168.132.11	DC
svr03-r2-web-1	DomainA	192.168.132.20	Web Server
svr03-r2-sql-1	DomainA	192.168.132.21	SQL Server
cltxp-pro-1	DomainB	192.168.132.50	Client

IIS and Kerberos Part 8 - a simple cross Forest/Domain delegation scenario

Ken — Sun, 29 Jun 2008 10:45:00 GMT

In this part we extend, slightly, upon the previous scenario, by adding delegation. Now we need to allow IIS, in our resource Forest (or domain) to delegate the end user’s credentials, to a backend service (SQL Server in this case):

The machines this case are:

Machine	Domain	IP address	Role
svr03-r2-dc-1	DomainA	192.168.132.10	DC
svr03-r2-dc-2	DomainB	192.168.132.11	DC
svr03-r2-web-1	DomainA	192.168.132.20	Web Server
svr03-r2-sql-1	DomainA	192.168.132.21	SQL Server
cltxp-pro-1	DomainB	192.168.132.50	Client

A packet capture is available for download (taken from the IIS server).

Opening the capture in Wireshark you should see the following (the bullet point numbers correspond to the numbers in the image below):

XP client makes a request to IIS server (Packet 14) and IIS server responds with 401 Access Denied (Packet 17)
XP client contacts DomainB Domain Controller for Kerberos ticket (Packet 19 – note the request for http/svr03-r2-web-1)
DomainB DC returns a referral to DomainA DC (packet 20)
XP client looks up the necessary service records for DomainA (packets 21-24) before requesting a service ticket from the DomainA DC (packet 33)
The DomainA DC returns a service ticket to the XP client (packet 34)
XP client makes a new request to IIS, supplying it’s Kerberos authentication data (packet 37)
IIS contacts its local DomainA DC seeking a referral to DomainB (packets 52-55)
DomainA DC refers IIS to DomainB DC
IIS requests a Kerberos ticket, on behalf of the end user, from DomainB DC (packet 61)
DomainB DC returns the necessary ticket (packet 62)
IIS now connects to SQL Server (packet 65), and gets the results of the query. The resulting webpage is returned to the client (packet 87)

The requirements to configure this scenario aren’t significantly beyond that to configure a basic cross-Forest/cross-Domain scenario featured in the previous part:

A two-way trust is required. This can use Selective Authentication. However Forest-Wide authentication may be administratively simpler to configure
An appropriate SPN needs to be registered for the backend SQL Server (similar to a single domain delegation scenario)

In the next part I will discuss publishing an arbitrary FQDN for the IIS host (e.g. a public facing internet site) and UPN suffix routing.

NOTE (Feb 2009): I finally got around to publishing promised part - see Part 9

Note: A listing of parts is available in the FAQ

IIS and Kerberos Part 7 - A simple cross Forest scenario

Ken — Tue, 13 May 2008 12:13:00 GMT

Note: I have created a list of all the IIS and Kerberos parts

I'm finally getting around to writing this section on IIS and Kerberos. This initial post will cover the basics of a cross-Forest Kerberos authentication scenario. In the next few posts we'll cover more complex situations including delegation and ISA Server publishing.

The basics of cross-domain Kerberos authentication (in the same Forest) are the same as a cross-Forest scenario, so I've covered the cross-Forest scenario in these posts, and steps that are unnecessary for a cross-domain scenario can be omitted.

Our setup involves a resource Forest (domainA.local) and a user Forest (domainB.local). A network packet capture is included (it can be opened using Wireshark/Ethereal - rename the extension back to .cap), and to help decipher the capture the machines involved are:

Machine	Domain	IP address	Role
svr03-r2-dc-1	DomainA	192.168.132.10	DC
svr03-r2-dc-2	DomainB	192.168.132.11	DC
svr03-r2-web-1	DomainA	192.168.132.12	Web Server
cltxp-pro-1	DomainB	192.168.132.50	Client

In the scenario the client in DomainB.local attempts to connect to svr03-r2-web-1 in DomainA.local. The sequence of packets are:

Client connects to web server and gets 401 (Packets 4 and 6)
Client connects to DC in local Domain asking to a ticket to http/svr03-r2-web-1.domainA.local (Packet 8)
The DC in DomainB.local provides a referral to DomainA.local (Packet 9)
The client connects to a DC in DomainA.local asking for a ticket (Packet 12)
The DC in DomainA.local provides a Kerberos ticket to the client (Packet 13)
The client again connects to the web server, presenting its Kerberos ticket (Packet 15)
The server responds with a 200 OK (Packet 21)

And the user successfully authenticates using Kerberos:

Things to be aware of in this simple scenario:

Typically a client will be connecting using the FQDN (fully qualified domain name) of the web server. Since Kerberos is only attempted if the website is in Internet Explorer's Intranet security zone, the website will need to be added to that security zone either using a GPO or manually
Clients must be able to contact domain controllers in the resource Forest in order to get appropriate Kerberos tickets. If there are some DCs in the resource domain that are unreachable (e.g. due to firewalls ec) then you need to ensure that clients in the user Forest only get referrals to reachable DCs
EDIT: Forest trusts can only be created when using a Windows 2003 functional level Forest. The Forest functional level can be raised using the Active Directory Domains and Trusts Admin MMC tool. Before you can raise the Forest functional level, you need to raise the Domain functional level of all Domains within the Forest to Windows Server 2003. If your Forest functional level is Windows 2000, only an external trust can be created, which does not permit Kerberos authentication.
EDIT: Only a one-way trust (the resource Forest trusts the User forest) is required for this scenario. In future scenarios (e.g. when we introduce delegation) a two-way trust will be required. However we can limit the access the Resource forest has to the User forest using Selective Authentication
EDIT: If you need guidance on creating a Forest Trust, then Microsoft's TechNet has a good guide

IIS - two security patches this month

Ken — Wed, 13 Feb 2008 11:23:00 GMT

Hi all,

There are two security patches out this month for IIS.

The first (MS08-005) affects Windows XP x86 (IIS 5.1), Windows XP x64 (IIS 6.0), Windows Server 2003 (IIS 6.0) and Vista RTM (IIS 7.0). Vista SP1 and Windows Server 2008 are not affected. This is a local escalation of privilege vulnerability, and requires that the attacker be able to access a server locally, or be able to somehow execute code locally (e.g. by placing a file that contains the necessary code on the server, and then have the server run that code from a remote location)

The second (MS08-006) affects Windows XP (x86/x64) and Windows Server 2003, and is a remote code exploitation. It does require that the ASP web service extension be enabled on Windows Server 2003.

Whilst it's always disappointing to see new bugs in IIS, I think the overall record of IIS 6.0 has been very good. Since it's release in early 2003, we've seen only a handful of bugs that are directly IIS' fault (e.g. the previous ASP issue), and handful of bugs that can be exploited via IIS (e.g. the previous WebDAV issue). Overall, there are less than 5 bugs exploitable via IIS 6.0 - which is a great record especially when compared with IIS 5.0 and with its major competitors.

Publishing Operations Manager 2007 Web Console with ISA Server 2006

Ken — Fri, 03 Aug 2007 06:36:00 GMT

Having just deployed a test Operations Manager 2007 server at home, I wanted to publish the Web Console site externally, so I wouldn't have to continually TS into my box at home, and use the regular console.

My only problem is that I have a single public IP address, and because I'm only publishing services over HTTPS, I only have a single FQDN that I can use (I'm not willing to pay for a wildcard certificate). So each service that I'm publishing needs to exist as a folder(s) off the root of my published FQDN (assuming I don't want to use non-standard ports and avoid certificate errors). My current publishing setup looks like this:

Unfortunately the Operations Manager 2007 Web Console website isn't located in a directory, but rather in the root of its own website. Due to what appears to be some fancy javascript employed within the site, straight reverse publishing with link translation results in a non-usable site.

Whilst it is possible to configure individual link translation elements for publishing this website, I found an easier way to get this working.

Open IIS Manager on the Operations Manager server. Locate the current Operations Manager Web Console website and choose to create a new Virtual Directory. Create the alias as whatever directory you wish to use externally (I'm using OpsMgr) and point the source folder to be the same as the root folder for the current website (the default is C:\Program Files\System Center Operations Manager 2007\Web Console). Ensure that the virtual directory is marked as an Application Root (a small cog icon in IIS Manager):

Now you can configure a standard Web Site publishing rule in ISA Server 2006 to publish requests to https://yourexternalFQDN/OpsMgr to http://yourInternalOpsMgr:51908/OpsMgr and your Operations Manager web console is available for use. Because I'm also publishing OWA, my web listener uses ISA Server 2006 FBA. For the Operations Manager publishing rule, configure NTLM delegation, and your users will only need to logon once (to ISA Server) to get access to the console:

IIS and Kerberos Part 5 - Protocol Transition, Constrained Delegation, S4U2S and S4U2P

Ken — Thu, 19 Jul 2007 12:24:00 GMT

Protocol Transition is a new feature in Windows Server 2003. The Kerberos implementation in Windows Active Directory domains provides the robustness of Kerberos whilst also obviating a number of the technical issues with non-Windows Kerberos implementations (platform infrastructure, ticket renewal, ticket proxy). However Kerberos has a downside – the need to get tickets from a KDC. In the IIS world, contacting a KDC simply isn’t a possible for many internet facing scenarios. Either the KDC is not exposed to internet facing clients (blocked by a firewall), or (more commonly) a KDC is simply not locatable because the necessary SRV (service records) are only located on internal DNS servers not available to the public:

In the diagram above '1' shows a typical problem with a non-Domain (i.e. public) client attempting to locate a KDC for a domain that a web server is in. Typically public DNS servers do not contain the necessary service records that tell a client where the KDC can be located.

Even if the client is able to locate a KDC, the '2' indicates the next hurdle - clients on the internet can not connect to the KDC to get the necessary tickets to use Kerberos Authentication to authenticate to the web server because a firewall or similar edge device blocks internet clients from directly contacting domain controllers.

Aside from an internet connection client establishing a VPN to your internal network, there are any number of technologies that allow such clients to authenticate to a web server, from Digest Authentication through to Client Authentication Certificates. However after a client has authenticated to a web server using such a technology, it can then become difficult to pass those credentials through to a backend server (Basic Authentication is an exception because it provides the web server with the user's username and password, allowing direct impersonation via LogonUser however a compromised web server in this case would allow a malicious attacker to harvest a rich database of users and their passwords).

Windows Server 2003 introduces two new technologies and two new services (not Windows Services in the sense of daemons, but services that can be leveraged) that address some of the authentication issues mentioned.

Windows Server 2003 introduces:

· Protocol Transition – this allows a non-Kerberos Authentication mechanism to be used to authenticate to IIS, whilst IIS can use Kerberos to connect to a backend server.

· Constrained Delegation – this allows Administrators to constrain what backend services IIS can connect to.

To facilitate these two pieces of functionality, Windows Server 2003 introduces two services that can be leveraged by your applications and by IIS:

· Services For User to Self (S4U2S)

· Services for User to Proxy (S4U2P)

Firstly let's address the necessary steps to configure Protocol Transition and Constrained Delegation in an IIS situation, and then we'll look through the actual implementation details that show how this all hangs together.

If you missed the previous parts in the series or need a refresher then you can find them at:

IIS and Kerberos Part 1 - What is Kerberos and how does it work?

IIS and Kerberos Part 2 - What are Service Principal Names?

IIS and Kerberos Part 3 - A simple scenario

IIS and Kerberos Part 4 - A simple delegation scenario

Configuring Active Directory

To support Protocol Transition you need to be running Windows Server 2003 for your IIS server and you need to have a Windows Server 2003 functional level domain (this requires all DCs in your domain to be running Windows Server 2003. To raise the Domain Functional level, use Active Directory Domains and Trusts MMC Snapin).

To configure Active Directory using the GUI (how to configure this all programmatically is explained later) open Active Directory Users and Computers MMC Snapin.

Assuming that you are not using a custom user account for your web application pool, locate your IIS server’s computer object and bring up that machine’s properties. On the delegation tab choose both:

· Trust this computer for delegation to specified services only and

· Use any authentication protocol

You will now need to specify the backend services that the IIS machine is permitted to delegate to. Click the "add" button and then the "users and computers" button. Enter the computer or user account that the backend service is running under (for example, if you are running SQL Server under a LocalSystem account on a remote server, enter the SQL Server's computer account. If you are running SQL Server under a custom user account, enter that user's account). A list of Service Principal Names (SPNs) registered under that account is displayed. Select the SPN that you wish IIS to be able to connect to. If you are not familiar with SPNs, or need to configure an additional SPN, then see Part 1 (Kerberos fundamentals) and Part 2 (Service Principal Names) in this series.

If you are running your web application pool under a custom user account, then perform the above steps for the user account, not the IIS server’s computer account.

Configuring IIS

There isn’t much to configure on the IIS box beyond what needs to be configured for straight Kerberos Delegation (see Part 3 in the series). The main difference is that the user account running the web application pool for your website needs to have SeTCBPrivilege (Act as Part of the Operating System) and SeImpersonateUser (Impersonate a User After Authentication). Your options involve either running your web application pool as LocalSystem, or granting a custom account these NT User Rights. These use rights can be assigned by editing the local security policy (start -> Run -> secpol.msc). Alternatively Group Policy can also be used.

Note: running a web application pool with any account that has SeTCBPrivilege is a security risk. Any potential compromise of your web application will result in the attacker having full privileges over your IIS server.

And that's the entire configuration that's required to support Protocol Transition natively on IIS to a backend server. Now you can authenticate to IIS using alternate authentication mechanisms, and still delegate to a backend service similar to how we configured IIS and SQL Server in Part 4 – A simple delegation scenario.

For more information on how this is actually implemented in Windows Server 2003, read on.

Services For User to Self

Services For User to Self (S4U2S) provides the ability for a service running on a server to get a Kerberos ticket for an end client, even if the end client did not authenticate using Kerberos. Instead of the service providing the end user’s TGT (Ticket Granting Ticket) or end user’s credentials (username/password) to the KDC, the service provides its own credentials.

The resulting token that is returned depends on what NT User Rights the service account has. If the service has SeTCBPrivilege (Act as Part of the Operating System) then the token returned is an Impersonation token. If the service does not have this privilege, the token is an Identification token. (TCB in SeTCBPrivilege stands for Trusted Computing Base a.k.a. the trusted kernel of the operating system). An Identification token can be used to determine a user’s group membership and validate the user’s access to resources. An Impersonation token further allows access to kernel mode objects using the end user’s identity.

In order to actually use an Impersonation token to impersonate an end user, the service must also have the SeImpersonatePrivilege (Impersonate a Client After Authentication). Attempting to impersonate an end user without this user right results in the Impersonation token being downgraded to an Identification token.

If the service has both SeTCBPrivilege and SeImpersonatePrivilege then the service can use the token to directly impersonate the end user (on the local system) without having the end user’s TGT or credentials. A service can do this by either directly calling LsaLogonUser (or the constructor for the .NET WindowsIdentity class that wraps LsaLogonUser), or by relying on the Kerberos SSP provided by Windows Server 2003.

Services for User to Self (S4U2S) help provide for Protocol Transition – the ability to perform Kerberos Authentication even though the end user has authenticated to our IIS server using some other protocol.

Services for User to Proxy

Services for User To Proxy (S4UTP) provides the ability for a service to obtain a Kerberos ticket on behalf of an end user that can be used to authenticate to a remote service. Whilst S4U2S discussed above allows a service to obtain a Kerberos Ticket, the Forwardable flag is not set, which does not permit the service to authenticate to remote services (e.g. a backend database) on behalf of the end user.

In order for the Kerberos ticket to be forwardable (i.e. used by the service to connect to a backend service such as a database), delegation must be enabled in Active Directory.

The actual series of events looks like the following:

In order for the service to be able to get forwardable tickets on an end user's behalf, a flag needs to be set on the service account’s userAccountControl property in Active Directory: TrustedToAuthenticateForDelegation (T2A4D). This flag has the value 0x1000000 (or 16777216 in decimal).

Note: if the end user had authenticated initially using Kerberos, then this particular flag doesn’t need to be set. We use it only when we are using Protocol Transition and we need to get forwardable tickets.

The T2A4D is new in Windows Server 2003 Active Directory domains. In a Windows 2000 functional level domain, a different flag: TrustedForDelegation (with a value of 0x80000 or 524288 in decimal) is set. This corresponds to the "Trust this computer for delegation to any service (Kerberos Only)" option in a Windows Server 2003 domain (see below). This was the only way to configure delegation in a Windows Server 2000 domain, and is known as "unconstrained delegation".

To set the T2A4D flag we choose the “Trust this computer for delegation to specific services only -> Use Any Authentication Protocol”. This means that a client can use any Authentication protocol to authenticate to our service, but then we’ll be using Protocol Transition and S4U2P to get Kerberos tickets to authenticate to these backend services.

The other Active Directory property we need to be aware of is the msAllowedToDelegateTo property. When we add a list of remote services that the service account is permitted to delegate to we populate the msAllowedToDelegateTo property of the service account. The msAllowedToDelegateTo property is populated whenever we use Constrained Delegation. If we choose the "Keberos Only" option, then only this property is populated. If we choose the "Use Any Authentication Protocol" then both the T2A4D userAccountControl flag is set and the msAllowedToDelegateTo field is set.

userAccountControl - TrustedToDelegate	When set, unconstrained delegation is permitted for the service. The service can connect to any backend service as the end user. However protocol transition is not supported – the end user must have authenticated using Kerberos.
userAccountControl - TrustedToAuthenticateForDelegation	When set, the service may use protocol transition to connect to backend services listed in msDS-allowedToDelegateTo. This flag is set when you configure “Use any authentication protocol”)
msDS-AllowedToDelegateTo	When using constrained delegation (either “Kerberos Only”, or “Use Any Authentication Protocol”) this property lists the backend services that the service can connect to.
SeTCBPrivilege	The service must have this privilege to get Impersonation tokens
SeImpersonateUser	The service must have this privilege to be able to use the Impersonation token to impersonate a user.

Now, some gotchas that you need to be aware of. As mentioned earlier but worth repeating;

Protocol Transition relies on using constrained delegation. You can’t use Protocol Transition in conjunction with unconstrained delegation.
Once you have used constrained delegation to hop to a server, all subsequent hops must also use constrained delegation. In the following example, connecting from IIS to SQL Server used Constrained Delegation. In order for SQL Server to connect to additional backend servers the msDS-AllowedToDelegateTo property in Active Directory must be explicitly configured to allow SQL Server to do so.
When using constrained delegation all servers in the delegation chain must be in the same domain. It is not sufficient that a domain or forest trust exists between the servers.

And that concludes this rather long Part 5. If you’re still reading this: thankyou. Please feel free to leave a comment if you feel that something was unclear or incomplete. If you feel something was incorrect, then please email me so I can avoid public embarrassment :-)

In Part 6 we’ll look at using Kerberos authentication across more than a single Active Directory forest. Subsequent parts will look at configuring additional services (such as ISA Server and Sharepoint). If there are specific scenarios you’d like me to cover, please drop me a line.

Edit: Due to blog spam - comments are disabled. Contact me through the contact form

Can you install more than one certificate per web site? (IIS 5 / 6)

Ken — Sat, 12 May 2007 11:00:00 GMT

I was asked recently by a colleague if a website defined in IIS could have multiple SSL certificates installed, so that the website would answer requests for https://www.abc.com as well as https://www.def.com without generating an error in the user's browser that the website's name didn't match the one in the certificate.

The simple answer to the question in the subject line, is that you can't install more than one certificate in IIS 5 and IIS 6. That doesn't mean that you can't solve the problem (read on for some solutions that might work for you).

IIS associates a certificate to be used with a website based on a property in the IIS Metabase called SSLCertHash. For each website there is space for a single SSLCertHash value to be set (see Figure 1)

Figure 1

The actual value that's stored in this SSLCertHash field corresponds to the server authentication certificate's "thumbprint" property that you can view using the MMC (after adding the Certificates snapin). See Figure 2 below:

Figure 2

So, how do we solve the problem of having two FQDNs serve the same web content over SSL/TLS without causing a warning error message in the client's browser? Well, here are some options:

Create two websites, and point the home directory of each website to the same physical root folder on your server. Install one certificate into each website. This does require that you have two IP addresses (or run the websites on different ports)
Use a certificate that has mulitple common names (see Figure 3 below)
Use a wildcard certificate (that matches *.domain.tld)

Figure 3

Certificate Services (2000, 2003) Web Enrollment does not work on Vista

Ken — Wed, 02 May 2007 13:45:00 GMT

Unfortunately if you have a new Vista PC, and you try to use the web enrollment pages (certsrv) hosted on a Windows Server 2000 Certificate Authority (CA) or a Windows Server 2003 CA, you won't be able to enrol for a certificate (indeed if you're using Windows Server 2003 SP2 you get a message to that effect).

If you are in a domain environment, then you may be able to get around some certificate issuance via user or machine auto-enrollment. Otherwise you need to perform manual certificate issuance. Alternatively you can setup a Longhorn Server Beta 3 CA, and use the webpages from that installation to allow web enrollment for Vista machines.

Hardly an ideal situation if you ask me!

More information can be found on Microsoft's website.

IIS and Kerberos. Part 4 - A simple delegation scenario

Ken — Sun, 28 Jan 2007 05:31:00 GMT

Delegation is a feature of Kerberos authentication that allows a server to obtain a Kerberos ticket on behalf of an end user without ever having access to the end user's password. This functionality allows Kerberos to solve typical "double-hop" authentication problems where a user's credentials need to flow through multiple levels in an n-tier architecture. Other authentication technologies (Digest and NTLM) do not allow this natively (we'll cover something called "Protocol Transition" later on down the track).

In this simple scenario, we'll add a backend SQL Server to our original simple scenario. Our user will authenticate, using Kerberos, to our web application, and then the web application will open a connection to SQL Server using the end-user's credentials (a "trusted connection").

The delegation functionality featured here can be used through multiple levels (for example if you have a web server, connecting to an application server, connecting to an SQL Server). The delegation done by the web server is repeated at each additional layer in the chain.

In the diagram above the following sequence of events takes place:

The client browser supplies a Kerberos service ticket to the web server. The process that happens in obtaining a service ticket is covered in the previous post.
The web server, seeing the need to open a connection to SQL Server using the end user's credentials obtains the necessary ticket from the KDC
The KDC returns a ticket if the web server is permitted to delegate
The server opens the connection, sending the ticket obtained from the KDC
The SQL Server permits the connection to be opened, or returns a error indicating that the user is not permitted login to SQL Server
The web server returns the web page to the end user

To get this working, we need some additional configuration in addition to what we performed previously. In Active Directory we need to give permission to the web server so as to allow it to get tickets on the end user's behalf. If you locate the web server's computer in Active Directory Users and Computers MMC, right-click and choose "Properties", there is a "Delegation" tab where you can configure the necessary options. The Delegation tab looks different depending on whether you have a Windows 2000 functional level domain, or a Windows 2003 functional level domain.

In a Windows 2000 functional level domain, there is a single checkbox to allow delegation for this server. In a Windows 2003 functional level domain, the dialogue looks like the one below:

The first option (unconstrained delegation) corresponds to the single setting in a Windows 2000 functional level domain. Enabling this setting sets certain bit values the AD UAC attribute for the server's computer account (typically it changes from 0x80 to 0x2080). Alternatively, you can configure "constrained" delegation. Constrained delegation permits the server to get a ticket only for the nominated services. It prevents the server from getting a ticket on behalf of the user to any service in your environment. This can be helpful in the event your server is ever compromised. Using this setting sets the msDS-AllowedToDelegateTo AD attribute for the computer account in question.

Constrained delegation makes available another option (Protocol Transition) - this is the option that is labelled "use any protocol". We'll deal with Protocol Transition, and its implications in another post in the series.

For our scenario, we'll configure constrained delegation to our backend SQL Server. Click the "Add" button, and browse for the relevant computer or user account (I am running SQL Server under LocalSystem, so I would browse for the machine account of the SQL Server). You'll be presented with a list of SPNs for that machine - add the SPN for the SQL Server service. If you are not familiar with SPNs, read Part 2 in this series.

There are a couple of "gotchas" with constrained delegation that you need to be aware of. Firstly, constrained delegation only works if the services are in the same domain. The end user (and their computer's machine account) can be in any domain (or indeed, even in another trusted Forest). However the web server and SQL server, and any other backend servers need to be in the same domain. Secondly, if one hop in the delegation chain uses constrained delegation, then all other subsequent hops in the chain must also use constrained delegation.

IIS and Kerberos. Part 3 - A simple scenario

Ken — Tue, 16 Jan 2007 20:32:00 GMT

In Part 3 of this series we look at setting up Kerberos Authentication in the simplest possible scenario. If you missed Parts 1 (What is Kerberos and how does it work) and 2 (Service Principal Names) they may be worth reading first. In this scenario, we have a client, a DC and a single IIS server. As we progress through the series, we will progressively add more elements into the mix.

In this very simplistic example a client wishes to authenticate to a website hosted on the webserver. The sequence of events is illustrated in the diagram:

1) The client makes a HTTP Request
2) The server denies the request with a 401 Authorization Required. It includes the WWW-Authenticate: Negotiate header and/or the WWW-Authenticate: Kerberos header indicating that it supports Kerberos authentication
3) The client requests a Service Ticket from the KDC hosted on the Domain Controller
4) The Domain Controller returns the Service Ticket
5) The Client generates the Authenticator, and sends this plus the Service Ticket in a new HTTP request to the web server
6) The webserver determines the identity of the client, checks the ACL on the resource and either permits or denies access to the resource.

In order for this sequence of events to work the following need to be configured.

The Browser
For Internet Explorer to use Kerberos to authenticate to IIS the following must be configured correctly:

Under Tools -> Internet Options -> Advanced the option "Enable Integrated Windows Authentication (Requires Restart)" must be checked. Whilst technically IWA encompasses both NTLm and Kerberos, IE will use NTLM only if this option is not checked whilst it can use both Kerberos or NTLM if this option is checked.
The website you are connecting to must be located in the "Intranet" Security zone. You can see what zone IE thinks the website is in by looking at the icon in the bottom right-hand side of IE's status bar. If the website is located in the "Internet" zone, IE will not even attempt Kerberos authentication. This is because, in most Internet scenarios, a connection with a domain controller can not be established. The simple rule is that any website that contains full stops (periods for Americans) such as an IP address or Fully Qualified Domain Name (FQDN) is in the Internet zone. If you are connecting to an IP address or FQDN then use IE's settings or Group Policy to add this site to the Intranet security zone. For more information on how IE determines what zone the website is in please see KB 258063

The Domain Controller
For the Domain Controller to generate the appropriate tickets to give to the client an appropriate Service Principal Name (SPN) must be registered in Active Directory. When a Windows Server 2003 machine is added to a domain, a HOST SPN for both the NetBIOS name and the FQDN of the server is automatically added to Active Directory. If your website is accessible at http://servername or http://servername.domain.tld (tld = Top Level Domain, such .com or .local) and the web application pool is running as Network Service, Local Service or Local System, you do not need to change any SPNs.

If the web application pool hosting the site is running under a custom account, the SPN HTTP/servername or HTTP/servername.domain.tld needs to be registered under that custom user account. If those HTTP SPNs exist under any other account, they need to be removed.

And lastly, if the website is accessible at an arbitrary hostname that is unrelated to the actual server’s name (e.g. www.domain.tld) then a SPN needs to be registered for that hostname. If the web application pool hosting the website is running as Network Service, Local Service or LocalSystem, then the SPN needs to be registered under the server’s computer account. If the web app pool is running under a custom user account, then the SPN needs to be registered under that user account in Active Directory.

SPNs can be added using a GUI-based tool such as ADSIEdit. Or can be added programmatically using an interface to AD (such as ADSI), or can be added using the SetSPN.exe command line tool (SetSPN is discussed in Part 2 of IIS and Kerberos listed earlier). To add an SPN using SetSPN for:

a servername under a custom user account:
setspn –A HTTP/servername Domain\Username
an arbitrary hostname under a computer account:
setspn –A HTTP/hostname.domain.tld Domain\MachineName
an arbitrary hostname under a custom user account:
setspn –A HTTP/hostname.domain.tld Domain\UserName

The IIS Server
There isn’t a lot to configure on the IIS Server. Firstly Integrated Windows Authentication (IWA) should be enabled for the website or application you are seeking to protect. By default this enabled both the Negotiate and NTLM Authentication Providers in the IIS metabase. If you have edited the metabase to remove the Negotiate provider, you will need to add it back in. The installation of some products (e.g. Sharepoint Portal Server 2001) removes the Negotiate provider – you may need to manually add it back in. See Microsoft KB Article 832769 for your options.

Secondly, all web applications hosted at the DNS name in question need to be running in one or more web application pools that are all running under the same user account. It’s easiest if all the web applications at that DNS name are running in a single web app pool. However if you do need to split web applications into multiple pools, those pools need to be running under the same user account.

Summary
And that should be all that is required for your Internet Explorer browser to authenticate to IIS using Kerberos. To verify whether this is occuring, you can use the tools described in my previous post on determining whether the browser is using NTLM or Kerberos to authenticate to IIS.

IIS and Kerberos. Part 2 - Service Principal Names

Ken — Sun, 19 Nov 2006 21:29:00 GMT

Apologies for the delay in posting Part 2 - I've been on holidays so it's been a bit hard finding the time to write these posts. In this part we cover Service Principal Names (SPNs).

In a previous post we covered the basics of Kerberos authentication. Everything is relatively straitforward, however I didn't cover the one particular aspect. Namely, how does the Authorisation Service (AS) and remote Service share their shared secret?

In an Active Directory domain, all computer and user objects have a password. This password is used as the basis of the shared secret between the AS and the remote service. If the remote service is running under an inbuilt principal such as LocalSystem or Network Service then the computer account's password is used as the basis of the shared secret. If the remote service is running under a custom user account, then the user account's password is used as the basis of the shared secret.

So how does the AS know which user or computer account's password should be used? When a user wishes to connect to a remote service, it tells the Domain Controller what Kerberos service it wishes to connect to. The AS searches through Active Directory to find a matching Service Principal Name (SPN). SPNs are attributes of user and computer objects in the directory. For example, for the computer w03-svr-sql we can see the following SPNs (using ADSIEdit):

SPNs can be viewed, added and removed using a GUI tool like ADSIEdit, or you can do the same using a command line tool such as SetSPN (part of the Windows 2000 Resource Kit).

Generally, when installing a product such as SQL Server or IIS that supports Kerberos, SPNs are registered for you for the accounts that those products are configured to use. However you later change the user account that the services are running under, you may need to set a new SPN for that Kerberos authentication continues working.

This method of determining the shared secret to be used between the AS and remote service raising a couple of gotchas which can break Kerberos Authentication:

1) The missing SPN
When installing IIS (and a lot of other common services) the installer will register a set of default SPNs in the Directory. However if you change the way that your service runs after installation, you may need to update the SPNs that are registered.

For example, after installing IIS, SPNs for servername and servername.domain.tld are registered under the server's computer account in Active Directory. These SPNs will allow Kerberos authentication to work when using the following built-in service principles: LocalSystem, Network Service or Local Service as the identity for your worker processes.

However if you change the process identity of your web application pool, and assign its worker process a custom domain user acccount as a process identity, then you will need to create SPNs for servername and servername.domain.tld under this custom user account. This allows the KDC to encrypt the service ticket with the password of the user account rather than the computer account.

2) The duplicate SPN
In the event that an SPN for the same service is registered under multiple accounts in Active Directory (e.g. under a computer account and a user account), then the KDC will not know which password should be used to encrypt the service ticket, and Kerberos Authentication will fail.

In the above scenario, once you change the identity of your web application pool, and add the new SPNs for servername and servername.domain.tld, you may need to remove the existing SPNs from under the computer account. Likewise, if you change the process identity from one user account, to another user account, you would most likely need to remove the SPNs from the first user account, and add them to the second user account.

3) Load-balanced IIS solutions
In this situation, the user's request might be routed to either of the two (or more) nodes in your cluster. In this case, you can not run your web application pools under an inbuilt principal (such as Network Service), because the KDC can not know which computer account's password should be used (it does not know which node in the cluster the request will be routed to). In this situation you must use a common domain user account as the process identity of your worker processes.

4) Multiple web applications hosted at a single domain name
Because SPNs are organised by name (either NetBIOS or fully qualified domain name), all web applications hosted at that domain name must be running in worker processes utilising the same, common, identity. This is so that the KDC can generate a service ticket using that identity, no matter what web application is being accessed at the FQDN. You can still run the web applications in separate web application pools, but each pool must be running under the same, common, identity.

IIS and Kerberos. Part 1 - What is Kerberos and how does it work?

Ken — Fri, 20 Oct 2006 12:01:00 GMT

Edit: I've created a list of all the parts in this series here, which will be updated as I add more parts.

Configuring Kerberos and Delegation is one of the more common problems I see in the communities and even within Avanade. Since Kerberos isn't a simple topic, I'm going to write a quick series explaining how Kerberos works, common scenarios and problems and some troubleshooting tips.

Kerberos is an open authentication protocol developed at MIT, and implemented in Windows 2000/2003 Active Directory domains (amongst other places). Authentication is the process of proving your identity to a remote system. Your identity is who you are, and authentication is the process of proving that. In many systems your identity is your username, and you use a secret shared between you and the remote system (a password) to prove that your identity.

The problem with simplistic shared secret systems is two-fold:
a) there is a scalability problem. If every user needs to maintain a shared secret with every individual server (or every service on every server!) then that results in poor passwords. Users can not be expected to remember dozens, hundreds or thousands of unique passwords and so end up repeating them regardless of whether the server is a low security or high security resource
b) there is an issue in securely transmitting the shared secret from the user to the server. Various technologies (like TLS/SSL) exist for securing the transport of data between machines, however it is incumbent upon each service to utilise services lower down in the network stack.

Kerberos is designed to overcome these limitations. In this part we look at how a simple Kerberos implementation works. In this scenario we have a user using a client machine that wishes to connect to a remote service (the user here is a person or application, the client is the OS or machine). Remember that we want a system that allows us to store shared secrets centrally, and to securely transmit user credentials between client and service. Lastly we should look to prevent replay attacks (where someone who is sniffing the wire can replay captured packets to impersonate a legitimate user, even if they do not know how to create the authentication packets themselves).

To begin with we introduce the Kerberos KDC - Key Distribution Centre. In the Windows Active Directory world, the KDC lives on Domain Controllers (DCs). The client connects to the Authorisation Service (AS) that runs on the KDC and asks the AS to authenticate the user to the remote service. Technically, the client doesn't need to authenticate itself to the Domain Controller. However in the Active Directory world, something called pre-authentication is used to ensure that the user (or client application) is actually who they say they are.

The AS on the KDC generates a session key that will be used by the client and the remote service. It encrypts the session key with the user's password (this is why the user doesn't need to authenticate - if the user isn't who they say they are, they won't be able to decrypt the session key because they don't know the user's password). The KDC also prepares a second piece of data - it again encrypts the session key as well as the user's username (known as a Kerberos principal), but using the service's password this time to encrypt the data. Only the remote service will be able to decrypt this second piece of data. This second piece of data is known as the Service Ticket (or just Ticket).

The KDC now sends both pieces of data back to the client. The user, knowing their own password, is able to decrypt the first piece of data, and extract the session key. The user however does not know the service's password, so is unable to decrypt the second piece of data. The client uses the session key to encrypt the current time (amongst other things, but they aren't so important right now). This piece of data is known as the Authenticator. The client sends the Authenticator it just generated, along with the Service Ticket received from the KDC to the remote service.

The remote service is able to decrypt the Service Ticket using its own password. It is thus able to get access to the session key, and the Principal (user) attempting to connect. It now uses the session key to decrypt the Authenticator, and extract the time. It compares the time to the current system time on the server to ensure a match. Since only the service, the KDC and the user, know the session key then the service can assume that user must be who they say they are.

If an imposter sent a Service Ticket to the service (e.g. by replaying captured packets) they wouldn't know the correct session key necessary to encrypt the timestamp correctly. Alternatively, if the imposter attempts to use captured Authenticator packets (which contain a timestamp), thus bypassing the need to know the session key, then the times will not match when the Authenticator is decrypted by the service and the service will refuse to authenticate the remote user.

If this was the extent of the Kerberos, then each and every time the client received an encrypted session key from the KDC, the user would need to enter their password to allow the client machine access to it. That could rapidly become a productivity sinkhole (imagine having to enter your password for each and every HTTP request you made!). To get around this, the client machine could cache the user's password, but that isn't a particulary secure system. What Kerberos does is introduce the concept of a Ticket Granting Ticket (TGT).

Ticket Granting Tickets are issued by the AS running on the KDC in the same way that a normal service ticket is issued. However the TGT is valid for the Ticket Granting Service, rather than a remote HTTP server (or any other type of server). Whenever the user wishes to connect to a remote service, it can use the TGT that it has already received to connect to the TGS. The TGS, after authenticating the user via the TGT, issues a Service Ticket to the remote service. However instead of encrypting anything using the user's password, it encrypts using the session key originally generated by the AS. Since the client machine aleady knows this from when the TGT was received in the first place, there is no need to bother the user for their password. The TGT typically has a short lifespan - around 8 hours or so.

Why Vista? Mandatory Integrity Control (MIC) (Security, Stability, System Integrity)

Ken — Fri, 18 Aug 2006 22:02:00 GMT

A little discussed feature in Windows Vista is Mandatory Integrity Control (MIC). Unlike DACL (Discretionary Access Control Lists), MIC is designed to protect your operating system based on the trustworthiness of the code being run. High integrity files (e.g. system operating files) are protected from accidental damage by users, and user data is protected from damage by untrusted code from outside the machine (e.g. downloaded from the internet)

There are five Integrity Levels in Windows Vista, ranging from 0 (anonymous tokens) through to 400 (LocalSystem)

By default, user mode processes have a IL of 200. An exception is Internet Explorer 7 running in Protected Mode. It has an IL of 100 only. This means that IE has limited opportunities to be able to alter files on the machine without triggering an elevation prompt that the user must agree to.

Objects created by processes inherit the IL of the process. So files downloaded by IE still have an IL of just 100, and without the permission of the user can not damage documents created by the user using programs running at Medium (200) level IL. To be able to write to a file you need equal to, or higher, IL. If the process doesn’t have a high enough IL, the user will be prompted to elevate their rights. Only the TCB (trusted computing base) can present this prompt to the user – the process itself can not elevate its own IL (though it can downgrade its IL). MIC does not prevent processes from reading files – you still need to use DACLs for that.

MIC even trumps DACLs, meaning that Administrators can not overwrite critical system files. MIC does not apply to the built in Administrator account though – which provides access for users to alter files.

To view the new Integrity levels in action, the following screenshots show notepad.exe and lsass.exe running under Vista. Notepad.exe, as a normal user mode process, has a medium integrity level. LSASS.exe as a critical system process has a system (400) integrity level.