Deploying Exchange ActiveSync Certificate-Based Authentication

  • 아티클

This document is intended primarily for Information Technology (IT) professionals who must deploy and manage certificate-based client enrollment and authentication of Microsoft® Exchange ActiveSync®, which is a new feature of Windows Mobile® 5.0 Messaging and Security Feature Pack (MSFP). The Messaging and Security Feature Pack is based on mobility features that are built into Microsoft Exchange Server 2003 with Service Pack 2 (SP2).

IT professionals include IT Managers, Infrastructure Specialists, System and Solution Integrators, and Desktop and End-User Support Specialists, Database Administrators, Applications Architects, and Web Administrators.

This document is divided into two main sections that describe the following:

  • Configuring client certificate authentication on the Exchange Server 2003 SP2 front-end and mailbox servers
  • Configuring client certificate enrollment on Windows Mobile MSFP devices

Windows Mobile 5.0 Messaging and Security Feature Pack

Windows Mobile 5.0 Messaging and Security Feature Pack is a corporate mobile solution that supports the following:

  • Windows Mobile Direct Push technology   Outlook information is "pushed" from a direct connection between Exchange Server and a Windows Mobile-based device.
  • Remotely enforced IT policy   By using the Exchange Server 2003 console, IT administrators can remotely manage and enforce select corporate IT policy over-the-air.
  • Local device wipe   Mobile devices can be reset or wiped after several failed logon attempts. You can configure the number of failed logon attempts.
  • Remote device wipe   Administrators can remotely reset devices over the Internet, which resets the device to its original configuration.
  • Wireless support for contact information   Support for over-the-air lookup of global address list (GAL) information that is stored on Exchange Server.
  • Certificate-based authentication   Native support for certificate-based authentication that enables users to gain access to their corporate network without using a separate password. Corporate credentials are no longer required to be stored on the device.

What Is Exchange ActiveSync?

Exchange ActiveSync is the synchronization mechanism built into Exchange Server 2003 that enables mobiles devices, including Windows Mobile-based devices in addition to third-party mobile devices that have integrated synchronization using Exchange ActiveSync, to synchronize a user's e-mail, calendar, contact, and task information that is stored in Exchange Server.

One benefit of this technology is that there are no additional subscription fees required to take advantage of the Exchange ActiveSync functionality for the users within your organization. If you have already deployed Microsoft Office Outlook® Web Access, your Exchange front-end server is set up to handle Exchange ActiveSync requests from mobile devices.

What the IT Professional Is Required to Know

The IT professional who will be deploying client certificate authentication for Exchange ActiveSync and Windows Mobile 5.0 MSFP should have an understanding of the following:

  • Active Directory® directory service
  • Windows Server 2003 Enterprise Certification Authority
  • Internet Information Services (IIS)
  • Outlook Web Access
  • Exchange ActiveSync
  • Windows Mobile 5.0

Prerequisites

The following is required for enabling Client Certificate-base Authentication for Windows Mobile and Exchange Server 2003 SP2.

중요

There are problems when you try to run the Exchange ActiveSync Certificate-based Authentication tool in a non-English version of Windows Server 2003. For a description and a workaround, see the Microsoft Knowledge Base article 927471, "Error message when you run the Exchange ActiveSync Certificate-based Authentication tool in Windows Server 2003: The security ID Security is invalid," at https://go.microsoft.com/ f wlink/?linkid=3052&kbid=927471.

  • Windows Server 2003 (running in Windows Server 2003 Domain Functional Level)
  • Windows Server 2003 Certification Authority
  • Exchange Server 2003 SP2 (Front End and Mailbox Servers)
  • Windows XP SP2
  • Microsoft Desktop ActiveSync® version 4.1 or 4.2. Download from Add-ons for ActiveSync at https://go.microsoft.com/fwlink/?linkid=75423.
  • Windows Mobile 5.0 with Messaging and Security Feature Pack

For More Information

