Exchange ActiveSync Policy Engine Overview

Applies To: Windows 8.1, Windows Server 2012 R2, Windows Server 2012, Windows 8

This topic for the IT professional describes the Exchange ActiveSync policy engine and lists resources for using it.

Did you mean…

• Exchange ActiveSync

• Security Policy Settings

Feature description

The Exchange ActiveSync (EAS) policy engine was introduced in Windows Server 2012, Windows 8, and Windows RT to enable apps to apply EAS policies on desktops, laptops, and tablets to protect data that is synchronized from the cloud, such as data from an Exchange Server. It supports a core set of Windows security primitives.

Practical applications

The EAS policy engine contains a set of WinRT APIs that enable Windows Store apps to manage security primitives on devices. The policies supported by the EAS policy engine include password requirements, inactivity timers, sign-in methods, and disk encryption status. The policy engine enables you to check device status and if the status conforms to your policies. Windows Store apps can leverage the EAS policy engine APIs to verify and enforce these policies.

The Exchange ActiveSync (EAS) protocol is an XML-based protocol designed to synchronize e-mail, contacts, calendar, tasks, notes, and policies between Exchange Server and a client device. The EAS policy engine can enforce a subset of the policies defined in the EAS protocol on devices running any of the supported versions of the Windows operating system (listed in the Applies To list at the beginning of this topic).

How it works

Supported devices

Devices, including servers, desktops, laptops and tablets, that are running the supported versions of Windows and are capable of installing a mail app from the Windows Store can enforce EAS policies.

Available device information

A mail app that is using the EAS policy engine also has the ability to read device information and report it to the Exchange Server. Following is a list of device information that is available:

• A unique device identifier called Device ID or ID

• Name of the computer

• Operating system running on the device

• System manufacturer

• System product name

• System SKU

Policies supported by a mail app and EAS policy engine

To synchronize data from an Exchange Server, the mail app first applies security policies on the client device. A mail app can apply a core set of these policies by using WinRT APIs in the EAS policy engine.

The EAS policy engine has the ability to check for policies applied on a device and check if the accounts on that device conform to these policies. It can also enforce policies related to sign in methods, password, and device inactivity.

The EAS policy engine does not support all of the policies specified by the EAS protocol in MS-ASPROV. Particularly, policies that pertain to storage card access, mail retention, and S/MIME are not supported. For more information see, [MS-ASPROV]: Exchange ActiveSync: Provisioning Protocol in the MSDN Library. Following is a list of all the supported policies.

For more information about each policy, see Use Exchange ActiveSync Policies for Device Management.

About password policies and accounts

Password policies help prevent a malicious user from accessing content on the device by requiring a password. This is also true for computers or devices that have one or more administrator accounts. Because administrators can potentially access data for other accounts, is it necessary that all administrator accounts adhere to password policies, even if EAS policies are not applied.

If password policies are applied, all administrator and all control user accounts are required to conform to password requirements at the next sign in or unlock action. In addition, if an administrator account has a blank password, a compliant password must be applied before the computer or device can be compliant to synchronize with Exchange data.

EAS protocol defines DevicePasswordEnabled, which is not directly supported in the operating system. If an Exchange Server sets DevicePasswordEnabled, apps that apply these policies are expected to set some of the underlying password policies with default values. These policies include length, complexity, history, expiration, and failed attempts.

MaxDevicePasswordFailedAttempts is set with a default value of 4. In the presence of BitLocker or Device Encryption, incorrect password attempts will result in a restart followed by device lock. If the disk is not encrypted, the device will restart to slow down casual brute-force attacks.

Administrator or user accounts that are disabled are set to change the password at the next sign in. But because they are disabled, they are considered to be compliant.

Password history and expiration apply only at the time a local user account password is evaluated or changed. They are only required to be locally enforced. These policies are not enforced for domain or Microsoft accounts. Microsoft accounts and Active Directory domain accounts have varying policies that are enforced on the server; therefore, they will not be bound by the policies from an EAS policy.

Password length and complexity supported by account types

Password length and complexity policies are evaluated and applied on different account types differently.

Local accounts

Current local account and all administrator accounts are required to have a password, if the EAS policies set minimum password length or complexity, or both. Failing to meet this requirement results in non-compliance. When password length and complexity rules are applied, all the control user and administrator accounts are marked to change the password at the next sign in to ensure complexity requirements are met.

Local accounts can support the full password length policy, but they can only support three character sets, not the full four that EAS protocol can specify. If an EAS policy is set to require four character sets, all local accounts will become non-compliant. This is because the Windows operating system does not explicitly support choosing the number of complex characters in a password; rather, it requires that passwords meet a certain complexity level. This complexity translates to three complex characters. Therefore, an EAS policy that requires MinDevicePasswordComplexCharacters greater than 3 cannot be supported by Windows accounts.

Local accounts default to a minimum password length and complexity policy ratio of 6 and 3 when any password policy is set. Complexity requirements are enforced when passwords are changed or created. All security threats over the network on accounts with a blank password are mitigated. However, when a user sets a password for a local account, the account is immediately vulnerable to password guessing or other password attacks over the network. So, to mitigate threats through network access, minimum requirements are set for local accounts, which provides a reasonable level of security.

Domain accounts

