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…
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.
EAS Policy Name |
Description |
Correlation to Group Policies |
||
|---|---|---|---|---|
AllowSimpleDevicePassword |
Specifies whether the user is allowed to use convenience sign-in methods like pin, picture password, or biometrics. |
There are three sets of Group Policies that control pin, picture password, and biometrics. These policies must be set to allow non-administrator accounts to become compliant without requiring an administrator action. Pin Policy setting: Turn on PIN sign-in Location in the Local Security Policy snap-in: Computer Configuration/Administrative Templates/System/Logon/ Picture Policy setting: Turn off picture password sign-in Location in the Local Security Policy snap-in: Computer Configuration/Administrative Templates/System/Logon/ Biometrics Policy settings:
Location in the Local Security Policy snap-in: Computer Configuration/Administrative Templates/Windows Components/Biometrics/ Note For client devices running the supported versions of Windows, if the Pin or Picture Group Policy setting is applied to bring non-administrator accounts into compliance, it is necessary to set the registry key that corresponds to DisallowConvenienceLogon, which is HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System\DisallowConvenienceLogon. |
||
MaxInactivityTimeDeviceLock |
Specifies the length of time a device can go without user input before it is locked. |
Policy setting: Interactive logon: Machine inactivity limit Location in the Local Security Policy snap-in: Computer Configuration/Windows Settings/Security Settings/Local Policies/Security Options/ |
||
MaxDevicePasswordFailedAttempts |
Specifies how many times an incorrect password can be entered before the device is rebooted. The device may be put into lock mode, which requires the recovery key to unlock the device in the presence of disk encryption. |
Policy setting: Interactive logon: Machine account lockout threshold Location in the Local Security Policy snap-in: Computer Configuration/Windows Settings/Security Settings/Local Policies/Security Options/ |
||
MinDevicePasswordComplexCharacters |
Specifies the minimum number of complex characters that are required for a password. |
Policy setting: Password must meet complexity requirements Location in the Local Security Policy snap-in: Computer Configuration/Windows Settings/Security Settings/Account Policies/Password Policy/ |
||
MinDevicePasswordLength |
Specifies the minimum password length. |
Policy setting: Minimum password length Location in the Local Security Policy snap-in: Computer Configuration/Windows Settings/Security Settings/Account Policies/Password Policy/ |
||
DevicePasswordExpiration |
Specifies the length of time after which a user password must be changed. |
Policy setting: Maximum password age Location in the Local Security Policy snap-in: Computer Configuration/Windows Settings/Security Settings/Account Policies/Password Policy/ |
||
DevicePasswordHistory |
Specifies the number of previous passwords that cannot be reused. |
Policy setting: Enforce password history Location in the Local Security Policy snap-in: Computer Configuration/Windows Settings/Security Settings/Account Policies/Password Policy/ |
||
RequireDeviceEncryption |
Specifies whether device encryption is required. If set to True, the device must be able to support and implement encryption to become compliant. Note Encryption cannot be enabled by the EAS policy engine, and an explicit user action is required to turn on encryption, if it is not already running |
There is no Local Security Policy or Group Policy Administrative Template that corresponds to this EAS policy. An explicit action is required to encrypt a device if this policy is required. |
.jpeg)
NoteFor 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
Note
Microsoft accounts were formerly known as Windows Live ID 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.
Note
The option to reset security policies is present only if policies are applied by the EAS policy engine.
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.
Warning
Disabling EAS policies will reduce security effectiveness.
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.
Content type |
References |
|---|---|
Product evaluation |
This topic |
Planning |
None |
Deployment |
None |
Operations |
|
Troubleshooting |
None |
Security |
None |
Tools and settings |
Security policy settings reference: Password Policy |
Community resources |
None |
Related technologies |