For in-depth technical information about topics such as certification authority (CA), Kerberos, mobile messaging, Public Key Infrastructure (PKI) technologies, Secure Sockets Layer (SSL) deployment, and other topics, see the following:

For information about ports and Desktop ActiveSync 4.1, see the Microsoft Knowledge Base article 259369, "TCP ports required by ActiveSync 4.x" at https://go.microsoft.com/fwlink/?linkid=3052&kbid=259369.

Configuration Steps

To enable Certificate-based authentication between a Windows Mobile 5.0 MSFP device and Exchange Server 2003 SP2, there are three core areas that must be configured.

  1. Configure the Exchange Server 2003 SP2 front-end server to accept Certificate-based authentication for the Exchange ActiveSync virtual directory.
  2. Configure Kerberos constrained delegation between Exchange Server 2003 SP2 front-end and back-end servers.
  3. Configure the certificate enrollment XML in Active Directory.

If you have a firewall or reverse proxy, such as an ISA server, there are additional configuration steps required.

Configuring Exchange Server 2003 Front-End Server

Exchange ActiveSync in Exchange Server 2003 SP2 relies on the built-in authentication mechanism of IIS 6.0 for both Basic and Client Certificate-based authentication.

Follow these steps to enable Client Certificate-based authentication on the Exchange Server 2003 SP2 front-end server.

  • Configure secure communications with SSL
  • Configure the Exchange ActiveSync virtual directory to accept Client Certificate-based authentication

Configure Secure Communications with SSL

Do the following to configure SSL for Exchange ActiveSync.

To configure SSL for Exchange ActiveSync

  1. In Internet Services Manager, for the default Exchange HTTP virtual server, right-click Default Web Site, and then click Properties.

  2. Click the Directory Security tab, and then select Server Certificate.

  3. Follow the instructions in the wizard, using the IIS documentation as a reference, to request and install the SSL certificate. HTTP SSL is configured individually for each virtual server or Web site. Therefore, if you create additional HTTP virtual servers in Exchange System Manager, you will need to configure SSL for each server (or Web site as it is referred to in Internet Services Manager).

  4. When the certificate is installed in Internet Services Manager, for the default Exchange HTTP virtual server, right-click Default Web Site, and then click Properties.

  5. Click the Directory Security tab, and then select Edit under Secure Communications.

  6. Select the Require secure channel (SSL) box. Select the box to Require 128-bit encryption.

  7. Click OK two times.

  8. Click OK to override any virtual directory inheritance.

  9. Repeat the procedure to force an SSL connection on the Microsoft-Server-ActiveSync virtual directory. You can do this to other Exchange service directories to also force SSL to authenticate to them. These directories include the following:

    • Exchange
    • Exchweb
    • Public
    • OMA

SSL Certificate Considerations

We recommend that you use an SSL certificate issued from a well-known Certification Authority to avoid having to install the corresponding Trusted Root Certificate on the mobile device.

Configure Certificate-Based Authentication for Exchange ActiveSync

Follow this procedure to be able to use IIS Manager to enable Client Certificate-based authentication on the Exchange ActiveSync virtual directory.

To use IIS Manager to enable Client Certificate-based authentication

  1. In IIS Manager, expand the local computer, Web sites, and Default Web site, right-click the Microsoft-Server-ActiveSync virtual directory, and then click Properties.

  2. Click the Directory Security tab.

  3. Under Secure communications, click Edit.

  4. In the Secure Communications check box, do the following:

    1. Under Client certificates, select Accept client certificates. The server requests a client certificate before it connects the user to the resource. Users who do not have a valid client certificate are denied access.
    2. Select the Enable client certificate mapping check box, and then click Edit.

  5. Click OK two times.

    참고

       This step is important because it correctly configures the certificate mapping even though no mappings are configured in this step.

  6. Right-click the Web Sites directory, and then click Properties.

  7. Click the Directory Security tab, and select the Enable the Windows directory service mapper check box.

  8. Click OK.

Configure Kerberos Constrained Delegation

