Microsoft Forefront Unified Access Gateway Product Team Blog : Intelligent Application Gateway

New White Paper: Implementing an ADFS Solution for Microsoft Dynamics CRM by Using Intelligent Application Gateway (IAG)

edgeaccessblog — Mon, 20 Jul 2009 20:31:59 GMT

Even though we are focused on UAG these days, we and our partners still promote IAG and add more content for our community. Here is a blog cross-post from the CRM team blog on enabling ADFS for CRM using IAG. Most of the content of this paper is also true for UAG and for other applications like SharePoint.

By default, an on-premise implementation of Microsoft Dynamics CRM 4.0 leverages Active Directory (Integrated Windows) Authentication to accommodate access by internal users. However, many businesses also require the ability to provide external users with access to the highly sensitive information that is stored in the CRM system and to accommodate this access without having to create Active Directory trusts.

Because providing external access to internal CRM resources can also introduce potential security risks from both external and internal sources, in these scenarios, the CRM implementation must be protected by a gateway, such as Intelligent Application Gateway (IAG) 2007, which is sensitive to application logic and data and can ensure that internal and external users perform their routine tasks in a secure manner.

By using a combination of IAG and Active Directory Federation Services (ADFS) to establish an authentication gateway, companies can provide access to CRM resources by any identity, from any organization and from any computer, complete with strong authentication and full Single Sign On from the end user to the internal CRM system with a full audit trail (including username and source IP).

The white paper Implementing an ADFS Solution for Microsoft Dynamics CRM by Using Intelligent Application Gateway (IAG), recently released by the MS CRM Engineering for Enterprise (E2) team, provides high-level guidance on using IAG to implement an ADFS solution for Microsoft Dynamics CRM 4.0. Developed in collaboration with the IAG team in Israel and the CRM Product team in Redmond, the document is available on Microsoft Downloads at:
https://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=47ee7f73-6059-4b20-a305-1b8b2b23f0e9

Cheers,

Jim Toland

CRM Engineering For Enterprise

After installing IAG 2007 SP2 - Mobile Devices can no longer synchronize through IAG

edgeaccessblog — Thu, 15 Jan 2009 19:57:00 GMT

With the release of IAG 2007 SP2 (although this behavior can happen with any new update), we have been receiving some support calls about this subject and we want to bring some awareness about this behavior. Last year we published two posts about Active Sync configuration on IAG 2007:

http://blogs.technet.com/edgeaccessblog/archive/2008/07/24/publishing-microsoft-activesync-through-iag-2007-part-1-of-2.aspx

http://blogs.technet.com/edgeaccessblog/archive/2008/07/29/publishing-microsoft-activesync-through-iag-2007-part-2-of-2.aspx

When you use Part 1 of this article you will notice that step 9 advises to make a modification to the file \Whale-Com\e-Gap\von\InternalSite\ActiveSyncLogin.asp in order to enter the authentication repository. This works, but there is a caveat that wasn’t mentioned in the original post. The caveat is that changes made to IAG’s default ASP/INC/etc. files could be overwritten when software updates are applied to IAG. So the question now is: what should I do?

There are some others approaches to achieve this task and here are the options that you have:

Method A) Add a custom “.inc” file in the CustomUpdate Folder

· How:

1. Create a file named [TrunkName](0|1)ActiveSyncLoginStart.inc in ..\Whale-Com\e-Gap\von\InternalSite\inc\CustomUpdate\

2. Within this file add the following content:

<% 'This file defines the repository that is used for ActiveSync for this trunk.

repository = “[RepositoryName]”

· Pros: easy to customize, flexible and update independent, will be backed up with an IAG backup.

· Cons: in comparison to the other methods, this requires an .inc file to be created for each trunk that runs ActiveSync and the file name needs to match the trunk name.

Method B) Create an ActiveSync specific repository that matches the domain name.

· Pros: Works out of the box. There will be no need to edit or maintain custom files and it will be backed up with an IAG backup.

· Cons: creates limitation in naming convention of repository.

Method C) Create a CustomUpdate ActiveSyncLogin.asp

· How:

1. Copy ActiveSyncLogin.asp from ..\Whale-Com\e-Gap\von\InternalSite to ..\Whale-Com\e-Gap\von\InternalSite\CustomUpdate

2. Modify the version in the CustomUpdate directory

3. Open the Advanced Configuration for the ActiveSync trunk

4. Select the Authentication Tab

5. Change the Login Page from ActiveSyncLogin.asp to /CustomUpdate/ActiveSyncLogin.asp

6. Change the On-the-Fly Login Page from ActiveSyncLogin.asp to /CustomUpdate/ActiveSyncLogin.asp

· Pros: Very advanced option that is not recommended unless major parts of ActiveSyncLogin.asp are to be re-written and designed to persist on software updates, will be backed up an the IAG backup

· Cons: Updates to IAG that change ActiveSyncLogin.asp will not be applied to the custom file any changes to the default file will have to be monitored and merged into the custom file manually after every update.

Now you just need to plan which option best fits with your needs and start deploying it.

Authors

Yuri Diogenes

Security Support Engineer – ISA/IAG Team

Microsoft – Texas

Dan Herzog

Security Support Engineer – IAG Team

Microsoft – Washington

Tech Reviewers

Ran Dolev

Security Consultant – IAG Team

Microsoft – Israel

Ophir Polotsky

Forefront Edge Supportability Program Manager

Microsoft – Israel

John Redding

Security Support Engineer – IAG Team

Microsoft - Washington

IAG SP2 – It is all about the application

edgeaccessblog — Sun, 02 Nov 2008 17:12:00 GMT

When Microsoft acquired Whale Communications about 2 years ago, there was a big question of how will Microsoft change the future of the access industry. As remote access was mainly a networking solution delivered by the networking vendors, the entrance of Microsoft into this game was sure to change the perception and the rules of this industry.

