Microsoft Forefront Unified Access Gateway Product Team Blog : ActiveSync

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

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