This is a standalone document version of my 7-part series, How to Deploy iPhones with Exchange ActiveSync in the Enterprise. I included the comments as of 6/18/2010 since they may help answer your own questions about your deployment. Please visit my blog at www.expta.com to add additional comments. Thanks, Jeff Guillet [MVP]

Friday, February 12, 2010How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise

I've been working on a solution for quite a while to securely deploy iPhones in the enterprise. This solution should work exactly the same way on the Apple iPad and should port over fairly easy to the Droid and other non-Microsoft ActiveSyncenabled phones, with some minor changes. I'll be writing a 7 part series of articles that document all the steps. I'm sure there are other ways to do this, but I can assure you, none of them are documented. (Hint to Apple: This is not documentation, and neither is the iPhone Enterprise Deployment Guide.) In the scenario I'll be documenting, the customer wants to configure Exchange ActiveSync to provide mobile access to email, calendars and contacts for iPhone users. To make it more challenging (and slightly more complicated), the customer has Exchange 2003 mailbox servers with

Exchange 2007 or 2010 Client Access Servers. The requirements for deployment are such: Only authorized ActiveSync users can access their Exchange email, contacts and calendars Only authorized devices (iPhone 3GS) are allowed to use Exchange ActiveSync Ability for users to configure/reconfigure ActiveSync for their iPhones over the air Information stored on the iPhone must be encrypted Capability to remotely wipe iPhones in the event of a security breach (wipes performed by end user or authorized administrator) Easy roles-based administration

Summary of the SolutionActiveSync will be configured to use Basic Authentication over SSL and require client certificates. An iPhone configuration profile will be created and "married" to each iPhone, preventing it from being used on any other iPhone than the one it is configured for. The profile will include the user certificate and its private key. ActiveSync policies will be used to configure the iPhone to comply with corporate security policies. The next step is to publish the same user certificate to each ActiveSync user in Active Directory. This will be used to enable certificate-based authentication for ActiveSync. I'll list a few ways that this can be done programmatically via scripts. Finally, the user needs a way to install the profile. This will be done using a website that the user will open using Safari from the iPhone.

The solution requires a certificate of authority (CA) server that can generate a single user certificate. The CA can be an internal stand-alone or ADCS CA server. I prefer Windows Server 2008 R2 ADCS for the CA, but any CA will do.

More to Come...

I'll break each of these steps down in separate phases. There's a fair amount of detail in each step and I'll include troubleshooting and gotchas as I go through it, but this has worked out be a secure and easy to manage solution.

2 comments: Anonymous said...

Hi Jeff This sounds good, as it is similar to a requirement I have. My exchange server is on a Windows 2003 SBS, but access is via a Cyberguard firewall. What must I do to enable my iPhone to get past the firewall to the server? I sit just port forwarding, and if so, which port? 445? Rod RocketFebruary 14, 2010 1:57 PM

Andreas said...

