Extranet access to ProClarity Analytics Server Using ISA Server 2006 and Kerberos
April 2009
Sean Flanagan
Summary
One of the most common case subjects at Microsoft support is with regard to permissions being passed from one server
to another in a distributed environment. Security best practices recommend that company web servers be separated
from database servers, domain controllers and other core service servers. The separation of roles to different servers
presents the challenge of authenticating to a chain of those servers. By far, Kerberos is the method of choice for
delegating credentials in a distributed environment. It is also the only protocol in a Microsoft Windows Active Directory
environment capable of passing credentials over a second hop (that is, over a connection from a middle tier server to
one or more back end servers when the connection to the middle tier is initiated by a third client machine). By design,
Kerberos has a number of security restrictions which make it difficult to use outside of a trusted domain or forest.
Microsoft Internet Security and Acceleration Server (ISA Server) can effectively extend the boundaries of Kerberos
Delegation outside the domain so users accessing the company website over the Internet (without a VPN) can take
advantage of Kerberos Delegation and not be prompted for credentials at each ‘hop’ in the environment. ISA Server can
do this by taking advantage of Kerberos features which do not require a Ticket Granting Ticket (TGT) from the client
workstation to access resources.
Disclaimer: This whitepaper will discuss the general configuration of Kerberos delegation. However it is intended for
audiences that have successfully configured Kerberos delegation in their internal environment and are looking to extend
that functionality to users connecting from locations beyond the perimeter of the company forest. This whitepaper is
not intended as a guide for configuring Kerberos delegation for intranet domain users. For internal Kerberos
configuration, please see this blog post.
Section 1: Extending Kerberos delegation via ISA Server 2006
ISA Server 2006 and Kerberos V5 have the ability to verify a user without Kerberos and then authenticate them to Active
Directory using Kerberos. ISA has a multitude of authentication options including a customizable HTML Form or a
standard HTTP Windows authentication page. Through Protocol Transition, the ISA server converts the authentication
package presented by the client and transitions to Kerberos authentication and connects to IIS. With ‘Services For User
To Proxy’ (S4U2P) and Kerberos Constrained Delegation the IIS server can then obtain an MSOLAP service ticket for the
remote user even though the remote user did not present a TGT from the Key Distribution Center.
SSL bridging also gives the ISA server the ability to decrypt SSL traffic from the internet facing NIC, apply the firewall
rules, convert to the Kerberos protocol, re-encrypt and send the traffic out the internal network interface to the
intended web server using the internal SSL certificate. SSL is considered required for sensitive web traffic being
transmitted over the internet. The credential hop from the ISA server to IIS can either be by Kerberos Constrained
Delegation or by a standard Kerberos connection (Negotiate) which does not requiring delegation.
Section 2: Protocol Transition
The ‘double-hop’ from the IIS server to SSAS requires a specific configuration as Protocol Transition will not work with
unconstrained delegation. The application pool identity permissions also play a key role in the required trust settings on
Active Directory objects. In short, Protocol Transition and S4U2P allow a service account to use a service ticket instead
of a TGT to obtain a service ticket for another user. Protocol transition and KCD do have some limitations, which are:
 Requires IIS6+
 Requires a domain functional level of Windows 2003+
 Will not work on Windows XP or Server 2000. However, Protocol Transition can call services on these platforms
 Protocol Transition must be used with Constrained Delegation to access resources on another server
 Constrained Delegation is restricted to within the local domain – it cannot cross domain or forest trusts
 After the first ‘Constrained’ hop, all hops in the chain after that point must also be constrained
