Comments on: Preparing the ISA Server 2006 for Kerberos Constrained Delegation http://blogs.isaserver.org/pouseele/2006/11/16/preparing-the-isa-server-2006-for-kerberos-constrained-delegation/ Stefaan Pouseele, an ISA Server MVP, discusses issues brought up within various ISA articles and Microsoft publications. Updates to the ISA Firewall, protocol support, discussions on the different ISA clients, ISA features, how to clean up network traffic and links to new ISA server literature are all be included within the blog. Get help on troubleshooting the ISA network firewall and learn how to create good security policies. Coverage on ISA Server 2006 also appears. Thu, 28 Aug 2008 05:24:52 +0000 http://wordpress.org/?v=MU by: Nelson Puello http://blogs.isaserver.org/pouseele/2006/11/16/preparing-the-isa-server-2006-for-kerberos-constrained-delegation/#comment-11576 Fri, 07 Sep 2007 11:45:07 +0000 http://blogs.isaserver.org/pouseele/2006/11/16/preparing-the-isa-server-2006-for-kerberos-constrained-delegation/#comment-11576 Stefaan, You should point out in your article that IIS on an Exchange Server computer runs under the Network Service account, which is basically the computer account. Because of this the SPN on the ISA server should specify the host name, and not the website. However, when you're dealing with websites that have different host headers and are running in application pools that have different service accounts, then you must set the SPN to point to the appropriate website name and the SPN for that website must be registered to the appropriate service account. The point of an SPN is to help the KDC find which account a service is running under. Thanks. Stefaan,

You should point out in your article that IIS on an Exchange Server computer runs under the Network Service account, which is basically the computer account. Because of this the SPN on the ISA server should specify the host name, and not the website. However, when you’re dealing with websites that have different host headers and are running in application pools that have different service accounts, then you must set the SPN to point to the appropriate website name and the SPN for that website must be registered to the appropriate service account. The point of an SPN is to help the KDC find which account a service is running under. Thanks.

]]> by: Thomas Shinder Blog » Blog Archive » How to Enable Integrated Authentication for Outlook RPC/HTTP Clients to Prevent Authentication Prompts with 2006 ISA Firewalls http://blogs.isaserver.org/pouseele/2006/11/16/preparing-the-isa-server-2006-for-kerberos-constrained-delegation/#comment-11564 Thu, 06 Sep 2007 11:22:05 +0000 http://blogs.isaserver.org/pouseele/2006/11/16/preparing-the-isa-server-2006-for-kerberos-constrained-delegation/#comment-11564 [...] http://blogs.isaserver.org/pouseele/2006/11/16/pre...ation/ [...] […] http://blogs.isaserver.org/pouseele/2006/11/16/pre...ation/ […]

]]> by: Stefaan Pouseele Blog » Blog Archive » Playing with Radius Authentication and ISA Server 2006 http://blogs.isaserver.org/pouseele/2006/11/16/preparing-the-isa-server-2006-for-kerberos-constrained-delegation/#comment-3173 Tue, 26 Dec 2006 16:50:40 +0000 http://blogs.isaserver.org/pouseele/2006/11/16/preparing-the-isa-server-2006-for-kerberos-constrained-delegation/#comment-3173 [...] One of my primary objectives is to find out what the limitations are when we would require the use of two-factor authentication such as Safeword, Vasco or other hardware tokens. By using two-factor authentication we are hoping to avoid that users have to enter domain credentials on non-trusted, read unmanaged, computers. Another objective is that by no means should there be a special software agent required on the clients or the servers to make it work. Otherwise that would defeat the anywhere access goal. In other words, only the ISA server should be aware of the use of the Radius OTP service. This implies that the Radius OTP service doesn’t need to be capable to authenticate the users against the internal domain but instead that the ISA server should use Kerberos constrained delegation to authenticate the users against the published service. Note: most Radius OTP services have a component that integrates with Active Directory. However, that doesn’t mean the users are authenticated against the internal domain. That integration is very often done to avoid the complexity of synchronizing the Radius OTP and the Active Directory users. In other words, the Active Directory user names are used and the OTP parameters are just extra attributes of those users. [...] […] One of my primary objectives is to find out what the limitations are when we would require the use of two-factor authentication such as Safeword, Vasco or other hardware tokens. By using two-factor authentication we are hoping to avoid that users have to enter domain credentials on non-trusted, read unmanaged, computers. Another objective is that by no means should there be a special software agent required on the clients or the servers to make it work. Otherwise that would defeat the anywhere access goal. In other words, only the ISA server should be aware of the use of the Radius OTP service. This implies that the Radius OTP service doesn’t need to be capable to authenticate the users against the internal domain but instead that the ISA server should use Kerberos constrained delegation to authenticate the users against the published service. Note: most Radius OTP services have a component that integrates with Active Directory. However, that doesn’t mean the users are authenticated against the internal domain. That integration is very often done to avoid the complexity of synchronizing the Radius OTP and the Active Directory users. In other words, the Active Directory user names are used and the OTP parameters are just extra attributes of those users. […]

]]>