Blog Post

Exchange Team Blog
8 MIN READ

Enforcing security settings on mobile devices with Exchange 2003 SP2

The_Exchange_Team's avatar
Jun 20, 2005

Note: This article refers to the policy mechanism of Exchange 2003 SP2, it does not apply to Exchange 2007. For information on how to manipulate Exchange 2007 policies, look for PowerShell tasks named ActiveSyncMailboxPolicy.

People in charge of IT departments want the ability to force users to have certain settings on their mobile devices. This usually includes things like requiring that the user enters a PIN (Personal Identification Number) before being able to use the phone. If the user forgets his phone in the Starbuck's restrooms, the person finding it won't be able to do much without knowing the PIN.

The upcoming Exchange 2003 Service Pack 2 (SP2) includes some enhancements in this area.

Where does the admin go to set those policies? It's in Exchange System Manager, under Global Settings / Mobile Services / Properties / General tab / Device Security button.

ESM will store this data in the Active Directory on the following object:

         CN=Outlook Mobile Access,CN=Global Settings,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=...
Most of the settings are in the msExchOmaExtendedProperties attribute, it is a multi-valued string which could, in the future, contain more than just policy stuff, so we gave the policy information prefixes to recognize them. Here's an example of what it would look like.
         PolicyData:<wap-provisioningdoc>Settings are here</wap-provisioningdoc>
         PolicyDataSalt:M9RNvCWoW0WISbLT90QNbg==
         PolicyKey:4321
         PolicyDataRefreshInterval:1440c

Most of the settings are stored in the string prefixed "PolicyData:". The values from the ESM dialog are encoded between the <wap-provisioningdoc> tags. That XML blob is in a format that is understood by the CSP modules of Windows Mobile devices, and it looks like:

<wap-provisioningdoc>
    <characteristic type="SecurityPolicy">
        <parm name="4131" value="0"/>
    </characteristic>
    <characteristic type="Registry">
        <characteristic type="HKLM\Comm\Security\Policy\LASSD\AE\{50C13377-C66D-400C-889E-C316FC4AB374}">
            <parm name="AEFrequencyType" value="1"/>
            <parm name="AEFrequencyValue" value="5"/>
        </characteristic>
        <characteristic type="HKLM\Comm\Security\Policy\LASSD">
            <parm name="DeviceWipeThreshold" value="20"/>
        </characteristic>
        <characteristic type="HKLM\Comm\Security\Policy\LASSD">
            <parm name="CodewordFrequency" value="5"/>
        </characteristic>
        <characteristic type="HKLM\Comm\Security\Policy\LASSD\LAP\lap_pw">
            <parm name="MinimumPasswordLength" value="8"/>
        </characteristic>
        <characteristic type="HKLM\Comm\Security\Policy\LASSD\LAP\lap_pw">
            <parm name="PasswordComplexity" value="0"/>
        </characteristic>
    </characteristic>
</wap-provisioningdoc>

We're looking at providing a simpler alternative in a future version of the server. For now, if you want to generate your own policies, you'll have to generate this XML. Everything in the XML is hard-coded, except for the content of the "value" attributes. The meaning of which depends on the "name" attribute of the "parm" object (I love how they save 1 byte by removing an 'a' from 'param', but then use things like "HKLM\Comm\Security\Policy\LASSD\AE\{50C13377-C66D-400C-889E-C316FC4AB374}").

Here's how the XML elements map to the UI:

