Your message dated Wed, 25 Mar 2020 10:32:35 -0700
with message-id <>
and subject line Re: slapd: normal user is able to change/delete/unset the 
password of other users
has caused the Debian Bug report #673400,
regarding slapd: normal user is able to change/delete/unset the password of 
other users
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact

Debian Bug Tracking System
Contact with problems
--- Begin Message ---
Package: slapd
Version: 2.4.23-7.2
Severity: normal

I've installed slapd on a plain debian squeeze together with 

After configuring slapd with dpkg-reconfigure, I logged in as admin on the 
ldap-account-manager and created 2 users (user1, user2). I logged in as user1 
and changed personal information. I noticed, that I am not able to change 
values of user2 except for the password. It's possible, logged in as user1, to 
change/delete/unset the password of user2 and vice versa. It seems that the 
standard setup lacks something like the following lines:

access to attr=userPassword
        by self write
        by anonymous auth
        by dn.base="cn=Manager,dc=example,dc=com" write
        by * none

I report this as a critical bug, since it could cause information leakage and 
not wanted privileges to services that authenticate against LDAP.

-- System Information:
Debian Release: 6.0.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686-bigmem (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages slapd depends on:
ii  adduser                3.112+nmu2        add and remove users and groups
ii  coreutils              8.5-1             GNU core utilities
ii  debconf [debconf-2.0]          Debian configuration management sy
ii  libc6                  2.11.3-3          Embedded GNU C Library: Shared lib
ii  libdb4.8               4.8.30-2          Berkeley v4.8 Database Libraries [
ii  libgnutls26            2.8.6-1+squeeze2  the GNU TLS library - runtime libr
ii  libldap-2.4-2          2.4.23-7.2        OpenLDAP libraries
ii  libltdl7               2.2.6b-2          A system independent dlopen wrappe
ii  libperl5.10            5.10.1-17squeeze3 shared Perl library
ii  libsasl2-2             2.1.23.dfsg1-7    Cyrus SASL - authentication abstra
ii  libslp1                1.2.1-7.8         OpenSLP libraries
ii  libwrap0               7.6.q-19          Wietse Venema's TCP wrappers libra
ii  lsb-base               3.2-23.2squeeze1  Linux Standard Base 3.2 init scrip
ii  perl [libmime-base64-p 5.10.1-17squeeze3 Larry Wall's Practical Extraction 
ii  psmisc                 22.11-1           utilities that use the proc file s
ii  unixodbc               2.2.14p2-1        ODBC tools libraries

Versions of packages slapd recommends:
ii  libsasl2-modules          2.1.23.dfsg1-7 Cyrus SASL - pluggable authenticat

Versions of packages slapd suggests:
ii  ldap-utils                    2.4.23-7.2 OpenLDAP utilities

-- debconf information:
  slapd/internal/generated_adminpw: (password omitted)
* slapd/password2: (password omitted)
  slapd/internal/adminpw: (password omitted)
* slapd/password1: (password omitted)
  slapd/invalid_config: true
* shared/organization:
* slapd/backend: HDB
  slapd/dump_database: when needed
* slapd/allow_ldap_v2: false
* slapd/no_configuration: false
* slapd/move_old_database: true
  slapd/dump_database_destdir: /var/backups/slapd-VERSION
* slapd/purge_database: true
* slapd/domain:

--- End Message ---
--- Begin Message ---

My squeeze chroot is long gone, but I tried this on jessie:

1. install slapd and ldap-account-manager;
2. login to LAM configuration and setup the local suffix;
3. login to LAM as admin and create "user1" and "user2" Unix users;
4. login to LAM as user1 and attempt to change user2's password;
5. login to LAM as user2 and attempt to change user1's password.

In both cases the users were prevented from changing the other's password, with an "Insufficient access" error message when "Save" is pressed (note "Set Password" alone does not commit the change, have to actually press "Save").

I'm closing this bug based on that, but feel free to reopen if you can provide a test case that reproduces the issue reported.


--- End Message ---

Reply via email to