Your message dated Tue, 13 Jul 2010 21:03:33 +0200
with message-id <[email protected]>
and subject line Re: ldappasswd hangs while smbk5pwd enabled
has caused the Debian Bug report #586334,
regarding ldappasswd hangs while smbk5pwd enabled
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 [email protected]
immediately.)
--
586334: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586334
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: slapd-smbk5pwd
Version: 2.4.21-1
With this overlay enabled in the slapd configuration, ldappasswd hangs.
ldappasswd is supposed to update the password of a user using an ldap
extended operation (as opposed to an ldapmodify command). The overlay is
there to also update the krb5Key and krb5KeyVersionNumber for objects
that have the krb5KDCEntry object class and the sambaLMPassword,
sambaNTPassword, and sambaPwdLastSet attributes of the objects that have
the sambaSamAccount object class. Instead, what happens is: once the
user has started ldappasswd (eg
ldappasswd -x -W -D 'cn=admin,dc=example,dc=com'
)
and has entered his correct current password, ldappasswd will give no
more output (except for "ldap_initialize( <DEFAULT> )" if you use -v)
and the user has to interrupt by pressing ctrl-c.
If a wrong password is given, you're simply denied access and returned
to the cmdline.
This also happens under Stable, by downloading the sources and compiling
the overlay myself as per
http://student.physik.uni-mainz.de/~reiffert/smbk5pwd.html#smbk5pwd.
I also tried to compile myself the whole openldap source, both 2.4.11
and 2.4.21, the actual latest stable, on Lenny, with the same results.
Some of the things I tried:
* It doesn't seem to matter what compile time options are used. Tried
openssl instead of gnutls, makes no difference.
* It also doesn't seem to matter if the object really has (is?) the
right object classes.
* Disabling either of the samba of kerberoz passwords has no result.
* I also tried starting the database over from scratch and enabling the
overlay before even starting the slapd for the first time.
This is what happens in the slapd log (I marked where I push ctrl-c; the
log is from Debian Unstable):
Jun 18 14:56:32 debian slapd[1162]: daemon: activity on 1 descriptor
Jun 18 14:56:32 debian slapd[1162]: daemon: activity on:
Jun 18 14:56:32 debian slapd[1162]:
Jun 18 14:56:32 debian slapd[1162]: slap_listener_activate(9):
Jun 18 14:56:32 debian slapd[1162]: daemon: epoll: listen=8
active_threads=0 tvp=zero
Jun 18 14:56:32 debian slapd[1162]: daemon: epoll: listen=9 busy
Jun 18 14:56:32 debian slapd[1162]: daemon: epoll: listen=10
active_threads=0 tvp=zero
Jun 18 14:56:32 debian slapd[1162]: >>> slap_listener(ldap:///)
Jun 18 14:56:32 debian slapd[1162]: daemon: listen=9, new connection on 17
Jun 18 14:56:32 debian slapd[1162]: daemon: added 17r (active)
listener=(nil)
Jun 18 14:56:32 debian slapd[1162]: conn=1001 fd=17 ACCEPT from
IP=[::1]:47463 (IP=[::]:389)
Jun 18 14:56:32 debian slapd[1162]: daemon: activity on 1 descriptor
Jun 18 14:56:32 debian slapd[1162]: daemon: activity on:
Jun 18 14:56:32 debian slapd[1162]:
Jun 18 14:56:32 debian slapd[1162]: daemon: epoll: listen=8
active_threads=0 tvp=zero
Jun 18 14:56:32 debian slapd[1162]: daemon: epoll: listen=9
active_threads=0 tvp=zero
Jun 18 14:56:32 debian slapd[1162]: daemon: epoll: listen=10
active_threads=0 tvp=zero
Jun 18 14:56:32 debian slapd[1162]: daemon: activity on 1 descriptor
Jun 18 14:56:32 debian slapd[1162]: daemon: activity on:
Jun 18 14:56:32 debian slapd[1162]: 17r
Jun 18 14:56:32 debian slapd[1162]:
Jun 18 14:56:32 debian slapd[1162]: daemon: read active on 17
Jun 18 14:56:32 debian slapd[1162]: connection_get(17)
Jun 18 14:56:32 debian slapd[1162]: connection_get(17): got connid=1001
Jun 18 14:56:32 debian slapd[1162]: connection_read(17): checking for
input on id=1001
Jun 18 14:56:32 debian slapd[1162]: op tag 0x60, time 1276865792
Jun 18 14:56:32 debian slapd[1162]: conn=1001 op=0 do_bind
Jun 18 14:56:32 debian slapd[1162]: >>> dnPrettyNormal:
<cn=admin,dc=vub,dc=ac,dc=be>
Jun 18 14:56:32 debian slapd[1162]: <<< dnPrettyNormal:
<cn=admin,dc=vub,dc=ac,dc=be>, <cn=admin,dc=vub,dc=ac,dc=be>
Jun 18 14:56:32 debian slapd[1162]: conn=1001 op=0 BIND
dn="cn=admin,dc=vub,dc=ac,dc=be" method=128
Jun 18 14:56:32 debian slapd[1162]: do_bind: version=3
dn="cn=admin,dc=vub,dc=ac,dc=be" method=128
Jun 18 14:56:32 debian slapd[1162]: ==> hdb_bind: dn:
cn=admin,dc=vub,dc=ac,dc=be
Jun 18 14:56:32 debian slapd[1162]:
bdb_dn2entry("cn=admin,dc=vub,dc=ac,dc=be")
Jun 18 14:56:32 debian slapd[1162]: conn=1001 op=0 BIND
dn="cn=admin,dc=vub,dc=ac,dc=be" mech=SIMPLE ssf=0
Jun 18 14:56:32 debian slapd[1162]: do_bind: v3 bind:
"cn=admin,dc=vub,dc=ac,dc=be" to "cn=admin,dc=vub,dc=ac,dc=be"
Jun 18 14:56:32 debian slapd[1162]: send_ldap_result: conn=1001 op=0 p=3
Jun 18 14:56:32 debian slapd[1162]: send_ldap_result: err=0 matched=""
text=""
Jun 18 14:56:32 debian slapd[1162]: send_ldap_response: msgid=1 tag=97 err=0
Jun 18 14:56:32 debian slapd[1162]: conn=1001 op=0 RESULT tag=97 err=0 text=
Jun 18 14:56:32 debian slapd[1162]: daemon: epoll: listen=8
active_threads=0 tvp=zero
Jun 18 14:56:32 debian slapd[1162]: daemon: epoll: listen=9
active_threads=0 tvp=zero
Jun 18 14:56:32 debian slapd[1162]: daemon: epoll: listen=10
active_threads=0 tvp=zero
Jun 18 14:56:32 debian slapd[1162]: daemon: activity on 1 descriptor
Jun 18 14:56:32 debian slapd[1162]: daemon: activity on:
Jun 18 14:56:32 debian slapd[1162]:
Jun 18 14:56:32 debian slapd[1162]: daemon: epoll: listen=8
active_threads=0 tvp=zero
Jun 18 14:56:32 debian slapd[1162]: daemon: epoll: listen=9
active_threads=0 tvp=zero
Jun 18 14:56:32 debian slapd[1162]: daemon: epoll: listen=10
active_threads=0 tvp=zero
Jun 18 14:56:32 debian slapd[1162]: daemon: activity on 1 descriptor
Jun 18 14:56:32 debian slapd[1162]: daemon: activity on:
Jun 18 14:56:32 debian slapd[1162]: 17r
Jun 18 14:56:32 debian slapd[1162]:
Jun 18 14:56:32 debian slapd[1162]: daemon: read active on 17
Jun 18 14:56:32 debian slapd[1162]: daemon: epoll: listen=8
active_threads=0 tvp=zero
Jun 18 14:56:32 debian slapd[1162]: daemon: epoll: listen=9
active_threads=0 tvp=zero
Jun 18 14:56:32 debian slapd[1162]: daemon: epoll: listen=10
active_threads=0 tvp=zero
Jun 18 14:56:32 debian slapd[1162]: connection_get(17)
Jun 18 14:56:32 debian slapd[1162]: connection_get(17): got connid=1001
Jun 18 14:56:32 debian slapd[1162]: connection_read(17): checking for
input on id=1001
Jun 18 14:56:32 debian slapd[1162]: op tag 0x77, time 1276865792
Jun 18 14:56:32 debian slapd[1162]: conn=1001 op=1 do_extended
Jun 18 14:56:32 debian slapd[1162]: conn=1001 op=1 EXT
oid=1.3.6.1.4.1.4203.1.11.1
Jun 18 14:56:32 debian slapd[1162]: daemon: activity on 1 descriptor
Jun 18 14:56:32 debian slapd[1162]: daemon: activity on:
Jun 18 14:56:32 debian slapd[1162]:
Jun 18 14:56:32 debian slapd[1162]: daemon: epoll: listen=8
active_threads=0 tvp=zero
Jun 18 14:56:32 debian slapd[1162]: daemon: epoll: listen=9
active_threads=0 tvp=zero
Jun 18 14:56:32 debian slapd[1162]: daemon: epoll: listen=10
active_threads=0 tvp=zero
CTRL-C HERE
Jun 18 14:56:39 debian slapd[1162]: daemon: activity on 1 descriptor
Jun 18 14:56:39 debian slapd[1162]: daemon: activity on:
Jun 18 14:56:39 debian slapd[1162]: 17r
Jun 18 14:56:39 debian slapd[1162]:
Jun 18 14:56:39 debian slapd[1162]: daemon: read active on 17
Jun 18 14:56:39 debian slapd[1162]: daemon: epoll: listen=8
active_threads=0 tvp=zero
Jun 18 14:56:39 debian slapd[1162]: daemon: epoll: listen=9
active_threads=0 tvp=zero
Jun 18 14:56:39 debian slapd[1162]: daemon: epoll: listen=10
active_threads=0 tvp=zero
Jun 18 14:56:39 debian slapd[1162]: connection_get(17)
Jun 18 14:56:39 debian slapd[1162]: connection_get(17): got connid=1001
Jun 18 14:56:39 debian slapd[1162]: connection_read(17): checking for
input on id=1001
Jun 18 14:56:39 debian slapd[1162]: ber_get_next on fd 17 failed errno=0
(Success)
Jun 18 14:56:39 debian slapd[1162]: connection_read(17): input error=-2
id=1001, closing.
Jun 18 14:56:39 debian slapd[1162]: connection_closing: readying
conn=1001 sd=17 for close
Jun 18 14:56:39 debian slapd[1162]: connection_close: conn=1001 sd=17
Jun 18 14:56:39 debian slapd[1162]: daemon: removing 17
Jun 18 14:56:39 debian slapd[1162]: conn=1001 fd=17 closed (connection lost)
Jun 18 14:56:39 debian slapd[1162]: daemon: activity on 1 descriptor
Jun 18 14:56:39 debian slapd[1162]: daemon: activity on:
Jun 18 14:56:39 debian slapd[1162]:
Jun 18 14:56:39 debian slapd[1162]: daemon: epoll: listen=8
active_threads=0 tvp=zero
Jun 18 14:56:39 debian slapd[1162]: daemon: epoll: listen=9
active_threads=0 tvp=zero
Jun 18 14:56:39 debian slapd[1162]: daemon: epoll: listen=10
active_threads=0 tvp=zero
--- End Message ---
--- Begin Message ---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ok, fix for this problem is in the slapd configuration:
[quote]
OK, I finally figured it out. It was a configuration issue after all -
you need to put the "overlay" directive behind the "database" directive.
Otherwise the server wil start fine (without crash, errors or complaint
about syntax), but refuse to actually execute the password change
operation.
[/quote]
Regards,
Matthijs Mohlmann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkw8uIUACgkQ2n1ROIkXqbAIIACfbHRa4+vCNDcdZqkXmuJlvKQJ
aFsAn17t+L/fzksxfZFGYuj1hdZ9xIow
=OgrU
-----END PGP SIGNATURE-----
--- End Message ---
