Friday, August 23, 2013

Net User and Reset Password Delegation

Hey Folks - I ran into an interesting issue recently where a user who has been given the right to change the password for another domain user, could not do so.  Let me give you a bit of background.

I have a user (let's call him "Account Owner") who manages another account that is used to bind to Active Directory (over LDAPS). Let's call that account "Bind User".  So, Account Owner has the rights to change the password for Bind User.

I told the Account Owner that he could issue the following command to change the bind_user account password:

Net User Bind_User * /domain

I informed him that this command would prompt him for a new password and he could manage the account that way (so he didn't need to install any additional management tools). I told him that this should work from any computer to which he is currently logged on.  The problem, as it turns out, was that I was wrong.  But why?

To answer that question, I configured one of my labs so that I can reproduce the issue. I'll walk you through the issue and solution(s).

The configuration


I created a new user called "bind_user" in an OU called "Delegated Rights Users".



In the "IT Dept" OU, I have a user called "Account_Owner".

The first step is to adjust the bind_user such that Account_Owner can reset the password. So I added those permissions:

Allow CREATION\account_owner          SPECIAL ACCESS for pwdLastSet
                                      WRITE PROPERTY
                                      READ PROPERTY
Allow CREATION\account_owner          Change Password
Allow CREATION\account_owner          Reset Password

This means that, outside of resetting the password (which includes writing the pwdLastSet property), Account_Owner cannot make any adjustments. (This should have been the end of our configuration, or so I thought.)

Testing The Config

As I mentioned earlier, I had directed Account Owner to use the "Net.exe" command to reset the password. But he got the following error.


"Access is Denied" is a surprising result given the permission that Account_Owner has been granted. This raises a question - what other attributes is the "Net.exe" command trying to alter?

To find out, I created another user account called "bind_user_full" and granted Full Control to the "Account_Owner" account.  Next, I took a snapshot of the attributes prior to issuing the command.

Note: I used "get-aduser bind_user -properties * | fl * -force" with a transcript running to capture the attributes into a text file.

Once I'd issued the Net.exe command, I took another snapshot of the AD attributes so I could make a comparison and see what has been modified.

Here are the attribute that have changed on the bind_user_full account after I reset the password with Net.exe:

accountExpires (original value):9223372036854775807
accountExpires (new value):     0

logonHours (original value): NULL
logonHours (new value):      {255, 255, 255, ... }  an array of values

Modified (original value): 8/23/2013 10:09:57 AM
Modified (new value):      8/23/2013 10:18:43 AM

modifyTimeStamp (original value): 8/23/2013 10:09:57 AM
modifyTimeStamp (new value):      8/23/2013 10:18:43 AM

passwordLastSet (original value): 8/23/2013 10:09:38 AM
passwordLastSet (new value):      8/23/2013 10:18:43 AM
* pwdLastSet matches this value

uSNChanged (original value):  32873
uSNChanged (new value):       32876

whenChanged (original value): 8/23/2013 10:09:57 AM
whenChanged (new value):      8/23/2013 10:18:43 AM

As we can see, quite a few attribute were changed after issuing the "Net.exe" command to reset the password. To identify which attributes were changed by the Net command and which were changed by Active Directory, I performed the same comparison, except using the ADSI provider in PowerShell to change the password of the original account*.

*Note: Using PowerShell to change the password instead of the Net command is how I stumbled upon this behavior in the first place.


With the password having been changed through the ADSI provider, I performed the same comparison as before.

Modified (original value): 8/23/2013 9:41:28 AM
Modified (new value):      8/23/2013 10:35:07 AM

modifyTimeStamp (original value): 8/23/2013 9:41:28 AM
modifyTimeStamp (new value):      8/23/2013 10:35:07 AM

passwordLastSet (original value): 8/23/2013 8:57:09 AM
passwordLastSet (new value):      8/23/2013 10:35:07 AM
* pwdLastSet matches this value

uSNChanged (original value):  32847
uSNChanged (new value):       32880

whenChanged (original value): 8/23/2013 9:41:28 AM
whenChanged (new value):      8/23/2013 10:35:07 AM


This behavior is much more consistent with what I expected.  Apparently the Net command makes a lot of assumptions about what you mean when you give it a command.  (Another example is "net user username /active:yes /domain"  both unlocks the account AND enables it, if it is disabled. - that can be a bad thing).

Conclusion


So it seems that the Net.exe command is doing quite a bit more behind that scenes that I'd expected. I could continue to investigate, identify all of the attributes that it wants to change, and grant them but I find that approach distasteful.

Instead, I directed Account Owner to use the PowerShell method to change the password until I get an opportunity to put a decent script together for him.

G. Samuel Hays

No comments:

Post a Comment