The access level of the IIS service identity also plays a role in Protocol Transition which I will refer to later in the
configuration section. The lab setup for this document uses the ‘Network Service’ account which must be configured to
delegate to a service “Using any authentication protocol”. Accounts that have a higher level of access to the server can
be configured to ‘Use Kerberos only’. For more information, see the article “Protocol Transition with Constrained
Delegation Technical Supplement” on MSDN.
Section 3: Setting up ISA server as a Reverse Proxy
ISA server has the ability to function as both a proxy and reverse-proxy. In the following configuration, ISA will act as a
reverse proxy and appear as the end-point for connecting users. However, in actuality it will pass along the web traffic
to the internal server configured on the firewall publishing rule. This section will focus on configuring ISA server to
publish an internal site on its internet facing adapter. In the sample configuration, the ISA and IIS servers are setup as:
The internal address of the web server (ProductionIIS1) is what the ISA server will connect to when forwarding traffic
from the internet. The External public address (proclarity.contoso.com) on the ISA server’s external NIC is what the
external internet users will use to connect to ProClarity. SSL is highly recommended for this connection. Also, the
public DNS address needs to be mapped to the IP address of the ISA server if users are going to use the DNS name to
connect. SSL encryption from ISA to the internal IIS site is optional.
The following descriptions and screenshots will go through the ISA configuration and will assume that the internal
ProClarity site is online and functioning for intranet users using Kerberos. The ISA server for contoso.local is ISA 2006
Standard Edition running on Windows Server 2003. After installation the ‘Edge Firewall’ template was applied via the
Configuration > ‘Networks’ page, ‘Templates’ tab on the Task Pane. Applying the template resets most of the server
configuration to the template. The following configuration steps continue after applying the template.
When installing ISA Server 2006, the wizard will present an opportunity to define the ‘Internal’ network. The internal
network range for the contoso.local domain is 192.168.0.1-192.168.255.254. The first step to configuring the ISA server
is telling the firewall where the internal network is:
 In the ‘ISA Server Management’ console, expand the ‘Configuration’ page and select Networks.
 On the default ‘Networks’ tab you will see the Internal network at the top of the list. For the contoso.local
domain the Internal network is configured as a network Range:
 If you click the ‘Network Rules’ tab you will see that for the Edge Firewall template ‘Network Address
Translation’ is configured for the internal network. Internal clients can use the ISA server as a Proxy server in
which all External (internet) bound traffic will be appended with the public IP address of the ISA server hiding
the internal addresses.
After the network ranges are defined the next step is to publish the internal ProClarity site to the internet. To do this we
will first need to create a ‘Web Listener’ which tells the ISA server to listen for requests from clients.
 To create a web listener for the ISA server, select ‘Firewall Policy’ below the ISA server name on the pages list.
The default firewall policy is to deny all traffic and you should see the ‘Last’ rule defined as such.
 On the Task Pane, select the ‘Toolbox’ tab > ‘New’ > Web Listener
 Name the Web listener with an appropriate name, which for contoso.local is ‘External SSL’. Click the “Next”
button”
 The next page is ‘Client Connection Security’. SSL encryption should be configured on any public website where
credentials will be transmitted. For the ‘proclarity.contoso.com’ public website a server authentication
certificate has already been installed. Ensure the first bullet in the list is selected ‘Require SSL secured
connections…’ and click next
 On the next page, select ‘External’ to tell the web listener to listen for requests from an IP address not in the
internal network ranges
 Uncheck the ‘ISA Server will compress content’ option and click next
 For the Listener SSL, click ‘Select Certificate’. For the Contoso ProClarity site we select the pre-installed
certificate ‘proclarity.contoso.com’, then click select and next
 On the Authentication settings page click the drop down and select “HTML Form Authentication” and make sure
the default ‘Windows(Active Directory)’ option is selected, then click next
 The public ProClarity site does not have SSO configured so we clear the ‘Enable SSO’ check box and click next. If
you have multiple web servers and websites in the same domain you can setup Single Sign On so that when an
external user navigates from one website/server to another they are not re-prompted to authenticate
 Click Finish to complete the wizard. To save and apply the configuration changes click ‘Apply’ on the Firewall
