How to Securely Deploy iPhones with Exchange ActiveSync - Phase 3 - Publishing User Certificates to Active Directory

Monday, March 1, 2010
This 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=860EE43A-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:

20 comments:

  1. Thanks for the interesting and informative post. I look forward to more in the future.

    ReplyDelete
  2. Thanks! Namescape is a pretty nice product, BTW.

    ReplyDelete
  3. 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?


    Thanks

    ReplyDelete
  4. 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.

    ReplyDelete
  5. 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?

    ReplyDelete
  6. 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.

    ReplyDelete
  7. 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?


    Thanks

    ReplyDelete
  8. No, the CA we configured in phase 1 is a certificate server on the internal network. It is not the OWA server.

    ReplyDelete
  9. 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?

    ReplyDelete
  10. 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?

    ReplyDelete
  11. 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.

    ReplyDelete
  12. 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.

    ReplyDelete
  13. 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?

    Thanks

    ReplyDelete
  14. 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.

    ReplyDelete
  15. Jeff,
    Question about changing the password: As you mentioned, the user has two options to synchronize the password it has been changed in AD: 1. Change the password from the prompt and 2. modifying it directly in the Settings. However, we have found that when working with Certificates, the password cannot be updated in the iphone, when it is inserted directly at the prompted screen; it can only be manually updated from Settings in the iPhone.
    I am wondering if you also have noticed this behavior (or there is something different in my configuration).
    Any advice on how to force the password synchronization, when the update is done from the prompt, will be appreciated.

    ReplyDelete
  16. That is not the behavior I see. If the password is changed in AD, I can change the password in email account settings on the iPhone to match the AD password and it works fine.

    ReplyDelete
  17. Yes, it works when you go to account settings, however it is failing when the password is inserted in the dialog box that automatically pop-ups after the AD password change.

    ReplyDelete
  18. Again, that isn't what I see. I can update my password from the dialog box, too, and it works.

    ReplyDelete
  19. Hi Jeff,

    Is it best practice to use the same user certificate for AD user accounts? Or are you just simplifying the administration over head when creating the iCU profile?

    Regards,
    RS

    ReplyDelete
  20. Hi Jeff,

    I just wnated to comment and let you know that if you have the CA as part of the domain you can publish the public certs directly to AD.

    Also if you setup a certificate on the Iphone/Ipad it uses THAT certificate to make the connection to Exchagne. So if I create a Cert using my credentials (exchange admin) then ALL users will be able to see ALL mailboxes.

    I think the fact that you set this up to use a stand alone CA (not part of the domain) has given you the option to use one cert at a different level.

    So this means that I need to create and publish a seperate cert for each user so they only use their own permission to access the Exchange server. (I think this is what the commenter was reffering to on March 7)

    ReplyDelete

Thank you for your comment! It is my hope that you find the information here useful. Let others know if this post helped you out, or if you have a comment or further information.