How a user can change their password in LDAP

  • 7022599
  • 24-Jan-2018
  • 24-Jan-2018


Novell eDirectory 8.7 for All Platforms
Novell eDirectory 8.7.3
Novell eDirectory 8.6 for All Platforms
Novell eDirectory 8.5 for All Platforms
Novell NetWare 5.1
Novell NetWare 5.0
Novell Directory Services RecMan Database
Novell Directory Services FLAIM Database
Sun Solaris 9 LDAP client
Formerly KB 295344


Change passwords after objects have been bulk imported into eDirectory
A user does not have sufficient rights to change their password.  The LDAP Server returns the error message - "insufficient access".
A user is not able to change their own password using standard LDAP calls to a NLDAP server
How a user can change their password in LDAP


To allow a user to change it's own password via LDAP with a changetype: modify and only an add: userpassword (as the Sun Solaris 9 LDAP client does), do the following.  Give the user the Write right to the "Password Management" property.  You can give this right directly to the user or use the [This] trustee which will allow each user to have rights to it's own Password Management property with one assignment (see TID #10087020 for more on the [This] property, see TID #10092670  on how to add the [This] trustee if it is not present in your tree).  When using the [This] trustee, make sure to flag it inheritable.
In Novell eDirectory 8.5 and higher, a user can change their password using the following LDIF file.  This file will work with any Novell eDirectory Server.

dn:cn=jane doe,o=novell
changetype: modify
add: userpassword
userpassword: *******

The user must have the write privilege set on her ACL attribute (or try the fix above using the Password Management property), in order for this to succeed.  The settings in Console1 that specify whether a user can change their password are not used by the LDAP server.  If the user has the "Allow user to change password" option not checked, they could still change their password via LDAP assuming the user has the correct privileges set.

A request has been submitted to Novell Engineering to specify access controls directly on the userpassword attribute.  Once a user has the write privilege on her ACL attribute, the user could potentially change any of their attributes.
The following section only applies to Novell Directory Services 8.  The current fix will work ONLY for a NetWare 5 server running NDS 8 Update 1 or higher.  (DS.NLM 8.17+) NLDAP 3.12. It has not been ported back to NetWare 5, legacy NDS.Please note that it is enough to use the LDAP attribute userpassword, no mappings are required.

The example LDIF file attached will work on a NetWare NLDAP server. Novell is working on a LDAP proposal in order to accomplish this with one LDAP call.

    changetype: modify
    delete: userpassword
    userpassword: *******
    add: userpassword
    userpassword: ********

Additional Information

In Novell eDirectory 8.5 and higher, a user can change their password with one LDAP call.  The user must have the appropriate privileges set for this to work correctly.

The following section only applies to Novell Directory Services 8.  The problem is that only admin can change someone's password without providing the existing password. The user cannot change their own password without providing their current password *and* the new password. In NetWare 5 and NDS 8, this problem doesn't allow a user to change their own password through LDAP (while admin can). In NDS8 Update 1, an LDAP modify request with a delete of the userpassword attribute (providing the current value) *and* an add of the userpassword attribute with the new value will allow a user to change their own password.  Very Important to notice is that actually the Novell LDAP implementation has a higher security than the Netscape implementation. For a Netscape Directory server one is not required to know the original password - only for the bind. This however means that anybody can walk to an unattended workstation and change the password.  Actually the userpassword is not stored as such in NDS. It is stored as an RSA public/private keypair in order to guarantee the highest security possible.

Formerly known as TID# 10053195

Formerly known as TID# NOVL11670