Highly interesting topic Jeff - and you're right; Apple isn't anywhere near providing actual documentation. (Their guide should almost be labeled foilware...) I covered parts of SCEP (for device certificates) and the over-the-air provisioning process over at my blog (http://mobilitydojo.net/2010/01/20/sinking-our-teeth-into-scep/), but I didn't cover the entire scenario like how to setup the CA, and configuring ISA and/or Exchange. From your description it looks like you might be looking at cradling the iPhones and using iPhone Configuration Utility, or accessing the certsrv site via WiFi, am I right? Anyways, looking forward to proper documentation of how this should be done :)February 17, 2010 3:57 AM

Tuesday, February 23, 2010How to Securely Deploy iPhones with Exchange ActiveSync Phase 1 - Building the CAThis is the second post in my series, How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise. To read an overview of the solution click here. In this phase, we will create a new certificate server and generate the user certificate that will be used for ActiveSync authentication. This single certificate will be installed on iPhones and published in Active Directory. If your organization already has a certificate server, you can use it to create a user certificate, as specified later in this article. In this soup-to-nuts series I will explain how to create a new stand-alone Windows Server 2008 R2 CA (Certification Authority) for this purpose.

Build a Windows 2008 R2 Certificate ServerBegin configuring the Windows Server 2008 R2 server by installing the Active Directory Certificate Services role. This can be a new, single-purpose server or one already deployed in your organization. Contrary to the role name, this is the role to install even if the server is not a member of an Active Directory domain (a workgroup server). Select the following Role Services when installing the ADCS role: Certification Authority Certification Authority Web Enrollment (this will also install Web Server (IIS) and all necessary components) If the server is a member of a domain, you can choose whether to install the CA as an Enterprise or Standalone (non-domain based) CA. For our purposes, it really doesn't matter which one you choose. However, if you're planning out a full PKI (which I highly recommend) you should select the CA type that's appropriate for your organization. For this article, we'll make it a standalone Root CA. Create a new private key and use the default cryptographic service provider (CSP) and key length (2048). Supply a common name for the CA, such as W2K8R2CA. Note that the default validity period for certificates generated by a Windows Server 2008 R2 CA is 5 years. Set this value for as long as you'd like. Consider the fact that the certificate will have to be replaced on the iPhone and in AD when it expires. I set my validity to 10 years.

Continue through the Add Roles Wizard, accepting all the default settings. Note that the name and domain settings of the server cannot be changed after Certification Authority has been installed. Click Install to complete the installation. No reboot is required, but it is recommended that you run a Windows Update to ensure that the binaries are up to date.

Configure the Certification Authority to Use SSLIn order to request certificates using the web interface, you must enable SSL on the CA's web server. Open Internet Information Services (IIS) Manager in Administrative Tools. Select the server name and open the Server Certificates feature. Select Create Self-Signed Certificate in the Actions pane and supply a friendly name for the certificate, such as "CA Server". Next, expand Sites and select the Default Web Site. Click Bindings in the Actions pane and add HTTPS, using the new self-signed certificate, as shown below.

Now select the CertSrv virtual directory under Default Web Site and open the SSL Settings feature. Select Require SSL and click Apply.

A Word About Certificate RevocationCertificates can be revoked by the CA Administrator. When the certificate is revoked, it can no longer be used for its intended purpose. A revoked certificate is

added to the Certificate Revocation List (CRL) which is usually hosted on the CA server.

Important - When ActiveSync uses client certificates, Exchange ActiveSync 2007/2010 requires confirmation from the CA that the user certificate has not been revoked. This happens before Basic authentication is attempted. If the CRL is not available, ActiveSync will assume that the certificate has been revoked and the user will not be able to use ActiveSync. You must ensure the CRL (typically, the CA server) is always online and available. For this reason, I recommend virtualizing the CA to provide greater flexibility.

Unless you configure the Online Responder role service which uses the Online Certificate Status Protocol (OCSP), the CA will use a Certificate Revocation List (CRL) to obtain the revocation status of the X.509 user certificate. OCSP has replaced the traditional CRL file used in the past. It performs much better and has a lower network cost. Complete details about OCSP can be read here. For the purposes of this article (and brevity), we'll be using a CRL, which requires no further configuration.

Generate a User CertificateNow we are ready to generate a user certificate from the certificate server. This is a two-step process where a request is submitted and then approved, creating the certificate and its private key.

Requesting the User CertificateYou make the certificate request using Internet Explorer directly from the CA. Go to https://servername/certsrv and click Request a certificate.

Click Advanced certificate request and then Create and submit a request to this CA. Click Yes to the Web Access Confirmation warning to allow the website to perform a digital certificate operation on your behalf. Complete the certificate request as shown, using your organization's information.

Note: Some reverse proxy servers and firewalls do not allow spaces or special characters in the certificate name or friendly name. For this reason, I recommend using a simple short name for the user certificate to prevent problems. Once you submit the certificate request, it must be issued by the CA administrator (probably you). To issue the certificate, expand the Active Directory Certificate Services role in Server Manager > CA server name > Pending Requests. Right-click the pending request ID and select All Tasks > Issue to issue the certificate. Now you need to install the new user certificate using the ADCS website. Click View the status of a pending certificate request from the Home page and then click the certificate request you generated earlier, as shown below.

Click Yes to the Web Access Confirmation warning to allow the website to perform a digital certificate operation on your behalf and then click Install this certificate.

The user certificate and private key will be installed in the user's (your) Personal certificates store. It now needs to be exported, both with and without the private

key. The certificate with the private key will be imported into the iPhone and the other will be published to the user account in Active Directory.

Exporting the CertificatesIn Internet Explorer, click Tools > Internet Options > Content > Certificates. You will see the new user certificate in your Personal certificate store. Select the certificate and click Export. Follow the default settings in the Certificate Export Wizard, but make sure you select Yes, export the private key and Include all certificates in the certification path if possible. Supply a password for the certificate. You will need this password to import the certificate for other Mobile Messaging Administrators in the future. Browse to the folder of your choice and name the file ActiveSyncUser.pfx. Now export the user certificate again, this time choosing No, do not export the private key. Browse to the folder of your choice and name the file ActiveSyncUser.cer. This certificate will be published later to the ActiveSync user accounts in Active Directory. Lastly, we need to export the CA's root certificate. This will be imported into the Trusted Root Certification Authorities certificate store on the Exchange CAS servers so they can trust the user certificate, since it's self-signed. Click the Intermediate Certification Authorities tab and select the CA's certificate, as shown below.

Click Export and follow the Certificate Export Wizard, selecting all the defaults. Browse to the folder of your choice and name the file RootCA.cer. We now have a working CA server, a user certificate with and without the private key, and the Root CA certificate.

This concludes Phase 1 of my series, How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise - Phase 1 - Building the CA. The next phase will cover how to configure the Exchange Client Access Servers for ActiveSync using client certificates. Other articles in this series: How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise Phase 1 - Building the CA Phase 2 - Configuring ActiveSync and Active Directory Phase 3 - Publishing User Certificates to Active Directory Phase 4 - Creating the iPhone Configuration Profile Phase 5 - Creating the Web Site for iPhone Profile Deployment Phase 6 - End-User Deployment of the ActiveSync Profile Posted by Jeff at 3:01 PM 3 comments: seanv said...

Jeff, the certificate template you are using "Client Authentication Certificate" is not available on my CA. Is this template a specific template for Windows 2008 R2? Our CA is Windows 2008. Any suggestions?June 2, 2010 12:34 PM

Jeff said...

Seanv,

You want to request a certificate using the "Advanced Certificate Request" link, not a standard user certificate.June 2, 2010 2:15 PM

Jeff said...

I see what you mean now. You're using a domain-based root CA and I was using a standalone CA. The Client Authentication Certificate template is only available on stand-alone CAs. You should be able to use the "User" certificate template, however.June 2, 2010 2:29 PM

Thursday, February 25, 2010How to Securely Deploy iPhones with Exchange ActiveSync Phase 2 - Configuring ActiveSync and Active DirectoryThis is the third post in my series, How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise. To read an overview of the solution click here. In this phase, we will configure ActiveSync on the Exchange CAS and Mailbox servers and make the necessary changes in Active Directory.

Securing Exchange ActiveSyncExchange ActiveSync is enabled by default for all Exchange users in a normal installation. It can be disabled for select users using Active Directory Users and Computers (ADUC) for Exchange 2003 users or the Exchange 2007/2010 management tools for those mailbox users. Since our solution requires that ActiveSync be available for only specific users, we could use a script that disables ActiveSync for all users who are not a member of an ActiveSync Users security group. While this would work, it would be clumsy and new users could access ActiveSync until the script runs again. It also wouldn't solve the requirement that only authorized devices can access ActiveSync. In order to fulfill the requirements that only authorized users can access ActiveSync using authorized devices, we will configure ActiveSync to require user certificates. The iPhones will receive a unique iPhone Configuration Profile that includes the user certificate we generated in Phase 1. That profile can be loaded on one, and only one, iPhone. More on that in a later phase. Configuring Exchange ActiveSync As mentioned earlier, ActiveSync is enabled by default in a normal Exchange installation. It is configured by default to use only Basic authentication. We need to configure the CAS servers to require user certificates. This is only configured on the CAS servers, not the Mailbox servers. To do this using the Exchange Management Console (EMC), expand Microsoft Exchange > Server Configuration > Client Access. Select the Client Access Server to configure and click the Exchange ActiveSync tab in the work pane. Double-click Microsoft-Server-ActiveSync to view its properties. Click the Authentication tab and select Require client certificates, as shown below.

Repeat these steps for each CAS server. To do the same thing using the Exchange Management Shell (EMS), use the following cmdlet to require client certificates for each CAS server: Set-ActiveSyncVirtualDirectory -identity "CASservername\MicrosoftServer-ActiveSync (Default Web Site)" -ClientCertAuth Required Finally, we need to make an adjustment to the uploadReadAheadSize value in the IIS metabase. This is required when you use certificate-based authentication. Run the following commands from a CMD prompt on the CAS server, replacing the value in quotes with the maximum message size (in bytes) allowed by your organization. C:\Windows\System32\inetsrv\appcmd.exe set config section:system.webServer/serverRuntime /uploadReadAheadSize:"10485760" /commit:apphost C:\Windows\System32\inetsrv\appcmd.exe set config "Default Web Site" section:system.webServer/serverRuntime /uploadReadAheadSize:"10485760" /commit:apphost

The commands above set uploadReadAheadSize to 10MB (the default is 48KB). 1024 * 1024 * 10 = 10MB. You then need to restart the IISAdmin service to affect the change. That's all there is to it. You may also want to configure Remote File Servers at this time, but I won't be covering that in this series. A Note About Exchange 2003 Mailbox Servers I mentioned in the introduction that this scenario has some Exchange 2003 mailbox servers, just to spice things up. If you use Exchange 2007 or 2010 CAS servers to front-end ActiveSync for Exchange 2003 mailboxes, you need to configure ActiveSync on the Exchange 2003 mailbox servers to allow Integrated Windows Authentication. This is because the Exchange 2007/2010 CAS servers use Kerberos pass-through authentication to the E2K3 mailbox servers. The trouble is, you can't configure this using Exchange ESM and if you try to modify the Microsoft-Server-ActiveSync virtual directory in IIS Manager, the Exchange DS2MB process will overwrite your changes in a few minutes. This is detailed on the Exchange Team blog here. To overcome this, download and install Microsoft KB 937031. The hotfix normally does not require a reboot, but will prompt for one if a scheduled reboot has been deferred. This hotfix will enable the Authentication button on the Access tab of the Microsoft-Server-ActiveSync object. This object is found in ESM under Servers > servername > Protocols > HTTP > Exchange Virtual Server > Microsoft-Server-ActiveSync. Simply enable Basic authentication and Integrated Windows Authentication, as shown.

Configuring Active DirectoryNow we need to configure Active Directory for the solution by creating the necessary user groups and publishing the self-signed CA Root certificate. Create Security Groups Create two universal security groups, ActiveSync Users and ActiveSync Admins. Populate the groups with the appropriate users. By using security groups, we can easily manage the solution using roles based security. Configure Group Policy Since our root CA is is not trusted by an external trusted CA like VeriSign or Entrust, we need to install the root certificate in the Trusted Root Certification Authorities certificate store on the Exchange CAS servers. While we can do this manually using the Certificates MMC, I'm going to show you how to publish it to all computers in AD using Group Policy, which is my best practice. Using appropriate credentials (usually Domain Admin), open the Group Policy Management Console (GPMC). Edit the Default Domain Policy and navigate to Computer Configuration > Policies > Windows Settings > Security Settings

> Public Key Policies > Trusted Root Certification Authorities, as show below.

Right-click Trusted Root Certification Authorities and select Import. Run through the Certificate Import Wizard to import the RootCA.cer certificate file we exported at the end of Phase 1. Be sure to place the certificate in the Trusted Root Certification Authorities store. You should now see the certificate in the Default Domain Policy. After AD replication completes, logon to a CAS server and run GPUpdate to refresh Group Policy and import the root certificate. Confirm that the certificate is installed using Internet Explorer. Click Tools > Internet Options > Content > Certificates. The root certificate should show under the Trusted Root Certification Authorities tab, as shown.

We have completed securing and configuring Exchange ActiveSync, and configured Active Directory by creating the necessary groups and importing the root certificate into the Default Domain Group Policy.

This concludes Phase 2 of my series, How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise. The next phase will cover how to publish the user certificates to user accounts who are members of the ActiveSync Users security group. Other articles in this series: How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise Phase 1 - Building the CA Phase 2 - Configuring ActiveSync and Active Directory Phase 3 - Publishing User Certificates to Active Directory Phase 4 - Creating the iPhone Configuration Profile Phase 5 - Creating the Web Site for iPhone Profile Deployment Phase 6 - End-User Deployment of the ActiveSync Profile Posted by Jeff at 3:55 PM Labels: ActiveSync, Exchange, iPhone, Microsoft Exchange 2003, Microsoft Exchange 2007, Microsoft Exchange 2010, tip

4 comments: Anonymous said...

Hey Jeff, I hope you can finish the series in the next day or two because I've been looking at this exact same setup for a few weeks on and off and am banging my head around certificates part. I've made iPhone work with Exchange 2003 without certificates (username / password authentication) but want to get it done right :-)March 1, 2010 10:58 PM

