You want to set permissions on attributes that do not show up in the default ACL Editor.
The ACL Editor shows only a subset of the object's attributes that permissions can be set on. These can be seen in the ACL Editor by clicking the Advanced button, adding or editing a permission entry, and selecting the Properties tab.
An attribute can have a read permission, write permission, or both, either of which can be set to Allow or Deny. If the attribute you want to secure is not in the list, you will need to modify the %SystemRoot%\system32\dssec.dat file on the computer running the ACL Editor.
There are sections for each object class, represented in square bracketse.g., [user]. Underneath that heading is a list of attributes that you can configure to display or not display in the ACL Editor. These are the first few lines for the [user] section:
[user] aCSPolicyName=7 adminCount=7 allowedAttributes=7
The value to the right of the attribute determines whether it is shown in the ACL Editor. The valid values include the following:
Both Read Property and Write Property are displayed for attribute.
Write property is displayed for the attribute.
Read property is displayed for the attribute.
No entries are displayed for the attribute.
If the attribute is not defined, then the default value (specified by @, if present) is used.
Much like the Delegation of Control Wizard, you can customize the attributes that are shown in the ACL Editor, but you still need to distribute the dssec.dat file to all computers that need to see the change.
A good example of when this recipe is needed is for delegating the ability to unlock accounts. This is common in larger organizations where you want to assign this task to the help desk without giving them additional rights on user objects. In this case, you need to set the lockoutTime in the [user] section of the dssec.dat file to 0.
MS KB 296490 (How to Modify the Filtered Properties of an Object) and MS KB 294952 (How To Delegate the Unlock Account Right)