Powerful Directory Management Tool

[elaan]

I'm testing LDAP Administrator 2.3 (Demo version) with iPlanet Directory Server 5.1. When changing the userPassword attribute I invariably get the message "[Error 19] Constraint violation". To rule out any security-problems I've also tried this with the cn=Directory Manager logon to no avail.
I'm running LDAP Administrator on WinNT 4 Service Pack 6 with Internet Explorer 5.5. The server is iPlanet Directory Server 5.1 on Solaris 8 (if that matters).

What can I do to make it work?

[Support]

<p>There are a lot of reasons when the iPlanet (formerly Netscape) server returns this error. Here is an extract from the Netscape SDK:</p> <p> The request adds or modifies the userpassword attribute, and one of the following is true: </p><ul><li>The server is configured to check the password syntax, and the length of the new password is less than the minimum password length.<li>The server is configured to check the password syntax, and the new password is the same as one of the values of the uid, cn, sn, givenname, ou, or mail attributes. <li>The server is configured to keep a history of previous passwords, and the new password is the same as one of the previous passwords. </ul>

[elaan]

Thanks Support but I've already checked all things mentioned: I've tried different passwords all with at least 6 characters, and one capital letter and one number in the first 6 characters.
I've tried this with:
- at least 10 different passwords;
- passwords that I know are not in the history;
- with the password-history cleared;
- with the password-history disabled;
- etc.
Moreover: I have tried changing the password with LDAP Administrator and got "[Error 19] constraint violation". Immideately thereafter I tried changing the same user via the iPlanet Console, giving it the same password and succeeded so this seems a LDAP Administrator problem.

Please help.

[elaan]

Sorry for replying to my own post again, but I have additional info.
I've tried all different combinations of password encryption schema's with LDAP Admin and the Directory Server and still get the "[Error 19] Constraint violation" message.
I've also tried 2 other LDAP Administration tools, both work.

Please help me as I'd like to get LDAP Administrator working: it's the only tools supporting secure (SSL) communications with the server.

[Support]

We have tried to reproduse your problem with Netscape 4.12 (Linux) and Netscape 6.01 (B2002.028.2020 for NT). In both cases we couldn't managed to reproduce the problem.

We suggest you turn your server to the debug mode, reproduce the problem, and then look for the error description in the log file.

[elaan]

Hello,

I've been testing all week. I had already made all kinds of debug-, access-, audit- and error-logs with the server. I also snoop'ed the networkinterface the Directory Server is bound too, to see the contents of the packet(s) being send by LDAP Administrator 2.3. For comparison I've also done the same with 2 other tools that I can use to change the userPassword attribute. I discovered there are several ways the password-modification can be send to the server, of which only {CRYPT} and cleartext are applicable to my situation as the entries I want to manage with LDAP Administrator require Unix-logins via the pam_unix.so module.
From the snoop-data and the Directory Server access- and error-logs I can see that:
1) The iPlanet Directory Console sends password updates in the clear, even if {CRYPT} is the default password-storage schema. When changing the password it not only changes the userPassword attribute, but also changes the objectclass attribute (to contain the same values which where already there). The Console manages to update the password successfully.
2) Another tool I used just changes the userPassword attribute when changing the password, sending it in {CRYPT} form. This tool also manages to change the password successfully.
3) Surprisingly LDAP Administrator 2.3 demo version always sends 2 (!) passwords in one TCP-packet. I checked to make sure I only request 1 password update. Moreover it always sends the first password in {CRYPT} form, even if I try to update the password in cleartext.
The first encrypted password will either be:
- the old password, forcing the Directory Server to respond with "Error 19, Constraint violation: password in history". This password is preceded by {CRYPT}. Or:
- an password which I didn't recognize as the old or the new password which is not formatted correctly, forcing the Directory Server to respond with "Error 19, Constraint violation: invalid password syntax." This password is sometimes preceded by {crypt} and sometimes by {CRYPT}, I don't know if this is allowed, or if the lower-case version violates the password-syntax defined in the LDAP RFC's.

The second password is the correct password as far as I can tell. As it is send in the same packet as the first one, maybe it is part of the same ldapmodify-operation?

I really hope you can help me debug this any further. I really like all other aspects of the way LDAP Administrator works, and the other tools fail in bigger ways, or have security problems related to them I'd very much like to avoid.

If you want me to make the snoop-data available to you I'd like to do that in private mail. If so please mail me the E-mail address I can send it to.

With kind regards, Erik Laan.

<font size=-1>[ This Message was edited by: elaan on 2002-08-23 14:31 ]</font>

[Support]

The case (upper or lower) of {SHA} or {CRYPT} is not significant. Values that begin with {SHA}, {sha} or {sHa} are equivalent.

LDAP Administrator's packet has two copies of password because the password change opration is implemented as ldap_modify() operation. The goal is to replace an old password with the new one. We create a modification list with two modification operations. The first modop is the old password in the form how it was read from the server. The type is LDAP_MOD_DELETE. The second modop is the new password encoded with hash type you have selected. The type is LDAP_MOD_ADD.

The possible reason of the problem might be that some objectclass in your entry has userPassword attribute marked as MUST. When server tries to execute first modop - the violation raises.

Please <a href="mailto:kirill@softerra.com">send us</a> your dumps, schema, and simple LDIF and we try to reproduce the problem at our server.

