I am slowly working my way through email and ran into a question that I seem to get rather often and the answer actually bothers me.
The email asked:
“Quick question.
What all attributes do I have to give a user permission to in order to set the password when creating an account? I can create the account up to the point where I enter the password. It says insufficient rights to set password, but creates the account in a disabled state. Everything else with the account looks fine.
Thus far, I gave it rights to the 4 pw attributes, useraccountcontrol and pwdlastset. I know i’m missing something just not sure what.”
The answer to the question, what rights do I need to grant to create an enabled user are simply
1. Create Child for the type of object you need to create, in this case user class objects. This permission needs to be applied to the OU (or OU’s) that you want the delegated group to be able to create the user in.
2. Reset password for user class objects.
The thing that bothers me about this is that I shouldn’t need #2. I should be able to just create the object with a password and enabled if I want without having explicit Reset Password… I mean I am creating the object hello and I can set all of the other attributes at creation, why not unicodePwd? What point in creating objects that you can’t actually use?
Done?
Hmmm maybe not… Some of you are probably scratching your head and thinking, the old bird is off his perch… You cannot create an enabled user with just those two permissions configured… Hmmm…. Nope I am not off my perch. I am just used to using a tool that can create users with the minimal necessary permissions – AdMod. It will allow you to create an enabled user with a single ldap_add function call. Those of you who use ADSI or by extension ADSIEDIT or ADUC are not able to do this, there is an add call and then some updates that follow along. That means you have to give out even more permissions. Specifically you need to additionally grant at least:
3. Write Property (WP) to userAccountControl for user class objects
In many instances you may have to grant
4. Read Property (RP) to userAccountControl for user class objects
as well if you have locked down security a little[1]. This is because ADSI seemingly[2] won’t let you set something you cannot read. If you want to expire the user ID so the user immediately has to change their password, you will also need to grant
5. WP to pwdLastSet for user class objects
and again possibly
6. RP to pwdLastSet for user class objects
Again, AdMod only needs those first two permissions and really should only need the first.
joe
[1] Like you have cleaned up Pre-Windows 2000 Compatible Access.
[2] I say seemingly because maybe it can if you wheeze and utter the opening to the Rings trilogy while thinking of Star Trek Voyager episodes that feature 7 of 9[3] it can be done but thankfully I am not dependent on ADSI… I love the LDAP API which is not, let me repeat, is NOT the same as the LDAP:// ADSI provider even though they look the same in name. The .NET framework can do real LDAP but I expect most NET apps by default are using the stuff that thunks down to the LDAP:// ADSI provider which then eventually thunks down to real LDAP. On the positive side, your hand has been held and you have likely been protected from doing something incorrectly… On the negative side, you can no longer afford the lollypop you wanted due to the overhead and poor conversion rate of your currency.
[3] All of which combined turns out out to be one of the more powerful geek prayers.
do you need reset pwd if you set pwd_not_required?
Yes.
Even if you set pwd_not_reqd and you don’t specify a password, a password is being set in the background… it is simply blank. Check the metadata, you will see password attribs set with version info.
Which begs the question: How do you figure the required perms for a given operation? I was recently wanting to allow computers to be able to rename themselves in AD. After much trial and error and a few (un)intelligent guesses, I narrowed it down to granting Self perms to “Write Computer name (pre-Windows 2000)” and “Write Account Restrictions”. I’m sure there HAS to be a faster way. If you’re bored, I’d settle for an app like Filemon that tells me specifically what failed when I get an access denied error.
Scotte: The best place to start is to look at the delegation whitepaper. I understand there are issues in it but at least it is a start. From there, I use network tracing as one of the primary mechanisms for figuring things out. Unfortunately, for multiple part ops, MSFT isn’t good at identifying everything that is failing, just one thing. If you see the actual update request and all of the attributes involved it is pretty easy, otherwise it can be quite trying.
Hey Scotte, I think about what I’m doing and jott down all the permissions I think I need (minimum permissions). I then grant those permissions, and enable full control failure auditing for the account i’m using. I then try the op and look at the security logs to see what failed, and take it from there…
This has only failed me once, in which case I’ll be doing what Mr. Richards recommended – tracing via NetMon as well as Failure auditing.
–Paul