Domain accounts are not evaluated locally for password policies that are set by EAS because it is assumed that the EAS policies and the domain account policies belong to the same account authority. These policies include complexity, length, expiration, and history settings.

Microsoft accounts

Much like a domain account, a Microsoft account is governed by a policy authority that is not related to a local device. Properties including password complexity, length, expiration, and history are part of the Microsoft account.

Microsoft accounts enforce a minimum password length of 8 characters and 2 character sets in a password. Therefore, Microsoft accounts can comply if the MinDevicePasswordLength policy is set at less than or equal to 8 characters and the MinDevicePasswordComplexCharacters policy is set at less than or equal to 2.

A password can still conform to the EAS policy rules, but nothing can prevent a user from creating a less-complex password for the Microsoft account. Non-compliance results if EAS policies are stricter than those that Microsoft accounts can enforce.

Expiration and history are not evaluated locally for Microsoft accounts.

Policy application on administrator and standard user accounts

EAS policies are applied to all administrator accounts, regardless of whether they have an app configured to use EAS policies.

EAS policies are also applied to any standard (non-administrator) account that has an app configured to use EAS policies. These accounts are called control user accounts. The EAS policy, MaxInactivityTimeDeviceLock is the exception because it is not applied to accounts, but rather to the device.

Policies specified by different sources

Given a set of policies that are enforced by Exchange ActiveSync, Group Policies, a Microsoft account, or local policies, the Windows operating system always enforces the strictest policy out of the set of governing policies.

Multiuser support

Windows provides for multiple users on a single device. Windows Live Mail also permits multiple EAS accounts for each user. When there are multiple EAS accounts with policies set on a device running any supported version of Windows, the policies are merged into the most restrictive resultant set.

EAS policies do not apply to all users on a device running Windows. Windows restricts standard user accounts in their ability to access data in other user profiles or in privileged locations. For this reason, EAS policies do not apply uniformly to standard users. The policies apply only to standard users who have a configured Exchange account that requires an EAS policy.

Accounts for users with Administrator rights always have the EAS policies applied.

Windows only provides a mechanism to apply a single instance of the EAS policies. Any account that is subject to an EAS policy is controlled by the strictest policy applied to the device.

Policy reset

To prevent an app from reducing security policies and posing a risk to the device, a policy cannot be reduced, even if the policy no longer exists on the server. A user must take action to reset policies in the event of policy relaxation, policy removal, account removal, or an app removal.

Policies can be reset by using the Control Panel. Click User Accounts and Family Safety, click User Accounts, and click Reset Security Policies. Users can also use Reset Security Policies to reset an EAS policy that causes an email delivery failure.

EAS policies and provisioning refresh

Exchange servers can force users to provision devices and reapply policies after a certain period of time. This ensures that if the device is no longer compliant with EAS policies, the policies are reapplied or the device is deemed non-compliant.

The Windows Mail client does not enforce the provisioning refresh, so it is the responsibility of the EAS administrator to make sure that if a policy change occurs, the provisioning refresh is triggered within a given time frame.

A provisioning refresh can be controlled by setting the Refresh Interval policy in the Exchange ActiveSync Mailbox Policy settings. For more information about setting the refresh interval, see View or Configure Exchange ActiveSync Mailbox Policy Properties.

Device lock

The supported Windows operating systems provide data protection through BitLocker Drive Encryption. When combined with password policies and the MaxDevicePasswordFailedAttempts policy, Windows Live Mail provides a robust data protection scheme to limit the risks of data loss due to device loss or theft.

Although many mobile devices support a complete removal of device content when a remote instruction is received or when the MaxDevicePasswordFailedAttempts threshold is reached by a user, the supported Windows operating systems do not.

The device lock feature in the supported Windows operating systems enables devices that are encrypted with BitLocker to cryptographically lock all encrypted volumes and reboot the device into the recovery console. A lost or stolen device is not readable unless the device recovery key is available to the possessor of the device.

The device lock feature provides protection for lost or stolen devices and provides a means for legitimate users who accidentally enter the device lock state to recover their device and continue using it.

Autologon behavior

Implementation of EAS policies prevents users from using the Autologon feature. Autologon permits the credentials of the signed on account to be encrypted and stored in the registry so when the computer is restarted the user’s account is automatically signed in using those stored credentials. Autologon is useful when administrators are required to sign in to a computer multiple times during configuration, or when a user has secure possession of their personal computer and desires an easier ability to sign in.

When EAS policies are implemented, autologon does not function by default and the user who is attempting to sign in must enter their account’s credentials. If autologon behavior is desired, the EAS policies must be disabled.

For more information about this downloadable tool, see, Autologon.

New and changed functionality

The EAS policy engine was introduced in Windows Server 2012 and Windows 8.

In Windows Server 2012 and Windows 8, Biometrics sign-in methods do not count towards the limits set in the MaxDevicePasswordFailedAttempts policy. In Windows Server 2012 R2 and Windows 8.1, if the device is encrypted using BitLocker or any other disk encryption software, Biometrics sign-in methods are not disabled when the limit is exceeded if the DisallowConvenienceLogon policy is set.

Software requirements

The EAS policy engine and its policy implementation is supported only on versions of the Windows operating system designated in the Applies To list at the beginning of this topic.

Additional resources

The following table provides additional and related information about the Exchange ActiveSync policy engine, including policies and APIs.