Bug in Set-ADAccountPassword cmdlet - by Baterias

Status : 

  External<br /><br />
		This item may be valid but belongs to an external system out of the direct control of this product team.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 777142 Comments
Status Resolved Workarounds
Type Bug Repros 9
Opened 1/22/2013 5:14:30 AM
Access Restriction Public


I have two Active Directory environment: production.mycompany.com and development.mycompany.com. I must change passwords on all employees in development environment. I tried this command:

Get-ADUser -filter * -SearchBase "ou=employees,dc=development,dc=mycompany,dc=com" -Server dc.development.mycompany.com|%{Set-ADAccountPassword $_.samaccountname -reset -NewPassword $pass -Credential $Adm -WhatIf}

This command has an serius error: credential $Adm belongs production environment. But no problem,-whatif parameter prevents damages in domain accounts.

Horror! -whatif parameter doesn't work in Set-ADAccountPassword cmdlet. My employees lost them passwords.

This is a serius bug in activedirectory module.
Sign in to post a comment.
Posted by Baterias on 11/23/2015 at 11:44 PM
What does this mean? The cmdlet does not already have this bug?
Posted by Jason [MSFT] on 11/23/2015 at 1:43 PM
I have resolved this as External. Issues with the AD cmdlets should be reported here: https://windowsserver.uservoice.com/forums/304621-active-directory
Posted by Adlan77 on 12/15/2014 at 11:12 PM
I was able to reproduce this on Server 2012 R2 / Powershell 4 / Active Directory Module Books online states that the -WhatIf parameter "Shows what would happen if the cmdlet runs. The cmdlet is not run.". This seems pretty unambiguous to me - it should not make changes to the user. I read this as verifying that the password could be changed if -WhatIf wasn't there, ie has permissions, is oldpassword correct etc. If 'OldPassword' was incorrect it would have to count as a failed login so that it can't be used for dictionary attacks. If it doesn't do this, what exactly does it do then?
Posted by TQuerec [MSFT] on 7/8/2014 at 5:05 PM
Hi everyone, Thanks for the feedback on the AD cmdlets. I agree that the behavior of the AD cmdlets with regards to -WhatIf is confusing, especially when using the cmdlets that make object modifications. I'll consider taking a change in a future version to improve this.

chustedde, With regards to the behavior of Set-ADAcountPassword when only -NewPassword is supplied. When run in this mode the cmdlet first attempts to perform a reset on the account. If this fails it will require -OldPassword to be supplied. The intent was to try best a effort to successfully change the password without requiring user's to supply -reset if they had permissions to perform a reset. Is this confusing? Would you have preferred it to fail and require -OldPassword or is this issue compounded by the lack of -WhatIf support? The only possible change for this would be to require -OldPassword but that could break current users of the cmdlet.

Travis Querec[MSFT]
Posted by chustedde on 4/28/2014 at 7:03 AM
This is even worse:

Set-ADAccountPassword -Identity $sAMAccountName -Server $server -NewPassword $password -ErrorAction Stop

The above command can reset a password for an existing user who already has a password, when in the documentation it says it shouldn't be able to unless -OldPassword is provided.
Posted by sup3rw0rm on 8/22/2013 at 1:01 PM
I can verify this. I was bitten by this last night.

Set-ADAccountPassword -Identity $User -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "password" -Force) -WhatIf