Policy page, then ok
The web listener is now configured to listen on port 443 for HTTPS requests from the external network. The final
sequence for configuring ISA is to publish the internal Website:
 Select the Firewall Policy page and in the task pane click the ‘Tasks’ tab
 Select ‘Publish Web Sites’ and enter an appropriate name for the publishing rule, then click next. For our site
the publishing rule is named ‘External ProClarity SSL site’
 Make sure the first bullet ‘Allow’ is selected, then click next
 We are publishing a single internal site however ISA has load balancing capability with the ability to monitor if
one of the nodes is not responding. For this page we select ‘Publish a single Web site’ then click next
 The Connection Security section is where you would configure the SSL connection from the ISA server to the
internal site. We are not encrypting this connection so the second options is selected: ‘Use non-secured
connection’
 Click next and enter the internal site name (that you use to connect on the intranet). Our internal server name
is ‘ProductionIIS1’ so that is what we will enter. If the ISA server is unable to resolve the internal site you can
check the box to ‘Use a computer name or IP address to connect to the published server’. This configuration
does not require that setting so we click next
 For the Path we enter “/*” which permits access to the entire website
 The Public Name is important because this must match the public DNS settings and SSL Certificate assigned
when adding the web listener. For this configuration we enter ‘proclarity.contoso.com’ and click next
 Select the ‘External SSL’ web listener from the dropdown list then click next. You also have the option to create
a new web listener here as well
 On the Authentication Delegation page we select ‘Kerberos constrained delegation’. Before clicking next we
verify the Service Principle Name that ISA will look for and ensure it is assigned to the IIS identity account
 We are granting access to all Authenticated Users and accept the default setting on the User Sets page, then
click next
 Click Finish to complete the wizard, then ok. To save and apply the configuration changes click ‘Apply’ on the
Firewall Policy page, then ok. The new rule should appear:
After the ISA server is configured we test the connection on the client machine by opening IE and connecting to
https://proclarity.contoso.com/pas. The HTML login page appears on the client:
Section 4: Configuring Active Directory for Protocol Transition
Configuring Active Directory for Protocol Transition is required to permit the IIS server to request access to resources
using service tickets instead of a TGT from the client machine. This section picks up after Kerberos has already been
configured successfully for the internal users. While the proclarity.contoso lab is configured to use KCD from the ISA
server to IIS, this is not a requirement. If you set the ISA server to use ‘Negotiate’ instead of ‘KCD’ then the ISA server
does not need to be trusted for delegation. There is an active debate about which setting is more secure. The latter
option (KCD) is the newest feature of ISA2006 and is required for SSL client certificates.
The ISA server in the contoso.local domain is using KCD so we configure the IIS computer account to trust the IIS
account:
 Open Active Directory Users and Computers and locate the computer account for the ISA server
 Right click the ISA computer account and select properties, then the Delegation tab
 For KCD from ISA to IIS, we select the 3rd option ‘Trust this computer for delegation to specified services only’
 In the sub-list we select ‘Use any authentication protocol’
 Next we must specify the specific service that the ISA server can delegate to by clicking ‘add’ then ‘Users or
Computers’
 The internal ProClarity website application pool identity is set to the ‘Network Service’ account so we select the
computer account for the IIS server. Type the name of the IIS application pool identity which in this case is
‘ProductionIIS1’, then ok
 In the ‘Add Services’ list, we select http and click ok
o Note: If a domain account was running the application pool for ProClarity we would select that domain
account instead of the IIS server name. The list of Services would only include the specific SPN’s
assigned to the domain account we select so the HTTP SPN’s would have to be assigned before
completing this step
 The properties page appears as follows:
Next we need to configure the IIS computer account for constrained delegation to the OLAP servers, which in this
environment are named ProductionSSAS1 and ProductionSSAS2. As our internal site is run by the Network Service
account we configure the IIS server computer account for delegation. If the application pool identity was set to a
domain account we would instead configure delegation on the domain account.








Open Active Directory Users and Computers and locate the computer account for the IIS server
Right click the IIS computer account and select properties, then the ‘Delegation’ tab
For KCD from IIS to SSAS, we select the 3rd option ‘Trust this computer for delegation to specified services only’
In the sub-list we select ‘Use any authentication protocol’
o Note: Protocol Transition requires a certain level of permissions on the IIS worker process identity for
the ‘Use Kerberos only’ option to work. If a domain account was running the website (as in a load
balanced configuration) then the option ‘Use Kerberos only’ could be selected here. For the Network
Service account, however, ‘Use any authentication protocol’ must be selected
Next we must specify the services that the IIS account can delegate to by clicking ‘add’ then ‘Users or
Computers’
The two Contoso production SSAS 2008 servers have their Analysis Services service running under a domain
account called ‘ssas’ so we enter the account ‘ssas’ and click ok
In the ‘Add Services’ list, we see a service for each SPN that is configured on the domain account and add both
ProductionSSAS1 and ProductionSSAS2
Click ‘apply’ to apply the changes. The Properties page for the contoso web account now looks like this:
After restarting the IIS services on ProductionIIS1 we are able to access the ProClarity website and views from a remote
user that is not on the domain or connecting through a VPN. At this point you will first want to re-test credentials
passing on the internal network, verify that is working and then test from an external connection.
Section 5: Summary and Future Versions
To access remote resources, Kerberos V5 has two extensions used in Protocol Transition, and Protocol Transition will
only work with constrained delegation. For more information on the mechanics of Protocol Transition and KDC, see the
links in the reference section at the end of this document. Troubleshooting constrained delegation can be difficult and a
network packet capture utility can be very useful to monitor the Kerberos traffic as you can see IIS picking up the
MSOLAPSvc.3 tickets. It is highly recommended to verify Kerberos as working internally before troubleshooting Protocol
Transition through the ISA server. Also, the IIS service will cache failed login attempts and these tickets cannot be
purged using kerbtray or klist, so rebooting the IIS server may be necessary to clear cached Kerberos tickets. For
additional Kerberos troubleshooting, please see the links section. The technologies referenced in this document apply
to applications other than ProClarity (SharePoint, Outlook) and the possibilities with ISA server are numerous. The
Enterprise Edition version has cluster and array capabilities for an enterprise level deployment.
ISA server 2006 is a 32-bit application and will only run on Windows Server 2003. It cannot run on Server 2008. The
next release of ISA Server, called Threat Management Gateway, is 64-bit only and will run on Windows Server 2008.
TMG is currently in Beta 2 and can be downloaded from the Microsoft website (RTM expected Q4 of 2009). Both ISA
and TMG have many other functions in addition to Reverse Proxy, and the firewall software is world class. Exploring
these platforms further for the possibilities they might offer is highly recommended.
Section 6: Links and References
ISA, KCD, and Protocol Transition:
 http://msdn.microsoft.com/en-us/library/aa480585.aspx
 http://msdn.microsoft.com/en-us/library/aa480609.aspx
 http://technet.microsoft.com/en-us/library/cc738207.aspx
 http://technet.microsoft.com/en-us/library/bb794858.aspx



http://www.microsoft.com/forefront/edgesecurity/isaserver/en/us/default.aspx
http://www.microsoft.com/forefront/edgesecurity/isaserver/en/us/tmg-beta.aspx
http://blogs.technet.com/isablog/
General Kerberos:
 http://technet.microsoft.com/en-us/library/cc772815.aspx
 http://blogs.technet.com/askds/archive/2008/06/13/understanding-kerberos-double-hop.aspx
 http://blogs.technet.com/askds/archive/2008/03/06/kerberos-for-the-busy-admin.aspx
 http://blogs.technet.com/proclarity/archive/2008/12/22/proclarity-and-kerberos-delegation.aspx



http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1434
http://www.microsoft.com/downloads/details.aspx?FamilyID=f4db40af-1e08-4a21-a26bec2f4dc4190d&DisplayLang=en
http://support.microsoft.com/kb/926027