Re: Changing NT/2000 accounts password from the command line

From: Russ (Russ.Cooper_at_RC.ON.CA)
Date: 07/18/01


Just to provide a bit of insight into how messages make it onto the
list, and to provide a little explanation that some people seem to
have missed;

1. When I read this message the first thing I told Alberto was that
in NT the ability of *any* user to attempt to change *any other*
user's password is controlled by the policy "User must be logged in
to change password". This according to the MS Platform SDK. Since he
didn't mention whether or not he had that policy in effect (on the
machine or Domain Controller responsible for the account he's
attempting to change), I pointed it out as a possible reason why he
saw the behavior that he did.

2. W2K operates differently than NT in this regard, and the way it
operates is dependent on what function call is being made. So I asked
Alberto what call he was using to do what he has seen.

3. Alberto indicated that he used NetUserChangePassword. Under W2K
this call should be restricted, by default, to Administrators and
members of the Account Operators group only. The ACL can be changed,
however, to widen the scope but since Alberto didn't make any mention
of that we assume no such change has taken place (he writes security
tools for NT, so I'd expect him to know this already).

Ergo, if he's seen what he says he has seen (and I've no reason to
doubt his claim), then there's a problem in the way the function call
NetUserChangePassword is implemented in W2K (no apparent problem in

W2K differentiates between "Query" security functions and "Update"
security functions. According to the Platform SDK,
NetUserChangePassword is an "Update" security function.

- From the SDK;
- -----
For queries, the default ACL permits all authenticated users and
members of the "Pre-Windows 2000 compatible access" group to view
information. For updates, the default ACL permits only Administrators
and account operators to write information.

Note By default, the "Pre-Windows 2000 compatible access" group
includes Everyone as a member. This enables anonymous access
(Anonymous Logon) to information if the system allows anonymous
access. Administrators can remove Everyone from the "Pre-Windows 2000
Compatible Access" group when installing a domain controller.
Removing Everyone from the group restricts information access to
authenticated users only.

Anonymous access to securable objects can also be restricted by
setting the following key in the registry to the value 1. (This is
also referred to as the RestrictAnonymous policy setting.)
- -----

So if we accept the SDK, then NetUserChangePassword should only be
able to be performed by Administrators and members of the Account
Operators group. But we know that a user can change their own
password without having to be a member of either group, so clearly
something's different about NetUserChangePassword.

So, not knowing precisely how NetUserChangePassword actually
executes, I applied simple logic. Before a password can be changed by
that call its necessary to check whether or not the password supplied
is currently valid. This could be done in a variety of ways, but
basically it is likely a simple "query". If the query succeeds (the
supplied previous password is valid for the account specified), then
the call flows to an "update", actually changing the user password.

- From the SDK snippet above, we know that the "Everyone" group,
including anonymous, is able to do a query security function
(assuming the AD was created in compatibility mode, otherwise the
Everyone group is not part of that group). So its logical that the
query part might succeed while the update part would fail, especially
since the supplied previous password isn't likely valid (until it

Since the error responses are descriptive (ERROR_ACCESS_DENIED,
reasonable to assume you could garner information about the users on
a machine/domain using this form of attempt.

Of course since the SDK documentation about NetUserChangePassword
isn't clear, and doesn't appear correct (not mentioning that users
can change their own passwords without being a member of either
Administrators or Account Operators), is it not also possible that
the function call works as Alberto describes?

After all I read and what I considered about the claim, I thought it
was possible, so I passed it on to you.

As to how serious this is, that's another kettle of fish altogether.
Might be that its simply a matter for the SDK documentation to be
clearer. Might be that some people begin auditing password change
attempts more vigorously. Might be that someone finds their entire
company user list is locked out one morning.

Just thought you'd like to know.

Russ - NTBugtraq Editor

Version: PGP Personal Privacy 6.5.2


Delivery co-sponsored by Trend Micro
If you would like to know about a virus outbreak before CNN and ZDNet get
Trend Micro Virus Info Feed FREE. Simply copy and paste a small piece of
code to give your visitors a real-time top 10 list and the latest virus
advisories. Setup takes just 10 minutes and requires no server-side code on
your Web site. All content is updated automatically from Trend Micro's Web