Today, I would like to call out your attention to a new Service Pack 2, which will be announced this week at Tech-Ed EMEA (Barcelona, Nov 3-7). In releasing IAG Service Pack 2, Microsoft is making the first step in a multi-year roadmap to deliver on the promise of seamless anywhere access, transforming it into a trivial task for any user, anytime and anywhere.

IAG SP2 centers around three core themes: virtualization, interoperability and application intelligence.

Virtualization:

Adding to the existing physical appliance offerings by our OEM partners, IAG SP2 will introduce the option of running as a virtual machine on Hyper-V Server 2008 or Windows Server 2008 with Hyper-V. This option enables customers to deploy the IAG solution in a flexible, secure, and low-TCO manner - important benefits as organizations seek more and more ways to cut costs. It opens new horizons for IAG in the modern corporate environment.

Interoperability:

With productivity as a main goal, and the ability to access from anywhere one of its core staples, IAG needs to extend beyond the managed- and Microsoft-oriented environments of Windows and Internet Explorer. Therefore, IAG SP2 introduces enhanced support for non-Microsoft environments such as Linux, Mac and Firefox.

Application Intelligence:

IAG SP2 continues to deliver on the promise of granular application control. It incorporates the previously released SharePoint alternate access mapping (AAM) publishing, and adds support for several applications, most notably Dynamics CRM Web access and Office Communicator Web Access.

I am very excited about the coming release. This is a major step for IAG in re-defining the remote access market. Watch this space… In the next few weeks, as we near the release of IAG SP2, we will add posts that highlight some of the individual solutions and improvements.

Several members of the senior staff will also be present in Tech-Ed Barcelona this week to give a few sessions, demos, and of course to meet many of you in the community. We hope to see you there.

Assaf Ronen

IAG/UAG Product Unit Manager

Publishing SharePoint with IAG 2007 – Part 3: SharePoint Topologies

edgeaccessblog — Mon, 13 Oct 2008 22:05:00 GMT

In this post I will review several SharePoint topologies and discuss how they influence IAG and AAM settings. For each topology I’ll explain the considerations and provide sample configurations. For complete step-by-step configuration guide, please use this TechNet article.

These topologies are simplification of much more complexed SharePoint topologies that are detailed in this SharePoint article along with IAG network location related to the SharePoint machines.

Publishing a SharePoint Web application – HTTP internal

This is the baseline topology for SharePoint publishing and it is the most common one. In this topology several SharePoint applications may be published from a single IAG trunk, and each application has a unique server and port. It is assumed that HTTPS is used externally outside the corporate network, and HTTP is used within the corporate network.

In order to publish SharePoint in this topology, the applications should be defined on the IAG trunk with a proper public host name, and a new AAM zone should be defined on the SharePoint server to support the external address.

HRPortal Application Settings

Web Server Address: HRPortal

Web Server Port: 80 (HTTP)

Public Host Name: HRPortal.contoso.com

Replace Host Header: Empty

Example for a configuration of such topology:

Semantics for all the drawings:

Grayed – Default configuration that should not be added or changed by the admin

Bold – Configuration that is unique to this topology or requires special attention

Publishing a SharePoint Web application – HTTPS internal

This topology is almost identical to the baseline. The only difference is that HTTPS is used both in the corporate network as well as over the Internet.

Publishing multiple SharePoint Web applications

This topology is also similar to the baseline. The only difference is that one of the applications is published on a non-default port. In this case the port number should be defined in the IAG application, and embedded in the URLs of the AAM zone.

Publishing multiple SharePoint Web applications on a single port

This topology assumes that there are several SharePoint Web applications published on the same port. In this case, the SharePoint server differentiates between the applications using the host header in the HTTP request.

In this topology, IAG is published in a similar manner to the baseline topology. But, there is one thing that is important to remember - when configuring the Web server address in IAG, it is important to put the SharePoint WebApp address (“HRPortal” and “Teams” in this example) rather than the actual SharePoint machine name or IP address so in every IAG application there is a unique Web server address.

Publishing a SharePoint Web application when using identical internal and public addresses

This topology refers to organizations that use the same URL for internal and external access to SharePoint (and usually with other applications), but use HTTP for internal traffic and HTTPS for external traffic. If HTTPS is used both internally and externally no additional configuration is required. In fact, in this case no AAM configuration should be made.

When publishing SharePoint in this topology, IAG has to “signal” to SharePoint that this request has to be replied to with HTTPS links rather than HTTP links. This “signal” is passed by replacing the host header with a bogus host header that is configured in one of the AAM zones.

Publishing a single SharePoint Web application via multiple IAG trunks

In this topology two IAG trunks are publishing the same SharePoint Web applications. Hence the same SharePoint Web application has two different external addresses.

In order to do this, two different AAM zones should be defined on the SharePoint server with two different external URLs.

Publishing SharePoint with IAG 2007 – Part 2: Common Questions

edgeaccessblog — Mon, 13 Oct 2008 21:44:00 GMT

Hi,

SharePoint publishing with IAG is a very popular scenario. Here is a list of common SharePoint publishing questions and issues I was frequently asked about during the last months:

· I can’t edit SharePoint datasheets / explorer view / other SharePoint functionality when it is published by IAG.

You have to install IAG 2007 SP1 update 2 or above on your IAG server. This update will also be incorporated into IAG 2007 SP2.

· I installed IAG 2007 update 2 and it still has the old limitations

Just installing the update is not enough. By default, after the update installation, existing SharePoint applications use the “backward compatibility” template to ensure that we don’t break anything until AAM is configured. After configuring the SharePoint server’s AAM settings, updating the trunk’s SSL certificate, and registering the new entry in DNS, you should remove from your portal trunk the old SharePoint application and publish it again by using the new template.

· Does such an update exist for the e-Gap v3.6 appliance?

Yes, e-Gap 3.6 update 2 has almost the same functionality as IAG 2007 SP1 update 2. Look here for more details.