You must configure Kerberos constrained delegation between the Exchange Server 2003 SP2 front-end and back-end servers.

Adding Service Principal Names

A service principal name (SPN) is the name by which a client uniquely identifies an instance of a service. The Kerberos authentication service can use an SPN to authenticate a service. For Kerberos constrained delegation to work between the ISA 2006 server and the Exchange Server front-end and back-end environment, and between the Exchange Server front-end and back-end servers, additional SPN entries are required.

Additional SPN entries can be configured by using the ADSIEdit MMC snap-in that is included in Windows Server 2003 Support Tools. To add the SPNs using ADSIEdit, follow these steps.

To add SPNs

  1. Click Start, click Run, and type ADSIEdit.msc to open the ADSIEdit console.

  2. Locate the Exchange front-end server in the Domain node of ADSIEdit.

  3. Right-click the Exchange front-end server object, and then click Properties.

  4. Locate the servicePrincipalName entry in the Attribute list and then click Edit.

  5. Enter http/<host name> and http/<friendly name> for the Exchange front-end server. For example, http/msx-fe and htttp/mail.

  6. Repeat the process using the FQDN entry for host name and friendly name.

Configure Servers to be Trusted for Delegation

For Kerberos constrained delegation to work, the Computer object entries in Active Directory must be configured to be Trusted for Delegation. The Exchange front-end server must be able to delegate Kerberos tickets to the Exchange back-end server.

참고

If your topology will include Internet Security and Acceleration (ISA) Server 2006, you will also need to configure the ISA 2006 server to be able to delegate Kerberos tickets to the Exchange front-end server.

Active Directory Users and Computers is an MMC snap-in that is a standard part of Microsoft Windows Server operating systems. However, when you install Exchange Server 2003, the Setup wizard automatically extends the functionality of Active Directory Users and Computers to include Exchange-specific tasks.

You start Active Directory Users and Computers from either an Exchange server or from a workstation that has the Exchange System Management tools installed.

참고

If the Active Directory Users and Computers snap-in is installed on a computer that does not have Exchange Server or the Exchange Server management tools installed, you cannot perform Exchange Server tasks from that computer.

The Delegation tab that is referenced in the following procedure lets you configure delegation in three ways:

  • Not allowed   Select the Do not trust this computer for delegation option.
  • Allowed for all services   Select the Trust this computer for deletion to any service (Kerberos only) option. Refers to the Windows 2000 Server delegation method.
  • Allowed for only a limited set of services   Select the Trust this computer for delegation to specified services only option. Refers to the constrained delegation method that is available with Windows Server 2003.

To use Active Directory Users and Computers to configure constrained delegation and protocol transitioning, follow these steps from the front-end server. The Exchange front-end server is required to delegate Kerberos tickets to the Exchange back-end server. Do the following to configure the Exchange front-end server delegation settings.

To configure Exchange front-end server delegation settings

  1. Open Active Directory Users and Computers and locate the ISA 2006 computer object within the organizational unit (OU) structure

  2. Right-click the Exchange front-end server object, and then click Properties.

  3. Click the Delegation tab.

  4. Check Trust this computer for delegation to specified services only, and then click Use any authentication protocol.

  5. Click Add, and then click Users or Computers.

  6. Enter the host name of the Exchange front-end server. For example, MSX-BE and then click OK to return to the Add services page.

  7. From the Available services list, select HTTP and W3SVC for the Exchange back-end server

  8. Click OK to return to the Properties page.

Configure Windows Mobile Certificate Enrollment

The section describes setting up Active Directory to be able to process client certificate enrollment requests made by Windows Mobile 5.0 MSFP devices These steps include the following:

  • Configuring Active Directory with the relevant Windows Mobile Certificate enrollment information
  • Enrolling for a new client certificate by using Desktop ActiveSync.

Overview of Certificate Enrollment Configuration

The following workflow drawing shows the end-to-end operation for getting a certificate enrolled and ready for authentication.

End_to_End_Certificate_Enrollment

