“Password changes using the Outlook Web Access app causes domain accounts to be locked out. What can we do?”
This question arose during a discussion in a Windows 7 Enterprise Deployment Class. Although not directly related to Windows 7 Client issues, I decided to take a crack at tracking down an answer for our student. The problem appears to be common, although the symptoms and the root cause reportedly vary widely.
There may be related Windows 7 (or Windows 8) client deployment issues though the more likely issue is the configuration and integration allowing the Outlook Web Access (OWA) Change Password feature itself.
From a Windows 7 or Windows 8 client perspective, all the related documentation suggests that OWA change password requires the use of Kerberos Authentication for user accounts. If you enable certificate based authentication, or one of the more powerful multi-factor authentication mechanisms supported by Windows 7 and Windows 8 Enterprise platforms, you probably want to disable the OWA Change Password feature as it only affects a synchronized reset of the Kerberos password.
The OWA Change Password feature is different across Microsoft Domain servers and Exchange platforms. The key solution will be based upon a common and consistent domain environment with little mixing of Active Directory domain servers, Exchange Server, or IIS delivery platform versions. You will also want to consider a business policy restricting access to OWA from specific platforms, although enforcement will be problematic.
To be honest, the varied requirements suggest a rather complicated solution even with a common, and comprehensive Microsoft Enterprise Domain environment.
For Exchange server 2003 Implementing the Change Password feature with Outlook Web Access, the OWA password reset feature is supported for IIS 4.0, IIS 5.0. and IIS 6.0 via the IISADMPWD virtual directory, though this directory is created and configured differently for each platform. You must also obtain and configure an SSL certificate for the IIS server, and make a number of precise registry configuration changes. Related operating platforms also require a specific set of hotfixes.
Exchange server 2007 RMT/SP1/SP2/SP3 Configuring the Change Password Feature in Outlook Web Accessdoes not require the IISADMPWD virtual directory, instead using Active Server Pages (ASP), along with Windows Server 2008 and IIS 7.0. By default the Change Password feature is enabled in the Exchange Client. An additional feature (Microsoft Internet Security and Acceleration Server 2006) is required if you want to enable password reset both before and after a Domain password has expired. Exchange server 2007 passwords support a broader range of Domain policy settings, but you should still limit your Domain policy to the set enabled by OWA if you want to use the Change Password feature and assure password synchronization.
Configuring the Change Password Feature in Outlook Web App for Exchange Server 2010 SP2/SP3 Configuring the Change Password Feature in Outlook Web App has been simplified, though still has integration limitations and specific requirements. The OWA Change Password can more easily be configured on a per user basis, for multiple users via the OWA virtual directory, or using segmentation Configure Segmentation in Outlook Web App. This might allow experimentation or isolation of password synchronization problems based on policy sets and password characteristics. Rather than referencing a dozen great articles here, search for “owa change password exchange 2010” at Bing.com or your favorite search engine. Although the Change Password feature is more powerful, or perhaps because of the added power, support for expired passwords and enhanced features requires additional setup that is not enabled by default.
Per all the above referenced articles, three types of Account policies are found in Windows server 2003 or 2008 domains: password policies, account lockout policies, and Kerberos authentication protocol policies. The policies apply to all users in the domain, including Outlook Web App users. Although there may be exceptions, the indicators fairly strongly suggest that Domain policies should be created and maintained with your specific OWA platform and all related policy limitations in mind if there is a desire to use the OWA Change Password feature.
There are several caveats and other interpretations as you read through TechNet articles and other related posts:
- Using Basic or forms-based authentication with OWA, extended ASCII or Unicode characters List of Unicode characters should NOT be used in passwords, since they may not be transmitted correctly between IIS and some web-browsers. Some of the special characters used in ‘strong’ passwords may therefore be invalid, or transmitted incorrectly thus causing password mismatches when subsequently entered via an alternate medium (for instance direct login to a work station). Based on lockout policy, the client may discover that they have inadvertently locked themselves out of the system.
- Password synchronization problems can be compounded through the use of mobile devices that access OWA. Multiple scenarios arise.
- Using Basic or forms-based authentication with OWA, extended ASCII or Unicode characters FAQs: Sign-in and Password Issues Among them multiple access attempts from a mobile app that is using a prior or expired password, and multiple apps attempting to simultaneously use the same account and password. While Microsoft suggests the use of Domain Account Lockout Policy, the recommended settings are different if your Enterprise uses OWA synchronization
- Using Basic or forms-based authentication with OWA, extended ASCII or Unicode characters Enabling Account Lock Out after Failed OWA Login . For instance, you want to allow five or more failed attempts before lockout. There is a more detailed discussion at Spiceworks [http://community.spiceworks.com/topic/226990-domain-account-locking-out-after-password-reset].
- The use of cached or local credentials can result in a password mismatch, particularly on mobile (laptops, notepads, etc.) or intermittently connected devices. There is one related discussion on Neowin
- Using Basic or forms-based authentication with OWA, extended ASCII or Unicode characters Neowin Forum. Recall that user credentials are stored (typically locally unless roaming profiles are used) when the user properly logs out of the OS, and that machine credentials are stored when the system is properly shut down. The use of the credential manager as a single sign-on solution is another possibility. I have experienced this scenario myself when I change my domain password on a domain desktop at a regular cycle and then fail to login to my laptop until I am on the road. I have had to force updates or resort to a local account until I could get my domain account reset while connected to the domain. Although OWA Change Password synchronizes with the AD Domain, the initial password change is made locally rather than directly to the Domain.
While doing the research for this blog, I did find one tool that may bear some exploration. ADSelfService Plus Active Directory Change Password Tool by Manage Engine is promoted as a tool that enables Domain password reset by the end user. This might be an alternative to password reset via the OWA Change Password feature without all the complication of custom settings and local registry changes.
Oh yes, and Merry Christmas, Happy Holidays, and a Great New Year as well.