· I see no difference between the “old” and the “new” templates

The two templates look almost the same. The main difference is two new fields in the Web Servers tab (highlighted in the screenshot):

· Public host name – Defines the external domain name that would be used for publishing this SharePoint application. See here which domains could be selected.

· Replace host header – Used for advanced scenarios as will be explained in part 3 of this blog post.

· Do I need a new SSL certificate?

An IAG trunk with a SharePoint application that is published using AAM has new external domains. These domains should be covered by the trunk’s SSL certificate. See this TechNet article about which type of SSL certificates should be used.

· Can I publish SharePoint without AAM?

Yes. If there are problems with getting certificates or DNS registration for the new domain names you can still use the “Backward Compatibility” template, though you should expect some SharePoint functionality will not work.

· Can I access the new SharePoint domains directly without going through the portal?

Yes! When publishing SharePoint by using the new application template and leveraging AAM, the SharePoint domains (e.g. HRPortal.contoso.com) can be accessed directly without going first via the portal. In this case IAG will prompt the user for login and then, after successful authentication, return the user to the requested page. IAG will present the trunk’s customized version of the login pages, so no special customization is required.

· If I start a session with one of the SharePoint domains, can I continue to other applications without logging in again?

Yes! You can start a session by accessing directly one of the SharePoint servers (e.g. “https://HRPortal.contoso.com/site1”) and then follow a link to another application that is published via the same IAG trunk without logging in again. The IAG single sign-on (SSO) experience still works.

· What additional functionality is provided by the IAG SharePoint application template?

As with the other application templates, the IAG SharePoint application template allows the administrator to enable or disable the following SharePoint functionality based on the health of client endpoints:

· Uploading, checking in files, and saving files from Microsoft Office applications

· Downloading files, exporting to a spreadsheet, or editing datasheets

· Access to sensitive areas of the application

· Access from the SharePoint Web application to third-party applications

How IAG 2007 Can Mitigate Against SQL Injection Attacks – Demo Scenario

edgeaccessblog — Fri, 19 Sep 2008 21:34:00 GMT

1. Introduction

SQL Injection is a potential threat to any web application that has an SQL based database backend. This is true not just for Microsoft SQL backend but any web application on any OS with an SQL database backend. There are lots of applications and application developers that didn’t or still don’t follow guidelines designed to mitigate or avoid this type of vulnerability. The questions that keep coming to the Forefront Edge Security Team about this is: can we mitigate this threat anyway at the edge before the injection reaches the SQL database? IAG 2007 can help you on that. With IAG 2007 administrations can specify the allowed parameters and return values from each field in the application that interacts with SQL and therefore mitigate possible SQL Injection attacks.

It is very important to realize that ideally this mitigation should be done in the source code of the web application, rather than by using a device on the edge, as this is more of a bandage than a fix. This is because the application will still be vulnerable to attacks originating from the internal network and not passing the edge, as well as also not being protected against the possibility of administrators having missed some mitigation on the edge device which could have been done better in the application code. The bottom line is don’t use the edge as your ultimate protection mechanism for this type of attack.

Before we move on to the sample implementation, it is recommended that you review the following articles that provide details about SQL Injections and the ways to mitigate the problem in applications:

MSRC’s advisory, includes links to tools for developers and IT professionals

http://www.microsoft.com/technet/security/advisory/954462.mspx

Covers the ins-and-outs of the mass SQL attacks

http://blogs.technet.com/swi/archive/2008/05/29/sql-injection-attack.aspx

Covers how to use parameterized queries in classic ASP

http://msdn.microsoft.com/en-us/library/cc676512.aspx

Additional examples of parameterized queries

http://blogs.technet.com/neilcar/archive/2008/05/21/sql-injection-mitigation-using-parameterized-queries.aspx

http://blogs.technet.com/neilcar/archive/2008/05/23/sql-injection-mitigation-using-parameterized-queries-part-2-types-and-recordsets.aspx

2. Weak Application Code – Sample

For this example we are going to use Nazim’s (from IIS Team) SQL Injection Demo code that he wrote for his blog. Nazim provides a very interesting example of how you can easily create weak code and what can happen when you do this.

3. Configuring IAG to publish the Web Application and inspect the traffic

The first step is to publish the web application:

· Follow Nazim’s blog to create the database and the asp code

· Create a website in IIS (it works perfectly with IIS 6)

· Add the two pages to the new website and put the web server behind IAG.

· Create a portal trunk in IAG

· Add a Generic Web Application to the newly created portal trunk

· Set the Application Type to SQL

· Follow the wizard to point the application to the web server & site you created with Nazim’s code

· Configure the Portal Link to have something like the following URL:

Figure 1 – Portal Link URL for this example.

After completing the configuration of the Web Application in IAG, follow the steps below to configure the URL Set that will block the SQL Injection attempts:

1. Select the Portal Trunk that you created the web application on.

2. Click the configuration button next to Advanced Trunk Configuration.

3. Click on the URL Set tab.

4. Look for the rule name that starts with the Application Type of your application. Look for this rule in the Name field (for this example the application type is SQL ) and click on it.

5. Change the Parameters column from Ignore to Handle

6. Make sure that the methods are set to be POST and GET.

7. Change the Parameter List according to the Figure 2:

Figure 2 – URL Set configuration.

Here is the real deal of this implementation: you need to know the application that you are publishing and know exactly what the parameters are, in order to make this configuration. By parameters, we refer to both query string parameters as well as to POST-ed form fields sent from the client as HTTP data. IAG collects both of these and then analyses them, one by one, against the specific rules configured. For this example the following fields were used:

Name

Name Type

Value

Length

Existence

Name of the parameter. This can be specified as the real parameter, as it appears in HTTP requests, or as a regular expression

The type of the parameter’s Name field.

· String: The parameter name is the real parameter, as it appears in HTTP requests

· Regular expression: this can be used in order to create one single definition that matches multiple parameters

The valid characters that can this parameter’s value can hold. Here you will type values using Regular Expression that can cover the valid strings that this field should accept. You have the option to leave this field empty, in which case the Value requirement is not enforced by IAG, but still other requirements, like Length and Existence, are enforced.

Length of this parameter. This field accepts a range. For example:

· 4:10: means four to ten chars in length are allowed

· 4:4: means only exactly four chars in length are allowed

Possible values:

· Mandatory: parameter must exist in the request

· Optional: parameter may or may not exist

· Reject: HTTP request will be rejected if this parameter appears in it

1. After making the above changes, click OK.

2. Click Activate to apply the changes.

Now that IAG is configured and ready, it’s time to test the examples from Nazim’s SQL Injection Demo blog post.

First example will be:

· Test 1 - Bypassing login for a known user. Let's say we know user 'Yuri' exists and using the '--' for commenting out the rest of the conditions in the query:

o Username: Yuri'--

o Password: nothing

IAG will intercept the traffic and it will display an error.

Figure 3 – Error that the user receives when clicking on Submit.

Going to IAG 2007 Web Monitor we have the following event:

Figure 4 – Parameter that was flagged as invalid.

If we try example 4 from Nazim’s SQL Injection Demo blog post we will have:

· Test 4 - Injecting a new user. Let's say I want to add a user 'Hijack' with password 'This'.:

o Username: ';INSERT INTO Users VALUES (100,'Hijack','This')--

o Password: nothing

When user tries to do that the following warning will appear in the IAG Web Monitor and the user will receive the same error as in Figure 5.

Figure 5 – Another attempt to exploit the application by inserting a new user.

4. Conclusion

This post gives you an overview on how IAG can be used to help mitigate SQL Injection attacks coming from external users against applications that are published through an IAG Portal. As explained above, while this is a good step, this is not the definitive answer for fixing SQL Injection problems in your environment. This does go a long way in preventing a problem, but the root cause is unchanged and until it’s resolved and the application is written securely, the potential for problems will continue to exist.

Author

Yuri Diogenes

Security Support Engineer – ISA/IAG Team

Microsoft – Texas

Technical Reviewer
Dan Herzog

Security Support Engineer – IAG Team

Microsoft – Washington

Ran Dolev
Security Consultant – IAG Team
Microsoft – Israel

ISA 2006 SP1 and IAG 2007 Supportability Statement

edgeaccessblog — Thu, 18 Sep 2008 22:02:00 GMT

Introduction

Occasionally you find the combination of two things that result in something better than the sum of the individual parts. Some combinations that come to mind are peanut butter and chocolate, steak and lobster, and ISA Server 2006 and IAG 2007. You can’t eat ISA and IAG but combined in the IAG 2007 product they create an awesome SSLVPN with rich features. Just like a good soup, IAG 2007 benefits from high quality ingredients. For more information on this “better together” approach review the articles below:

http://www.microsoft.com/forefront/edgesecurity/iag/en/us/secure-remote-access.aspx

http://www.microsoft.com/Forefront/edgesecurity/iag/en/us/faq.aspx

Real World Experience

Recently, I began seeing questions about the addition of ISA 2006 SP1 on customers IAG 2007 systems. After some research it turned out that Windows update was detecting the lack of ISA 2006 SP1 and prompting administrators to install the service pack on their IAG 2007 servers. If you are familiar with IAG 2007 predecessor eGap 3.6 you will remember that the internal server was protected by a SCSI interface that shuttled between the external and internal servers. In IAG 2007 the external server and SCSI interconnect have been removed and replaced by ISA 2006. In this configuration ISA 2006 protects the external interface of IAG 2007 amongst other things.

Since SP1 for ISA 2006 includes feature updates as well as security updates, just like any other windows application it is essential to make sure there is no security vulnerability that might affect the ISA application. Hence it is important to make sure the ISA server is also updated from time to time.

When you first initialize the IAG 2007 system you will notice that ISA server 2006 is installed as well. As applications are added to the portal trunk, rules are created in ISA 2006 to allow the specific traffic types that IAG 2007 will publish. If IAG 2007 is configured for automatic updates or you visit the Windows update site, SP1 for ISA 2006 will be queued for installation if it is not already installed. You can review the benefits of SP1 for ISA 2006 by following this link: http://blogs.technet.com/isablog/archive/2008/05/23/isa-server-2006-service-pack-1-features.aspx

As you can see from reading the list we fixed a few things in ISA 2006 with SP1. In addition, patch management is part of the Desktop, Device, and Server security process best practices that IT professionals should be following. Recently, while testing IAG 2007 SP2 our product group tested with ISA 2006 SP1 installed and found no issues related to this service pack. So go ahead and add ISA 2006 SP1 to your IAG 2007 system. I bet you will find it’s a great combination and is a high quality ingredient in your security soup.

Author

Dan Watson

Security Support Engineer –IAG Team

Microsoft – NC

Technical Reviewers
Yuri Diogenes

Security Support Engineer – ISA/IAG Team

Microsoft – Texas

Mohit Saxena

Security Technical Lead – ISA/IAG Team

Microsoft – Washington

Certificates on IAG 2007

edgeaccessblog — Wed, 17 Sep 2008 03:08:00 GMT

1. Introduction

The use of Digital Certificates with IAG 2007 is essential for several IAG authentication and access scenarios as well as for providing encryption of sensitive data. There are two main scenarios when using certificates; it is common to have misunderstandings about which scenarios each type of certificates are used. The first article of this series will give you an overview of the different types and usages of each certificate when you are using IAG 2007.

2. When does IAG use Certificates?

The diagram below shows the various scenarios where IAG uses certificates for authentication and/or data encryption:

Figure 1 – IAG SSL Communication

This diagram shows the two parts of the communication when IAG 2007 is used to allow external access to internal resources. The main purpose here is to define which type of certificates are involved when each communication happening, therefore let’s see the following table:

Communication Channel	Certificate Type	Certificate Usability	Where the Certificate is Installed
Client to Server	Client Authentication	· Client authentication · Endpoint Detection	Client workstation
Server to Client	Server Authentication	· Regular Publishing Scenarios · Network Connector · IAG Portal	IAG Server
Server to Server	Server Authentication	· Encrypted connection to protocol transaction, such as LDAPs and HTTPs	Application Server (Web Server) or in the Authenticator (Domain Controller for instance)

3. Client Certificate Authentication with IAG

The previous table summarizes the scenarios where a certificate is used, but how really IAG authenticates the user when using client certificate? IAG certificate authentication works in four main phases:

1) Certificate is checked in IIS against CRL to make sure it is not revoked