There is no interactive user interface (UI) for entering information or configuration. The administrator relies on error messages and progress indicators as part of the device server synchronization certificate enrollment process.

In summary, the IT configuration steps and application actions involved in certificate enrollment are as described in the following table.

Task or activity

What occurs

Outcome

Use the certificate enrollment tool.

The administrator creates the device certificate enrollment configuration XML from the sample XML that is provided with the tool download. Then, the sample XML is uploaded to Active Directory using the Microsoft Visual Basic® Scripting Edition (VBScript) file that was provided with the tool download.

The device certificate enrollment XML that is customized for the users' IT environment is available in the correct Active Directory location. See "Uploading the XML to Active Directory," for more information.

Deploy Desktop ActiveSync 4.1 to user desktops.

Desktop ActiveSync is installed on the user's corporate computer.

The user can cradle the device, thereby connecting it to the corporate network and enabling it to perform the certificate enrollment steps noted below.

Configure device.

The device is connected through Desktop ActiveSync4.1 to the users' corporate desktop, to enroll.

The Desktop ActiveSync application downloads the configuration XML from Active Directory.

Desktop ActiveSync "pushes" the XML to the Windows-based mobile device over the USB Remote API (RAPI) connection.

During the setup of the device and desktop partnership, the user is prompted to enter his or her corporate username, password, and domain. To add these credentials to the device to enable enrollment, the Save the password check box must be selected.

Bb508836.note(ko-kr,EXCHG.65).gifNote:

After the enrollment has been attempted one time, the username, password, and domain information are purged from the memory of the device. These items are used only for one attempted enrollment.

The XML is processed into registry settings that you can use for the certificate enrollment operation.

Attempt at initial synchronization.

The device tries an initial server synchronization.

Synchronization fails.

This step occurs by design because the client tries to use Basic authentication password authentication. However, the server requires certificate authentication so it returns an HTTP 403 error to the device. The error indicates that a certificate is required for authentication.

Enroll certification.

The device initiates certificate enrollment using the saved Exchange ActiveSync username, password, and domain, combined with the certificate enrollment configuration.

A connection is made to the Windows Certificate Services Web server that is specified in the enrollment configuration.

Enrollment is processed using a Windows 2000 Server or a Windows Server 2003 certification authority (CA) that is running the Web-based enrollment feature.

Bb508836.note(ko-kr,EXCHG.65).gifNote:

If authentication fails because the password is incorrect, the user can retry, but he or she must enter the password on the device. If authentication fails because a bad username or domain was entered, the Exchange server settings on the mobile device must be deleted and then re-created.

Attempt at subsequent synchronization.

Receives the certification context from the Certificate Enrollment API. ActiveSync tries to re-authenticate to the Exchange front-end server that uses the returned certificate.

Certificate-based authentication continues to work after the certificate enrollment step has been processed.

The same process is used to enroll for a new certificate if the certificate is deleted or expires.

System Requirements for the Certificate Enrollment Tool

The following operating system and applications are required for the correct operation of the tool.

  • Windows 2000 Server SP4 or later versions or Window Server 2003 SP1 (recommended)
  • Microsoft Exchange Server 2003 Service Pack 2
  • Messaging and Security Feature Pack for Windows Mobile 5.0
  • Active Directory
  • Internet Information Services (IIS)
  • Microsoft Desktop ActiveSync 4.1 or a later version. Download from Windows Mobile Downloads and Programs at https://go.microsoft.com/fwlink/?linkid=37727
  • Windows certification authority (CA) running the Web-based enrollment feature

Downloading the Certificate Enrollment Tool

