Ken Schaefer : IIS, Securityhttp://www.adopenstatic.com/cs/blogs/ken/archive/tags/IIS/Security/default.aspxTags: IIS, SecurityenCommunityServer 2.1 (Build: 60809.935)Denial of Service attach detailed against IIS 5 / IIS 6 FTP Servicehttp://www.adopenstatic.com/cs/blogs/ken/archive/2009/09/07/25293.aspxMon, 07 Sep 2009 15:39:00 GMTe0e31441-78b9-4457-b9b0-6f7906e03e71:25293Ken1http://www.adopenstatic.com/cs/blogs/ken/comments/25293.aspxhttp://www.adopenstatic.com/cs/blogs/ken/commentrss.aspx?PostID=25293http://www.adopenstatic.com/cs/blogs/ken/rsscomments.aspx?PostID=25293<p>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.</p><p>Microsoft has an <a href="http://www.microsoft.com/technet/security/advisory/975191.mspx" title="Microsoft Security Advisory" target="_blank">official advisory</a>, and some more details are available on the <a href="http://secunia.com/blog/62/" title="Secunia Security Blog" target="_blank">Secunia blog</a>. 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.</p><img src="http://www.adopenstatic.com/cs/aggbug.aspx?PostID=25293" width="1" height="1">IISSecurityIIS and Kerberos Part 9 - Cross Forest Delegation scenario with UPN suffix routinghttp://www.adopenstatic.com/cs/blogs/ken/archive/2009/02/25/21173.aspxThu, 26 Feb 2009 11:44:00 GMTe0e31441-78b9-4457-b9b0-6f7906e03e71:21173Ken13http://www.adopenstatic.com/cs/blogs/ken/comments/21173.aspxhttp://www.adopenstatic.com/cs/blogs/ken/commentrss.aspx?PostID=21173http://www.adopenstatic.com/cs/blogs/ken/rsscomments.aspx?PostID=21173<p>As an extension of the <a href="http://adopenstatic.com/cs/blogs/ken/archive/2008/06/28/17805.aspx" title="IIS and Kerberos Part 8 - Cross Forest Delegation">previous article</a> 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. </p><p>In this scenario we have the same two Forests as in <a href="http://adopenstatic.com/cs/blogs/ken/archive/2008/06/28/17805.aspx" title="IIS and Kerberos Part 8 - Cross Forest Delegation">Part 8</a>. Forest A (domainA.local) contains our resource servers (web server and SQL server). Forest B (domainB.local) contains our users and client PC.</p><p>Users are going to access a web site at <em>www.myCompany.com</em>, 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. <em>intranet.company.com</em>) 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.</p><p>A diagram of the process involved:</p><p><img alt="Kerberos with UPN suffix routing" border="0" height="361" src="http://adopenstatic.com/images/resources/blog/Kerberos18.jpg" style="width:397px;height:361px;" title="Kerberos with UPN suffix routing" width="397" /></p><p><br />Wireshark/Ethereal packet captures of the actual traffic are available for <a href="http://adopenstatic.com/resources/Kerberos4.bin" title="IIS and Kerberos Part 9 Packet Capture">download</a> (rename to .pcap).&nbsp; I&rsquo;ll explain the packets to look for a bit further down in the blog post.</p><p>The configuration steps required for this setup are:</p><ol><li>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)<br /><img alt="Configure name resolution" border="0" height="480" src="http://adopenstatic.com/images/resources/blog/Kerberos19.jpg" style="width:640px;height:480px;" title="Configure name resolution" width="640" /></li><li>Create an additional UPN (user principal name) suffix in your resource Forest (domainA.local). To do this: <ul><li>Open the Active Directory Domains and Trusts Administrative Tool</li><li>Right-click on the top level &quot;Domains and Trusts&quot; node</li><li>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)<br /><img alt="Adding a UPN suffix" height="448" src="http://adopenstatic.com/images/resources/blog/Kerberos20.jpg" style="width:404px;height:448px;" title="Adding a UPN suffix" width="404" /></li></ul></li><li>Configure Name Suffix Routing across the Forest Trust. To do this:</li><ul><li>Open the Active Directory Domains and Trusts Administrative Tool in DomainB.local (the user domain)</li><li>Right-click on your domain (domainB.local) and choose Properties</li><li>On the Trusts tab select DomainA.local under either options (Domains trusted by this domain or Domains that trust this domain) &ndash; it doesn&rsquo;t matter which one. Click the Properties button</li><li>On the Name Suffix Routing tab select *.www.myCompany.com and click Enable<br /><img alt="Enable suffix routing" height="448" src="http://adopenstatic.com/images/resources/blog/Kerberos21.jpg" style="width:404px;height:448px;" title="Enable suffix routing" width="404" /></li><li>Click OK to exit all the dialogues</li></ul><li>Steps 4 &amp; 5 are generic Kerberos configuration steps that aren&rsquo;t specific to cross-Forest scenarios: Add the requisite SPN (Service Principal Name). To learn about SPNs review <a href="http://adopenstatic.com/cs/blogs/ken/archive/2006/11/19/606.aspx" title="IIS and Kerberos Part 2 - Service Principal Names">Part 2</a> 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 <a href="http://adopenstatic.com/cs/blogs/ken/archive/2008/02/21/16275.aspx" title="IIS and Kerberos - What&#39;s new in IIS 7.0">Part 6</a>&nbsp;on new features in IIS 7.0<br /><img alt="Add the SPN" height="331" src="http://adopenstatic.com/images/resources/blog/Kerberos22.jpg" style="width:668px;height:331px;" title="Add the SPN" width="668" /><br /><br />After adding the SPN, you should see the following in Active Directory:<br /><br /><img alt="SPN in AD" height="448" src="http://adopenstatic.com/images/resources/blog/Kerberos23.jpg" style="width:404px;height:448px;" title="SPN in AD" width="404" /></li><li>Add the website www.myCompany.com to the Intranet Security Zone of the user&rsquo;s computer. Recall from <a href="http://adopenstatic.com/cs/blogs/ken/archive/2007/01/16/1054.aspx" title="IIS and Kerberos Part 3 - Simple Scenario">Part 3</a> 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.</li></ol><p>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 <a href="http://adopenstatic.com/cs/blogs/ken/archive/2008/06/28/17805.aspx" title="IIS and Kerberos Part 8 - Cross Forest Delegation">Part 8 packet capture</a> 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:</p><ol><li>Packet 6 &ndash; HTTP request by client</li><li>Packet 9 &ndash; Initial 401 response from web server</li><li>Packet 18 &ndash; DomainA.local DC returns service ticket for http/www.myCompany.com to client</li><li>Packet 21 &ndash; new HTTP request by client including Kerberos ticket</li><li>Packets 47-50 &ndash; tickets granted to access backend SQL Server</li><li>Packet 59 &ndash; HTTP 200 response to client with data from backend SQL Server</li></ol><p>For reference the machines in question are:</p><p><table style="font-family:verdana, geneva, arial;"><tr><td>Machine</td><td>Domain</td><td>IP address</td><td>Role</td></tr><tr><td>svr03-r2-dc-1</td><td>DomainA</td><td>192.168.132.10</td><td>DC</td></tr><tr><td>svr03-r2-dc-2</td><td>DomainB</td><td>192.168.132.11</td><td>DC</td></tr><tr><td>svr03-r2-web-1</td><td>DomainA</td><td>192.168.132.20</td><td>Web Server</td></tr><tr><td>svr03-r2-sql-1</td><td>DomainA</td><td>192.168.132.21</td><td>SQL&nbsp;Server</td></tr><tr><td>cltxp-pro-1</td><td>DomainB</td><td>192.168.132.50</td><td>Client</td></tr></table></p><p>&nbsp;</p><img src="http://www.adopenstatic.com/cs/aggbug.aspx?PostID=21173" width="1" height="1">IISSecurityIIS and Kerberos Part 8 - a simple cross Forest/Domain delegation scenariohttp://www.adopenstatic.com/cs/blogs/ken/archive/2008/06/28/17805.aspxSun, 29 Jun 2008 10:45:00 GMTe0e31441-78b9-4457-b9b0-6f7906e03e71:17805Ken16http://www.adopenstatic.com/cs/blogs/ken/comments/17805.aspxhttp://www.adopenstatic.com/cs/blogs/ken/commentrss.aspx?PostID=17805http://www.adopenstatic.com/cs/blogs/ken/rsscomments.aspx?PostID=17805<p style="font-family:verdana, geneva, arial;">In this part we extend, slightly, upon the <a href="http://adopenstatic.com/cs/blogs/ken/archive/2008/05/12/17533.aspx" title="IIS and Kerberos Part 8 - a simple cross Forest/Domain scenario">previous scenario</a>, by adding delegation. Now we need to allow IIS, in our resource Forest (or domain) to delegate the end user&rsquo;s credentials, to a backend service (SQL Server in this case):</p><p style="font-family:verdana, geneva, arial;">The machines this case are:</p><table style="font-family:verdana, geneva, arial;"><tr><td>Machine</td><td>Domain</td><td>IP address</td><td>Role</td></tr><tr><td>svr03-r2-dc-1</td><td>DomainA</td><td>192.168.132.10</td><td>DC</td></tr><tr><td>svr03-r2-dc-2</td><td>DomainB</td><td>192.168.132.11</td><td>DC</td></tr><tr><td>svr03-r2-web-1</td><td>DomainA</td><td>192.168.132.20</td><td>Web Server</td></tr><tr><td>svr03-r2-sql-1</td><td>DomainA</td><td>192.168.132.21</td><td>SQL&nbsp;Server</td></tr><tr><td>cltxp-pro-1</td><td>DomainB</td><td>192.168.132.50</td><td>Client</td></tr></table><p style="font-family:verdana, geneva, arial;">A packet capture is available for <a href="http://adopenstatic.com/resources/Kerberos2.bin">download</a> (taken from the IIS server).</p><p style="font-family:verdana, geneva, arial;">Opening the capture in Wireshark you should see the following (the bullet point numbers correspond to the numbers in the image below):</p><ol style="font-family:verdana, geneva, arial;"><li>XP client makes a request to IIS server (Packet 14) and IIS server responds with 401 Access Denied (Packet 17)</li><li>XP client contacts DomainB Domain Controller for Kerberos ticket (Packet 19 &ndash; note the request for http/svr03-r2-web-1)</li><li>DomainB DC returns a referral to DomainA DC (packet 20)</li><li>XP client looks up the necessary service records for DomainA (packets 21-24) before requesting a service ticket from the DomainA DC (packet 33)</li><li>The DomainA DC returns a service ticket to the XP client (packet 34)</li><li>XP client makes a new request to IIS, supplying it&rsquo;s Kerberos authentication data (packet 37)</li><li>IIS contacts its local DomainA DC seeking a referral to DomainB (packets 52-55) </li><li>DomainA DC refers IIS to DomainB DC</li><li>IIS requests a Kerberos ticket, on behalf of the end user, from DomainB DC (packet 61)</li><li>DomainB DC returns the necessary ticket (packet 62)</li><li>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)</li></ol><p style="font-family:verdana, geneva, arial;"><img alt="Cross Forest Delegation" border="0" height="360" src="http://adopenstatic.com/images/resources/blog/Kerberos17.jpg" style="width:247px;height:360px;" title="Cross Forest Delegation" width="247" /></p><p style="font-family:verdana, geneva, arial;">The requirements to configure this scenario aren&rsquo;t significantly beyond that to configure a basic cross-Forest/cross-Domain scenario featured in the previous part:</p><ul style="font-family:verdana, geneva, arial;"><li>A two-way trust is required. This can use Selective Authentication. However Forest-Wide authentication may be administratively simpler to configure</li><li>An appropriate SPN needs to be registered for the backend SQL Server (similar to a <a href="http://adopenstatic.com/cs/blogs/ken/archive/2007/01/28/1282.aspx" title="IIS and Kerberos Part 4 - a simple delegation scenario">single domain delegation scenario</a>)</li></ul><p style="font-family:verdana, geneva, arial;">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. </p><p style="font-family:verdana, geneva, arial;">NOTE (Feb 2009): I finally got around to publishing promised part - <a href="http://adopenstatic.com/cs/blogs/ken/archive/2009/02/25/21173.aspx" title="IIS and Kerberos Part 9 - UPN Suffix routing">see Part 9</a></p><p style="font-family:verdana, geneva, arial;">Note: A listing of parts is available in the <a href="http://adopenstatic.com/FAQ" title="IIS FAQ">FAQ<br /></a></p><img src="http://www.adopenstatic.com/cs/aggbug.aspx?PostID=17805" width="1" height="1">IISSecurityIIS and Kerberos Part 7 - A simple cross Forest scenariohttp://www.adopenstatic.com/cs/blogs/ken/archive/2008/05/12/17533.aspxTue, 13 May 2008 12:13:00 GMTe0e31441-78b9-4457-b9b0-6f7906e03e71:17533Ken16http://www.adopenstatic.com/cs/blogs/ken/comments/17533.aspxhttp://www.adopenstatic.com/cs/blogs/ken/commentrss.aspx?PostID=17533http://www.adopenstatic.com/cs/blogs/ken/rsscomments.aspx?PostID=17533<p>Note: I&nbsp;have&nbsp;created a list of all the <a href="http://adopenstatic.com/faq/" title="IIS FAQ">IIS and Kerberos parts</a>&nbsp;</p><p>I&#39;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&#39;ll cover more complex situations including delegation and ISA Server publishing.</p><p>The basics of cross-domain Kerberos authentication (in the same Forest) are the same as a cross-Forest scenario, so I&#39;ve covered the cross-Forest scenario in these posts, and steps that are unnecessary for a cross-domain scenario can be omitted.</p><p>Our setup involves a resource Forest (domainA.local) and a user Forest (domainB.local). A <a href="http://adopenstatic.com/resources/Kerberos.bin" title="Kerberos Cross Forest Packet Capture">network packet capture</a> is included (it can be opened using <a href="http://www.wireshark.org" title="Wireshark (formerly Ethereal)" target="_blank">Wireshark/Ethereal</a>&nbsp;- rename the extension back to .cap), and to help decipher the capture the machines involved are:</p><table><tr><td>Machine</td><td>Domain</td><td>IP address</td><td>Role</td></tr><tr><td>svr03-r2-dc-1</td><td>DomainA</td><td>192.168.132.10</td><td>DC</td></tr><tr><td>svr03-r2-dc-2</td><td>DomainB</td><td>192.168.132.11</td><td>DC</td></tr><tr><td>svr03-r2-web-1</td><td>DomainA</td><td>192.168.132.12</td><td>Web Server</td></tr><tr><td>cltxp-pro-1</td><td>DomainB</td><td>192.168.132.50</td><td>Client</td></tr></table><p>In the scenario the client in DomainB.local&nbsp;attempts to connect to svr03-r2-web-1 in DomainA.local. The sequence of packets are:</p><ol><li>Client connects to web server and gets 401 (Packets 4 and 6)</li><li>Client connects to DC in local Domain asking to a ticket to http/svr03-r2-web-1.domainA.local (Packet 8)</li><li>The DC in DomainB.local provides a referral to DomainA.local (Packet 9)</li><li>The client connects to a DC in DomainA.local asking for a ticket (Packet 12)</li><li>The DC in DomainA.local provides a Kerberos ticket to the client (Packet 13)</li><li>The client again connects to the web server, presenting its Kerberos ticket (Packet 15)</li><li>The server responds with a 200 OK (Packet 21)</li></ol><p><img alt="IIS and Kerberos - cross Forest scenario network diagram" border="0" height="370" src="http://adopenstatic.com/images/resources/blog/Kerberos15.jpg" style="width:368px;height:370px;" title="IIS and Kerberos - cross Forest scenario network diagram" width="368" /></p><p>And the user successfully authenticates using Kerberos:</p><p><img alt="IIS and Kerberos - cross forest scenario" border="0" height="448" src="http://adopenstatic.com/images/resources/blog/Kerberos16.jpg" style="width:403px;height:448px;" title="IIS and Kerberos - cross forest scenario" width="403" /></p><p>Things to be aware of in this simple scenario:</p><ul><li>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&#39;s Intranet security zone, the website will need to be added to that security zone either using a GPO or manually</li><li>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</li><li>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.</li><li>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</li><li>EDIT: If you need guidance on creating&nbsp;a Forest Trust, then Microsoft&#39;s TechNet has a <a href="http://technet2.microsoft.com/windowsserver/en/library/544d5801-205e-45b0-a1d7-cb9c39a7d7091033.mspx?mfr=true" title="Microsoft TechNet: creating Forest Trusts" target="_blank">good guide</a></li></ul><img src="http://www.adopenstatic.com/cs/aggbug.aspx?PostID=17533" width="1" height="1">IISSecurityIIS - two security patches this monthhttp://www.adopenstatic.com/cs/blogs/ken/archive/2008/02/12/16210.aspxWed, 13 Feb 2008 11:23:00 GMTe0e31441-78b9-4457-b9b0-6f7906e03e71:16210Ken1http://www.adopenstatic.com/cs/blogs/ken/comments/16210.aspxhttp://www.adopenstatic.com/cs/blogs/ken/commentrss.aspx?PostID=16210http://www.adopenstatic.com/cs/blogs/ken/rsscomments.aspx?PostID=16210<p>Hi all,</p><p>There are two security patches out this month for IIS.</p><p>The first (<a href="http://go.microsoft.com/fwlink/?LinkId=106361" title="Microsoft Security Bulletin MS08-005" target="_blank">MS08-005</a>) affects Windows XP x86&nbsp;(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)</p><p>The second (<a href="http://www.microsoft.com/technet/security/bulletin/ms08-006.mspx" title="MS08-006" target="_blank">MS08-006</a>) affects Windows XP (x86/x64) and&nbsp;Windows Server 2003, and is a remote code exploitation. It does require that the ASP web service extension be enabled on Windows Server 2003. </p><p>Whilst it&#39;s always disappointing to see new bugs in IIS, I think the overall record of IIS 6.0 has been very good. Since it&#39;s release in early 2003, we&#39;ve seen only a handful of bugs that are directly IIS&#39; fault (e.g. the previous <a href="http://www.microsoft.com/technet/security/Bulletin/MS06-034.mspx" title="MS06-034 Security Bulletin" target="_blank">ASP issue</a>), and handful of bugs that can be exploited via IIS (e.g. the previous <a href="http://www.microsoft.com/technet/security/Bulletin/MS04-030.mspx" title="MS04-030 Security Bulletin" target="_blank">WebDAV</a>&nbsp;issue). Overall, there are less than 5 bugs exploitable via IIS 6.0&nbsp;- which is&nbsp;a great record especially when compared with IIS 5.0 and with its major competitors.</p><img src="http://www.adopenstatic.com/cs/aggbug.aspx?PostID=16210" width="1" height="1">IISSecurityPublishing Operations Manager 2007 Web Console with ISA Server 2006http://www.adopenstatic.com/cs/blogs/ken/archive/2007/08/02/9139.aspxFri, 03 Aug 2007 06:36:00 GMTe0e31441-78b9-4457-b9b0-6f7906e03e71:9139Ken1http://www.adopenstatic.com/cs/blogs/ken/comments/9139.aspxhttp://www.adopenstatic.com/cs/blogs/ken/commentrss.aspx?PostID=9139http://www.adopenstatic.com/cs/blogs/ken/rsscomments.aspx?PostID=9139<p>Having just deployed a test Operations Manager 2007 server at home, I wanted to publish the Web Console site externally, so I wouldn&#39;t have to continually TS into my box at home, and use the regular console.</p><p>My only problem is that I have a single public IP address, and because I&#39;m only publishing services over HTTPS, I only have a single FQDN that I can use (I&#39;m not willing to pay for a wildcard certificate). So each service that I&#39;m publishing needs to exist as a folder(s) off the root of my published FQDN (assuming I don&#39;t want to use non-standard ports and avoid certificate errors). My current publishing setup looks like this:</p><p><img alt="Reverse Publishing with ISA Server 2006" border="0" height="423" src="http://www.adopenstatic.com/images/resources/blog/publishingOpsMgrConsole1.jpg" style="width:437px;height:423px;" title="Reverse Publishing with ISA Server 2006" width="437" /></p><p>Unfortunately the Operations Manager 2007 Web Console website isn&#39;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. </p><p>Whilst it is possible to configure individual link translation elements for publishing this website, I found an easier way to get this working.</p><p>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&#39;m using <em>OpsMgr</em>) 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):</p><p><img alt="Configuring IIS" border="0" height="422" src="http://www.adopenstatic.com/images/resources/blog/PublishingOpsMgrConsole2.jpg" style="width:600px;height:422px;" title="Configuring IIS" width="600" /></p><p>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&#39;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:</p><p><img alt="The published Operations Manager 2007 Web Console" border="0" height="450" src="http://www.adopenstatic.com/images/resources/blog/publishingOpsMgrConsole3.jpg" style="width:600px;height:450px;" title="The published Operations Manager 2007 Web Console" width="600" /></p><img src="http://www.adopenstatic.com/cs/aggbug.aspx?PostID=9139" width="1" height="1">IISOther TechSecurityIIS and Kerberos Part 5 - Protocol Transition, Constrained Delegation, S4U2S and S4U2Phttp://www.adopenstatic.com/cs/blogs/ken/archive/2007/07/18/8460.aspxThu, 19 Jul 2007 12:24:00 GMTe0e31441-78b9-4457-b9b0-6f7906e03e71:8460Ken15http://www.adopenstatic.com/cs/blogs/ken/comments/8460.aspxhttp://www.adopenstatic.com/cs/blogs/ken/commentrss.aspx?PostID=8460http://www.adopenstatic.com/cs/blogs/ken/rsscomments.aspx?PostID=8460<p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">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 &ndash; the need to get tickets from a KDC. In the IIS world, contacting a KDC simply isn&rsquo;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:</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><img alt="Kerberos problems for internet clients" border="0" height="318" src="http://www.adopenstatic.com/images/resources/blog/kerberos8.jpg" style="width:635px;height:318px;" title="Kerberos problems for internet clients" width="635" /></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">In the diagram above &#39;1&#39; 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.</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">Even if the client is able to locate a KDC, the &#39;2&#39; 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.</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">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&#39;s username and password, allowing direct impersonation via <em>LogonUser</em> however a compromised web server in this case would allow a malicious attacker to harvest a rich database of users and their passwords).</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">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.</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">Windows Server 2003 introduces:</font></p><p class="MsoListParagraphCxSpFirst" style="text-indent:-18pt;margin:0cm 0cm 0pt 36pt;"><span style="font-family:Symbol;"><span><font size="3">&middot;</font><span style="font:7pt 'Times New Roman';">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><font face="Calibri" size="3">Protocol Transition &ndash; 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.</font></p><p class="MsoListParagraphCxSpLast" style="text-indent:-18pt;margin:0cm 0cm 10pt 36pt;"><span style="font-family:Symbol;"><span><font size="3">&middot;</font><span style="font:7pt 'Times New Roman';">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><font face="Calibri" size="3">Constrained Delegation &ndash; this allows Administrators to constrain what backend services IIS can connect to.</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">To facilitate these two pieces of functionality, Windows Server 2003 introduces two services that can be leveraged by your applications and by IIS:</font></p><p class="MsoListParagraphCxSpFirst" style="text-indent:-18pt;margin:0cm 0cm 0pt 36pt;"><span style="font-family:Symbol;"><span><font size="3">&middot;</font><span style="font:7pt 'Times New Roman';">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><font face="Calibri" size="3">Services For User to Self (S4U2S)</font></p><p class="MsoListParagraphCxSpLast" style="text-indent:-18pt;margin:0cm 0cm 10pt 36pt;"><span style="font-family:Symbol;"><span><font size="3">&middot;</font><span style="font:7pt 'Times New Roman';">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><font face="Calibri" size="3">Services for User to Proxy (S4U2P)</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><img alt="Services for User to Self (S4USelf) and Services for User to Proxy (S4U Proxy)" border="0" height="168" src="http://www.adopenstatic.com/images/resources/blog/kerberos9.jpg" style="width:455px;height:168px;" title="Services for User to Self (S4USelf) and Services for User to Proxy (S4U Proxy)" width="455" /></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">Firstly let&#39;s address the necessary steps to configure Protocol Transition and Constrained Delegation in an IIS situation, and then we&#39;ll look through the actual implementation details that show how this all hangs together. </font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">If you missed the previous parts in the series or need a refresher then you can find them at:</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3"><a href="http://www.adopenstatic.com/cs/blogs/ken/archive/2006/10/19/512.aspx" title="IIS and Kerberos Part 1 - How does it work?">IIS and Kerberos Part 1 - What is Kerberos and how does it work?</a></font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3"><a href="http://www.adopenstatic.com/cs/blogs/ken/archive/2006/11/19/606.aspx" title="IIS and Kerberos Part 2 - Service Principal Names">IIS and Kerberos Part 2 - What are Service Principal Names?</a></font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3"><a href="http://www.adopenstatic.com/cs/blogs/ken/archive/2007/01/16/1054.aspx" title="IIS and Kerberos Part 3 - A simple authentication scenario">IIS and Kerberos Part 3 -&nbsp; A simple scenario</a></font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3"><a href="http://www.adopenstatic.com/cs/blogs/ken/archive/2007/01/27/1282.aspx" title="IIS and Kerberos Part 4 - A simple delegation scenario">IIS and Kerberos Part 4 - A simple delegation scenario</a></font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><strong><font size="3"><font face="Calibri">Configuring Active Directory</font></font></strong></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">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).</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">To configure Active Directory using the GUI (how to configure this all programmatically is explained later) open Active Directory Users and Computers MMC Snapin.</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">Assuming that you are not using a custom user account for your web application pool, locate your IIS server&rsquo;s computer object and bring up that machine&rsquo;s properties. On the delegation tab choose both:</font></p><p class="MsoListParagraphCxSpFirst" style="text-indent:-18pt;margin:0cm 0cm 0pt 36pt;"><span style="font-family:Symbol;"><span><font size="3">&middot;</font><span style="font:7pt 'Times New Roman';">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><font face="Calibri" size="3">Trust this computer for delegation to specified services only<span>&nbsp; </span>and </font></p><p class="MsoListParagraphCxSpLast" style="text-indent:-18pt;margin:0cm 0cm 10pt 36pt;"><span style="font-family:Symbol;"><span><font size="3">&middot;</font><span style="font:7pt 'Times New Roman';">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><font face="Calibri" size="3">Use any authentication protocol</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><img alt="Configuring Active Directory" border="0" height="466" src="http://www.adopenstatic.com/images/resources/blog/kerberos10.jpg" style="width:404px;height:466px;" title="Configuring Active Directory" width="404" /></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">You will now need to specify the backend services that the IIS machine is permitted to delegate to. Click the &quot;add&quot; button and then the &quot;users and computers&quot; 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&#39;s computer account. If you are running SQL Server under a custom user account, enter that user&#39;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 <a href="http://www.adopenstatic.com/cs/blogs/ken/archive/2006/10/19/512.aspx" title="IIS and Kerberos Part 1 - How Kerberos Works">Part 1 (Kerberos fundamentals)</a> and <a href="http://www.adopenstatic.com/cs/blogs/ken/archive/2006/11/19/606.aspx" title="IIS and Kerberos Part 2 - Service Principal Names">Part 2 (Service Principal Names)</a> in this series.</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3"><img alt="Add Service Principal Names" border="0" height="386" src="http://www.adopenstatic.com/images/resources/blog/kerberos11.jpg" style="width:404px;height:386px;" title="Add Service Principal Names" width="404" /></font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">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&rsquo;s computer account.</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><strong><font size="3"><font face="Calibri">Configuring IIS</font></font></strong></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">There isn&rsquo;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 <em>SeTCBPrivilege</em> (Act as Part of the Operating System) and <em>SeImpersonateUser</em> (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 -&gt; Run -&gt; secpol.msc). Alternatively Group Policy can also be used.</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">Note: running a web application pool with any account that has <em>SeTCBPrivilege</em> is a security risk. Any potential compromise of your web application will result in the attacker having full privileges over your IIS server.</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">And that&#39;s the entire configuration that&#39;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 &ndash; A simple delegation scenario.</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">For more information on how this is actually implemented in Windows Server 2003, read on.</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><strong><font size="3"><font face="Calibri">Services For User to Self</font></font></strong></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">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&rsquo;s TGT (Ticket Granting Ticket) or end user&rsquo;s credentials (username/password) to the KDC, the service provides its own credentials.</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">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 <em>Impersonation</em> token. If the service does not have this privilege, the token is an <em>Identification</em> token.<span>&nbsp; </span>(TCB in SeTCBPrivilege stands for Trusted Computing Base a.k.a. the trusted kernel of the operating system). An <em>Identification </em>token can be used to determine a user&rsquo;s group membership and validate the user&rsquo;s access to resources. An <em>Impersonation </em>token further allows access to kernel mode objects using the end user&rsquo;s identity.</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font size="3"><font face="Calibri"><span>&nbsp;</span>In order to actually use an <em>Impersonation</em> 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 <em>Impersonation </em>token being downgraded to an <em>Identification</em> token.</font></font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">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&rsquo;s TGT or credentials. A service can do this by either directly calling <em>LsaLogonUser</em> (or the constructor for the .NET <em>WindowsIdentity</em> class that wraps LsaLogonUser), or by relying on the Kerberos SSP provided by Windows Server 2003.</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">Services for User to Self (S4U2S) help provide for Protocol Transition &ndash; the ability to perform Kerberos Authentication even though the end user has authenticated to our IIS server using some other protocol.</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><strong><font size="3"><font face="Calibri">Services for User to Proxy </font></font></strong></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">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 <em>Forwardable</em> 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.</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">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.</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">The actual series of events looks like the following:</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3"><img alt="Constrained Delegation" border="0" height="297" src="http://www.adopenstatic.com/images/resources/blog/kerberos12.jpg" style="width:561px;height:297px;" title="Constrained Delegation" width="561" /></font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">In order for the service to be able to get forwardable tickets on an end user&#39;s behalf, a flag needs to be set on the service account&rsquo;s userAccountControl property in Active Directory: TrustedToAuthenticateForDelegation (T2A4D). This flag has the value 0x1000000 (or 16777216 in decimal). </font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">Note: if the end user had authenticated initially using Kerberos, then this particular flag doesn&rsquo;t need to be set. We use it only when we are using Protocol Transition and we need to get forwardable tickets.</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">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 &quot;Trust this computer for delegation to any service (Kerberos Only)&quot; 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 &quot;unconstrained delegation&quot;.</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><img alt="Unconstrained Delegation" border="0" height="466" src="http://www.adopenstatic.com/images/resources/blog/kerberos13.jpg" style="width:404px;height:466px;" title="Unconstrained Delegation" width="404" /></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">To set the T2A4D flag we choose the &ldquo;Trust this computer for delegation to specific services only -&gt; Use Any Authentication Protocol&rdquo;. This means that a client can use any Authentication protocol to authenticate to our service, but then we&rsquo;ll be using Protocol Transition and S4U2P to get Kerberos tickets to authenticate to these backend services.</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">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.<span>&nbsp; </span>The msAllowedToDelegateTo property is populated whenever we use Constrained Delegation. If we choose the &quot;Keberos Only&quot; option, then only this property is populated. If we choose the &quot;Use Any Authentication Protocol&quot; then both the T2A4D userAccountControl flag is set and the msAllowedToDelegateTo field is set.</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><img alt="msAllowToDelegateTo property in action" border="0" height="448" src="http://www.adopenstatic.com/images/resources/blog/Kerberos14.jpg" style="width:404px;height:448px;" title="msAllowToDelegateTo property in action" width="404" /></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><table cellpadding="0" cellspacing="0" class="MsoNormalTable" style="border-collapse:collapse;border:medium none;"><tr><td style="padding-bottom:0cm;background-color:transparent;padding-left:5.4pt;width:231.05pt;padding-right:5.4pt;padding-top:0cm;border:black 1pt solid;"><p class="MsoNormal" style="line-height:normal;margin:0cm 0cm 0pt;"><font size="3"><font face="Calibri">userAccountControl - TrustedToDelegate</font></font></p></td><td style="border-bottom:black 1pt solid;border-left:#f0f0f0;padding-bottom:0cm;background-color:transparent;padding-left:5.4pt;width:231.05pt;padding-right:5.4pt;border-top:black 1pt solid;border-right:black 1pt solid;padding-top:0cm;"><p class="MsoNormal" style="line-height:normal;margin:0cm 0cm 0pt;"><font size="3"><font face="Calibri">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 &ndash; the end user must have authenticated using Kerberos. </font></font></p></td></tr><tr><td style="border-bottom:black 1pt solid;border-left:black 1pt solid;padding-bottom:0cm;background-color:transparent;padding-left:5.4pt;width:231.05pt;padding-right:5.4pt;border-top:#f0f0f0;border-right:black 1pt solid;padding-top:0cm;"><p class="MsoNormal" style="line-height:normal;margin:0cm 0cm 0pt;"><font size="3"><font face="Calibri">userAccountControl - TrustedToAuthenticateForDelegation</font></font></p></td><td style="border-bottom:black 1pt solid;border-left:#f0f0f0;padding-bottom:0cm;background-color:transparent;padding-left:5.4pt;width:231.05pt;padding-right:5.4pt;border-top:#f0f0f0;border-right:black 1pt solid;padding-top:0cm;"><p class="MsoNormal" style="line-height:normal;margin:0cm 0cm 0pt;"><font size="3"><font face="Calibri">When set, the service may use protocol transition to connect to backend services listed in msDS-allowedToDelegateTo. This flag is set when you configure &ldquo;Use any authentication protocol&rdquo;)</font></font></p></td></tr><tr><td style="border-bottom:black 1pt solid;border-left:black 1pt solid;padding-bottom:0cm;background-color:transparent;padding-left:5.4pt;width:231.05pt;padding-right:5.4pt;border-top:#f0f0f0;border-right:black 1pt solid;padding-top:0cm;"><p class="MsoNormal" style="line-height:normal;margin:0cm 0cm 0pt;"><font size="3"><font face="Calibri">msDS-AllowedToDelegateTo</font></font></p></td><td style="border-bottom:black 1pt solid;border-left:#f0f0f0;padding-bottom:0cm;background-color:transparent;padding-left:5.4pt;width:231.05pt;padding-right:5.4pt;border-top:#f0f0f0;border-right:black 1pt solid;padding-top:0cm;"><p class="MsoNormal" style="line-height:normal;margin:0cm 0cm 0pt;"><font size="3"><font face="Calibri">When using constrained delegation (either &ldquo;Kerberos Only&rdquo;, or &ldquo;Use Any Authentication Protocol&rdquo;) this property lists the backend services that the service can connect to.</font></font></p></td></tr><tr><td style="border-bottom:black 1pt solid;border-left:black 1pt solid;padding-bottom:0cm;background-color:transparent;padding-left:5.4pt;width:231.05pt;padding-right:5.4pt;border-top:#f0f0f0;border-right:black 1pt solid;padding-top:0cm;"><p class="MsoNormal" style="line-height:normal;margin:0cm 0cm 0pt;"><font size="3"><font face="Calibri">SeTCBPrivilege</font></font></p></td><td style="border-bottom:black 1pt solid;border-left:#f0f0f0;padding-bottom:0cm;background-color:transparent;padding-left:5.4pt;width:231.05pt;padding-right:5.4pt;border-top:#f0f0f0;border-right:black 1pt solid;padding-top:0cm;"><p class="MsoNormal" style="line-height:normal;margin:0cm 0cm 0pt;"><font size="3"><font face="Calibri">The service must have this privilege to get <em>Impersonation</em> tokens</font></font></p></td></tr><tr><td style="border-bottom:black 1pt solid;border-left:black 1pt solid;padding-bottom:0cm;background-color:transparent;padding-left:5.4pt;width:231.05pt;padding-right:5.4pt;border-top:#f0f0f0;border-right:black 1pt solid;padding-top:0cm;"><p class="MsoNormal" style="line-height:normal;margin:0cm 0cm 0pt;"><font size="3"><font face="Calibri">SeImpersonateUser</font></font></p></td><td style="border-bottom:black 1pt solid;border-left:#f0f0f0;padding-bottom:0cm;background-color:transparent;padding-left:5.4pt;width:231.05pt;padding-right:5.4pt;border-top:#f0f0f0;border-right:black 1pt solid;padding-top:0cm;"><p class="MsoNormal" style="line-height:normal;margin:0cm 0cm 0pt;"><font size="3"><font face="Calibri">The service must have this privilege to be able to use the <em>Impersonation</em> token to impersonate a user.</font></font></p></td></tr></table></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">Now, some gotchas that you need to be aware of. As mentioned earlier but worth repeating;</font></p><ul style="margin-top:0cm;"><li class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">Protocol Transition relies on using constrained delegation. You can&rsquo;t use Protocol Transition in conjunction with unconstrained delegation.</font></li><li class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">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.</font></li><li class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">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.</font></li></ul><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">And that concludes this rather long Part 5. If you&rsquo;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 <a href="http://www.adopenstatic.com/contact/" title="Contact Ken">email me</a> so I can avoid public embarrassment :-)</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">In Part 6 we&rsquo;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&rsquo;d like me to cover, please drop me a line.</font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3"></font></p><p class="MsoNormal" style="margin:0cm 0cm 10pt;"><font face="Calibri" size="3">Edit: Due to blog spam - comments are disabled. Contact me through the contact form</font></p><img src="http://www.adopenstatic.com/cs/aggbug.aspx?PostID=8460" width="1" height="1">IISSecurityCan you install more than one certificate per web site? (IIS 5 / 6)http://www.adopenstatic.com/cs/blogs/ken/archive/2007/05/11/5050.aspxSat, 12 May 2007 11:00:00 GMTe0e31441-78b9-4457-b9b0-6f7906e03e71:5050Ken8http://www.adopenstatic.com/cs/blogs/ken/comments/5050.aspxhttp://www.adopenstatic.com/cs/blogs/ken/commentrss.aspx?PostID=5050http://www.adopenstatic.com/cs/blogs/ken/rsscomments.aspx?PostID=5050<p>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 <a href="https://www.abc.com/">https://www.abc.com</a> as well as <a href="https://www.def.com/">https://www.def.com</a> without generating an error in the user&#39;s browser that the website&#39;s name didn&#39;t match the one in the certificate.</p><p>The simple answer to the question in the subject line, is that you can&#39;t install more than one certificate in IIS 5 and IIS 6. That doesn&#39;t mean that you can&#39;t solve the problem (read on for some solutions that might work for you).</p><p>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)</p><p><img alt="SSL Certificate Hash property in IIS Metabase" border="0" height="480" src="http://www.adopenstatic.com/images/resources/blog/SSLCerthash1.jpg" style="width:640px;height:480px;" title="SSL Certificate Hash property in IIS Metabase" width="640" /></p><p>Figure 1</p><p>The actual value that&#39;s stored in this SSLCertHash field corresponds to the server authentication certificate&#39;s &quot;thumbprint&quot; property that you can view using the MMC (after adding the Certificates snapin).&nbsp; See Figure 2 below:</p><p><img alt="Certificate Thumbprint" border="0" height="474" src="http://www.adopenstatic.com/images/resources/blog/SSLCertHash2.jpg" style="width:409px;height:474px;" title="Certificate Thumbprint" width="409" /></p><p>Figure 2</p><p>&nbsp;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&#39;s browser? Well, here are some options:</p><ol><li>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)</li><li>Use a certificate that has mulitple common names (see Figure 3 below)</li><li>Use a wildcard certificate (that matches *.domain.tld)</li></ol><p><img alt="Multiple CNs in a certificate" border="0" height="475" src="http://www.adopenstatic.com/images/resources/blog/SSLCertHash3.jpg" style="width:408px;height:475px;" title="Multiple CNs in a certificate" width="408" /></p><p>Figure 3</p><img src="http://www.adopenstatic.com/cs/aggbug.aspx?PostID=5050" width="1" height="1">IISSecurityCertificate Services (2000, 2003) Web Enrollment does not work on Vistahttp://www.adopenstatic.com/cs/blogs/ken/archive/2007/05/01/4487.aspxWed, 02 May 2007 13:45:00 GMTe0e31441-78b9-4457-b9b0-6f7906e03e71:4487Ken3http://www.adopenstatic.com/cs/blogs/ken/comments/4487.aspxhttp://www.adopenstatic.com/cs/blogs/ken/commentrss.aspx?PostID=4487http://www.adopenstatic.com/cs/blogs/ken/rsscomments.aspx?PostID=4487<p>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&#39;t be able to enrol for a certificate (indeed if you&#39;re using Windows Server 2003 SP2 you get a message to that effect).</p><p>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. </p><p>Hardly an ideal situation if you ask me!</p><p>More information can be found on <a href="http://support.microsoft.com/kb/922706" title="Microsoft KB 922706" target="_blank">Microsoft&#39;s website</a>.</p><img src="http://www.adopenstatic.com/cs/aggbug.aspx?PostID=4487" width="1" height="1">IISVista / Windows Server 2008SecurityIIS and Kerberos. Part 4 - A simple delegation scenariohttp://www.adopenstatic.com/cs/blogs/ken/archive/2007/01/27/1282.aspxSun, 28 Jan 2007 05:31:00 GMTe0e31441-78b9-4457-b9b0-6f7906e03e71:1282Ken10http://www.adopenstatic.com/cs/blogs/ken/comments/1282.aspxhttp://www.adopenstatic.com/cs/blogs/ken/commentrss.aspx?PostID=1282http://www.adopenstatic.com/cs/blogs/ken/rsscomments.aspx?PostID=1282<p>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&#39;s password. This functionality allows Kerberos to solve typical &quot;double-hop&quot; authentication problems where a user&#39;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&#39;ll cover something called &quot;Protocol Transition&quot; later on down the track).</p><p>In this simple scenario, we&#39;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&#39;s credentials (a &quot;trusted connection&quot;).</p><p><img alt="IIS and Kerberos - a delegation scenario" border="0" height="404" src="http://www.adopenstatic.com/images/resources/blog/Kerberos6.jpg" style="width:576px;height:404px;" title="IIS and Kerberos - a delegation scenario" width="576" /></p><p>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. </p><p>In the diagram above the following sequence of events takes place:</p><ol><li>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 <a href="http://www.adopenstatic.com/cs/blogs/ken/archive/2006/11/19/606.aspx" title="IIS and Kerberos. Part 3 - A simple scenario">previous post</a>.</li><li>The web server, seeing the need to open a connection to SQL Server using the end user&#39;s credentials obtains the necessary ticket from the KDC</li><li>The KDC returns a ticket if the web server is permitted to delegate</li><li>The server opens the connection, sending the ticket obtained from the KDC</li><li>The SQL Server permits the connection to be opened, or returns a error indicating that the user is not permitted login to SQL Server</li><li>The web server returns the web page to the end user</li></ol><p>To get this working, we need some additional configuration in addition to what we performed <a href="http://www.adopenstatic.com/cs/blogs/ken/archive/2007/01/16/1054.aspx" title="IIS and Kerberos. Part 3 - A Simple Scenario">previously</a>. In Active Directory we need to give permission to the web server so as to allow it to get tickets on the end user&#39;s behalf. If you locate the web server&#39;s computer in Active Directory Users and Computers MMC, right-click and choose &quot;Properties&quot;, there is a &quot;Delegation&quot; 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.</p><p>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:</p><p><img alt="Configuring Delegation - Windows Server 2003 functional level domain" border="0" height="466" src="http://www.adopenstatic.com/images/resources/blog/Kerberos7.jpg" style="width:404px;height:466px;" title="Configuring Delegation - Windows Server 2003 functional level domain" width="404" /></p><p>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&#39;s computer account (typically it changes from 0x80 to 0x2080). Alternatively, you can configure &quot;constrained&quot; 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 <a href="http://msdn2.microsoft.com/en-us/library/ms677183.aspx" title="msDS-AllowedToDelegateTo">msDS-AllowedToDelegateTo</a> AD attribute for the computer account in question.</p><p>Constrained delegation makes available another option (Protocol Transition) - this is the option that is labelled &quot;use any protocol&quot;. We&#39;ll deal with Protocol Transition, and its implications in another post in the series. </p><p>For our scenario, we&#39;ll configure constrained delegation to our backend SQL Server. Click the &quot;Add&quot; 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&#39;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 <a href="http://www.adopenstatic.com/cs/blogs/ken/archive/2006/11/19/606.aspx" title="IIS and Kerberos. Part 2 - Service Principal Names">Part 2</a> in this series.</p><p>There are a couple of &quot;gotchas&quot; 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&#39;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.</p><img src="http://www.adopenstatic.com/cs/aggbug.aspx?PostID=1282" width="1" height="1">IISSecurityIIS and Kerberos. Part 3 - A simple scenariohttp://www.adopenstatic.com/cs/blogs/ken/archive/2007/01/16/1054.aspxTue, 16 Jan 2007 20:32:00 GMTe0e31441-78b9-4457-b9b0-6f7906e03e71:1054Ken22http://www.adopenstatic.com/cs/blogs/ken/comments/1054.aspxhttp://www.adopenstatic.com/cs/blogs/ken/commentrss.aspx?PostID=1054http://www.adopenstatic.com/cs/blogs/ken/rsscomments.aspx?PostID=1054<p>In Part 3 of this series we look at setting up Kerberos Authentication in the simplest possible scenario. If you missed Parts 1 (<a href="http://www.adopenstatic.com/cs/blogs/ken/archive/2006/10/19/512.aspx" title="IIS and Kerberos - Part 1">What is Kerberos and how does it work</a>) and 2 (<a href="http://www.adopenstatic.com/cs/blogs/ken/archive/2006/11/19/606.aspx" title="IIS and Kerberos - Part 2">Service Principal Names</a>) 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.</p><p>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:</p><p><img alt="IIS and Kerberos - a simple scenario" border="0" height="423" src="http://www.adopenstatic.com/images/resources/blog/Kerberos5.jpg" style="width:418px;height:423px;" title="IIS and Kerberos - a simple scenario" width="418" /></p><p>1) The client makes a HTTP Request<br />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<br />3) The client requests a Service Ticket from the KDC hosted on the Domain Controller<br />4) The Domain Controller returns the Service Ticket<br />5) The Client generates the Authenticator, and sends this plus the Service Ticket in a new HTTP request to the web server<br />6) The webserver determines the identity of the client, checks the ACL on the resource and either permits or denies access to the resource.</p><p>In order for this sequence of events to work the following need to be configured.</p><p><strong>The Browser<br /></strong>For Internet Explorer to use Kerberos to authenticate to IIS the following must be configured correctly:</p><ol><li>Under Tools -&gt; Internet Options -&gt; Advanced the option &quot;Enable Integrated Windows Authentication (Requires Restart)&quot; 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.</li><li>The website you are connecting to must be located in the &quot;Intranet&quot; 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&#39;s status bar. If the website is located in the &quot;Internet&quot; 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&#39;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 <a href="http://support.microsoft.com/?id=258063" title="KB Article 258063" target="_blank">258063</a></li></ol><p><strong>The Domain Controller<br /></strong>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.</p><p>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.</p><p>And lastly, if the website is accessible at an arbitrary hostname that is unrelated to the actual server&rsquo;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&rsquo;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.</p><p>SPNs can be added using a GUI-based tool such as <a href="http://www.adopenstatic.com/cs/blogs/ken/archive/2006/11/19/606.aspx" title="IIS and Kerberos - Service Principal Names">ADSIEdit</a>. Or can be added programmatically using an interface to AD (such as <a href="http://msdn2.microsoft.com/en-us/library/aa772218.aspx" title="MSDN ADSI Reference" target="_blank">ADSI</a>), 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:</p><ol><li>a servername under a custom user account:<br />setspn &ndash;A HTTP/servername Domain\Username<br /></li><li>an arbitrary hostname under a computer account:<br />setspn &ndash;A HTTP/hostname.domain.tld Domain\MachineName<br /></li><li>an arbitrary hostname under a custom user account:<br />setspn &ndash;A HTTP/hostname.domain.tld Domain\UserName</li></ol><p><strong>The IIS Server</strong><br />There isn&rsquo;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 &ndash; you may need to manually add it back in. See Microsoft KB Article <a href="http://support.microsoft.com/?id=832769" title="KB Article 832769" target="_blank">832769</a> for your options. </p><p>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&rsquo;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.</p><p><strong>Summary<br /></strong>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 <a href="http://www.adopenstatic.com/cs/blogs/ken/archive/2006/08/02/Two-easy-_2800_easier_3F002900_-ways-to-determine-Kerberos-from-NTLM-in-a-HTTP-capture.aspx" title="Two easy ways to determine whether NTLM or Kerberos is being used">determining whether the browser is using NTLM or Kerberos</a> to authenticate to IIS.</p><img src="http://www.adopenstatic.com/cs/aggbug.aspx?PostID=1054" width="1" height="1">IISSecurityIIS and Kerberos. Part 2 - Service Principal Nameshttp://www.adopenstatic.com/cs/blogs/ken/archive/2006/11/19/606.aspxSun, 19 Nov 2006 21:29:00 GMTe0e31441-78b9-4457-b9b0-6f7906e03e71:606Ken21http://www.adopenstatic.com/cs/blogs/ken/comments/606.aspxhttp://www.adopenstatic.com/cs/blogs/ken/commentrss.aspx?PostID=606http://www.adopenstatic.com/cs/blogs/ken/rsscomments.aspx?PostID=606<p>Apologies for the delay in posting Part 2 - I&#39;ve been on holidays so it&#39;s been a bit hard finding the time to write these posts. In this part we cover Service Principal Names (SPNs).&nbsp;</p><p>In a previous post we covered the basics of Kerberos authentication. Everything is relatively straitforward, however I didn&#39;t cover the one particular aspect. Namely, how does the Authorisation Service (AS) and remote Service share their shared secret?</p><p>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&#39;s password is used as the basis of the&nbsp;shared secret. If the remote service is running under a custom user account, then the user account&#39;s password is used as the basis of the shared secret.</p><p>So how does the AS know which user or computer account&#39;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):</p><p><img alt="Service Principal Name (SPN)" border="0" height="448" src="http://www.adopenstatic.com/images/resources/blog/kerberos2.jpg" style="width:404px;height:448px;" title="Service Principal Name (SPN)" width="404" /></p><p><img alt="Service Principal Names (SPN)" border="0" height="379" src="http://www.adopenstatic.com/images/resources/blog/kerberos3.jpg" style="width:366px;height:379px;" title="Service Principal Names (SPN)" width="366" /></p><p>SPNs can be viewed, added and removed using a GUI tool like <a href="http://technet2.microsoft.com/WindowsServer/en/Library/ebca3324-5427-471a-bc19-9aa1decd3d401033.mspx" title="Download ADSIEdit from Microsoft.com" target="_blank">ADSIEdit</a>, or you can do the same using a command line tool such as <a href="http://www.microsoft.com/downloads/details.aspx?familyid=5fd831fd-ab77-46a3-9cfe-ff01d29e5c46&amp;displaylang=en" title="Download SetSPN from Microsoft.com" target="_blank">SetSPN</a> (part of the Windows 2000 Resource Kit).</p><p><img alt="Using SetSPN" border="0" height="331" src="http://www.adopenstatic.com/images/resources/blog/kerberos4.jpg" style="width:668px;height:331px;" title="Using SetSPN" width="668" /></p><p>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.</p><p>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:</p><p>1) The missing SPN<br />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.</p><p>For example, after installing IIS, SPNs for servername and servername.domain.tld are registered under the server&#39;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.</p><p>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.</p><p>2) The duplicate SPN<br />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.</p><p>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.</p><p>3) Load-balanced IIS solutions<br />In this situation, the user&#39;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&#39;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.</p><p>4) Multiple web applications hosted at a single domain name<br />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.</p><img src="http://www.adopenstatic.com/cs/aggbug.aspx?PostID=606" width="1" height="1">IISSecurityIIS and Kerberos. Part 1 - What is Kerberos and how does it work?http://www.adopenstatic.com/cs/blogs/ken/archive/2006/10/19/512.aspxFri, 20 Oct 2006 12:01:00 GMTe0e31441-78b9-4457-b9b0-6f7906e03e71:512Ken18http://www.adopenstatic.com/cs/blogs/ken/comments/512.aspxhttp://www.adopenstatic.com/cs/blogs/ken/commentrss.aspx?PostID=512http://www.adopenstatic.com/cs/blogs/ken/rsscomments.aspx?PostID=512<p>Edit: I&#39;ve created a list of all the parts in this series <a href="http://www.adopenstatic.com/faq/" title="IIS FAQ">here</a>, which will be updated as I add more parts.&nbsp;</p><p>Configuring Kerberos and Delegation is one of the more common problems I see in the communities and even within Avanade. Since Kerberos isn&#39;t a simple topic, I&#39;m going to write a quick series explaining how Kerberos works, common scenarios and problems and some troubleshooting tips.</p><p>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.</p><p>The problem with simplistic shared secret systems is two-fold:<br />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<br />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.</p><p>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).</p><p>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&#39;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.</p><p><img alt="Simple Kerberos implementation" border="0" height="425" src="http://www.adopenstatic.com/images/resources/blog/Kerberos1.jpg" style="width:473px;height:425px;" title="Simple Kerberos implementation" width="473" /></p><p>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&#39;s password (this is why the user doesn&#39;t need to authenticate - if the user isn&#39;t who they say they are, they won&#39;t be able to decrypt the session key because they don&#39;t know the user&#39;s password). The KDC also prepares a second piece of data - it again encrypts the session key as well as the user&#39;s username (known as a Kerberos principal), but using the service&#39;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).</p><p>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&#39;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&#39;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.</p><p>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. </p><p>If an imposter sent a Service Ticket to the service (e.g. by replaying captured packets) they wouldn&#39;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.</p><p>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&#39;s password, but that isn&#39;t a particulary secure system. What Kerberos does is introduce the concept of a Ticket Granting Ticket (TGT). </p><p>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&#39;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.</p><img src="http://www.adopenstatic.com/cs/aggbug.aspx?PostID=512" width="1" height="1">IISSecurityTwo IIS patches this month - what's the risk?http://www.adopenstatic.com/cs/blogs/ken/archive/2006/07/12/Two-IIS-patches-this-month-_2D00_-what_2700_s-the-risk_3F00_.aspxWed, 12 Jul 2006 23:08:00 GMTe0e31441-78b9-4457-b9b0-6f7906e03e71:183Ken1http://www.adopenstatic.com/cs/blogs/ken/comments/183.aspxhttp://www.adopenstatic.com/cs/blogs/ken/commentrss.aspx?PostID=183http://www.adopenstatic.com/cs/blogs/ken/rsscomments.aspx?PostID=183<p style="font-family:verdana, geneva, arial;">Microsoft released two IIS-related updates in this month&#39;s batch of security patches. The first involves ASP, and the second ASP.NET. Both are listed as Important. What are the actual risks and vulnerability details though? </p><p style="font-family:verdana, geneva, arial;"><strong>ASP.NET</strong> The ASP.NET patch (<a href="http://www.microsoft.com/technet/security/bulletin/MS06-033.mspx" title="MS06-033" target="_blank">MS 06-033</a>) deal with a potential Information Disclosure risk. In ASP.NET v2 a special folder called app_data is used to hold a number of web application specific files. All files used natively by ASP.NET and Visual Studio have their extensions already mapped to the System.Web.HttpForbiddenHandler HTTP handler, and will not be served. </p><p style="font-family:verdana, geneva, arial;">However if you create a file with a custom file extension, and place it into the app_data folder, a user may be able to download this file if they know, or can guess the name. If you are using IIS 6.0, then you also have to have a MIME type defined for that custom file extension, as IIS 6.0 does not serve files with no defined MIME type. </p><p style="font-family:verdana, geneva, arial;">So you are only at risk here if you create files with custom file extensions or you have changed the default configuration of ASP.NET to allow requests to file types that ASP.NET or Visual Studio use. </p><p style="font-family:verdana, geneva, arial;">The following file types are (by default) blocked: *.asax, *.ascx, *.master, *.skin, *.browser, *.sitemap, *.config (but not *.exe.config or *.dll.config), *.cs, *.csproj, *.vb, *.vbproj, *.webinfo, *.licx, *.resx, *.resources, *.mdb, *.vjsproj, *.java, *.dd, *.jsl, *.ldb, *.ad, *.ldd, *.sd, *.cd, *.adprototype, *.lddprototype, *.sdm, *.sdmDocument, *.mdf, *.ldf, *.exclude, *.refresh </p><p style="font-family:verdana, geneva, arial;"><strong>ASP</strong> The ASP flaw (<a href="http://www.microsoft.com/technet/security/bulletin/MS06-034.mspx" title="MS06-034" target="_blank">MS06-034</a>) allows an attacker to execute code under the process identity of the process hosting the ASP page. On IIS 6.0, by default, this is Network Service. On IIS 5.0, by default, this is IWAM_. However it may be LocalSystem if you have changed the default worker process user account in IIS 6.0, or are using Low process isolation in IIS 5.0. </p><p style="font-family:verdana, geneva, arial;">However to exploit this vulnerability, an attacker must be able to get a malicious ASP page onto your server (just requesting an existing, safe, ASP page is not sufficient), and make a request to this malicious page. So, if you are a hosting company and must allow clients to upload pages to their sites, you are at risk. However if you are running a site where external users are not able to get their own ASP pages onto your server, then you do not appear to be at risk at this stage. </p><img src="http://www.adopenstatic.com/cs/aggbug.aspx?PostID=183" width="1" height="1">IISASP.NETSecurity