2) Certificate validity is checked to make sure it’s not expired (cert.asp)

3) Two pieces of data are collected from the cert the “username” and the “email address” (cert.asp)

4) The directory service choose in the authentication repository is queried using the “username” and then if a match is found is that user is queried for the “email” parameter ([repositoryname].inc.) The email parameter retrieved from the directory is compared to the value retrieved from the certificate([trunkname]1validate.inc). If any of the 4 checks or subset of the checks fail or do not match the user is not authenticated.

It is important to remember that the IAG certificate authentication mechanisms are provided as samples. These samples are intended to be re-written or modified to match the requirements each particular customer has. Customer PKI schema vary so significantly customer to customer that it’s not possible to have a default configuration that knows how to deal with even most cases.

There were some cases where the DN used as the Certificate SubjectCN, in this case our sample would properly pick up that object and use it for authentication. However there are other cases the certificate does not contain DN or UPN but contains some other collection of objects we can use to write a custom ADSI query to AD to look up the user’s DN. The framework provided is very flexible and customizable and is designed to allow as many cases as possible.

4. What comes next?

This post gives you an overview of how IAG uses certificate and starts to introduce client certificate mechanism. The coming articles will cover:

· Certificate Authentication with and without Kerberos

· Implementing Client Certificate Authentication

