Skip to main content

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).


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


Popular posts from this blog

Automating IP addresses with TMG

In the past few months I've had the "opportunity" (note the quotes, maybe I'll write a post about all the troubles I've run into) to deal with some Office 365 integration projects.

When integrating one or more cloud services with Office 365 or Office 365 with on-prem Exchange, it is typical to limit the IP addresses that are aloud to communicate between services. This is an important layer on the security model and obviously reduces the attack surface. Microsoft maintains lists of IP addresses for the various services here:

That page links to other pages with more specific information about various other Microsoft cloud services such as the link below for Exchange online. for example.

At the time of this writing, you'll notice that the lists are inconsistent between pages. >:-(

Microsoft on two separate Premier Support Calls has told me…

Windows Last Logon problem and solution

As someone who has been involved in Network Administration (in Microsoft Land) since Windows NT 4.0, I find it surprising that is still so difficult to get simple (yet important) information such as "When was the last time Joe User logged in?".

One would think that, with the fourth edition of Active Directory in production (Windows Server 2008 R2), a tool or set of tools would have been issued with Windows to provide those answers.  Well, because they don't, I've decided to go ahead and write one.  (Yes, I know that there are probably others out there to be downloaded or purchased but... you know, I don't care.)

All that is required: PowerShell 2.0 (and a functioning Active Directory).

Defining the Problem:
Active Directory stores numerous properties on objects in the Directory. Some of these properties are replicated amongst the Domain Controllers and some are not. Unfortunately, for some reason, one of the design decisions was to not replicate the "LastLogo…

LDAP and SAN Certificates

Hey everyone - I ran across an interesting problem with certificates and services. The problem was that I needed to see which certificate is being presented to the client on a non-HTTPS service; specifically - binding to LDAP over SSL (LDAPS). So the question is, how can you be sure what certificate is being presented?

Windows, so far as I've been able to find, does not offer any native help in this regard. Luckily there is a solution, but first let me give you a slightly longer description of the scenario so you can appreciate what we're talking about a little bit better.

An environment exists with some number of Domain Controllers, let's say ten. Within this environment, third party applications (think Java apps, Linux systems, etc) need to bind to LDAP to enumerate groups or validate authentication or whatever. These systems, however, can only have a single (or at best, two) LDAP hosts configured. What do you do? Pick two DCs? Round-Robin DNS?

Well, in my case, a load-b…