Microsoft Forefront Unified Access Gateway Product Team Blog : Datacenter Deployments

Intelligent Application Gateway (IAG) 2007 Goes into Data Center with Service Pack 2 (SP2) – Part 2

edgeaccessblog — Thu, 08 Jan 2009 18:47:00 GMT

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 http://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 http://crm è http://crm-internal and http://app1 to http://app1-internal .

Now there are two ways to make public names to point to IAG –

a. Add the public DNS name (e.g. http://crm and http://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. http://portal) by setting up a simple Web server to act as a “redirector”. To do this register all public DNS names (e.g. http://crm and http://app1) to resolve to the redirector IP and configure it to redirect all requests to IAG portal (http://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 http://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

Intelligent Application Gateway (IAG) 2007 Goes into Data Center with Service Pack 2 (SP2) – Part 1

edgeaccessblog — Tue, 23 Dec 2008 17:46:00 GMT

John Neystadt is here again. Today I am blogging first part of an overview of how to protect Data Center applications with IAG. Hope you are enjoying the holidays. I will blog second part after they are over.

Changing threats blur the difference between remote and local access

For many years network and security departments engineered their networks around the concept of physical security. Establish a security perimeter; guard physical access to a building with human guards and badges; guard network perimeters with an access gateway using strong user authentication; verify endpoint compliance with a security policy that enables restricted access to corporate applications, knowing that when users connect remotely threats are greater than when they connect locally.

However, mobility and increased outsourcing have changed the threat landscape for local access. There are a number of questions that many security departments ask themselves today:

· How do I know who connects to my Wi-Fi network from the parking lot or lobby?

· How do I control which applications can be accessed from mobile phones?

· Do I trust on-site vendors to the same degree as employees?

· How do I mitigate the risk from guests’ unmanaged laptops that are allowed to access my business applications?

· How do I enable and secure access to my data center for clients that are not controlled by my IT department. For example:

o My company has recently merged with or acquired a company that uses a different desktop security standard.

o My company has outsourced desktop management and I can’t control what is installed on desktops.

o My IT environment is loosely coupled as is my organization (this is common for government, educational, and many other organizations). I am in control of the data center only, but not of the clients.

· How do I enforce compliance for all above scenarios, and be able to monitor and audit all these activities?

If you are asking yourself one or more of these questions, than perhaps you are ready for reperimeterization - and IAG 2007 SP2 can help you.

Reperimeterization and the changing role of perimeter security

The idea behind reperimeterization (also known as deperimeterization) is simple. Let’s separate data centers and clients, and route all access to corporate applications through a data center gateway which provides the same level of security as that which we enforce for remote access.

What am I gaining from such a configuration?

1. I can provides users coming from different domains or partners with a great seamless single sign-on experience, without requiring them to explicitly enter credentials when accessing Web applications. This can be done using a combination of either Integrated Windows Authentication (IWA) or Active Directory Federation Services (ADFS), and Kerberos Constrained Delegation (KCD) authentication delegation.

2. I can implement granular access control, based on the endpoint security state of the client (For example, is the endpoint patched? Is it running an antivirus with recent signatures? Is an anti-malware application turned on?). You might ask what the difference is between IAG and NAP endpoint policies. NAP is a great and simple way to enforce and automatically remediate endpoint compliance for environments that have standardized on a single desktop standard, as NAP expects a specific anti-virus or anti-malware to be present. NAP is binary about client compliance. If a client doesn’t comply with NAP, then the client is restricted to the remediation network. You certainly should use NAP for managed client computers. However, when dealing with loosely coupled environments or “unmanaged” computers - when you don’t control the clients and can’t enforce a uniform standard - you need a technology that enables “unmanaged” Windows, Linux and Mac clients to access a restricted set of applications while enforcing policies such as “must have any anti-virus” or “must have any anti-malware software installed”. In addition NAP supports Windows XP SP3 and newer client operating systems, and you can NAP for these client endpoints, in combination with IAG endpoint security to secure Windows 2000 and pre-Windows XP SP3 clients.

3. I can monitor and log all application access using the IAG Web Monitor.