· Understanding IAG’s “Certified Endpoint” feature

· Understanding Endpoint Detection of Client Certificates

Stay tuned.

Authors

Yuri Diogenes

Security Support Engineer – ISA/IAG Team

Microsoft – Texas

Dan Herzog

Security Support Engineer – IAG Team

Microsoft – Washington

Publishing Microsoft ActiveSync through IAG 2007 – Part 2 of 2

edgeaccessblog — Tue, 29 Jul 2008 16:40:00 GMT

1. Introduction

We published the first part of this article, which had step by step details of how to configure Microsoft ActiveSync through IAG 2007. In this second part, we will cover troubleshooting the most common issues that we’ve encountered while publishing ActiveSync through IAG 2007.

2. Gathering Data

One of the most important areas that you need to be aware of in troubleshooting ActiveSync, is what data you need to collect. As a rule of thumb the following logs should be enabled for this scenario:

2.1. IAG Trace logs

Follow the steps below to enable this log:

1. Browse to C:\Whale-Com\e-Gap\von\InternalSite\inc\trace.inc

2. Modify trace_on = false to trace_on = true and save the file

3. Browse to C:\Whale-Com\e-Gap\common\conf\trace.ini

4. Go to the last line of the file and add the following lines:

[Trace\WhlFilter]

*=xheavy

[Trace\UserMgrCom]

*=xheavy

5. Save the file

Tracing will now start for both WhlFilter and UserMgrCom,. These logs will be located in \whale-com\e-gap\logs and should be named *.usermgrcom*.log and *.whlfilter.*.log

2.2. Filter log

Follow the steps below to enable this log:

1. Run regedit

2. Browse to HKEY_LOCAL_MACHINE\SOFTWARE\WhaleCom\e-Gap\von\UrlFilter

3. Locate the LogFlag DWORD

4. Modify the value from HEX 0 to HEX 4

In about 30 seconds logging will start and the log will be located in \whale-com\e-gap\von\conf\websites\[TrunkName]\Logs\*WhlFilter.log

Note: These logs are very verbose and fill up disk space quickly. Therefore enable these logs only for troubleshooting purposes. After you’re done gathering the data you need, it is strongly recommended to disable all of them.

3. Troubleshooting Scenarios

The environment used for this troubleshooting guide is the following one:

Figure 1 – Basic diagram.

3.1. After completing the IAG configuration by following part 1, I’m getting an error when I try to synchronize my mobile device. I enabled the logs but there is nothing in there.

If this is the first attempt to synchronize after enabling the ActiveSync Trunk and the logs are empty, most likely you are running into a certificate issue. If you enable Netmon trace on the external NIC of the IAG server you will notice the following:

TCP Handshake on port 443

192.168.0.185 192.168.0.181 TCP TCP:Flags=......S., SrcPort=1032, DstPort=HTTPS(443), PayloadLen=0, Seq=337408, Ack=0, Win=32768 (scale factor 0) = 32768

192.168.0.181 192.168.0.185 TCP TCP:Flags=...A..S., SrcPort=HTTPS(443), DstPort=1032, PayloadLen=0, Seq=2541104422, Ack=337409, Win=16384 (scale factor 0) = 16384

192.168.0.185 192.168.0.181 TCP TCP:Flags=...A...., SrcPort=1032, DstPort=HTTPS(443), PayloadLen=0, Seq=337409, Ack=2541104423, Win=33580 (scale factor 0) = 33580

SSL Handshake

192.168.0.185 192.168.0.181 SSL SSL: Client Hello.

192.168.0.181 192.168.0.185 SSL SSL: Server Hello. Certificate. Server Hello Done.v

- Ssl: Server Hello. Certificate. Server Hello Done.

- TlsRecordLayer:

ContentType: HandShake

- Version: TLS 1.0

Major: 3 (0x3)

Minor: 1 (0x1)

Length: 1426 (0x592)

- SSLHandshake: SSL HandShake TLS 1.0 Server Hello Done(0x0E)

