Solved

net user weakuser newpa$$word /domain gets access denied - why?

Posted on 2014-03-18
8
509 Views
Last Modified: 2014-04-15
Hi experts.

First: please be aware that this question is not that easy and that wild guesses are likely to be ignored. You should try any suggestion yourself prior to making it.

Setup: Domain Controller on 2008 R2 or (if you like) on 2012 R2 (maybe 2003, haven't tested)
Clients: does not matter, anything you have
1) users may change their Password interactively using CTRL-Alt-Del
2) domain administrators may change anyone's password using the shell command
net user someuser newpa$$word /domain
3) standard users get "access denied" trying 2)

**now for the interesting part, the reason why I am asking**

4) standard users that use passwd.exe (a freeware alternative command line password changer) may successfully change their password.

Why is that so? What does passwd.exe do that net.exe cannot? Has Microsoft crippled net.exe for some reason?
--

Why do I need this: Because we would like to use script-based self-invoked password changing with standard user accounts and hoped not to use 3rd party utilities for that.

Find passwd.exe attached, change .doc to .exe
passwd.doc
0
Comment
Question by:McKnife
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 6
  • 2
8 Comments
 
LVL 54

Author Comment

by:McKnife
ID: 39938612
Edit: I am aware that the difference between net.exe and passwd.exe is fundamental: while net.exe does not need to know the old password, passwd.exe cannot do without. Effectively, that makes net.exe's action a password RESET, while passwd.exe SETS a password.

At the ACLs of the user objects I have  tried to modify granular permissions so the "self" account may reset the password but to no avail. Not before I gave full access to the "self" account could users successfully use net.exe.

Question is indeed: what granular permission is needed for RESET?
0
 
LVL 10

Expert Comment

by:Schuyler Dorsey
ID: 39938623
Net.exe does not allow standard user accts to submit password changes via this method by design.

http://support.microsoft.com/kb/149427
0
 
LVL 54

Author Comment

by:McKnife
ID: 39938633
Yes and no. While the symptoms are characterized correctly, MS does not mention that users may indeed reset their pw if they are only granted a certain access right to their own user object... which is what I am trying to find out.
What is needed to not only be able to change but to reset a password? "reset password" is present as granular privilege nut granting it does not change anything.
0
Use Case: Protecting a Hybrid Cloud Infrastructure

Microsoft Azure is rapidly becoming the norm in dynamic IT environments. This document describes the challenges that organizations face when protecting data in a hybrid cloud IT environment and presents a use case to demonstrate how Acronis Backup protects all data.

 
LVL 10

Expert Comment

by:Schuyler Dorsey
ID: 39938677
Once you tick the Reset Password right in ADUC, you have to use something that is LDAP aware to reset the user password.

Net.exe is not LDAP aware. So some admins use a vb script (with the ldap info populated) to do it.
0
 
LVL 54

Author Comment

by:McKnife
ID: 39938975
How come he can use net.exe if I give him full access to his own object?
0
 
LVL 54

Author Comment

by:McKnife
ID: 39967855
Schuyler Dorsey, why is net.exe only usable with full permissions on the object? If it were LDAP-aware, how would it use this "awareness"?
0
 
LVL 54

Accepted Solution

by:
McKnife earned 0 total points
ID: 39993410
No progress was made, closing.
To have at least done something, I have investigated how to workaround this using a powershell script - for anybody interested:
--
Function Set-AdUserPwd ([string]$user,[string]$pwd) {
    $objSearch = New-Object System.DirectoryServices.DirectorySearcher 
    $objSearch.Filter = "(SamAccountName=$user)"
    $allUsers = $objSearch.FindOne()
    foreach ($user in $allUsers) {
    	$o = $user.GetDirectoryEntry()
        $o.Invoke("SetPassword",$pwd)
        $o.CommitChanges()
    }
}
Set-AdUserPwd -user $env:USERNAME -pwd "Passw0rd"

Open in new window

0
 
LVL 54

Author Closing Comment

by:McKnife
ID: 40001111
No progress was made, closing.
0

Featured Post

Major Incident Management Communications

Major incidents and IT service outages cost companies millions. Often the solution to minimizing damage is automated communication. Find out more in our Major Incident Management Communications infographic.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This article outlines the process to identify and resolve account lockout in an Active Directory environment.
In-place Upgrading Dirsync to Azure AD Connect
Microsoft Active Directory, the widely used IT infrastructure, is known for its high risk of credential theft. The best way to test your Active Directory’s vulnerabilities to pass-the-ticket, pass-the-hash, privilege escalation, and malware attacks …
Attackers love to prey on accounts that have privileges. Reducing privileged accounts and protecting privileged accounts therefore is paramount. Users, groups, and service accounts need to be protected to help protect the entire Active Directory …

738 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question