Re: LDAP changePassword always returns error

From: Tom (
Date: 06/10/05

Date: Fri, 10 Jun 2005 06:14:03 -0700


The code follows. I've disabled error handling to show the error.

I based it off this script at Technet:

I get the same error when I run the script as the user through a web page,
the user logged into the machine, or a domain administrator logged into the
machine. However, forcing the password to be overwritten works fine when
logged in as a domain admin.

function changePassword(p_DistinguishedName, p_NewPassword, p_OldPassword)

'on error resume next
if p_DistinguishedName= "" then
end if
  set objUser = getObject("LDAP://" & p_distinguishedName)
                if isObject(objUser) then
                  'When run in the contect of a domain administrator, this
                  'the new password to overwrite the old. It works fine.
          'objUser.setPassword p_NewPassword

                  'This is the line of code in question. It's based off a
script in Technet's
                  'script center.
          objUser.ChangePassword p_OldPassword, p_NewPassword
    strMsg = Server.URLEncode("Sorry, there was a problem processing your
password change. <a href='changepassword.asp'>Please try again</a>.<p>If
this problem persists, please contact your administrator.")
    response.redirect("confirm.asp?m=" & strMsg & "&e=1")
  end if
  strMsg = Server.urlEncode("Password for user <b>" &
request.Form("username") & "</b> has been changed!")
  response.redirect("confirm.asp?m=" & strMsg)

end function

"Joe Richards [MVP]" wrote:

> Post the script
> --
> Joe Richards Microsoft MVP Windows Server Directory Services
> Tom wrote:
> > I'm working on a script to change a user's password in an AD domain.
> >
> > Our problem is a script that uses the changePassword method to change a
> > user's password. No matter how strong the new password is, we always return
> > an error that says the new password is either not unique or doesn't meet the
> > policy for strong passwords. This script doesn't work when run as either the
> > user making the change or the domain administrator.
> >
> > I think this error is bogus; we have another script that overwrites the
> > user's password with a strong random one (which runs in the context of the
> > domain admin), and that works fine.