HandShakeType: ServerHello(0x02)

Length: 70 (0x46)

+ ServerHello: 0x1

HandShakeType: Certificate(0x0B)

Length: 1344 (0x540)

- Cert: 0x1

CertOffset: 1341 (0x53D)

- Certificates:

CertificateLength: 1338 (0x53A)

- X509Cert: Issuer: Denver CA,contoso,com, Subject: *.contoso.com

+ SequenceHeader:

- TbsCertificate: Issuer: Denver CA,contoso,com, Subject: *.contoso.com

+ SequenceHeader:

+ Tag0:

+ Version: v3 (2)

+ SerialNumber: 0x612021a7000000000007

+ Signature: Sha1WithRSAEncryption (1.2.840.113549.1.1.5)

+ Issuer: Denver CA,contoso,com

+ Validity: From: 09/26/06 22:45:52 UTC To: 10/10/10 09:18:23 UTC

+ Subject: *.contoso.com

+ SubjectPublicKeyInfo: RsaEncryption (1.2.840.113549.1.1.1)

+ Tag3:

+ Extensions:

+ SignatureAlgorithm: Sha1WithRSAEncryption (1.2.840.113549.1.1.5)

+ Signature:

HandShakeType: Server Hello Done(0x0E)

Length: 0 (0x0)

192.168.0.185 192.168.0.181 SSL SSL: Client Key Exchange. Change Cipher Spec. Encrypted Handshake Message.

192.168.0.181 192.168.0.185 SSL SSL: Change Cipher Spec. Encrypted Handshake Message.

192.168.0.185 192.168.0.181 TCP TCP:Flags=...A...F, SrcPort=1032, DstPort=HTTPS(443), PayloadLen=0, Seq=337659, Ack=2541105897, Win=33580 (scale factor 0) = 33580

What happen here is that the *.contoso.com certificate was issued by a CA (the Denver machine) that the client (Windows Mobile) does not trust. To fix this problem follow the instructions from KB915840 to add the root CA certificate to your mobile device.

3.2. I have added the root CA certificate to my mobile device and I was able to connect and synchronize just fine. However, after working for a while, I’m now getting the message below when I try to synchronize:

Figure 2 – Error trying to synchronize

This is a very generic error, so the best approach here is to get a Netmon trace, but this time on the internal interface of the IAG server. Gather also the logs that were enabled in session 1. Let’s see the result:

From UserMgrCom log:

Authentication Request

** 25.07.08 10:05:52.257 USERMGR_SERVICE:GENERAL T5900

AuthenticateUser got [CAuthenticateUserIn:

m_repository = [AD]

m_user = [administrator]

m_password = [**Confidential**]

m_domain = [contoso]

m_param_vec = <EmptyField>

m_site_name = [activesynctrunk]

m_secure = [1]

m_session_id = [22B36058-D0B7-4A6E-A8A6-EDD7DF35E325]

m_login_type = [2]

m_source_ip = [192.168.0.183]

]

* at line 334, file "src/UserMgrCore.cpp".

** 25.07.08 10:05:52.257 CONFIGMGR_SERVICE:GENERAL T5900

Get the site [activesynctrunk] secure [1] info.

* at line 555, file "src/SiteContainer.cpp".

Authentication Succeed:

** 25.07.08 10:05:52.267 USERMGR_SERVICE:GENERAL T5900

Authenticate the user [administrator] domain [contoso] in the ldap server [10.1.1.6] port [389] dn [CN=Users,DC=contoso,DC=com] type [Active Directory]

* at line 320, file "src/Ldap.cpp".

** 25.07.08 10:05:52.267 USERMGR_SERVICE:GENERAL T5900

Connect user [administrator] domain [contoso].

* at line 2178, file "src/Ldap.cpp".

** 25.07.08 10:05:52.267 USERMGR_SERVICE:GENERAL T5900

Connect with bind auth negotiate.

* at line 2209, file "src/Ldap.cpp".

** 25.07.08 10:05:52.288 USERMGR_SERVICE:GENERAL T5900

Connect success

After authentication, IAG needs to contact the Exchange Server to access the ActiveSync URL. At this point, IAG attempts to resolve the name of the Exchange server, as specified in step 6 of the previous article. If the name cannot be resolved the connection will fail, as seen below:

10.1.1.5 10.1.1.6 DNS DNS:QueryId = 0x8442, QUERY (Standard query), Query for mail.contoso.com of type Host Addr on class Internet

10.1.1.6 10.1.1.5 DNS DNS:QueryId = 0x8442, QUERY (Standard query), Response - Name Error

To fix this problem enable the IAG server to resolve the name that appears in step 6 of the previous article. After fixing this problem, you should see the following traffic on the internal network:

10.1.1.5 10.1.1.6 DNS DNS:QueryId = 0x234E, QUERY (Standard query), Query for mail.contoso.com of type Host Addr on class Internet

10.1.1.6 10.1.1.5 DNS DNS:QueryId = 0x234E, QUERY (Standard query), Response - Success, 49, 0

10.1.1.5 10.1.1.6 TCP TCP:Flags=......S., SrcPort=1718, DstPort=HTTP(80), PayloadLen=0, Seq=1407512359, Ack=0, Win=32768 (scale factor 0) = 32768

10.1.1.6 10.1.1.5 TCP TCP:Flags=...A..S., SrcPort=HTTP(80), DstPort=1718, PayloadLen=0, Seq=2078452756, Ack=1407512360, Win=16384 (scale factor 0) = 16384

10.1.1.5 10.1.1.6 TCP TCP:Flags=...A...., SrcPort=1718, DstPort=HTTP(80), PayloadLen=0, Seq=1407512360, Ack=2078452757, Win=32768 (scale factor 0) = 32768

10.1.1.5 10.1.1.6 HTTP HTTP:Request, POST /Microsoft-Server-ActiveSync

