Even though you say you checked the group memberships, it really sounds like your "admin" account doesn't have the same group memberships as the "Administrator" account.
The Windows "whoami.exe" (not the Cygwin whoami) with the "/ALL" parameter will show you each user's group memberships so that you can compare them.
(In theory, it would be possible to modify the permissions of user objects in AD to deny the "admin" user rights to change their password while still having "admin" be members of the same groups as "Administrator", but I think that's highly unlikely.)
To rule out anything to do with the cygwin SSH altogether, why not logon locally to the server comuter with the "admin" credential and try your "NET USER" from an NT command prompt?
Edit:
There really isn't any kind of group policy setting that affects the ability to change passwords, per se. If your "admin" account is a member of "Enterprise Admins" it should be able to reset the password of any other account in the Active Directory. Like I said above, there are "tweaks" that one could have made to AD that would change that behaviour, but I find it highly unlikely that any of that would've been done. I think that something else is happening.
If you don't have failure auditing of account management events enabled, now is a good time to either create a new GPO linked to your "Domain Controllers" OU (the preferred) or to modify your "Default Domain Controllers" GPO (not preferred-- you really shoild leave this GPO "stock) and turn on account management event failure auditing. Dig down into "Computer Configuration", "Windows Settings", "Security Settings", "Local Policies", and "Audit Policy" and enable failure auditing on "Account management".
Run a "gpupdate" on your domain controller comptuers, try your "NET USER" again, and examine the Security Event Log on all your DC's to see which one is recording the failed password change.
I'm keen to figure out what's going on. Like I said, I expect that it's something simple that's being overlooked... We'll see...
I asked this question over on SO and it got moved here. That said I no longer have the ability to edit the question as if I owned it, or even accept the correct answer, but this turned out to be the true reason why and how to solve it:
Found here User "rohandhruva" on there gives the right answer:
This happens if you change the
hostname during the install process.
To solve the problem, edit the file
/etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 <ADD_YOURS_HERE>
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 <ADD_YOURS_HERE>
Best Answer
I think you're confusing two commands:
sudoandsu.sudoallows you to run a single command as another user.suallows you to switch to another user.So, when you've signed in as your normal user, if you want to issue a single command as root, you should use sudo:
This will ask for your password.
Likewise, if you want to issue a command as user
jimbob:This will also ask for your password.
If you want to switch to the root user:
This will ask for the root password.
It is highly recommended that you always use
sudoto run privileged commands, though, instead of switching to another user.