Appendix: Setting User Account Control Policy for Delegated Administrators

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2

As outlined in Chapter 5: Establishing Secure Administrative Practices, establishing a delegated service administration model through the use of a controlled subtree and organization units (OUs) at the domain level is an effective starting point for setting a secure domain policy. One additional point to consider is that delegated service administrators who are able to create and set user and computer objects can own modification of attributes for those object which can have unintended consequences.

For example, without further administrative control, a delegated administrator might be able to do the following in violation of domain policy for a user account they are delegated the ability to create:

  • Set the user account to not require a password.

  • Undo expiration of a password on a user account where the current password has aged beyond the allowed duration, thus enabling the user to not have to change or update their password as intended.

  • Enable storing of clear text password in a reversibly encrypted format.

How User Account Policy Violations Occurred in Windows 2000 Server Prior to SP4

For administrators to accomplish these types of violations, delegated administrators first create user and computers objects under a certain OU. This allows those administrators management over the user and computer objects they are delegated authority to create or own within the controlled OU.

By default, these administrators can modify any attribute on the user or computer objects they own, including the userAccountControl attribute. Flags in this attribute control how a user can change their password and how other aspects of password management operations work at the user object level.

By manipulating these flags, delegated administrators could permit user and computer objects attributes to be modified to allow exceptions to the domain wide password policy. For example, if on a user object the PASSWD_NOTREQD bit flag has been set as part its userAccountControl attribute, that user can change his password to blank even though domain wide password policy might state that the minimum password length is 6 characters.

How Controlled Access Rights to User Accounts Are Enforced in Windows 2000 Server SP4 and Later

To enable better enforcement of user password policy to remain at the domain level and limit the ability of delegated service administrators in controlled OUs, several controlled access rights (CARs) checks were added for Windows 2000 Server SP4 and later. These CAR checks are applied at the domain root and specified against the following bit flags for the userAccountControl attribute for all user objects within the domain regardless of OU subdelegation within the domain. The following list below details the specific flags of interest.

Name Description

PASSWD_NOTREQD

This flag determines whether a password is required or not for the user.

DONT_EXPIRE_PASSWORD

This flag determines whether password expiration is enforced for the user.

ENCRYPTED_TEXT_PWD_ALLOWED

This flag determines whether a user password is stored in reversibly encrypted form or not.

Because the ability to reliably enforce password policy at the domain level is essential, additional corresponding security checks were added in Windows 2000 Server SP4 and later versions of Active Directory. Specifically, the following extended control access rights checks were added to assist domain administrators in controlling unintended override to user account attributes that violate or circumvent domain user and password policies. These checks are applied by Active Directory at the domain root object. Each extended control access right corresponds to one of the problems that was specified previously.

Before any attempt to update the bit flags on the userAccountControl attribute (i.e. those specified in the previous table) is dispatched by the directory service, an access check is triggered. The access check examines whether the current user (or client) is allowed to complete the desired operation or not.