10.1.1.6 10.1.1.5 HTTP HTTP:Response, HTTP/1.1, Status Code = 401, URL: /Microsoft-Server-ActiveSync

10.1.1.6 10.1.1.5 TCP TCP:[Continuation to #48]Flags=...AP..., SrcPort=HTTP(80), DstPort=1718, PayloadLen=409, Seq=2078454217 - 2078454626, Ack=1407512979, Win=64916 (scale factor 0) = 64916

10.1.1.5 10.1.1.6 HTTP HTTP:HTTP Payload, URL: /Microsoft-Server-ActiveSync

10.1.1.6 10.1.1.5 TCP TCP:Flags=...A...., SrcPort=HTTP(80), DstPort=1718, PayloadLen=0, Seq=2078454626, Ack=1407512992, Win=64903 (scale factor 0) = 64903

10.1.1.5 10.1.1.6 HTTP HTTP:Request, POST /Microsoft-Server-ActiveSync

10.1.1.6 10.1.1.5 HTTP HTTP:Response, HTTP/1.1, Status Code = 100, URL: /Microsoft-Server-ActiveSync

5. Conclusion

This troubleshooting guide covers two common problems that might arise when configuring a Microsoft ActiveSync Trunk on IAG 2007. Although this article does not cover all possible issues and resolutions, it should give you a good overview of the troubleshooting steps, and the approach to gather and analyze data for ActiveSync publishing through IAG 2007.

Authors

Yuri Diogenes

Security Support Engineer – ISA/IAG Team

Microsoft – Texas

Dan Herzog

Security Support Engineer – IAG Team

Microsoft – Washington

Technical Reviewer

Ran Dolev

Security Consultant – IAG Team

Microsoft – Israel

Publishing Microsoft ActiveSync through IAG 2007 – Part 1 of 2

edgeaccessblog — Thu, 24 Jul 2008 04:04:00 GMT

1. Introduction

Publishing Microsoft ActiveSync through IAG 2007 in theory is pretty straight forward. When I say in theory it is because just following the wizard steps may not be enough. There are some scenarios that require you to make customizations to the configuration after finishing execution of the wizard.

This post will be divided in two parts as follow:

· Part 1: Will explain how to create a Microsoft ActiveSync Trunk and how to customize authentication. We will also use the Windows Mobile 6.1 Professional Emulator to simulate the external Mobile device.

· Part 2: Will explore the most common issues with IAG and ActiveSync, and how to troubleshoot them.

2. Scenario

For the purpose of this guide, IAG 2007 is a standalone server, the mobile device is a Windows Mobile 6.1 device, and the Domain Controller is running Exchange 2007 with active sync enabled for all users.

3. Configuring the ActiveSync Trunk

Open the IAG 2007 Configuration Console and follow the steps below:

1) On the main menu, expand HTTPS Connections, right click on it and choose New Trunk. Select Webmail Trunk as show below:

Figure 1 – Selecting the trunk type.

2) Click Next and choose the option Microsoft ActiveSync as show below:

Figure 2 – Choosing the Webmail trunk type.

3) Click Next and type the trunk name, the external IP and the ports that this trunk will listen on, as showed below:

Figure 3 – Trunk information.

4) Click Next and in the “Step 4 Authentication” window you will select the authentication repository. For the purpose of this demo we are using a repository named “AD” which is an Active Directory repository. To select the repository click the Add button and select your repository from the list. There is no need to adjust any of the remaining settings and you can leave the options at their defaults, click Next.

Figure 4 – Selecting the authentication repository.

5) In the next window you should select the certificate that will be used for this trunk. For this demo we are going to use the wildcard certificate *.contoso.com as show below:

Figure 5 – Certificate selection.

6) Click Next and now you need to type the information about your Exchange Server. The IP address, port number and the hostname are all required. After finishing that click Next to continue.

Figure 6 – Certificate selection.

Note: For this purpose of this demo we are going to use HTTP (port 80) to communicate with the Exchange Server, this is to facilitate the troubleshooting we will do in Part 2.

7) Again, you will need to specify which authentication repository you will use so IAG can auto reply to authentication requests that Exchange might send out. We must select the same authentication repository we set earlier to allow the system to negotiate authentication without having to prompt you again for authentication. Click Next.

Figure 7 – Authentication repository for auto reply.

8) Click Next, leave the default endpoint policy selected and then click in Finish to conclude the wizard.

Figure 8 – Endpoint policy Selection.

9) Since the repository name (AD) is not the same as the domain name (CONTOSO) we need to edit the file \Whale-Com\e-Gap\von\InternalSite\ActiveSyncLogin.asp and change the line below:

Figure 9 – Customizing the activesynclogin.asp file.

10) After changing that, save the file and close it.

11) In the IAG Configuration Click in File and Activate (or CTRL + G), type your passphrase if it is requested.

12) Click Activate and OK.

4. Testing the Access

Now that this feature is enabled on the IAG, let’s see how it will be presented to the final user. As mentioned before we are going to use the Windows Mobile 6.1 Emulator to simulate the external Mobile device. The exact image that is going to be used in this demo is called Windows Mobile 6 Professional. Here are some briefings about this tool:

- Make sure to bind the application to the network where you are testing access from. Refer to the article Establish Network Connectivity on the Emulator from Microsoft TechNet for more information on this.

- Use the Windows Mobile 6 Emulator help file to configure the IP address, name resolution and Exchange Connectivity. You also can use the tips from this blog post to configure the device.

- To get more experience with this tool you also can practice using the TechNet Virtual Labs for Windows Mobile with Exchange 2007.

After configuring the Windows Mobile Emulator client to access the trunk in Active Sync you can try to synchronize. After synchronize you should see the Windows Mobile window showing the user’s inbox as show the example below:

Figure 10 – Windows Mobile Emulator.

5. Conclusion

In the first part of this guide we saw how to create the trunk and use the Windows Mobile Emulator to synchronize from the outside network. The next part of the guide we will explore the most common issues with IAG and ActiveSync and how to troubleshoot them.