[elaan]

I've checked all objectclasses used by the entry concerned: none of the require the userPassword attribute, 5 out of 7 of the have the userPassword attribute as 'allowed' in them.
I've tested the ldapdelete and ldapadd operations separately: with other tools they succeed, with LDAP Administrator the ldapdelete operation fails. If I delete the userPassword attribute with another tool and add it with LDAP Administrator it succeeds.
From the snoop-data of both these sessions I see the following difference:
- the other tool (iPlanet Console) just delete's the userPassword attribute of the entry without specifying the value of the userPassword attribute.
- In the packet LDAP Administrator sends I see the old password value specified. The respons from the server in the return packet is: "password in history". The logs of the server say "invalid password syntax" and LDAP Administrator replies the the dreaded "[Error 19] Constraint violation".

I've send the requested items via private mail. I hope we can track this problem down.

Erik

[elaan]

OK, I've retraced my steps from last week and redid some. Turns out I only disabled the password-syntax checking and not the password history checking, although I thought I'd done both. With the passwordhistory disabled LDAP Administrator works.

I'm not happy with disabling the password history as bypass, I'll certainly get into trouble with our EDP-auditors when advising this solution.

The reason the problem is provoked is that LDAP Administrator replaces the userPassword attribute by first deleting the specified attribute/value pair and then adding another. Other tools just use the 'replace' action to modify the password. Actually LDAP Administrator behaves better than iPlanet Console, because _if_ the userPassword has multiple values LDAP Administrator only replaces the desired one, and iPlanet Console just replaces all.

However: While deleting only one attribute/value pair as LDAP Administrator does, the old value of the password needs to be specified, which causes it to violate the passwordhistory if it's turned on, at least on my server(iPlanet Directory Server 5.1).

Strange thing is that the serverТs access logs report Сinvalid password syntaxТ which let me to believe the problem was in LDAP Administrator. If you look at the snoop-data of the packets being send between the LDAP Administrator and the server, the message that the server sends back contains the string Сpassword in historyТ.

ItТs unclear to me whether this is a problem with LDAP Administrator or with iPlanet Directory Server 5.1. IТll see if using Service Pack 1 of iPlanet Directory Server 5.1 will solve the problem.

It is up to Softerra whether they want to change LDAP Administrator to bypass this issue. If you do I have several suggestions for the way to handle this:

1) Change LDAP Administrator to use:
ldapmodify ...
replace: attributename
attributename: newattributevalue
when changing attributes that have only one value in this entry.

2) Change LDAP Administrator to use:
ldapmodify ...
delete: attributename
add: attributename
attributename: newattributevalue1
attributename: oldattributevalue2 Е
attributename: oldattributevalueN
when changing attributes that have more than one value in this entry (where oldattriutevalue1 is the one being replaced).

3) Change LDAP Administrator to use:
ldapmodify ...
replace: atributename
attributename: newattributevalue1
attributename: oldattributevalue2 Е
attributename: oldattributevalueN
when changing attributes that have more than one value in this entry (where oldattriutevalue1 is the one being replaced).

4) Keep the current LDAP Administrator behaviour when changing attributes that have more than one value in this entry.

Chosing between the combination of options 1&2, options 1&3 or options 1&4 could in my opinion very well be an option in the server-profile.

[elaan]

I've just tested LDAP Administrator against the newest version of iPlanet (now SunONE) Directory Server, version 5.1 SP1. The problem persists.

(Please note that the 5.1SP1 version is installed on WinNT4, while the 5.1 version is installed on SUN Solaris2.8 ).

<font size=-1>[ This Message was edited by: elaan on 2002-08-29 07:59 ]</font>

[Support]

We have tested this issue with v4.12 (Linux) and v6.01 (WNT).The behavior the same. This is, of course, Netscape specific issue.

We'll fix the password manager algorithms in v 2.4 which is scheduled to be released at the end of September.

Thank you for cooperation!

[Support]

In the version 2.4 we added the workaround for Netscape servers. By default this workaround is turned off. To activate it - connect to the server, open the server profile property, choose 'LDAP Settings' tab and check the 'The server's 'Password History' is currently enabled' option.

[elaan]

Hi,

I just yesterday downloaded the new version and immediately went searching for this option. I found it, tested it and it works.

Thanks very much, Erik Laan

[jzuzek]

I'm now encountering a similar problem with LDAP Administrator version 3.4 and Sun LDAP 5.2 SP4. In our case, we're trying to add an objectclass to an existing account. The objectclass has an allowed attribute of "userPassword'. When we try to add the objectclass, we get a constraint violation complaining that the password is already in the history.

The LDAP Settings profile options seem to have changed from LDAP Admin version 2.4 to version 3.4, and I can't find a check box for "The server's 'Password history' is enabled". Can anyone advise how to deal with this problem in LDAP Administrator version 3.4?

Thanks.

[fmadir]

Hi

I have a similar problem with Java web console and Sun LDAP 5.2 (Enterprise edition 6.0).

I'm trying to Modify a userPassword in two cases (the user is connected and he doesn't). But i get a error "RESULT err=19 tag=103 nentries=0 etyma=0, Password already hashed. Cannot check quality" the error 19 means "constraint violation" and i have a message indicates that the password is already in the history.

I tried different combinaisons of password, and i have the same result

I need your help

Thanks