Jeff said...

Thanks, I'll try. I'm posting another phase this morning after I get another screenshot.March 2, 2010 6:15 AM

Anonymous said...

Hi Jeff, After importing certificate as described and publishing it through GP, the certificate ends up in my Trusted Root certification authorities store rather than Intermediate store - is this an error / typo in the article? In first step we import into Trusted store, and that's where it should end up on client IE?March 6, 2010 9:06 PM

Jeff said...

Good catch, that was a typo. I've corrected the article above. Thanks!March 6, 2010 9:46 PM

Monday, March 1, 2010How to Securely Deploy iPhones with Exchange ActiveSync Phase 3 - Publishing User Certificates to Active DirectoryThis is the fourth post in my series, How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise. To read an overview of the solution click here. In this phase, we will publish the same user certificate to each user object in Active Directory that is a member of the ActiveSync Users security group. As mentioned earlier, ActiveSync will be configured to require user certificates for authentication. This means that the user needs a user certificate with the private key and ActiveSync will check this certificate for a matching certificate in Active Directory. We need to publish the user accounts in Active Directory, as shown below.

When you view the properties of the published certificate, you see that it was issued by the CA (W2K8R2-CA) and that the certification path is valid, since we published the root CA certificate to all machines in the domain using Group Policy in Phase 2.

While this is a fairly simple process to do, I wrestled with different ways of doing it programmatically. I finally decided to use VBScript to publish the certificate to AD. I chose VBScript instead of PowerShell because I could not be certain that the ActiveSync Administrator(s) would have PowerShell installed. The script uses CAPICOM, which is a security technology from Microsoft that allows Microsoft Visual Basic, Visual Basic Script, ASP, and C++ programmers to easily incorporate digital signing and encryption into their application. To use CAPICOM, you must download and register the CAPICOM.DLL on the computer that runs the script. The script automatically registers the DLL, as long as it resides in the same network share where the ActiveSync user certificate resides. First, download CAPICOM and extract the contents to get the CAPICOM.DLL file (we have no need for any of the other files or examples). Then create a network share that the mobile administrators have access to (for example \\fileserver\iPhone). Copy the CAPICOM.DLL, the ActiveSyncUser.cer user certificate (exported in Phase 1), and the vbscript below to the share. You will need to edit the script to reflect the name you used for your ActiveSync Users group in AD, the path to CAPICOM.DLL and the user certificate, and the name of the user certificate if necessary. Here's the Publish Mobile Cert.vbs script:

'============================================================================ ========================================================== 'Publish Mobile Cert.vbs - The admin running the script must have rights to modify the user accounts that are members of the ActiveSync Users group in AD. 'Jeff Guillet '02/10/2010 ' 'This script publishes the mobile user certificate into Active Directory for all members of the ActiveSync Users security group ' 'Micosoft link for CAPICOM: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=860EE 43A-A843-462F-ABB5-FF88EA5896F6 '============================================================================ =========================================================== On Error Resume Next 'Configure constants Const ADS_PROPERTY_UPDATE = 2 Const ADS_PROPERTY_APPEND = 3 '-------------------------------------------------------------------------'Modify the three variables below, as required '-------------------------------------------------------------------------eASUsersGroup = "ActiveSync Users" pathToFiles = "\\fileserver\iPhone\" certFile = "ActiveSyncUser.cer" '-------------------------------------------------------------------------msg = "This script publishes the '" & certFile & "' certificate to all members of" & vbCRLF msg = msg & "the '" & eASUsersGroup & "' security group. Do you want to continue?" r = MsgBox(msg, vbYesNo + vbQuestion, "Publish Mobile Cert") If r = vbNo then Wscript.Quit 'Create log file Set fso = CreateObject("Scripting.FileSystemObject") Set FullLog = fso.OpenTextFile(pathToFiles & "Publish Mobile Cert.log", 8, True) 'Check for and set dependencies '--Check for CAPICOM.DLL Set FSO = CreateObject("Scripting.FileSystemObject") If NOT FSO.FileExists ("C:\Windows\System32\capicom.dll") Then If NOT FSO.FileExists (pathToFiles & "capicom.dll") Then MsgBox pathToFiles & "capicom.dll is missing. Cannot continue.", vbCritical,