Stay tune.

Authors

Yuri Diogenes

Security Support Engineer – ISA/IAG Team

Microsoft – TX

Dan Herzog

Security Support Engineer – IAG Team

Microsoft – WA

Walk-through for RSA SecurID Authentication for IAG 2007 – Part 2 of 2

edgeaccessblog — Wed, 23 Jul 2008 03:27:00 GMT

Last post we reviewed the RSA Agent configuration, now we are going to cover the IAG.

IAG 2007 Configuration

• Install the RSA Authentication Agent on the IAG server.

• IAG 2007 uses the RSA supplied authentication agent to communicate with and verify credentials against, the RSA Authentication Manager. The RSA Authentication Agent is typically supplied with your RSA software package. It is also available directly from RSA.

• NOTE: The installation of the RSA Authentication Agent on the IAG server will update the GINA on the server. However, you can still provide AD credentials when logging in to the IAG 2007 server.

• Test authentication and create the Node Secret

• After installing the RSA Authentication Agent, and rebooting the server, launch the RSA Security Center application on the IAG server. In RSA Security Center, select ‘Authentication Test’ and click the ‘Test’ button. In the Authenticator drop-down list, select ‘Key fob, standard card, PINPad. For User name, enter a user name that has been created on the RSA Authentication Manager. For Passcode, enter the Passcode shown on the token that is currently associated with the user name entered.

This test will:

1. Verify the connection between the IAG server and the RSA Authentication Manger

2. Verify that the credentials and Passcode supplied are valid

3. Establish the Node Secret between the IAG server and the RSA Authentication Manager. The established Node Secret is stored in the registry on the IAG server.

Figure 1

• Configure RSA SecurID authentication on the IAG server

• In the IAG Configuration application, under HTTPS Connections, select the relative Portal/Trunk. Under the ‘Security & Networking’ section, click Configure next to ‘Advanced Trunk Configuration’.

• In the Advanced Trunk Configuration dialog, select the Authentication tab and click ‘Add’. In the ‘Authentication and User/Group Servers dialog, click ‘Add’.

• In the ‘Add Server’ dialog, select ‘ACE’ in the Type drop-down list. Enter a name to represent this authentication server (i.e. SecurID). Enter the IP address of the RSA Authentication Manager server. The default port for SecurID authentication is 5500. If the RSA Authentication Manager has been configured with an alternate/non-default port, enter the port number here. Click OK. Activate the Configuration.

Figure 2

• The Portal login page will now have the SecurID authentication type available. Note that if you have configured multiple Authentication servers in your Portal, when logging into the Portal, you will need to make sure you select the RSA SecurID authentication type from the available choices in the ‘Directory’ drop-down list.

Figure 3

Author

Richard Barker

Security Support Engineer – ISA/IAG Team

Microsoft – NC

Publishing Windows 2008 Terminal Services Farm (session broker) behind IAG 2007

edgeaccessblog — Tue, 22 Jul 2008 17:08:00 GMT

The Terminal Server Session Broker Load Balancing feature allows to evenly distribute the session load between servers in a load-balanced terminal server farm. With TS Session Broker Load Balancing, new user sessions are redirected to the terminal server with the fewest sessions.

Using TS Session Broker to load balance sessions involves two phases:

1. In the first phase, initial connections are distributed by a preliminary load-balancing mechanism, such as Domain Name System (DNS) round robin. After a user authenticates, the terminal server that accepted the initial connection queries the TS Session Broker server to determine where to redirect the user.

2. In the second phase, the terminal server where the initial connection was made redirects the user to the terminal server that was specified by TS Session Broker. The redirection behaviour is as follows:

•	A user with an existing session will connect to the terminal server where their session exists.
•	A user without an existing session will connect to the terminal server that has the fewest sessions.

For more details on Session broker please refer to the following TechNet article:

http://technet2.microsoft.com/windowsserver2008/en/library/902a6081-9ecd-45ec-96ee-f51097d71c8c1033.mspx?mfr=true

Publishing Terminal Server farm using Windows 2008 Session Broker server behind IAG 2007 appears to be a challenge. You would be essentially publishing it as one of the Terminal Services application over an HTTP/S Trunk. The problem is when you publish the session broker server via IAG assuming that DNS Round Robin configured for load balancing will enable session broker to distribute the terminal session to the backend farm effectively it will not work for end user connecting through IAG to this farm.

IAG is aware of only one published Terminal Server – the Session Broker – and will therefore route terminal service requests from end users only to this server. What Session Broker does for load balancing at the backend is that it redirects sessions to another terminal server in the farm, and this is essentially a new session request from IAG perspective each time.

When, after being load balanced, this traffic is sent from the client back through IAG towards another terminal server in the farm, IAG will not treat this as a valid request since in the IAG configuration the Terminal Services application exposes only the Session Broker server. With this configuration when a client connects via IAG server to a Session Broker managed farm, the client gets an error message saying “the client cannot connect to the remote computer”, as no handling is performed by the IAG SSL VPN components on the client side in order to intercept RDP traffic to this other terminal server.

To solve this problem we have to consider using Socket Forwarder and publishing the entire Terminal Server farm and not only the Session Broker server.

Here is the step by step configuration:

1. Publish the Terminal Server application for the entire farm by specifying all the terminal servers IP addresses (single/ranges/subnets) and hostnames (all listed manually or by using wildcards).

2. Set one Terminal Server as the jump-start and set it as a lead server.

3. The MSTSC.exe client will connect initially to that server, but if the TS session broker will "redirect" to another terminal server in the farm (either by its name or its IP address) the Socket Forwarding component will intercept and route that RDP traffic to the appropriate server seamlessly.

4. Without Socket Forwarder installed, only the first server on the list is supported.

Author: Faisal Hussain

Developer Support - Security

UK GTSC Developer Internet Team