The Exchange ActiveSync Certificate-based Authentication tool can be downloaded from the Tools for Exchange Server 2003 Web site at https://go.microsoft.com/fwlink/?linkid=55032, and consists of a folder that contains the following items:

  • EASAuthUploadXMLtoAD.vbs   The VBScript file that uploads the XML configuration file to Active Directory.
  • EASCertAuthSampleXML.xml   The sample XML configuration file.
  • Software license terms.rtf   Microsoft Software License Terms.
  • Cert_based_Auth.doc   The user documentation (this file) for the tool.
  • RapiConfig.exe   A desktop configuration tool that enables the execution of provisioning XML on a Windows Mobile-based device or an emulator that is connected by using Exchange ActiveSync.
  • QryCertReg.xml   The XML file that is used as a parameter in RapiConfig.exe that indicates whether the mobile device is getting the configuration from Active Directory.

Configuring the Enrollment XML

For certificate enrollment deployment to continue, pre-configuration must be completed. The administrator must create the device certificate enrollment configuration XML, make changes as required, and upload it to Active Directory. The configuration XML includes:

  • Certification authority (CA) server name
  • Certificate template that will be used
  • Other settings, such as custom Web enrollment URLs

The following is a commented sample of the XML that is changed and then uploaded using the Active Directory VBScript. Sample XML is included in the tool download to help with making changes.

<wap-provisioningdoc>
  <characteristic type="Registry">
    <characteristic type="HKCU\Software\Microsoft\CertEnroll\ServerDef">
  <parm name="PrimaryServer" value="http://priserverdef" datatype="string"/>
  <parm name="SecondaryServer" value="http://secserverdef"  datatype="string"/>
  </characteristic>

<!-- COMMENT: In the above settings, edit only the name of the primary Windows 2000 Server or Windows Server 2003 certificate server, http://PrimaryDefaultCAServerName, and the name of the backup or secondary server, http://SecondaryDefaultCAServerName. The Windows Mobile-based device tries to enroll against the primary, and it falls back to the secondary server if it fails. The primary server name is required, and the secondary server name is optional. -->

<characteristic type="HKCU\Software\Microsoft\CertEnroll\DomainMapping\<domain name here>">
<parm name="PrimaryServer" value="http://priserver" datatype="string" /> 
<parm name="SecondaryServer" value="http://secserver" datatype="string" /> 
</characterstic>

