By the time a user calls the Help desk to ask for assistance with a forgotten password, Windows 2000 will likely have locked out that user's account as a result of several failed logons. To enable account lockout, you must select a check box on the Account tab of User Properties, as Figure 1 shows. As I mentioned in a previous column, you might want to create a HelpDeskStaff group and give your Help desk staff the authority to handle forgotten passwords without giving them sweeping administrative privileges. Along these same lines, you might want to grant them the authority to reset locked out user accounts.
At first glance, Win2K doesn't appear to provide authority to reset locked out accounts. But, in fact, you'll learn that it can be done. To demonstrate this point, open Active Directory Users and Computers and create a user account called TestUser. Select the Security tab, and click Advanced. Select any entry in the ACL, and click View/Edit. Win2K will display a window with two permission tabs, as Figure 2 shows. The Object tab shows permissions for the object as a whole, and the Properties tab shows individual property permissions. Notice that no permission exists to reset locked out accounts. If you experiment thoroughly, you’ll see that no object or property permissions have any affect on the Account is locked out check box. Unless you have "write all properties" permission on the target user object, the account lockout check box remains disabled. Unfortunately, granting this permission to the HelpDeskStaff group defeats the purpose of the group, because doing so provides almost full administrator-level access.
Without an account lockout permission, users have to wait for their accounts to automatically unlock according to your domain policy or call an administrator or account operator for assistance. Thankfully, however, Microsoft does provide total granularity for accessing AD objects, although the company has yet to document the process. Let's look at how you can delegate the authority to unlock accounts by granting write access to the lockoutTime property, which corresponds to the Account is locked out check box.
Resetting Locked Out Accounts
Microsoft realized that displaying the ACL information for every property in the ACL editor dialog box would be impractical because of the large number of properties that AD objects possess. For instance, a user object has more than 250 properties. Consequently, Win2K hides some properties, including lockoutTime, from view. Win2K uses a special file in %systemroot%\system32 called dssec.dat to decide which properties to hide and which to display in the ACL editor. Dssec.dat is a simple text file that you can edit with a typical text editor, such as NotePad. Learning the format of dssec.dat is easy. The file lists every class of object, such as Group, User, or Computer, followed by each property that you've defined for that class. A class listing begins with a header line in the format of the class name surrounded by brackets. For instance, to find the list for user objects, open dssec.dat with NotePad and search for "\[user\]." Underneath the header line you’ll see a cryptic line that says "@=7," as Listing 1 shows. This line indicates that the number seven means hidden. Notice the next few lines—they all contain the name of a property of the user object followed by "=7." As a result, these properties are hidden from the ACL editor when you view the permissions for a user object.
To reveal a property, you must change the number 7 to something else or delete that line of code altogether. To reveal the lockoutTime property, find its line in dssec.dat under "\[user\]," and change the 7 to an 8. Save the file and open Active Directory Users and Computers again. Maneuver back to the security page of TestUser, and click Advanced again. Click Add, select the HelpDeskStaff group from the list that appears, and click OK. You’ll now see a Permission Entry window in which you can grant access to this user object for the select group. Click the Properties tab and scroll down the list to see entries for read and write access to lockoutTime that did not appear before you edited dssec.dat. Grant HelpDeskStaff read and write access to this property, and close all the windows associated with this user account. Next, verify that you've enabled account lockout in your domain by opening Domain Security Policy under Administrative Tools and maneuvering to Windows Settings/Security Settings/Account Policies. Make sure that you've properly configured the account lockout duration, threshold, and reset values (e.g., five invalid attempts within 30 minutes locks out the account for 60 minutes). Then, log off and attempt to log on as TestUser with an incorrect password enough times to lock out the account—as though you’ve forgotten your password. Finally, log on as a member of the HelpDeskStaff group and open Active Directory Users and Computers. Now when you open the properties of the user object, you can unlock the account.
Taking a New Approach
It’s important to understand Win2K's access control so that you can delegate authority according to the proven concept of least privilege. Using AD permissions and
organizational units (OUs) can be confusing at first, not to mention understanding the
arcane details of dssec.dat. Just remember this analogy: You are already familiar with
managing user access to files using ACLs, and typically you manage file access at the
directory level. Now, just view users and groups as files, and OUs as directories.
Finally, remember that although you typically control user access to files, you typically
control sub-administrator access to users and groups. As you can see, Win2K does offer
total granularity of access control over AD objects. You can usually find permissions
corresponding to the level of access you want to grant already visible in the ACL editor.
However, if you need to manage access to specific properties that don’t appear in the
permission dialog box, just edit dssec.dat as I've described.
