| Downloads |
|---|
| 41551.zip |
EDITOR'S NOTE: Share your Windows and .NET discoveries, comments, problems, solutions, and experiences with products and reach out to other Windows & .NET Magazine readers (including Microsoft). Email your contributions (400 words or less) to r2r@winnetmag.com. Please include your phone number. We edit submissions for style, grammar, and length. If we print your submission, you'll get $100. Submissions and listings are available online at http://www.winnetmag.com. Enter the InstantDoc ID number in the InstantDoc ID text box.
When I heard that you could delegate Active Directory (AD) tasks, I wondered whether I could use this feature to give departments the ability to unlock user accounts and thereby lighten my Help desk staff's workload. I decided to give unlock rights to several people in each department: the department manager or supervisor, two people who start work early, and two people who work late.
I created an AD group that contained these people and followed the instructions in the Microsoft article "How To Delegate the Unlock Account Right" (http://support.microsoft.com/?kbid=294952) to grant unlock rights to this group. Although my solution worked, the users with unlock rights had to open the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, click the organizational unit (OU), select the user whose account needed to be unlocked, open the user's properties, and clear the Account is Locked out check box. In an attempt to simplify the task, I added the Active Directory Users and Computers snap-in to a new MMC. I then created a new Taskpad View that showed only the OU containing the users from the target department. I distributed this MMC to the users with unlock rights. This method was easier but still required five or more clicks to unlock a user's account. In addition, this method let the users with unlock rights easily view other users' properties (e.g., account expiration).
To solve the problem, I adapted the MMC I had created. I configured an Unlock User Account button (i.e., task) on the Taskpad View. When you select a user and click the button, the Unlock.vbs script, which Listing 1 shows, runs to unlock the user—whether or not the user was locked out. For tracking reasons, the script also writes an event to one of our servers, noting who unlocked whom and when.
For relevance and simplicity, I also pared down the MMC Taskpad View to contain only three columns: the username, logon name, and object type (i.e., User). I configured the Unlock User Account button to run the Unlock.vbs script, passing the username (i.e., the value in column 0) as arguments.
The script concatenates the username into a Lightweight Directory Access Protocol (LDAP) name (I couldn't easily find the LDAP name to pass as an argument), then sets the LockoutTime attribute to 0. Clearing the LockoutTime attribute unlocks the account.
The script then notes that the user's account is unlocked and records the transaction details in the domain controller's (DC's) event log in which the user is logged on. Because of the nature of delegation, users can unlock only user accounts in their own OUs—except administrator accounts or their own accounts. In my organization, we also let users unlock backup user accounts (e.g., for staff who dial in to check backups).
You need to ensure that the snap-in is secure before you distribute it. Set the correct permissions on the file and script to prevent users from authoring the file or script or changing either's contents.
Department staff, rather than the Help desk staff, can now unlock user accounts. This method is simple and requires just one program and one click.