"Missing File" Wscript.Quit Else FSO.CopyFile pathToFiles & "capicom.dll", "C:\Windows\System32\" End if End if '--Check for certificate If NOT FSO.FileExists (pathToFiles & certFile) Then MsgBox pathToFiles & certFile & " is missing. Cannot continue.", vbCritical, "Missing File" Wscript.Quit End If '--Register CAPICOM.DLL Set WshShell = WScript.CreateObject("WScript.Shell") Return = WshShell.Run("regsvr32 C:\Windows\System32\capicom.dll /s", 0, true) 'Load the certificate file and convert it to Base-64 Set Certificate = CreateObject("CAPICOM.Certificate") Certificate.Load pathToFiles & certFile BinaryEncodedCertificate = Certificate.Export(CAPICOM_ENCODE_BINARY) Set Utilities = CreateObject("CAPICOM.Utilities") ArrayEncodedCertificate = Utilities.BinaryStringToByteArray(BinaryEncodedCertificate) 'Configure connection to Active Directory Set con = CreateObject("ADODB.Connection") con.Provider = "ADsDSOObject" con.Open "DS Query" Set command = CreateObject("ADODB.Command") Set command.ActiveConnection = con command.Properties("searchscope") = 2 command.Properties("Page Size") = 20000 command.Properties("Timeout") = 180 'Get default domain Set oRoot = GetObject("LDAP://rootDSE") oDomain = "LDAP://" & oRoot.Get("defaultNamingContext") 'Construct and execute query to get the eASUsersGroup command.CommandText = "SELECT AdsPath FROM '" & oDomain & "' WHERE name = '" & eASUsersGroup & "' AND objectClass = 'Group'" Set rs = Command.Execute 'Append to the log file FullLog.writeline String(75, "=") FullLog.writeline "Publish Mobile Cert.vbs" FullLog.writeline Now FullLog.Writeline "Adding the mobile user certificate to the following

users:" FullLog.writeline String(75, "-") 'Loop through the result set Do While NOT rs.EOF Set oGroup = GetObject(rs.fields(0)) groupDN = oGroup.distinguishedName 'Publish the certificate to each member of the group For Each Member In oGroup.Members userCount = userCount + 1 'Append the certificate to the user's certificate store in Active Directory Set UserObj = GetObject("LDAP://" & member.distinguishedName) UserObj.PutEx ADS_PROPERTY_APPEND, "userCertificate", Array(ArrayEncodedCertificate) UserObj.SetInfo If Err.Number = 0 Then FullLog.writeline member.distinguishedName Else FullLog.writeline "Unable to update user: " & member.distinguishedName errorCount = errorCount + 1 End If Next Exit Do Loop FullLog.writeline String(75, "=") & vbCRLF & vbCRLF msg = "Successfully published the certificate to " & userCount - errorCount & " user accounts." & vbCRLF msg = msg & "Review the Publish Mobile Cert.log for details." If errorCount > 0 Then msg = msg & vbCRLF & vbCRLF & errorCount & " error(s) were encountered." MsgBox msg, vbExclamation, "Publish Mobile Cert" Else MsgBox msg, vbInformation, "Publish Mobile Cert" End If

Here's a link to the script for those of you averse to copying and pasting. To run the script you must have rights to modify the user accounts that are members of the ActiveSync Users security group. Simply double-click the script to run it. The script will register CAPICOM.DLL, connect to Active Directory and search for the ActiveSync Users group, enumerate all the members of the group, and publish the ActiveSync user certificate to each user. A log file is generated in the folder path specified in the script each time it is run.

We have now completed publishing the ActiveSync user certificate to the user accounts in Active Directory that are members of the ActiveSync Users group.

This concludes Phase 3 of my series, How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise. The next phase will cover how to create the iPhone Configuration Profile using Apple's iPhone Configuration Utility. Other articles in this series: How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise Phase 1 - Building the CA Phase 2 - Configuring ActiveSync and Active Directory Phase 3 - Publishing User Certificates to Active Directory Phase 4 - Creating the iPhone Configuration Profile Phase 5 - Creating the Web Site for iPhone Profile Deployment Phase 6 - End-User Deployment of the ActiveSync Profile Posted by Jeff at 7:02 PM Labels: ActiveSync, Exchange, iPhone, Microsoft Exchange 2003, Microsoft Exchange 2007, Microsoft Exchange 2010, scripts, tip 14 comments: Namescape Active Directory Software Solutions said...

Thanks for the interesting and informative post. I look forward to more in the future.March 2, 2010 1:15 PM

Jeff said...

Thanks! Namescape is a pretty nice product, BTW.March 2, 2010 1:53 PM

Anonymous said...

Hi Jeff, Is this part done only to ensure that a connecting user has permissions to connect *at all*? And per-device config ensures he's providing password for a preset email account? Also, do we must have device with us when configuring per-device iPhone profile, or can that be done differently? I'd prefer to avoid asking users to bring their devices to me and somehow enroll them over the air, am I missing something? ThanksMarch 4, 2010 4:36 PM

Jeff said...

User certificate authentication is used to control which users can access ActiveSync. If the user doesn't have the correct user certificate, they cannot connect to their mailbox even if it's permitted in their mailbox rights. In order for certificate authentication to work, the user must present the same certificate (with private key) that is published to the user's account in AD. The fact that we can embed the user certificate and private key into the iPhone configuration profile works in our favor, because the user is unable to export the user cert and place it on an unauthorized device. Regarding your second question: Yes, you must have the physical device to "check it into" the iPhone Configuration Utility. This created a device profile that the profile can be married (encrypted) to. It cannot be done over the air. The customers I've worked with purchase the iPhones for their employees, so they already have the phone in their possession to deploy them.March 4, 2010 7:46 PM

Anonymous said...

That works if you are deploying new phones - we (and conceivably many others) have a situation where many users had their own iPhones for a while and only now we are pushing to integrate those with company Exchange server. Some of these users are hundreds of kilometers away and visit the main office once per quarter, so that represents a major pain. One thing I thought was possible is this: User uses their Safari (would it work?) to visit www.company.com/certsrv and request a user certificate, which they then download into their own iPhone device. Admin on the other side exports that certificate into user's AD account, then creates a generic company iPhone profile and makes it available at www.company.com/iPhoneconfig and sends the link to the user. User follows the link to get the profile, and is good to go. Am I completely off with this method?March 5, 2010 10:14 AM

Jeff said...

I'm not sure that the iPhone will be able to request and install user cert from the cert server. That would also require that you make the CA available from the Internet (a bit risky). In theory, this would work, though. Another way to do it is to have the user download the iPhone Configuration Utility on their PC. Then they simply run it and plug their iPhone in. The iCU will create a device profile in the %USERPROFILE%\Local Settings\Application Data\Apple Computer\MobileDevice\Devices folder. Have the user send you the LongDeviceID.deviceinfo file, which you put into your Devices folder. Then follow the instructions I've given.March 5, 2010 10:24 AM

Anonymous said...

Isn't owa.company.com/certsrv already exposed to outside sort of by default when you make owa available (or that's just if you don't do extra securing)? Any chance you could find time to test this case out, with self-service certificate handling? ThanksMarch 6, 2010 6:33 PM

Jeff said...

No, the CA we configured in phase 1 is a certificate server on the internal network. It is not the OWA server.March 6, 2010 9:26 PM

Anonymous said...

Looks like I made this work on a single 2003 Exchange, still have to check a few things. One suggestion for the certificate deployment script - can you include part to check / delete existing cert with same name? In testing I found it adds certs so makes duplicates, and in real world you can imagine running the script every once in a while when new user joins the group - we don't want to have old users spammed with same certs?March 6, 2010 11:59 PM

Anonymous said...

Another thing - even with profiles deployed, as you said user is required to enter password only once which happened. However I can still go to Settings > > > Account Info and set / change the password. I tried this and immediately got prompted for password saying "password incorrect", which leads me to believe password is used for authentication beyond initial setup? I thought password won't be used

after that initial point, again (my) idea was to avoid using username / password for authentication?March 7, 2010 12:04 AM

Jeff said...

