By
default, ActiveSync is configured to use Integrated Windows
authentication. This form of authentication works fine if access to the
server is over a trusted internal network, but is not feasible for
access over the Internet, which is where most mobile devices originate
from.
Because of this limitation, a
form of authentication that can be sent across the Internet must be
used. This effectively limits the ActiveSync server to using Basic
authentication, which is supported by most web browsers and devices. The
problem with Basic authentication, however, is that the username and
password that the user sends is effectively sent in clear text, and can
be intercepted and stolen in transit. In addition, mail messages and
other confidential information are transmitted in clear text, which is a
huge security issue.
The solution to this
problem is to use what is known as Secure Sockets Layer (SSL) encryption
on the traffic. SSL encryption is performed using Public Key
Infrastructure (PKI) certificates, which work through the principle of
shared-key encryption. PKI SSL certificates are widely used on the
Internet today, any website starting with an https:// uses them, and the
entire online merchant community is dependent upon the security of the
system.
For ActiveSync, the key
is to install a certificate on the server so that the traffic between
the device and the server is protected from prying eyes. There are
effectively two options to this approach, as follows:
Use a third-party certificate authority—
A common option for many organizations is to purchase a certificate for
ActiveSync (and other Exchange HTTP access methods such as OWA) from a
third-party trusted certificate authority (CA), such as VeriSign,
Thawte, or others. These CAs are already trusted by a vast number of
devices, so no additional configuration is required. The downside to
this option is that the certificates must be purchased and the
organization doesn’t have as much flexibility to change certificate
options.
Install and use your own certificate authority—
Another common approach is to install and configure Windows Server
2003/2008 Certificate Services to create your own CA within an
organization. This gives you the flexibility to create new certificates,
revoke existing ones, and not have to pay immediate costs. The downside
to this approach is that no browsers or mobile devices will recognize
the CA, and error messages to that effect will be encountered on the
devices unless the certificates are trusted.
Each of these options is outlined in the subsequent sections of this chapter.
Installing a Third-Party CA on a CAS
If a third-party
certificate authority will be used to enable SSL on a server with the
CAS role, a certificate request must first be generated directly from
the CAS. After this request has been generated, it can be sent to the
third-party CA, who will then verify the identity of the organization
and send it back, where it can be installed on the server.
When deciding which CA to
use, keep in mind that Windows Mobile devices automatically trust the
certificate authorities of the following organizations:
If an internal CA will
be utilized, this section and its procedures can be skipped, and you
can proceed directly to the subsequent section titled “Using an Internal Certificate Authority for OWA Certificates.”
To generate an SSL
certificate request for use with a third-party CA, you can create a
certificate from the Exchange Management Shell using the
New-ExchangeCertificate applet, or you can create the request directly
from IIS. For optimal flexibility, use the PowerShell applet because it
enables you to create multiple Subject Alternative Name (SAN) entries in
the certificate, enabling the Exchange server to impersonate multiple
FQDNs, such as mail.companyabc.com, autodiscover.companyabc.com,
activesync.companyabc.com, and so on.
After the certificate request has been generated, the text file, which will look similar to the one shown in Figure 1,
can then be emailed or otherwise transmitted to the certificate
authority via their individual process. Each CA has a different
procedure, and the exact steps need to follow the individual CA’s
process. After an organization’s identity has been proven by the CA,
they will send back the server certificate, typically in the form of a
file, or as part of the body of an email message.
The certificate then needs to be installed on the server itself. If it was sent in the form of a .cer
file, it can simply be imported via the process described next. If it
was included in the body of an email, the certificate itself needs to be
cut and pasted into a text editor such as Notepad and saved as a .cer file. After the .cer file has been obtained, it can be installed on the CAS using the Import-ExchangeCertificate applet.
Using an Internal Certificate Authority for OWA Certificates
If a third-party
certificate authority is not utilized, an internal CA can be set up
instead. There are several different CA options, including several
third-party products, and it might be beneficial to take advantage of an
existing internal CA. Windows Server 2008 also has a very functional CA
solution built into the product, and one can be installed into an
organization.
Caution
Proper design of a
secure PKI is a complex subject, and organizations might want to spend a
good amount of time examining the many factors that can influence CA
design. This sample scenario assumes a very basic design, with an
enterprise CA installed directly into a domain. Most enterprise CAs want
to consider a stand-alone root CA and a second or even third tier of
intermediate and issuing enterprise CAs, depending on the organization.
The following types of CAs are available for installation:
Enterprise Root CA—
An enterprise root CA is the highest level CA for an organization. By
default, all members of the forest where it is installed trust it, which
can make it a convenient mechanism for securing OWA or other services
within a domain environment. Unless an existing enterprise root CA is in
place, this is the typical choice for a homegrown CA solution in an
organization.
Enterprise Subordinate CA—
An enterprise subordinate CA is subordinate to an existing enterprise
root CA, and must receive a certificate from that root CA to work
properly. In certain large organizations, it might be useful to have a
hierarchy of CAs, or the desire might exist to isolate the CA structure
for OWA to a subordinate enterprise CA structure.
Stand-Alone Root CA—
A stand-alone root CA is similar to an enterprise root CA, in that it
provides for its own unique identity, and can be uniquely configured. It
differs from an enterprise root CA in that it is not automatically
trusted by any forest clients in an organization.
Stand-Alone Subordinate CA—
A stand-alone subordinate CA is similar to an enterprise subordinate
CA, except that it is not directly tied or trusted by the forest
structure, and must take its own certificate from a stand-alone root CA.
After the internal CA is in place, the CAS can automatically use it for generation of certificates.
After
being placed on a server, SSL encryption will be made available on the
CAS. If the enterprise CA was installed in an Active Directory domain,
all the domain members will include the internal CA as a trusted root
authority and connect to OWA via SSL with no errors. External or
nondomain members, however, will need to install the enterprise CA into
their local trusted root authorities. This includes Windows Mobile
devices as well. The procedure for installing a third-party certificate
for a Windows Mobile device is covered in the next section of this
chapter titled “Installing a Root Certificate on a Windows Mobile Device.”
Installing a Root Certificate on a Windows Mobile Device
If a
third-party or self-generated certificate authority is used for
ActiveSync, Windows Mobile devices must be configured to trust that CA.
If they are not configured like this, they will error out with something
similar to the error shown in Figure 2 when attempting to connect via ActiveSync.
For Windows desktops
and laptops, this task is relatively straightforward, and involves
simply installing the enterprise root CA for this third-party
certificate into the Trusted Root Certificate Authority group for the
machine.
Note
Be sure to select the root certificate, and not the actual certificate used for the virtual server
For Windows Mobile devices, however, the enterprise root certificate must first be exported to a .cer
file. After the certificate has been exported, it must be copied to the
Windows Mobile device, either through the Explore button in Microsoft
ActiveSync (while the device is cradled), or via a memory chip.
After the .cer
file is installed, clicking on it using the File Explorer in Windows
Mobile (Start, Programs, File Explorer) invokes a dialog box, warning
that you are about to install the certificate. Click Yes and the
certificate will be automatically installed and ActiveSync over SSL can
be performed.
