Hello everyone,
I am writing a Java program to reset LDAP account password. I know the password should be quoted passwrod and then encoded in UTF-16. I have a question, if someone can confirm please.

I am getting encoded password as follow:

 String oldPassword = "Password1234";
 String newPassword = "Password9999";

 String oldQuotedPassword = "\"" + oldPassword + "\"";  
 byte[] oldUnicodePassword = oldQuotedPassword.getBytes("UTF-16LE");  
 String newQuotedPassword = "\"" + newPassword + "\"";  
 byte[] newUnicodePassword = newQuotedPassword.getBytes("UTF-16LE");

 System.out.println("Old Password: " + new String(oldUnicodePassword));
 System.out.println("New Password: " + oldUnicodePassword);
 System.out.println("Old unicode Password: " + new String(newUnicodePassword));
 System.out.println("Old unicode Password: " + newUnicodePassword);

 ==============================================
 Output: First run
 Old Password: "Password1234"
 New Password: "Password9999"
 Old unicode Password: [B@e015ef 
 New unicode Password: [B@1ce02ae1

 Output: Second run
 Old Password: "Password1234"
 New Password: "Password9999"
 Old unicode Password: [B@5fd9fb 
 New unicode Password: [B@e015ef

 Output: Third run
 Old Password: "Password1234"
 New Password: "Password9999"
 Old unicode Password: [B@e015ef 
 New unicode Password: [B@1c03ae1


 And so on....

Now my question is, why the value of encoded password is deffirent each time program runs? Is it expected? Because I set the password encoded value as my password value in AD, and if it's deffirent each time, I don't think it's gonna work.

Here's how I set password:

ModificationItem[] mod = new ModificationItem[2];
mod[0]= new ModificationItem(DirContext.REMOVE_ATTRIBUTE, new BasicAttribute("univodePwd", oldUnicodePassword));
mod[0]= new ModificationItem(DirContext.ADD_ATTRIBUTE, new BasicAttribute("univodePwd", newUnicodePassword));
ctx.modifyAttributes(myDistinguishedName, mod);

So, when I update the password, I get a success message that password is updated. But when I try to login with new password (Password9999), then I get a login faileur. I can not login with old password (Password1234) either.

My assumption is that the password is reset, but to something else and it's not my new password (Password9999). I am not sure if I get the unicoded password correctly. Please advise...

Dani AI

Generated

Short summary tied to the thread: is correct — the console lines like [B@e015ef are Java object identity strings, not the byte contents. That explains the changing labels you saw and is benign. The LDAP failures, however, usually come from one of a few other causes; removing the misleading sysout simply removed the visual confusion but does not by itself guarantee a successful AD password change.

Checklist of high‑value things to verify (most common causes of 0000052D or “password not what you expect”):

  • Attribute name and modify array: use the correct attribute unicodePwd and make sure you do not overwrite mod[0] (populate mod[0] and mod[1] or build the array correctly).
  • Use the right LDAP operation: for an administrative reset use a single REPLACE on unicodePwd; for a user change use a single modify that DELETEs the old and ADDs the new.
  • Secure channel: Active Directory requires the unicodePwd write be done over LDAPS (SSL/TLS).
  • Password rules: AD may reject the value for policy/complexity/history reasons — that also yields a constraint error.
  • Verify the actual bytes (don’t rely on System.out.println(byte[])): use Arrays.toString(...), Arrays.equals(...) or print hex/Base64 to inspect and compare raw bytes.

Example snippets (inspect and replace — not copied from earlier posts):

System.out.println(Arrays.toString(newUnicodePassword));
if (Arrays.equals(oldUnicodePassword, newUnicodePassword)) { / handle / }

ModificationItem[] mods = {
new ModificationItem(DirContext.REPLACE_ATTRIBUTE, new BasicAttribute("unicodePwd", newUnicodePassword))
};
ctx.modifyAttributes(dn, mods);

If errors persist, test the same modify with a simple LDAPS tool (ldp.exe or ldapsearch over TLS) to isolate whether the problem is Java/JNDI usage or an AD policy/SSL issue.

Recommended Answers

All 6 Replies

And as a result of this, I am getting the following error:

LDAP: error code 19 - 0000052D: AttrErr: DSID-3190f80, #1:
            0: 0000052D: DSID-3190f80, problem 1005 (CONSTRAIN_ATT_TYPE), data 0. Att 9005a (UnicodePwd)

I believe it has to do with my UnicodePwd value of the password.

Any advise, please?

anyone help please?

 System.out.println("Old Password: " + new String(oldUnicodePassword));
 System.out.println("New Password: " + oldUnicodePassword);
 System.out.println("Old unicode Password: " + new String(newUnicodePassword));
 System.out.println("Old unicode Password: " + newUnicodePassword);

This snippet doesn't match to your output. Have you made any modifications?

Yeah sorry for that, it's actually this:

System.out.println("Old Password: " + new String(oldUnicodePassword));
System.out.println("New Password: " + new String(newUnicodePassword);
System.out.println("Old unicode Password: " + oldUnicodePassword);
System.out.println("New unicode Password: " + newUnicodePassword);

I guess this is because oldUnicodePassword and newUnicodePassword correspond to the location of the byte array and not its value. So everytime you instantiate a byte[] you would get a unique location of storage whenever you call System.out.println(byteArray). Even when the values stored are the same.

If you wish to compare contents, you could convert the byte array into strings or compare each element of Array1 to Array2.

Thank you for your reply.
Yes, you are 100% correct! Removing sysout from my code, indeed worked.
thanks.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.