I'm not sure what you mean by this. You only need one user certificate that will be used for all users in the ActiveSync Users group. I can run the script over and over, but it only adds that same user cert once per user. Note that the script will not remove the cert from users who are removed from the ActiveSync Users group.March 7, 2010 10:21 AM

Jeff said...

For the second comment about changing the password -- Yes, the user is able to change the password in Account Info. This is the Exchange ActiveSync (EAS) password, and is used for authentication to EAS on the CAS. If you change it on the iPhone you will not be able to authenticate to EAS because it is out of sync with AD. Here's the behavior of password changes for EAS: * The user changes his password in AD, either by choice or due to a password expiration policy. * EAS on the mobile device (in this case the iPhone) tries to sync to ActiveSync using the old password and is denied. EAS on the iPhone will prompt the user for the new AD password. The iPhone will not sync until the EAS password on the iPhone matches the password in AD. Typically, the user would change the EAS password on the iPhone from this prompt, not from Settings on the iPhone, but they're both the same thing.March 7, 2010 10:35 AM

Anonymous said...

Hi Jeff, About the certs - if you run the script twice you'll have the cert listed twice in the user account properties (first screenshot on this page). From there I assume if you keep running the script again and again it will keep adding the same cert to existing users? So just to confirm - the way certs are used in your guide the user's password still exists on the device and has to be changed whenever AD password changes? Does the possibility exist for user's account to be locked out if he doesn't change password when prompted, or missed 3 or 5 times (whatever AD settings for account lockout)? I'm thinking of the scenario where we use per-user personal certs to do the authentication. When you do properties > edit secure communications on OMA virtual folder, there is "Enable client certificate mapping" and it seems we can map a personal certificate to the user account - is this how authentication without password would be done? What would the process look like, as diff from what's described in the article? ThanksMarch 7, 2010 12:18 PM

Jeff said...

OK, so the script will only publish the same cert one time to each AD account that is a member of the ActiveSync Users security group (unless you specify a different cert). If you re-run the script it will duplicate the same cert again to the same user account, it will only republish it. Yes, your confirmation is correct. The EAS password on the iPhone will have to be updated when the AD account password changes. When the AD account password changes, EAS on the iPhone will prompt for the new password and will not check again until the password has been updated on the iPhone. This prevents the iPhone from locing out the

AD account. Keep in mind that if the user enters the wrong password too many times on the iPhone, they can lock out the AD account (just like what would happen from OWA). I don't believe EAS supports Client Certificate Mapping. The EAS code appears to require Basic Authentication (you can't configure EAS on the iPhone without a username/password), so I doubt this will work. Client Certificate Mapping is an IIS security construct, not an EAS authentication option.March 7, 2010 1:05 PM

Tuesday, March 2, 2010How to Securely Deploy iPhones with Exchange ActiveSync Phase 4 - Creating the iPhone Configuration ProfileThis is the fifth post in my series, How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise. To read an overview of the solution click here. In this phase, we will create iPhone Configuration Profiles using Apple's iPhone Configuration Utility. I will also show you how to embed the user certificate and private key into the profile and how to marry the profile to a specific iPhone. Let's get started. First, you will need to download and install the Apple iPhone Configuration Utility (iCU). The latest version as of this writing is version 2.1.0.163 and is the one I will use here. The iCU only installs on Windows XP SP3 or Windows Vista SP1 or greater. It will not install on Windows Server. It also requires NET 3.5 SP1. Note: The iCU is not an enterprise class software program. All the configurations, hardware profiles and configuration profiles are stored locally on the workstation in %USERPROFILE%\Local Settings\Application Data\Apple Computer\MobileDevice folder. For this reason, I recommend using a single workstation for iPhone management and to backup this folder and child folders to a network location periodically. Begin the configuration process by logging into the workstation with the credentials used to request and install the user certificate created in Phase 1. This user has the ActiveSyncUser user certificate stored in his/her personal certificate store. It will be needed later in this process. Before the iPhone can be configured it must be activated on the AT&T network. This is performed using iTunes. Simply launch iTunes, connect the new iPhone to the computer using the USB cable, and follow the iTunes Setup Assistant. Once the iPhone is activated you can close iTunes. Now launch the iPhone Configuration Utility. The iPhone will automatically be added to the Devices Library in the iCU, as shown below:

In the Devices library, click the iPhone and enter the user's name and email address to identify the device profile. Note that most iPhones will have the helpful name "iPhone", so the Contact info you enter here will help you out later. Now click the Configuration Profiles library and click the New icon to create a new base configuration profile. The base configuration profile can be used for configuration settings that cannot be made using the Exchange ActiveSync Policy, such as iPhone Restrictions or VPN settings. Apple calls these configurations "payloads". To create a new base configuration, select the General (Mandatory) setting and enter a Name, Identifier, Organization, and Description, as shown.

Choose whether the base configuration profile can be removed. Choices are Always, With Authentication (using a password), or Never. For base configurations, I recommend With Authentication to prevent end-users from easily removing company restrictions. You must then supply the Authorization password. Notice there is no "Save" button anywhere. Whatever you configure is written immediately to the configuration profile(s). You can now configure your base configuration settings and restrictions, as shown. Refer to the iCU help for configuration settings. If you want to delete a payload from a profile, click the minus sign in the top right corner of the configuration item.

I recommend using Exchange 2007 / 2010 ActiveSync over-the-air policies for any configuration that can be configured using them (for example, device locking duration and passcode complexity). This will give you the greatest amount of flexibility and will allow you to make changes on the fly. Now deploy the iPhone Base Profile to the iPhone by clicking the iPhone name under DEVICES on the left pane. Select the iPhone Base Profile and click Install.

The iPhone will prompt you to install the iPhone Base Profile, as shown below. Tap Install and the Install Now. After the profile installs, tap Done.

Back in the iCU, click the Configuration Profiles library. Click the New icon again to create the ActiveSync Profile. Configure the General (Mandatory) section as shown:

I recommend setting Security so that the ActiveSync Profile can Always be removed. This will allow users to remove the EAS profile, which will help later if you ever need to re-deploy the EAS profile. Now click the Exchange ActiveSync section and configure your ActiveSync settings for the iPhone. Enter the Account Name, Exchange ActiveSync Host, Domain, User, and Email Address, as shown:

Do not enter the user's password. The iPhone will prompt the user for any field you leave blank when it installs the profile. Going forward, the only items you will need to configure for subsequent ActiveSync profiles are the User and Email Address. Click the + sign under Authentication Credential Name. The Personal Certificate Store will open for you to add the ActiveSyncUser user certificate to the Exchange ActiveSync profile, as shown:

Enter the password you entered for the certificate's private key in Phase 1. The certificate and private key will be added to the Exchange ActiveSync configuration. Check Include Authentication Credential Passphrase to include it in the profile, otherwise the device will prompt the user for the passphrase (not good).