• The "Enforce password on device" checkbox maps to the name="4131" (don't ask me where 4131 comes from, I don't know). And it uses the value of "0" for enabled and the value of "1" for disabled (intuitive, isn't it?). If the checkbox is disabled, the rest of the settings are meaningless, so they are not included.
• The "Minimum password length" maps to name="MinimumPasswordLength" and is simply the minimum number of characters in the PIN. If the checkbox is unchecked, the value becomes 1. Remember that this setting is present only if a PIN is required, so a minimum length of 1 is implied anyway.
• The "Require both numbers and letters" checkbox maps to name="PasswordComplexity", the possible values are: 0 = Require alphanumeric, 1 = Require only numeric, 2 = Anything goes. ESM will only set values 0 (when checked) or 2 (when unchecked).
• The "Inactivity time" maps to name="AEFrequencyType" and name=" AEFrequencyValue". AEFrequencyType of 0 means there is no inactivity time (checkbox unchecked) while 1 means there is (checkbox checked) and the number of minutes is in AEFrequencyValue.
• The "Wipe device after failed (attempts)" maps to name="DeviceWipeThreshold". A value of -1 means the checkbox is unchecked, otherwise it's the number of failed attempts at entering a PIN before the device wipes all memory.

You then might be wondering what name="CodewordFrequency" means. First, "DeviceWipeThreshold" protects you from a hacker who "borrowed" your phone and is trying to guess your password. The memory will be wiped after a few attempts. On the other hand, "CodewordFrequency" protects you from your 3-year-old offspring. If little Timmy grabs your phone while you're reading the newspaper, and starts entering PINs at random, he could wipe your phone's memory! To prevent that, the phone will prompt Timmy to enter a certain "codeword" (it even tells you what the codeword is). Since most 3-year-olds can't read, he won't get to try more PINs. There is no UI in ESM for this setting, we set it to half of DeviceWipeThreshold, but no higher than 8.

Before I explain the other "PolicyXXX" strings, I need to explain how/when that policy data is sent to the device.

When the device tries to execute an Exchange Active Sync (EAS) command (synchronizing a folder, fetching an attachment, etc...) it will also send an X-MS-PolicyKey string in the HTTP headers of the request. The server looks at this policy key and compares it with the string that follows "PolicyKey:" in the multi-valued attribute above. If they don't match, the server will tell the device that it must issue a PROVISION command before it is allowed to execute any other command (the server does that by returning an HTTP status code of 449).

Every time ESM modifies the policy settings, it also modifies the "PolicyKey:" string. Once the device issues that PROVISION command, it will be given the policy data. The device must then send a second PROVISION command to confirm that it has successfully applied this policy. The server then answers the new policy key string that the device can use in X-MS-PolicyKey to execute other commands.

If the admin wants to, she can force devices to re-issue a PROVISION command every X hours (see "Refresh settings" in the UI). That refresh interval value is stored in the "PolicyDataRefreshInterval:" string (in number of minutes). To enforce this interval, the server needs to answer a 449 whenever it's been too long since the device last applied the policy settings. The server stores the timestamp of the last successful provision command in the user's mailbox, in the non-IPM subtree (so Outlook doesn't show it) along with a bunch of other information the server needs to maintain for each device.

There's still one more string I haven't explained: "PolicyDataSalt:". Since users have full unrestricted access to their own mailboxes, somebody could write a simple application that would continuously update the timestamp in the user's mailbox (using MAPI or DAV) so that the server always thinks the device has recently refreshed its policy. We must prevent users from tampering with that timestamp. To that end, we sign the timestamp by also storing its hash, but to make that hash non-guessable, we need to add random data to it. That's what the "salt" is; it's simply random bytes (base64 encoded). Users won't have access to it, so they can't generate a valid hash to sign the timestamp. The salt should only be created when the first policy is set, no need to change it when the policy changes (it would invalidate all the hashes).

If you look at the UI again, there are still two things I haven't covered: "Allow access to devices that do not support password settings" and the "Exceptions" button.

The first one is what we refer to as "loose" enforcement, meaning that if a device doesn't know anything about policies and the provision command (we know that by the absence of any X-MS-PolicyKey header), we would normally answer a 403 (Forbidden) HTTP response to any command. But if you have this checkbox checked, we will allow such devices to execute commands. Only devices that do send X-MS-PolicyKey will be required to apply policies. This is to provide a transition period for companies that have both old and new devices and don't want to lock out all their old devices. That option is not stored in the same multi-valued attribute like the other policy settings, it is stored as bit 0x00000010 in the msExchOmaAdminWirelessEnable attribute. The bit is set to 1, if the policy is to be enforced "loosely".

The last option is the Exceptions. This allows the admin to choose a list of users who are not required to apply the policy settings. Maybe only a handful of users have old devices, maybe the CEO doesn't like having to enter a PIN every time he uses his phone, etc... The server knows a user is exempt from policy settings, if bit 0x00000020 of msExchOmaAdminWirelessEnable is set to 1. But when ESM wants to display the list of exempted users, it needs an attribute it can query on (LDAP doesn't support searching for individual bits), so exempted users also have "PolicyDataExemption:true" added to the msExchOmaAdminExtendedSettings attribute (another multi-valued string) of the user object in the Active Directory.

I'll let you in on a little secret... even though ESM only let's you set policy settings on the global "Outlook Mobile Access" object; you can actually store them on this msExchOmaAdminExtendedSettings attribute of the user objects in the same way. The server will look for those "PolicyData:", "PolicyDataSalt:", etc... strings on the user object first, if it doesn't find it there, it then looks at the global object. This way you can override policy settings for individual users. But note that if one of those strings appears on the user object, they all need to be there. The server won't take some of the strings from the user object and others from the global object.

- Patrick Tousignant

Published Jun 20, 2005
Version 1.0
  • Great! More information about Exchange 2003 SP2.

    Patrick Tousignant blogs about the new mobile security...
  • Up on the Exchange Blog, I know you have already read it before reading this, but you should read this...
  • looks good can't wait to see it in action.

    How does this security compare with RIN/Blackbery?
  • I don't really know what security features backberries have (I do not own one), so I can't really make a fair comparison.
  • The official Exchange blog has some more information on Exchange 2003 SP2 leaking out.&amp;nbsp; In particular,...
  • Hello Sir,

    I wonder if anyone has actually thought this through. There has been a huge deal about this feature but this solution as presented here is far from complete or usable.

    One policy for the whole of the Exchange organization???? Corporations such as I work in have many different business units with different needs and requirements spanning many countries. All these business units can comfortably fit into an Exchange organization due to the well thought out way of organizing administrative rights models and per server (if required) policies for the managment of mailboxes and server settings. Overall, Exchange is very flexible across a diverse business landscape.

    Why o why would you implement a one size fits all policy for all mobile devices? It seems remarkably out of place compared to the other flexibility embodied in the product.

    Rather I would have liked to see Windows Mobile devices be able to join the domain and we can set policies with GPO's against them.

    The current proposed method looks like a poor mans hack to try and steal some thunder from the well developed policy model that Blackberry uses. Windows Mobile and Exchange is capable of so much more than the Blackberry platform. Why settle for such a simple solution un-implementable solution?

    Sandor.
  • We are very aware of that. But...

    This is a service pack feature. And in a service pack, as a rule, we do not upgrade the Active Directory schema, so we couldn't add a per user mechanism configurable through GPO.

    That said, we did add a way to set the policy XML on each user (read the last paragraph of the post), it's an all-or-nothing deal, so it's not quite perfect, but that's all we could do given our AD restrictions.

    The next version of Exchange will have those settings on the user object and be manageable through GPO (or any other policy mechanism that can deal with AD settings). The debate on whether or not to create a Mobile Device AD object is still on-going, but the settings will be configurable, at least, at the user level.
  • &amp;nbsp;Software / Hardware&amp;nbsp;

    PalmSource has shifted it&amp;rsquo;s engineering efforts to focus on...