I answer this question a lot on the newsgroups - "How do I delegate enabling and disabling Active Directory accounts?". The long and short of it is you can't. More precisely you can't without delegating access to set a whole bunch of other stuff. The enabled/disabled flag is set as part of a larger bitmask which controls various other properties of a user account.
The attribute that this is stored in is the userAccountControl bitmask which is on every user account. The vast majority of options in this bitmask are the checkboxes that you see on the account tab of ADUC:
The complete list of what's stored in the bitmask (copied out of the iads.h header) is below. Most of them should be fairly self explanatory but this MSDN article explains them all. The numbers are the bit which represents this value in the mask (in hex):
- ADS_UF_SCRIPT = 0x1
- ADS_UF_ACCOUNTDISABLE = 0x2
- ADS_UF_HOMEDIR_REQUIRED = 0x8
- ADS_UF_LOCKOUT = 0x10
- ADS_UF_PASSWD_NOTREQD = 0x20
- ADS_UF_PASSWD_CANT_CHANGE = 0x40
- ADS_UF_ENCRYPTED_TEXT_PASSWORD_ALLOWED = 0x80
- ADS_UF_TEMP_DUPLICATE_ACCOUNT = 0x100
- ADS_UF_NORMAL_ACCOUNT = 0x200
- ADS_UF_INTERDOMAIN_TRUST_ACCOUNT = 0x800
- ADS_UF_WORKSTATION_TRUST_ACCOUNT = 0x1000
- ADS_UF_SERVER_TRUST_ACCOUNT = 0x2000
- ADS_UF_DONT_EXPIRE_PASSWD = 0x10000
- ADS_UF_MNS_LOGON_ACCOUNT = 0x20000
- ADS_UF_SMARTCARD_REQUIRED = 0x40000
- ADS_UF_TRUSTED_FOR_DELEGATION = 0x80000
- ADS_UF_NOT_DELEGATED = 0x100000
- ADS_UF_USE_DES_KEY_ONLY = 0x200000
- ADS_UF_DONT_REQUIRE_PREAUTH = 0x400000
- ADS_UF_PASSWORD_EXPIRED = 0x800000
- ADS_UF_TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION = 0x1000000
So then what's my point in listing all this stuff out? If you delegate a user rights to modify the userAccountControl attribute, you give them rights to tinker with all these other options. In smaller shops I'll go ahead and do this as I'm just not as worried about side effects, but, at the same time I think a harder about who is getting the rights and if I trust them.
The preferred solution coming from my background of large enterprise environments is to setup some type of web based system which end users log in to and then execute the actions via the website. The website runs in the context of a user account which does have rights to modify the userAccountControl attribute. As part of this implementation the site determines the rights of the calling user (that is, the person logging in to the site) via some other mechanism, be it AD group membership, a SQL table, etc. It also implements event logging to a SQL table or something along that line for audit purposes.
The other question I have when someone asks me this question is what purpose they have for needing to delegate this right. There should be an automated process which takes care of user account provisioning (aka hire/fire) when users are terminated by HR. Even in small shops this can save a ton of time in the long run if someone invests an hour a day over the course of a week or a month and implements some automation. Any automation to make running a directory or any other IT component is well worth it.
So that bit said, here's the quick write up on how to do the delegation assuming you're comfortable with the risks involved. I'm going to use ADSIEdit (install the support tools from the Windows 2003 CD or the link):
I'm going to give a group called User Admins rights to modify the userAccountControl attribute on all User objects in the Sales OU in this example. As always, it's a best practice to never delegate a right to a user but rather to delegate a right to a security group which the user is a member of.
So the first step is to fire up ADSI Edit - start>run>adsiedit.msc
Browse down to the parent OU (or even the domain NC head if you want) and pull up the properties of it, hit the security tab, and then click advanced. Click Add and put in the name of the group you're going to delegate the rights to. At this point your screen should look something like this:
Hit OK and then switch to the properties tab of the ACL editor dialog that comes up. Select "User objects" from the Apply onto dropdown and scroll down to the userAccountControl entry. Tick the Allow checkboxes for Read userAccountControl and Write userAccountControl (technically the Read right is not necessary but I've chosen to include it in case default permissions have been modified elsewhere).
At this point you just need to wait for replication and populate the group you delegated the rights to if it isn't already populated. You can use the runas command line utility to test the functionality with a test account. Just launch "mmc" and add an Active Directory Users and Computers snapin to it.
It seems the KB article 305144 handles the same issue. I prefer yours as the explanation here is clear.