You now have a fully configured iPhone ActiveSync Configuration Profile. All that's left is to export the ActiveSync Profile so that the user can install it. You need the user to do this because the profile will prompt for the user's Active Directory password (something I hope you don't know).

Ensure that the ActiveSync Profile is selected and click the Export button. The Export Configuration Profile window will open. Select Create and sign encrytped configuration profile for each selected device from the dropdown box and select the correct device, as shown below. Then click Export. This will "marry" the ActiveSync configuration profile to the selected device, preventing it from being installed on any other iPhone. This is how we meet the requirement that "only authorized devices can access ActiveSync".

Now I need to jump forward a bit. In the next phase, I will explain how to create the deployment website. For now, let's assume that the website already exists and that the UNC path to the share for that website is \\EXCAS1\eas. Save the configuration profile to that share, naming the profile with the AD user's logon name (for example, jqsmith.mobileconfig). Congratulations! You have now created a unique ActiveSync configuration profile with the embedded ActiveSyncUser user certificate, and encypted and married the profile to a specific iPhone.

This concludes Phase 4 of my series, How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise. The next phase will cover how to create the website for end-user iPhone profile deployment. Other articles in this series: How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise

Phase Phase Phase Phase Phase Phase

1 2 3 4 5 6

-

Building the CA Configuring ActiveSync and Active Directory Publishing User Certificates to Active Directory Creating the iPhone Configuration Profile Creating the Web Site for iPhone Profile Deployment End-User Deployment of the ActiveSync Profile

Posted by Jeff at 6:34 PM Labels: ActiveSync, Exchange, iPhone, Microsoft Exchange 2003, Microsoft Exchange 2007, Microsoft Exchange 2010, tip 7 comments: Anonymous said...

Hi, I was hoping to see how to configure iPhone and certificates on the device so that user doesn't have to enter their AD username and password to sync with Exchange. The challenge we have is that company policy dictates password to be changed every 60 days, and if the iPhone uses UN/Pass credentials to get to Exchange it will lock the account out (unless user remembers to change his AD password in iPhone as well, which we all know is not something we should rely on). ThanksMarch 2, 2010 3:15 PM

Jeff said...

This solution only requires the user to enter their Active Directory password once, when installing the iPhone profile. The user will NEVER need to know or enter the certificate password. ActiveSync will never lock the user out. BTW, Exchange ActiveSync clients cannot handle password expiration notification messages. Additionally, you cannot change an expired password by using an Exchange ActiveSync client.

March 2, 2010 3:22 PM

Kevin Westby said...

When applying a baseline profile on the iPhone that is intended to restrict the passcode timeout to 1 hour, it doesn't appear to limit it to the 1 hour setting. After installing the profile, I can still set the timeout value to 4 hours. Is there a way to restrict that, or am I missing something? BTW: this article series is great, very helpful!May 11, 2010 10:59 AM

Jeff said...

Kevin, are you configuring the setting in an iPhone configuration profile or using an EAS policy?May 11, 2010 11:03 AM

Kevin Westby said...

Right now, just in the iPhone configuration profile.May 11, 2010 12:19 PM

Mark said...

Jeff, I have an issue where I set up a second desktop in a remote location (so iphone can be provisioned there) and when I go to add the cert to the activeSync mobile profile it generates an error "certificate exception: key not valid for use in specified state"

I generate the same config on mine here and it works fine (although I dont have the device here) - same cert Any ideas????June 17, 2010 10:33 PM

Jeff said...

Hi Mark, It sounds like you don't have the private key installed for the user on the second desktop. Try exporting the user cert and private key again from the first desktop to a PFX file and reimporting it on the second desktop.June 18, 2010 9:36 AM

Tuesday, March 2, 2010How to Securely Deploy iPhones with Exchange ActiveSync Phase 5 - Creating the Website for iPhone Profile DeploymentThis is the sixth post in my series, How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise. To read an overview of the solution click here. In this phase, we will create the deployment website that end-users will use to download the appropriate iPhone Configuration Profile created in Phase 4. Since you're most likely using Outlook Web Access served up by the CAS servers, these make a natural choice for hosting the website. I'll cover how to do this using a single CAS server and then follow up with guidance and best practices for environments with multiple CAS servers. Add the ASP Role Service to the Web Server Begin by logging into the CAS server with administrator credentials and opening Server Manager. Expand Roles and select Web Server (IIS). Right-click Web Server (IIS) and select Add Role Services. Under Application Development add the ASP role service, as shown.

Click Next and Install to complete the installation. No restart is required. Create the EAS Virtual Directory

Open Internet Information Services (IIS) Manager. Expand the CAS server name > Sites > Default Web Site. Right-click Default Web Site and choose Add Virtual Directory. Enter EAS for the Alias and click the (...) button to browse for the Physical Path. Navigate to C:\inetpub\wwwroot and click the Make New Folder button. Name the new folder EAS and click OK twice.

Configure the EAS WebSite Permissions Right-click the new EAS virtual directory and choose Edit Permissions. Click the Sharing tab and configure the EAS share with the following share permissions: Add ActiveSync Users (Read) and ActiveSync Admins (Full Control). Remove Everyone from the share permissions. On the Security tab click Advanced and Change Permissions. Uncheck Include inheritable permissions from this object's parent, click Add (for Windows Server 2008, click Copy), and click OK twice. Click Edit and remove the Users (CASname\Users) group. Add ActiveSync Users (Read & Execute, List Folder Contents, Read) and ActiveSync Admins (Full Control), and click OK twice. Configure the EAS WebSite Authentication Select the EAS website and double-click Authentication. Disable Anonymous Authentication and enable Basic Authentication. Select Basic Authentication and click Edit in the Actions pane. Enter the domain name for the Default Domain and click OK.

Configure MIME Handling MIME handling tells the web server how to handle different file extensions and associates file extensions with applications. Select the EAS website and double-click MIME Types. Click Add in the Actions pane. Enter mobileconfig for the File name extension and application/iphone-configuration for the MIME type, as shown, then click OK.

Create the Default Document for the EAS Website We now need to create a default ASP document for the folder. This ASP page will be used to cause the iPhone to automatically download the correct iPhone Configuration Profile. Download the default.asp page here. Edit default.asp to replace webmail.companyabc.com in the second to last line with the FQDN of your publicly available CAS server. Save the file in the EAS folder. You can now close Internet Information Services (IIS) Manager. Putting It All Together Now that we have the EAS share and website configured, it's simply a matter of exporting the iPhone configuration profiles to the EAS share (as described in Phase 4), using the ActiveSync user's logon name as the name of the file (for example, jqsmith.mobileconfig). You then instruct the user to enter https://webmail.companyabc.com/eas in Safari from the iPhone. The user will be prompted for authentication to access the website. After the user enters his/her AD username and password, the iPhone Configuration Profile that matches the logon name will be downloaded to install on the iPhone. I'll cover those steps in detail in the final phase.

Special Configuration for Multiple CAS Servers If your environment has more than one CAS server in a load-balancing solution used for OWA, you need to perform the procedures above for each of those CAS servers. You will also need to make sure that you copy the encrypted and signed iPhone Configuration Profiles to each CAS server's EAS share when you export it. If this pertains to your environment, I recommend using DFS to replicate and distribute the profiles amongst the participating CAS servers. With DFS you can save the iPhone Configuration Profiles to \\domain\EAS and it will replicate to all the CAS servers automatically. This completes the configuration of the EAS deployment website.

This concludes Phase 5 of my series, How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise. In the last phase I will provide the end-user instructions and procedures. Other articles in this series: How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise Phase 1 - Building the CA Phase 2 - Configuring ActiveSync and Active Directory Phase 3 - Publishing User Certificates to Active Directory Phase 4 - Creating the iPhone Configuration Profile Phase 5 - Creating the Web Site for iPhone Profile Deployment Phase 6 - End-User Deployment of the ActiveSync Profile Posted by Jeff at 9:07 PM Labels: ActiveSync, Exchange, iPhone, Microsoft Exchange 2003, Microsoft Exchange 2007, Microsoft Exchange 2010, tip

Wednesday, March 3, 2010How to Securely Deploy iPhones with Exchange ActiveSync Phase 6 - End-User Deployment of the ActiveSync ProfileThis is the seventh and last post in my series, How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise. To read an overview of the solution click here. In this phase I will demonstrate the steps and procedures that the end-user will perform to configure their iPhone for ActiveSync. I will also cover some advanced reverse proxy configurations, such as using Microsoft Threat Management Gateway (TMG), ISA, Tivoli Access Manager (TAM), etc. As a review, the infrastructure has been built and the necessary software and certificates have been installed and configured. Members of the ActiveSync Administrators group configure iPhone Configuration Profiles, one per iPhone, which includes the user's ActiveSync configuration settings and the ActiveSyncUser user certificate. Each iPhone Configuration Profile (iCP) is married to the iPhone and exported to the EAS share, which is also a website virtual directory on the CAS server. The iCP is named for the user for which it is intended (i.e., jqsmith.mobileconfig).

In this final phase, the user authenticates to the EAS website using Safari from the iPhone. The iPhone automatically downloads the iCP that matches the username. Here are the steps in detail:

The user is instructed to tap Safari on the iPhone and navigate to https://webmail.companyabc.com/eas (where webmail.companyabc.com is the public FQDN for the CAS server). The user logs into the Secure Website using the user's AD logon name and password, as shown:

After successfully logging in, the iPhone will download the user-specific ActiveSync Configuration Profile, as shown.

The green Verified indication signifies that the profile was encrypted and signed for this device. If the user taps More Details on the profile, the details of the configuration profile are displayed showing the ActiveSync server and the email address used in the configuration profile, as shown. Note that the user cannot tell that a user certificate is embedded in the configuration profile.

Back on the Install Profile screen, tap Install and Install Now to begin installing the profile. Note that the iPhone only supports one Exchange ActiveSync profile at a time (I sincerely hope this changes in the near future). If the user already has Exchange ActiveSync configured, the iPhone will display the warning, "Can't install Profile. Only one Exchange account can be set up at a given time." Remove the existing ActiveSync settings and begin the process again. If the iPhone already has a passcode configured, the user will need to enter it at this time to begin installing the profile. During installation of the profile the user is prompted for his/her AD password to connect to their mailbox, as shown:

Enter the AD password, tap Return, and then tap Next to complete installation of the profile. When the profile has been successfully installed, tap Done. The user can now close Safari. If a device lock passcode has been configured in the Exchange ActiveSync Policy, the iPhone will display a message that the user must accept the new policy. It will then prompt the user for a passcode using the complexity requirements specified in the EAS policy. It may take a few minutes to complete synchronizing the user's email, calendar, contacts and tasks for the first time. If at any time in the future the user needs to re-install the ActiveSync Profile on the iPhone (for example, after a hardware reset or software restore), simply follow these steps again. Removing the ActiveSync Profile If the user wants to remove the ActiveSync Profile, follow these steps. Removing the ActiveSync profile also removes the user certificate from the iPhone. Tap Settings on the iPhone home screen and then tap General. Scroll to the bottom and tap Profiles. Tap the profile to remove and then tap Remove. If the iPhone has a passcode configured, it must be entered to remove the profile.

Reverse Proxy Scenarios

Some environments secure their Client Access Servers from direct Internet communication using Microsoft ISA, Threat Management Gateway (TMG) server, or another reverse proxy solution. In these scenarios, the public ActiveSync connection and authentication is made at the reverse proxy. The reverse proxy then proxies the authentication to the internal CAS server(s). The CAS servers, themselves, act as reverse proxies to the mailbox servers. With an environment such as this, you need to install the certificate and private key on the reverse proxy server(s). The reverse proxies need to be configured to require client certificates and use Basic Authentication. They must then pass the certificate, username, password to the CAS servers to complete the connection. This diagram should help.

I hope this series helps you with the deployment of iPhones in your Exchange ActiveSync environment. I welcome your comments.

This concludes my series, How to Securely Deploy iPhones with Exchange

ActiveSync in the Enterprise. Other articles in this series: How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise Phase 1 - Building the CA Phase 2 - Configuring ActiveSync and Active Directory Phase 3 - Publishing User Certificates to Active Directory Phase 4 - Creating the iPhone Configuration Profile Phase 5 - Creating the Web Site for iPhone Profile Deployment Phase 6 - End-User Deployment of the ActiveSync Profile Posted by Jeff at 5:38 AM Labels: ActiveSync, Exchange, iPhone, Microsoft Exchange 2003, Microsoft Exchange 2007, Microsoft Exchange 2010, tip 23 comments: Anonymous said...

Outstanding series! Thanks for taking the time to do this!!March 3, 2010 5:46 PM

Anonymous said...

It works!!! I followed your steps exactly and it works perfectly. Thank you so much for writing this up. It must have taken you a long time to do. We decided to have our remote users install the iphone configuration utility to create their device hardware profile and email it to us so we can create the profiles. That way they don't have to bring the iphones into the office. Works perfectly! Shame on Apple for not having clear instructions like yours... I can't believe you're doing this for free.March 14, 2010 4:43 PM

Jeff said...

Thanks! I'm glad it's working out for you.March 14, 2010 4:46 PM

Anonymous said...

Jeff, we are moving from blackberry to iPhone because they are "cooler" according to management and i've had a pain in my head just thinking about the implications of this project but you have just made my weekend, i'm going to sleep soundly and i'm almost looking forward to getting started on monday. very comprehensie and very well thought out, thank you very much in advance. regards, Kev from IrelandApril 23, 2010 4:58 PM

Jeff said...

Thanks for the kind words, Kev. Have a nice shot of Jameson's for me!April 23, 2010 5:05 PM

rq said...

Excellent article - well written. I do have one question for you though. We are exploring the use of the iPhone configuration Utility as a means to lockdown iPhones/iPads in use in the Organization. While we can deploy the profiles via the methodologies outlined here or other

means, our testing has shown that the User can simply turn off the mail app under Settings and we no longer can see the device in Exchange. Once we no longer see the device in Exchange, we lose the ability to remote wipe the device should it get lost/stolen. We logged a case with Apple and they confirmed the behavior, although they seemed a bit surprised it was that easy. They suggested that we could edit the XML config file to possibly remove the ability to turn off the mail app (grey out the button much like Parental Controls does for Location), but since we do not have an Enterprise Agreement, they would charge us $695 for the custom config with no guarentee it would work other than they would put forth a "best effort". Have you considered how to remove the users ability to simply turn off the mail app (or the thieve/finder of the device) should it be lost? Any insight would be appreciated!April 28, 2010 7:23 PM

Jeff said...

Thanks for the comments, RQ. This behavior isn't any different than a Windows Mobile device. If the user unconfigures ActiveSync on a WinMo device it can no longer be remotely wiped. I'm not aware of any way to prevent this on WinMo, except possibly using System Center Mobile Device Manager. I would advise the best practice is to enforce a passcode on the device to prevent someone from disabling ActiveSync, and to remotely wipe the device as soon as the device is confirmed lost.April 29, 2010 9:54 AM

rq said...

Jeff:

Understood. That means that both WinMo and Apple have a bit to go to match the security that a BES does for RIM devices. Although it could be said that it is a fault of the ActiveSync protocol itself since the ability to permanently attach a profile to a active sync mobile device does not exist (Android also suffers this same issue but to a greater degree). Even MobileMe appears to have the same problem: if you turn off MobileMe or remove the account, then remote access is removed as well. Using a passwork lock on the screen is a usable work around (and was a suggestion by Apple support), but does not prevent an authorized user from turning off the mail account either inadvertantly or maliciously. Thanks for the insight! I shall continue to persue other angles and I will be implementing your deployment steps outlined in this article this weekend (just for fun!) rqApril 29, 2010 11:38 AM

Jeff said...

Actually, it's because WinMo and iPhones are not email only single task devices. The Blackberry device is basically useless without email service. The iPhone and WinMo device is not. If a user should delete the EAS agreement, the Exchange email, calendar and contacts are deleted from the device anyway. At that point it becomes less of a security issue.April 29, 2010 11:47 AM

Kalpesh said...

Hi Jeff, Can you confirm that every new device will have to have to be connected to the iPhone Configuration Utility to have a unique profile configured? Following this the user sets up their own account via the deployement website? Kind RegardsMay 10, 2010 1:54 AM

Jeff said...

Hi Kalpesh, Yes, each iPhone will need to be physically connected and checked into the iPhone Configuration Utility. That's the way that the iPhone's unique device ID is captured in order to encrypt the unique iPhone configuration profile. Once the iPhone has been checked into the iCU and the profile is created, the rest of the process is done over the air from the iPhone. If it's impossible or difficult for you to physically check the iPhone into the iCU, you can have the user download the iCU and check their iPhone into it. Then have them send you the [long device id].deviceinfo file in the "%userprofile%\Local Settings\Application Data\Apple Computer\MobileDevice\Devices" folder of their computer.May 10, 2010 7:34 AM

Kalpesh said...

Thanks for that Jeff, Great series of articles and should definitely be officially documented in some form or the other. Just a couple of questions: 1. In Phase 1 we generate a PFX file to import into the ICU. But we

dont seem to use it later on in the project. In Phase 3 we publish the Activesync.cer file (without the private key) to AD. As a result, the Certificate wasnt available in the ICU at Phase 4. I manually imported that file as a workaround. Have I missed a step? 2. This is an open question. Does anyone know if we would be able to disable basic authentication with this implementation? My organisation has to be PCI compliant and our network scans report back a failure because we have Plain Text Authentication enabled on our Exchange servers. I tried to disable it after following this article but it just threw up authentication errors on the iPhone! Thanks again for this - its been a real help!May 11, 2010 3:30 AM

Jeff said...

Kalpesh, The certificate and private key that are exported to a PFX file in Phase 1 are used when you want to create a new Mobile Messaging Administrator. Admins need to have both the cert and private key in their online personal certificates store to include in the iPhone configuration profiles (iCP). The new admin will need to double-click the PFX file and supply the password to import the cert and private key. I updated the documentation in Phase 1 to reflect this. The ActiveSyncUser.cer file published to AD in Phase 4 must match the cert and private key in the iPhone configuration profile for EAS client certificate authentication to work. It sounds like you created the iCP from a different computer (or user) from the one where the certificate was requested and installed. Import the PFX file so it can be used in the iCP creation. ActiveSync requires Basic authentication. There's no way around that it's part of the code. The mitigation is that it's SSL encrypted and, in our case, requires client certificates. This provides two-factor authentication which is stronger than most online banks use. I would think this would satisfy any PCI audit.May 11, 2010 8:01 AM

Mark said...

Hi Jeff great article ! in the section Reverse Proxy Scenarios - you state the reverse Proxy (ISA servers) needs to be configured to require client certificates and use Basic Authentication. Our ISA servers in the DMZ are not domain members and I believe client certs offload to ISA will not work. With the phones hitting reverse proxy first can authentication with client certs still first occur on the CAS servers?May 13, 2010 7:31 PM

Jeff said...

Hi Mark, In your case, the client's EAS connection terminates at ISA. ISA then proxies the client's connection to the Exchange CAS servers to complete the EAS connection. That means that ISA needs to present the same client certificate that you installed on the iPhone. You create a listener on ISA for EAS that requires the iPhone client certificate. You then configure ISA to present the iPhone client certificate along with the basic auth credentials to the CAS. There is no need for ISA to be a domain member.May 13, 2010 8:13 PM

Jason said...

Jeff, Hi, thank you for taking the time to document this procedure.

We have a Exchange 2007 setup (CCR / 2 CAS servers) and ISA 2006 using FBA to authenticate our users for OWA. I am a bit confused with the ISA configuration in regard to the private certs and the listeners. Do I have to import in each individual private cert into the ISA server? Is there a unique listener that needs to be setup? i thought only 1 cert can be bound to a listener in ISA. Our ISA server is part of AD. If you please elaborate on the ISA configuration, it would be most appreciated.May 17, 2010 6:45 PM

Jeff said...

Hi Jason, You only need to use one cert on the ISA server. It's the same one you use on the iPhones. The listener should be configured to require a user certificate (the iPhone user cert) and authenticates with the CAS servers using the same certificate. This only works when your ISA server or array is a member of a domain. I haven't set this up with ISA 2006, but it should be pretty straight forward. Take a look at http://technet.microsoft.com/enus/library/bb794722.aspx.May 17, 2010 8:05 PM

Jason said...

Jeff, Thanks for the quick reply. The main issue I can see with ISA2006 is that OWA required Forms Based Authentication for Port 443 as the

Listener. From what I understand, Active-sync is hard coded to 443. If I try to setup a listener with the user cert, ISA complains that you cannot have 2 listeners on the same port/IP address. Perhaps as a workaround I could register another name such as 'activesync.company.com' registered to a different IP address which would allow a unique listener. Another potential issue is that it does not appear I can import in a user cert into the listeners in ISA, only a web server cert. If anyone reading these posts has successful set this up with ISA 2006, any hints/tips would be most appreciated.May 17, 2010 8:21 PM

Jeff said...

My colleague, Michael Noel, recommended reading http://www.isaserver.org/tutorials/Publish-Microsoft-Exchange-ActiveSync-EAS-ISA-Server-2006-Part1.htmlMay 17, 2010 10:58 PM

Mark said...

Jeff, I've implemented your solution - thanks for the info - well done ! Would I be correct in saying that the user cert and Domain password are stored on the iPhone and you could call that 2 factor? CheersJune 7, 2010 10:14 PM

Jeff said...

Two-factor authentication is something you have (the client certificate) and something you know (the user password). The cert is installed on the iPhone in the iPhone profile. The password is entered by the user when they configure ActiveSync.June 7, 2010 10:20 PM

Damian Gunner said...

Jeff, Great article, you might be interested in this if you haven't seen it: http://mobilitydojo.net/2010/05/19/securing-exchange-activesyncwith-client-certificates-lan-access/ and http://mobilitydojo.net/2010/05/20/securing-exchange-activesyncwith-client-certificates-wan-access/ I don't see why it won't work for iPhones, however there is the hassle factor of creating iPhone profiles for each user whereas your solution avoids that but has two-factor authentication - both solutions have their merits imo.June 8, 2010 5:37 AM

Anonymous said...

Is it possible to expand the use of this infrastructure so you can also allow users with Windows Mobile or other devices to connect but control their access and the devices they use?June 17, 2010 5:07 AM

Jeff said... This solution will work with any mobile device that supports Exchange ActiveSync and user certificates for authentication.

Because we embed the user certificate in the iPhone profile, we control which devices and users can access ActiveSync. Windows Mobile doesn't support embedding the user cert, so there's nothing to prevent an EAS user from "sharing" the user cert with an unauthorized user or device. June 18, 2010 9:50 AM