The following table gives the detail of the operations and results of how the directory service performs these access checks when certain operations are performed on the userAccountControl attribute for user objects. For more information, see How to use the userAccountControl flags to manipulate the user account (https://go.microsoft.com/fwlink/?LinkId=140090).

Extended Control Access Rights (in Windows 200 Server SP4 and later) Operations subject to access check Operation result

Update Password Not Required

Any attempt to modify this flag in userAccountControl attribute on an existing user object.

Operation fails with access denied error if desired control access right is not held. Otherwise, returns success.

   

User creation

If desired control access right is not held, user account will still be created but with PASSWD_NOTREQD bit set to 0 – off. Otherwise, user account will be created with this bit set to 1. In both case, user creation API will return SUCCESS.

Unexpire Password

  1. Any attempt to Unexpire Password, (Note – expiring password is not subject to this DS access check) including:

  • Set PwdLastSet attribute to max value FFFFFFFF,FFFFFFFF through LDAP or NET API

  • Password change or set operation, and client also sets password should remain unexpired in the same operation.

  • Set DONT_EXPIRE_PASSWORD bit in userAccountControl attribute to 1

Operation fails with access denied error if desired control access right is not held. Otherwise, returns success.

   

Password change or set operation, but client does not indicate password should remain unexpired.

If desired control access is not held by client, user account password will still be changed or set, but the new password remains expired. Otherwise, newly changed or set password remains unexpired. In both cases, password change or set operation returns success.

Enable Per User Reversible Encrypted Password

Any attempt to toggle ENCRYPTED_TEXT_PWD_ALLOWED bit in userAccountControl flags on user and computer objects.

Operation fails with access denied error.

Note

These control access rights (CARs) checks are only performed for domain users when operating in directory service mode and not for local user accounts. Computer objects are not subject to the access checks on the PASSWD_NOTREQD or DONT_EXPIRE_PASSWORD bits because such checks could cause application compatibility issues.

Modifying the default security setting

By default, all three CARs are granted to Authenticated Users on the domain root object. Permissions can be restricted to limit the ability to set these rights to either full administrators or delegated administrators for the domain, as described in the following procedure.

To restrict the ability to set the CARs to domain administrators

  1. Open Active Directory Users and Computers. To open Active Directory Users and Computers, click Start, click Control Panel, double-click Administrative Tools, and then double-click Active Directory Users and Computers.

  2. On the View menu, click Advanced Features.

  3. In the console tree, right-click the domain node, and then click Properties.

    Where?

    • Active Directory Users and Computers/domain node
  4. Click the Security tab.

  5. In Group or user names, select Authenticated Users.

  6. In Permissions for Authenticated Users, scroll to view each of the following, and then click the Deny check box for each:

    • Enable Per User Reversibly Encrypted Passwords

    • Unexpire Password

    • Update Password Not Required Bit

  7. In Group or user names, select Domain Admins.

  8. In Permissions for Domain Admins, scroll to view the following, and then ensure that the Allow check box for each of the following is selected:

    • Enable Per User Reversibly Encrypted Passwords

    • Unexpire Password

    • Update Password Not Required Bit

    Note

    As an alternative, you may want to assign these rights to delegated administrators. To do this, perform steps 7 and 8 for the delegated administrators group instead.

  9. Click OK.

Controlling OWF Password Policy

The Security Accounts Manager (SAM) in Windows Server has an API which provides a method for changing passwords using the One Way Function (OWF) format. Once OWF password hash is sent to server through this API, SAM has no way to enforce domain wide password policy. This is because a clear text password cannot be derived from an OWF formatted password. This feature presents a possible way for users to work around domain password policy.

For Windows 2000 Server SP4 and later, a registry value was introduced to control how the OWF password change API behaves at the server when attempts to set or change passwords are received that are sent and formatted using the OWF password change API.

The details of this registry value are as follows:

  • Key KEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa
  • Value name SamRestrictOwfPasswordChange
  • Data type REG_DWORD
  • Allowed values 0, 1, 2 0 - Client can change password through OWF password change API, and the new password remains unexpired. 1 - Client can change password through OWF password change API (SamrChangePasswordUser), but the password expires immediately. This is the default behavior for Windows 2000 Server SP4 and later. 2 - Client use of the OWF password change API is prohibited at the server. This API (SamrChangePasswordUser) will be totally disabled and return STATUS_ACCESS_DENIED for all clients except for LocalSystem and members of builtin administrators group. This setting can provide some additional security.

Summary

  • None of the restrictions discussed in this section are applied to the built-in System service account or for members of the built-in Administrators group for the domain.

  • If the registry value does not exist or it exists but does not contain a valid value, the default value of 1 is used.

  • This registry-based security setting is an independent control. It does not interactive with the control access rights checks discussed in the previous section.

  • The feature can work for either domain users or local users depending on the role of the server computer. If set on a domain controller, it applies to domain users. If set on a member server, it applies only to local user accounts on the server computer where it is set.