Intelligent Application Gateway (IAG) 2007 Goes into Data Center with Service Pack 2 (SP2) – Part 2
Here is the second part (first part is here) of how to secure access to your data center with IAG.
Implementing Data Center access with IAG
Which applications?
As a first stage, I would suggest that you route Web applications through IAG. This is where the user experience will be optimal and most protection will be provided. To do this you will need to publish these applications using the IAG Configuration console, and specify the security policies that will control access to these applications.
You don’t have to publish all Web applications at once through IAG. You can do this incrementally, starting with high business impact applications for which security is a high priority. Let other Web application and non-web traffic continue to flow directly to the application or Web server. Securing non-Web traffic requires additional considerations. The performance overhead will usually be significant, and pre-authentication of non-Web traffic requires IPSec deployment, which is fairly complex. You can read about deploying IPSec for deploying Server and Domain isolation at https://www.microsoft.com/technet/security/guidance/architectureanddesign/ipsec/.
Making clients to go through IAG instead of directly reaching applications
So how do you make clients access the applications through IAG instead of accessing them directly? There are two potential strategies you can employ:
1. If your clients access Web applications through an enterprise portal, modify portal links to the applications to point to IAG.
2. Modify your DNS infrastructure to make clients go to IAG.
Allocate two DNS names to each Web application – one internal and one public.
Change the hostname of the application to be internal DNS name, and configure this internal name on the IAG settings for the published application. For example change https://crm è https://crm-internal and https://app1 to https://app1-internal .
Now there are two ways to make public names to point to IAG –
a. Add the public DNS name (e.g. https://crm and https://app1) as an additional host name for the IAG trunk and point to the IAG IP address. This is the DNS name that users will use for quick access to the application through IAG. You will also need to include all public DNS application names on the SSL certificate used for trunk configuration, or use a wildcard certificate. This is shown in orange color on the diagram below.
b. You can use a simple single name certificate with IAG’s portal name only (e.g. https://portal) by setting up a simple Web server to act as a “redirector”. To do this register all public DNS names (e.g. https://crm and https://app1) to resolve to the redirector IP and configure it to redirect all requests to IAG portal (https://portal). This is shown in blue color in the diagram below.
IAG portal
An IAG portal organizes all applications a user is authorized to access, and helps users to discover published applications without memorizing all the links or creating individual bookmarks.
When you deploy IAG in a data center, all your local users can benefit from IAG. If your organization already has a central portal with all corporate applications, you can choose to configure it as the initial IAG application, instead of using the built-in IAG portal. If you choose this option, you can still embed the IAG built-in portal application list as a Web part inside your enterprise portal. See “How to integrate the IAG portal into SharePoint” on how to do this.
IAG and NAP
If you have deployed NAP in your environment, then how do you deploy IAG with a Data Center alongside NAP?
Firstly you need to configure DHCP in order to assign clients that do not comply with NAP policy an IP address in a remediation network. You will then need to expose IAG to the remediation subnet, so that clients located there can access it.
In this scenario, you want IAG to perform endpoint security validation of unmanaged clients, but skip this check for managed computers, as NAP will perform this function for them. This can be achieved by configuring different policies for session access and privileged endpoint policies in the Endpoint Policies section of the trunk properties.
Assign managed clients as privileged endpoints. Do not require any endpoint settings, except for some specific file, folder, registry key or machine certificate that is provisioned on all you corporate desktops, and which is used to distinguish them from unmanaged computers.
Authentication and Single-Sign-On
A design choice that you need to make is whether to authenticate the users on IAG. Pre-authenticating users on IAG prevents any unauthorized traffic from ever reaching application servers. This is an important security function during remote access. As you would like to keep user experience simpler during access of applications from local network, it is desirable that they will not need to type credentials during the access, similar how they access the applications without IAG.
There are two ways to achieve this:
- Use seamless authentication, when a browser is transparently authentications with IAG, without requiring user to enter credentials explicitly. Rest of this section will focus on how to achieve this with IAG with Integrated Windows Authentication (IWA) or Active Directory Authentication Services (ADFS) and Kerberos Constrained Delegation (KCD).
- Require no authentication on IAG, so that IAG only enforces client health, but doesn’t pre-authenticate the users. This reduces the security IAG provides, but is usable in many scenarios.
Integrated Windows authentication
The first step is configuring front-end authentication – how users are authenticated by IAG. When you want to publish applications to your internal Active Directory users, the best choice would be Integrated Windows authentication, which uses Kerberos and NTLM protocols. When IWA is used, all users from IAG Active Directory forest and any trusted Active Directory forest will be able to login to IAG without re-typing their credentials. There are few things to be remembered before you configure IWA:
· IAG server should be a member server of your Active Directory forest. If you plan also to use KCD to provide SSO to backend applications, IAG server and application server must be members of the same domain.
· If you plan to use Kerberos as part of IWA, all public trunk names must be registered as SPN of IAG server. That includes published SharePoint servers’ external names. For instance if you have a trunk with a public name www.contoso.com and you IAG server is called my-iag-server, then you must access AD account of my-iag-server and add “http/www.contoso.com” as it’s SPN.
For more details about how to plan and configure IAG to use Integrated Windows authentication you can read “About publishing applications to users located on corporate networks with IAG SP2” and “Publishing applications to users located on corporate networks with IAG SP2”
Active Directory Federation Services
While Integrated Windows Authentication is mostly suited for internal users, the solution for your extranet users is to implement ADFS authentication on IAG. You can also use ADFS when establishing two-way trust between users and IAG domain is not possible.
IAG support ADFS v1 NT-tokens mode. There are several prerequisites to remember when you plan to use ADFS authentication on IAG.
· IAG server should be domain member of Active Directory forest, where your applications (resources) are located.
· NT-tokens mode requires shadow accounts configured in resource Active Directory forest. IAG supports user-to-user and group-to-user mappings between users’ forest and resource forests.
· IAG requires that Federation Server Proxy (FS-P) will be implemented on IAG server.
For more information on implementing ADFS on IAG see - Enabling Active Directory Federation Services in IAG SP1.
If your application supports ADFS authentication, you can allow users to directly authenticate to the application using ADFS, just don’t enable authentication delegation on IAG.
If your application doesn’t support ADFS, you can use Kerberos constrained delegation, described later on, to provide Single Sign-On experience to your partners’ users. By implementing ADFS on IAG, you can provide ADFS login to applications that are not extranet ready.
Authentication delegation and Single Sign-On
The next step is to plan how users will authenticate to the applications. There are several options for you to choose, each of them have different user experience, prerequisites, pros, and cons.
Kerberos constrained delegation provides full Single Sign-On user experience and users are not required to re-type their credentials. When KCD is performed, IAG performs Kerberos authentication to the application on behalf of the user. There are several things to be remembered before enabling KCD on IAG server.
· The very trivial, but most forgotten one – application must support Kerberos authentication. Sometimes, when application states it supports Windows login, it really supports only the NTLM. A great tool to verify which authentication is supported by your web application is Wfetch.
· If your application is servers farm that uses Load Balancer or Application Delivery Controller to distribute requests between servers, you’ll have to run all instances of your application on all servers under same security identity. Otherwise Kerberos authentication will not work. This means that instead of running your application pool with “Local System” identity, you’ll have to create application user, register your application SPN for that user and reconfigure all your servers to run application with this user identity. For more information on how to configure Kerberos authentication in IIS 6.0 please read Integrated Windows Authentication (IIS 6.0).
· IAG server and application server must be members of the same Active Directory domain.
· When your users reside in separate Active Directory forest, there should be two-way trust between users Active Directory forest and application Active Directory forest.
· KCD requires Active Directory configuration changes each time you publish a new application that uses KCD. Don’t worry, IAG will help you to make the change easy and will create an LDIF script file that can be imported to your Active Directory, but you’ll need a help from someone with Active Directory administrative rights to actually import it.
All the details are available in “Configuring Kerberos constrained delegation with IAG SP2”
When implementing KCD is impossible you might want to consider implementing authentication pass-through. Since both the user and the application belong to either same or trusted Active Directory forests, we can assume that user can seamlessly login to the application directly using Integrated Windows authentication. The idea of authentication pass-through is to allow the user to authenticate directly to the application, once user authenticated to the IAG. This is possible with the NTLM protocol. So when you decide to use authentication pass-through, you’ll have to disable Kerberos in IAG trunk configuration, disable authentication delegation handling and enable authentication pass-through on IAG server.
When neither of the above options is possible to implement, you can still configure IAG authentication delegation. User will be prompted for credentials when accessing the application, but only once through the session and these credentials can be reused to all applications that share same authentication server. For instance when you publish number of SharePoint servers that use same Active Directory, user will be prompted for credentials only when accessing first SharePoint server; when subsequently accessing other SharePoint servers, IAG will reuse provided credentials on behalf of the user and provide Single Sign-On experience.
Virtualized Data Centers
Many customers are planning and deploying virtualized data centers today. If you are one of those, you can deploy IAG as a virtual machine using the pre-configured IAG SP2 VHD. See my previous blog post at https://blogs.technet.com/edgeaccessblog/archive/2008/11/26/iag-sp2-goes-virtual.aspx for more details.
Authors
John Neystadt, Architect
Eli Tovbeyn, Sr. Program Manager
Technical Reviewers
Meir Mendelovich, Sr. Program Manager
Ran Dolev, Sr. Support Engineer
Noam Ben-Yochanan, Sr. Program Manager
Oleg Ananiev, Group Program Manager