0

I manage to perform a STARTTLS ldapmodify ( -ZZ) of an attribute, but fail to perform the same modification using javax.naming.ldap coding

The server is OpenLDAP. It has SSigned SSL Certificate for modification, and unsecured reading is allowed. Classical combination.

I run the following command from the same server on which I will try to execute the Java code (later):

ldapmodify -H ldap://my.ldap.server:389 -D "myldapadmin" -W -ZZ
Enter LDAP Password:
dn: CN=John Westood,OU=L100,DC=l,DC=woods
changetype: modify
replace: uPwd
uPwd:: 234WF34TG2U
modifying entry "CN=John Westood,OU=L100,DC=l,DC=woods"

... as you can see, it asks me for myldapadmin's password, I enter it, and the modification happens.

Here is what I am doing from Java, I want to do the same modification, I am running it on the same server. I have imported the SSigned LDAP SSL certificate into java first.

Hashtable<String, Object> env = new Hashtable<String, Object>();
env.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, "ldap://my.ldap.server:389");

// Create initial context
LdapContext ctx = new InitialLdapContext(env, null);

ctx.addToEnvironment(Context.SECURITY_PRINCIPAL, "myldapadmin");
ctx.addToEnvironment(Context.SECURITY_CREDENTIALS, "myadminpass");

// Start TLS (STARTTLS is also used by the console command ldapmodify)
StartTlsResponse tls = (StartTlsResponse) ctx.extendedOperation(new 
StartTlsRequest());
SSLSession sess = tls.negotiate();

//Modification of 'uPwd' attribute
ModificationItem[] mods = new ModificationItem[1];
Attribute mod0 = new BasicAttribute("uPwd", "4G45G435G436UJWG");
mods[0] = new ModificationItem(DirContext.REPLACE_ATTRIBUTE, mod0);
ctx.modifyAttributes("CN=John Westood,OU=L100,DC=l,DC=woods", mods);

// Stop TLS
tls.close();
// Context close
ctx.close();

I get exception in method ctx.modifyAttributes. The Exception is the following:

javax.naming.OperationNotSupportedException: [LDAP: error code 53 - 0000052D: SvcErr: DSID-031A12D2, problem 5003 (WILL_NOT_PERFORM), data 0

Anybody have idea why modify uPwd works with STARTLS from commandline, but not from Java ?

PatlaDJ
  • 1,226
  • 2
  • 17
  • 31
  • Why do you think the issue is `STARTLS`? AFAIK you should just get a Connection refused error if that was the problem. It seems like your Java program is **not** performing the operation you think. Does you ldap server log all modifications requested? Try to see what the java code is doing – Giacomo Alzetta Feb 07 '18 at 13:10
  • Yes, you are right. I am not sure it is up to the STARTTLS. – PatlaDJ Feb 07 '18 at 13:58
  • Anyway, as long as I understand properly, with REPLACE_ATTRIBUTE I am doing a modification of the attribute uPwd over a STARTTLS layer, that is exactly what the ldapmodify command is doing from the command line. ldapmodify is working, but REPLACE_ATTRIBUTE in Java - not. STARTTLS and Authentication seems to be fine in Java, exception is thrown on routine code for attribute modification. – PatlaDJ Feb 07 '18 at 14:12
  • According to this question: https://stackoverflow.com/questions/17290539/ldap-operationnotsupportedexception-error-code-53-0000001f you may be using the wrong port. Try to use `636` instead of `389` – Giacomo Alzetta Feb 07 '18 at 15:48
  • Thank you, but we've already tried that. And also, why ldapmodify uses 389 ? – PatlaDJ Feb 07 '18 at 16:19
  • Did you check the result with the new password to verify that the ldapmodify worked? Did it return a 0 exit code? If the active directory requires complexity or enforces history, you need a better password with at least upper/lower/number throw in a special character for good measure – englebart Sep 09 '21 at 14:15

1 Answers1

0

Appears you are trying to change perhaps a password against Microsoft Active Directory (Even though you show openLDAP) (I have no idea what uPwd could be.)

Changing Microsoft Active Directory Passwords has several constraints.

Once you are confident you have an acceptable connection to Microsoft Active Directory, We have an example for Changing Microsoft Active Directory Password with JNDI

FYI: By default startTLS would use 389.

jwilleke
  • 10,467
  • 1
  • 30
  • 51
  • It did not help. The LDAP server is Microsoft Active Directory. And I have no control over it. That's why I installed OpenLDAP locally to test. I moved ctx.addToEnvironment(SECURITY_PRINCIPAL and SECURITY_REDENTIALS after the TLS handshake, and that made it work connecting and changing passwords on my local OpenLDAP. However on the MS Active Directory server - the WILL NOT PERFORM Exception persist :( – PatlaDJ Feb 12 '18 at 09:04