Cannot change password if you use the UPN suffix

If you try to use the User Principal Name (UPN) (user name@UPN domain suffix) in the Change Password dialog box, you may receive an error message that states that the domain cannot be contacted or that the password is incorrect.

This symptom only occurs on a domain member with a user who has a UPN domain suffix that does not match the Active Directory DNS domain name. In this case, the explicit UPN suffix is used (alternative). The implicit suffix that matches the Active Directory DNS domain name is not used.

Note that this symptom does not occur if you only use the ordinary user name and you select the NetBIOS domain name in the Change Password dialog box (as with NTLM).

This behavior may occur when the built-in Authenticated Users group was removed from the organizational unit where the user account resides. By default, the computer account is a member of the Authenticated Users group. If you use the Change Password dialog box, the local computer account is used to resolve the UPN. If the Authenticated Users group was removed from the organizational unit that contains the user account, you cannot successfully change the password.

To work around this behavior, give the computer account read access to the organizational unit that contains the user account, or use the NTLM naming convention (NetBIOS domain name\user name) instead of the UPN.

This behavior is by design.

The behavior that is described in this article is likely to occur in a scenario where users are hosted in separate organizational units, and the users from one organizational unit have no rights to browse other organizational units that are beyond their own user container.

This type of configuration is referred to in the "Building Hosted Application Services using Windows 2000 and Active Directory" white paper. The white paper states that the Authenticated Users group was removed from the user's organizational unit permissions list and was granted user-specific permissions.

In addition to this configuration, provide customer-specific UPN domain suffixes for every hosting organizational unit. For more information about how to add UPN suffixes to a forest, click the following article number to view the article in the Microsoft Knowledge Base:

Problem

The white paper states that the Authenticated Users group was removed from the security property in the hosted organizational unit. A typical computer account is also a member of the Authenticated Users group, and because of this, no longer has access.

The change password window works in the computer account context to resolve the specified UPN user name (IDL_DRSCrackNames). In the specific constellation, that the chosen UPN domain suffix does not match the AD/DNS domain name, the computer account must be able to access the user properties for validation in the hosting organizational unit. This does not work because the computer account has no read access.

Afterward, the UPN domain suffix is treated as a separate DNS domain, and winlogon tries to obtain an LDAP server for it. The appropriate DNS requests are filed for _LDAP that contains the UPN domain name. This does not work because the problem is not DNS related.

Solution

• If the computer accounts are also hosted, group them together (AllComputers@Customer1), and then provide this group read access for the hosting organizational unit Customer1.
• If the computer accounts are not hosted, a trust to the domain where the computer accounts reside is necessary (and are grouped together as previously described).