<!-- COMMENT: You will use the above settings only if your environment has more than one PKI that it can be enrolled against. If not, delete this whole characteristic. In the above settings, edit only the name of a domain (MappedDomainName) and the associated primary/secondary servers (http://MappedDomainPrimary/CAServerName) for that domain. This configuration is optional. However, if used, both the domain name and the primary CA server name are required, and the secondary CA server name is optional. When configured, certificate enrollment will try to match the domain name used for authentication of the certificate enrollment to any domain mapped in this configuration section. If the domain is found, the certificate enroller uses the configured CA server name for the connection. This is useful when there is more than one forest or PKI that a user may have to enroll against. -->

<characteristic type="HKCU\Software\Microsoft\CertEnroll">
<parm name="Template" value="user" datatype="string" />

<!--COMMENT: The template parameter is a required setting. Change the name of the template to one that is available on Windows 2000 Server and Windows Server 2003 certification authority (CA). In this sample XML, it is set to user. It is recommended that you use the "user" template because it is the default template that is available on Windows Certificate Services. -->

<parm name="CertPickupPage" value="/certsrv/certnew.cer" datatype="string" />

<!--COMMENT: Do not change the CertPickupPage parameters unless you have decided to change the default path of the Windows Certificate Services Web-based enrollment pages on the Web server. These are the default settings-->

<parm name="CertReqPage" value="/certsrv/certfnsh.asp" datatype="string" />

<!--COMMENT: Do not change the CertReqPage parameters unless you have decided to change the default path of the Windows Certificate Services Web-based enrollment pages on the Web server. These are the default settings.-->

    </characteristic>
  </characteristic>
</wap-provisioningdoc>

Changing the Enrollment XML

Information about what should be considered for change is included in the following table. Be aware that each domain has a primary server and a secondary server for fallback. Every deployment must configure the primary and secondary servers for the serverdef characteristic.

Use Characteristic or Parameter Comments

Required

PrimaryServer

This setting is the name of the default primary certification authority server. This includes the https schema that will be used.

Optional

SecondaryServer

This setting is the name of the default backup certification authority server that will be used.

Optional

Template*

Name of the certificate template that is targeted for enrollment, and the Windows certification authority setting that specifies attributes for a specific certificate type. Select a template from your created templates that suits your requirements for certificate enrollment. The default is ClientAuth.

Optional

DomainMapping

Used only when domain mapping is used. Domain mapping allows the CA name to be mapped to a domain name that is used during user authentication. You can have 0 or more domain mappings. If you are using domain mapping, put your domain name here and make sure that you include a primary server and a secondary server for each domain name that is mapped. You can have multiple domain names entered here. If the domain used in the logon is not listed as a mapped domain, the code reverts to the PrimaryServer and SecondaryServer entries.

Optional

CertPickupPage and

Used only when the path/name for the Web-based enrollment pages has been changed. The default for CertPickupPage is /certsrv/certnew.cer.

Optional

CertReqPage

Used only when the path/name for the Web-based enrollment pages has been changed. The default for CertReqPage is /certsrv/certfnsh.asp.

*The template that is used must be one that is configured to create the enrolled certificate's properties from information in the authenticating user's Active Directory user object. To make sure that the selected template can be used, follow these steps.

  1. Open the MMS snap-in Certificate Templates on the certification authority (CA).
  2. Click Subject Name in the Properties of the selected certificate template.
  3. Under Source of subject name, make sure that Built from information in Active Directory is selected.

By default, the built-in user certificate template includes this required configuration.

Uploading the Enrollment XML to Active Directory

The VBScript file performs several actions on a computer that is physically connected to the network that hosts the target Active Directory forest, and has a domain administrator logged on. In addition, the following procedure works only with Windows Server 2003 Active Directory. The script to upload the completed XML to Active Directory is run from a command line.

To upload the XML to Active Directory

  1. Click Start, click Run, type cmd to open a command prompt, and then click OK.

  2. Type the following command, where file.xml is the name of the customized XML file:

    EASAuthUploadXMLtoAD.vbs file.xml

When the XML has been applied, changes are made in the registry by the device configuration manager.

The XML is stored in Active Directory within the URL property of the Outlook Mobile Access container (msExchOmaConfigurationContainer), in the following path, and available through Active Directory Service Interfaces (ADSI).

  DC=DC Name (for example, DomainController1), ADSIEdit will default to the currently connected domain controller

  DC=Domain Name (for example, corp),

  DC=Forest (for example, Microsoft),

  DC=com,

  CN=Global Settings,

  CN=First Organization, This value can vary across deployments. To discover which value is First Organization, enumerate all the children of the Microsoft Exchange object and look for the child that has the msExchOrganizationContainer in the objectClass attribute of its properties.

  CN=Microsoft Exchange,

  CN=Services,

  CN=Configuration,

  CN=Outlook Mobile Access,

The string is identifiable at the start and end as follows:

<CertEnrollXML><wap-provisioningdoc>

...more XML here…

</characteristic></characteristic></wap-provisioningdoc>

The script sets parameters on this location so that authenticated users in the domain can read and download the string to be able to configure the clients.

Enrolling for Client Certificate using Desktop ActiveSync

This step describes how to test the enrollment process. Also, this step will be used by the end-users to enroll for their own client certificates.

After you change the XML and upload it to Active Directory using the VBScript, you must test to ensure that the XML works correctly.

To perform the enrollment process

  1. Log on to a Desktop ActiveSync desktop that is logged on to a domain in the forest where the XML was published.

  2. Connect the mobile device to a desktop using Desktop ActiveSync.

  3. Step through the Desktop ActiveSync New Partnership wizard after you connect the device to the desktop for the first time. Desktop ActiveSync New Partnership wizard is the setup wizard that becomes active on the desktop when a new, unknown device connects for the first time. Enter settings in the wizard as you would if you were using a password to authenticate to the server. Enter the name of the Exchange front-end server, the username, password, and domain. Select the Save password check box, which is enabled so the password can be used one time to enroll for a certificate before it is deleted from the device. If the device fails the authentication to the server, follow the testing steps.

To test the enrollment process

  1. Copy RapiConfig.exe to a directory on the desktop.

  2. Determine whether the certificate is enrolled successfully as follows:

    • In the Microsoft ActiveSync dialog box, click Tools, click Advanced Tools, and then click Get Device Certificates.
    • Verify that the certificate has been enrolled in the Personal store. If the certificate is there, the enrollment was successful, and you can continue to do server or network troubleshooting. If the enrollment was not successful, continue to the next step.

  3. Determine whether the enrollment settings were successfully added to the registry on the device as follows:

    • Click Start, click Run, type cmd to open a command prompt, and then click OK.
    • At the command prompt, type the path of RapiConfig.exe on the desktop using QryCertReg.xml as the parameter: rapiconfig /P /M QryCertReg.xml

A file that is named RapiConfigOut.xml is produced in the same directory where RapiConfig.exe is located. When you examine RapiConfigOut.xml, you can see whether Desktop ActiveSync published the certificate enrollment configuration to the mobile device. If it did not, RapiConfigOut will look like this:

<wap-provisioningdoc>
  <characteristic type="Registry">
    <nocharacteristic type="HKCU\Software\Microsoft\CertEnroll"/>
  </characteristic>
</wap-provisioningdoc>

Possible causes of a failure include the following.

  • The desktop does not have access or permissions to the correct object attribute in Active Directory. Try to access the location using ADSIEdit or Lightweight Directory Access Protocol (LDAP) from the same desktop by using the same user logon.
  • The desktop did not download the settings from Active Directory before mobile device enrollment was attempted. If your device did not synchronize because it did not have a certificate, it signals the desktop on the next connection to download the enrollment settings. Therefore, try to synchronize from the device, and then cradle the device again to Desktop ActiveSync.

If the enrollment configuration has been correctly propagated, you will see the custom settings configured in the XML.

Certificate-based Authentication Error Codes Returned by Windows Mobile

The following table shows the error messages returned to the mobile device.

Error Message Body of Error Message Cause HResult

E_ACTIVESYNC_GETCERT

The Exchange Server requires certificates to log on. Connect your device to your PC on the corporate network to obtain a certificate.

This error is returned when you try to synchronize against a server that requires certificate authentication and you do not have a client certificate on your device.

(HRESULT)0x85030027

E_ACTIVESYNC_ENROLLER_BAD_CERT

Cannot obtain a valid certificate. To try again, please disconnect and reconnect your device to a PC on the corporate network. If this problem persists, please contact your administrator.

This error is returned when the client certificate you used to authenticate with the server is malformed.

(HRESULT)0x85030028

E_ACTIVESYNC_EXPIRED_CLIENT_CERT

The certificate that is required to sync with Exchange Server has expired. To obtain a new certificate, connect your device to your PC on the corporate network.

This error is returned when the client certificate you used to authenticate with the server has expired.

(HRESULT)0x85030029

E_ACTIVESYNC_CERT_AUTH_FAILURE

Could not authenticate using a valid client certificate. To obtain a new client certificate and retry again, please disconnect and reconnect your device to a PC on the corporate network. If this problem persists, please contact your administrator.

This error is returned when the device cannot authenticate to the server by using a client certificate issued by the certification authority.

(HRESULT)0x8503002A

Configuring the Firewall for Certificate-based Authentication

ISA Server 2006 has a new feature that can end the SSL connection from the mobile device, authenticate a client connection, and then use Kerberos constrained delegation to the Exchange Server 2003 SP2 front-end server. This is an improvement because traffic can be inspected at ISA and then passed to the Exchange 2003 front-end server for processing. Earlier versions of ISA Server required that SSL tunneling be set up. This made it necessary for the Exchange back-end server to end the SSL connection, authenticate the user, and process the request.

[Topic Last Modified: 01/08/2007]