Re: openldap password fails to update
Le samedi 8 mars 2014, 16:14:53 Matthew Weigel a écrit : On 03/08/2014 03:11 PM, Stéphane Guedon wrote: when I use 127.0.0.1 in php scripts, I can use ldap. if the script is running with 'localhost' then, no ldap data... Any idea why ? I have checked host resolution... telnet localhost ldap gives the good behavior Is PHP running inside a chroot? Does that chroot have an /etc/hosts with an entry for localhost? you get it ! By copying the hosts system file in the nginx/php chroot, I am now able to log in. [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: openldap password fails to update
Le samedi 8 mars 2014, 14:20:23 Matthew Weigel a écrit : On 03/08/2014 12:16 PM, Stéphane Guedon wrote: I am looking through logs and config since the beginning of the day... Actually, asking help on forums or mailing lists is always my last step in solving problems... We try to help. But... giving detailed descriptions of the problem, and showing relevant configs and logs the first time, goes a long way to helping people help you. Reading manuals helps too. Among others, ypldap(8), ypldap.conf(5), login.conf(5), login_ldap(8) from ports, and whatever manuals for OpenLDAP. But why can't I authenticate (using ssh or login) on the system ? Do I really have to go through ypldap ? Sounds not efficient to have an intermediate ! There are two separate mechanisms: how user information is looked up, and how users are authenticated. You provide zero details on how ypldap or login_ldap are configured, so it's hard to guess whether you have some configuration wrong. I can say it works for me. Because when beginning, I just tried to auth with ldap alone ! Now that I try with ldap + ypldap, it works. Thanks Guys ! I solved it... The user lookup is configured (via +:: entries in /etc/passwd and /etc/group) to use YP routines. Thus the user is looked up in ypldap when they attempt to login, which is configured to identify the user's login class as ldap. The ldap login class is configured in login.conf to authenticate via login_ldap talking to the LDAP server, which is configured to have the appropriate users. This is what I meant by that's a lot more moving parts than just passwords in LDAP. [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: openldap password fails to update
On 2014-03-07, Stéphane Guedon steph...@22decembre.eu wrote:
But when I try to change this user password it fails :
# ldappasswd -x -v -D uid=test,ou=users,dc=22decembre,dc=eu \
-w somesecret -s anothersec
ldap_initialize( DEFAULT )
Result: Other (e.g., implementation specific) error (80)
Additional info: password hash failed
What is password-hash set to in slapd.conf on the server?
I think there is a bug with password-hash {CRYPT}, if you use this
you can try password-hash {SSHA} for now, or (probably better)
encrypt the password locally and change it using ldapmodify (or
ldapvi, etc).
slappasswd never gives the same result !
That's expected for salted hashes.
Does any of you can suggest what's wrong ? Do you need other
information ?
It won't necessarily help, but you should always mention versions (or
dates if building from source) of any relevant software and what machine
architecture you use in any problem report.
Re: openldap password fails to update
Le samedi 8 mars 2014, 12:23:19 Stuart Henderson a écrit :
On 2014-03-07, Stéphane Guedon steph...@22decembre.eu wrote:
But when I try to change this user password it fails :
# ldappasswd -x -v -D uid=test,ou=users,dc=22decembre,dc=eu \
-w somesecret -s anothersec
ldap_initialize( DEFAULT )
Result: Other (e.g., implementation specific) error (80)
Additional info: password hash failed
What is password-hash set to in slapd.conf on the server?
I think there is a bug with password-hash {CRYPT}, if you use this
you can try password-hash {SSHA} for now, or (probably better)
encrypt the password locally and change it using ldapmodify (or
ldapvi, etc).
slappasswd never gives the same result !
That's expected for salted hashes.
Does any of you can suggest what's wrong ? Do you need other
information ?
It won't necessarily help, but you should always mention versions
(or dates if building from source) of any relevant software and
what machine architecture you use in any problem report.
Thanks everybody from the list...
I changed the standard hash yesterday and now, password update works.
But I am still having problems with other parts of the ldap...
Notably, the user fails to auth and do login (with openbsd login
system AND webpages) eventhough password is correct according to ldap
itself !
By the way, anybody use the light ldapd daemon included in base ? can
we update password with it ?
[demime 1.01d removed an attachment of type application/pgp-signature which had
a name of signature.asc]
Re: openldap password fails to update
On Mar 8, 2014, at 6:29 AM, Stéphane Guedon steph...@22decembre.eu wrote: Notably, the user fails to auth and do login (with openbsd login system AND webpages) eventhough password is correct according to ldap itself ! That's a lot more moving parts than just passwords in LDAP. Have you checked your configuration of all those moving parts? Looked at logs? You don't even mention what else you're using, much less how they've been configured or what their logs report. I am using ypldap from base and login_ldap from ports; your mileage may vary. By the way, anybody use the light ldapd daemon included in base ? can we update password with it ? I use it. It does not currently support the modify password extended operation (what ldappasswd relies on). I am working on a patch for it but I haven't finished it and it requires a bit more refactoring than just processing one new request. Until that's done I rely on a short Perl script I wrote. It's a pretty simple kind of thing to do; it is more a codification of a particular policy than a technically challenging problem. -- Matthew Weigel
Re: openldap password fails to update
Le samedi 8 mars 2014, 09:09:08 Matthew Weigel a écrit :
On Mar 8, 2014, at 6:29 AM, Stéphane Guedon
steph...@22decembre.eu wrote:
Notably, the user fails to auth and do login (with openbsd login
system AND webpages) eventhough password is correct according to
ldap itself !
That's a lot more moving parts than just passwords in LDAP.
Yes, but passwords are the first things to change to secure your
users/install.
I am currently working on a little webpage in python to allow easy
ldap management (add/remove users and groups, passwords update).
Have you
checked your configuration of all those moving parts? Looked at
logs? You don't even mention what else you're using, much less how
they've been configured or what their logs report.
I am looking through logs and config since the beginning of the day...
Actually, asking help on forums or mailing lists is always my last
step in solving problems...
here is my config :
include schema/core.schema
include schema/cosine.schema
include schema/inetorgperson.schema
include schema/misc.schema
include schema/nis.schema
include schema/openldap.schema
loglevel256
pidfile run/slapd.pid
argsfilerun/slapd.args
allow bind_v2
password-hash {SHA}
###
# BDB database definitions
###
databasebdb
suffix dc=22decembre,dc=eu
rootdn cn=admin,dc=22decembre,dc=eu
access to dn.base= by * read
access to dn.base=cn=Subschema by * read
#access to attrs=userpassword
# by self write
# by anonymous auth
# by * none
#rootpw secret
rootpw {SSHA}vdszl5a7z9UlAU6iHU0xlKJCY+Tpgmv+
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory data
# Indices to maintain
index objectClass eq
index uid eq
index uidNumber eq
index gidNumber eq
index memberUid eq
index homeDirectory eq
index loginShell eq
index cn,gn,mail pres,eq,sub
##
I have tried to disable all acl (so default policy : everything
readable). But still no possible to logon.
Here is what I get when trying to using the login_ldap with debugging
:
# /usr/local/libexec/auth/login_-ldap -d -s login stephane ldap
Password:
load_ssl_certs says:
cacert none
cacertdir none
usercert none
userkey none
parse_server_line buf = localhost
parse_server_line port == NULL, will use default
parse_server_line mode == NULL, will use default
host localhost, port 389, version 3
setting cert info
clearing ssl set
connect success!
set version to 3
defaults:
basedn ou=users,dc=22decembre,dc=eu
binddn none
bindpw none
set timeout sec 60, usec 6
set noref 0
set keepcreds 0
bind success!
usearch:
ufilter ((objectclass=posixAccount)(uid=stephane))
scope: sub
0: search (ou=users,dc=22decembre,dc=eu, ((objectclass=posixAccount)
(uid=stephane)))
1: msgid 0, type 64
1: SEARCH_ENTRY userdn uid=stephane,ou=users,dc=22decembre,dc=eu
1: msgid 1, type 65
1: returning userdn = uid=stephane,ou=users,dc=22decembre,dc=eu
userdn uid=stephane,ou=users,dc=22decembre,dc=eu
user bind failed, dn: uid=stephane,ou=users,dc=22decembre,dc=eu
reject
I am using ypldap from base and login_ldap from ports; your mileage
may vary.
By the way, anybody use the light ldapd daemon included in base ?
can we update password with it ?
I use it. It does not currently support the modify password extended
operation (what ldappasswd relies on). I am working on a patch for
it but I haven't finished it and it requires a bit more refactoring
than just processing one new request.
Ok, so I think I will check ldapd from time to time...
--
Matthew Weigel
[demime 1.01d removed an attachment of type application/pgp-signature which had
a name of signature.asc]
Re: openldap password fails to update
Le samedi 8 mars 2014, 17:21:26 Stéphane Guedon a écrit :
Le samedi 8 mars 2014, 09:09:08 Matthew Weigel a écrit :
On Mar 8, 2014, at 6:29 AM, Stéphane Guedon
steph...@22decembre.eu wrote:
Notably, the user fails to auth and do login (with openbsd login
system AND webpages) eventhough password is correct according to
ldap itself !
That's a lot more moving parts than just passwords in LDAP.
Yes, but passwords are the first things to change to secure your
users/install.
I am currently working on a little webpage in python to allow easy
ldap management (add/remove users and groups, passwords update).
Have you
checked your configuration of all those moving parts? Looked at
logs? You don't even mention what else you're using, much less how
they've been configured or what their logs report.
I am looking through logs and config since the beginning of the
day... Actually, asking help on forums or mailing lists is always
my last step in solving problems...
here is my config :
include schema/core.schema
include schema/cosine.schema
include schema/inetorgperson.schema
include schema/misc.schema
include schema/nis.schema
include schema/openldap.schema
loglevel256
pidfile run/slapd.pid
argsfilerun/slapd.args
allow bind_v2
password-hash {SHA}
### # BDB database definitions
###
databasebdb
suffix dc=22decembre,dc=eu
rootdn cn=admin,dc=22decembre,dc=eu
access to dn.base= by * read
access to dn.base=cn=Subschema by * read
#access to attrs=userpassword
# by self write
# by anonymous auth
# by * none
#rootpw secret
rootpw {SSHA}vdszl5a7z9UlAU6iHU0xlKJCY+Tpgmv+
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory data
# Indices to maintain
index objectClass eq
index uid eq
index uidNumber eq
index gidNumber eq
index memberUid eq
index homeDirectory eq
index loginShell eq
index cn,gn,mail pres,eq,sub
##
I have tried to disable all acl (so default policy : everything
readable). But still no possible to logon.
Here is what I get when trying to using the login_ldap with
debugging
# /usr/local/libexec/auth/login_-ldap -d -s login stephane ldap
Password:
load_ssl_certs says:
cacert none
cacertdir none
usercert none
userkey none
parse_server_line buf = localhost
parse_server_line port == NULL, will use default
parse_server_line mode == NULL, will use default
host localhost, port 389, version 3
setting cert info
clearing ssl set
connect success!
set version to 3
defaults:
basedn ou=users,dc=22decembre,dc=eu
binddn none
bindpw none
set timeout sec 60, usec 6
set noref 0
set keepcreds 0
bind success!
usearch:
ufilter ((objectclass=posixAccount)(uid=stephane))
scope: sub
0: search (ou=users,dc=22decembre,dc=eu,
((objectclass=posixAccount) (uid=stephane)))
1: msgid 0, type 64
1: SEARCH_ENTRY userdn uid=stephane,ou=users,dc=22decembre,dc=eu
1: msgid 1, type 65
1: returning userdn = uid=stephane,ou=users,dc=22decembre,dc=eu
userdn uid=stephane,ou=users,dc=22decembre,dc=eu
user bind failed, dn: uid=stephane,ou=users,dc=22decembre,dc=eu
reject
when using the one in /usr/libexec/auth/login_... instead of
/usr/local/libexec... it works !
and I can start ypldap !
But why can't I authenticate (using ssh or login) on the system ? Do I
really have to go through ypldap ? Sounds not efficient to have an
intermediate !
And still having problem with my php scripts, which I am debugging
now.
Thanks for your help and answers. Please continue if you have any idea
! :D
I am using ypldap from base and login_ldap from ports; your
mileage
may vary.
By the way, anybody use the light ldapd daemon included in base
?
can we update password with it ?
I use it. It does not currently support the modify password
extended operation (what ldappasswd relies on). I am working on a
patch for it but I haven't finished it and it requires a bit more
refactoring than just processing one new request.
Ok, so I think I will check ldapd from time to time...
--
Matthew Weigel
Re: openldap password fails to update
On 03/08/2014 12:16 PM, Stéphane Guedon wrote: I am looking through logs and config since the beginning of the day... Actually, asking help on forums or mailing lists is always my last step in solving problems... We try to help. But... giving detailed descriptions of the problem, and showing relevant configs and logs the first time, goes a long way to helping people help you. Reading manuals helps too. Among others, ypldap(8), ypldap.conf(5), login.conf(5), login_ldap(8) from ports, and whatever manuals for OpenLDAP. But why can't I authenticate (using ssh or login) on the system ? Do I really have to go through ypldap ? Sounds not efficient to have an intermediate ! There are two separate mechanisms: how user information is looked up, and how users are authenticated. You provide zero details on how ypldap or login_ldap are configured, so it's hard to guess whether you have some configuration wrong. I can say it works for me. The user lookup is configured (via +:: entries in /etc/passwd and /etc/group) to use YP routines. Thus the user is looked up in ypldap when they attempt to login, which is configured to identify the user's login class as ldap. The ldap login class is configured in login.conf to authenticate via login_ldap talking to the LDAP server, which is configured to have the appropriate users. This is what I meant by that's a lot more moving parts than just passwords in LDAP. -- Matthew Weigel hacker unique idempot . ent
Re: openldap password fails to update
On 2014-03-08, Stéphane Guedon steph...@22decembre.eu wrote: Notably, the user fails to auth and do login (with openbsd login system AND webpages) eventhough password is correct according to ldap itself ! How are you doing ldap authentication? (i.e. what software are you using, and how does it authenticate? attempt binding as the user trying to login, or looking up the password via a high-privileged account? I'm using login-ldap from packages for ldap password auth, this works fine for me against passwords stored in openldap. I have this in login.conf: ldap:\ :auth=-ldap:\ :x-ldap-server=127.0.0.1:\ :x-ldap-timeout=5:\ :x-ldap-basedn=ou=user,dc=exaple,dc=com:\ :x-ldap-filter=((objectclass=posixAccount)(uid=%u)):\ :tc=default: and set the login class to ldap on accounts which should use this as their password source (e.g. class is the 5th field in master.passwd if using statically configured accounts with ldap passwords, or 'fixed attribute class ldap' in ypldap.conf if doing it that way).
Re: openldap password fails to update
Le samedi 8 mars 2014, 19:16:07 Stéphane Guedon a écrit :
Le samedi 8 mars 2014, 17:21:26 Stéphane Guedon a écrit :
Le samedi 8 mars 2014, 09:09:08 Matthew Weigel a écrit :
On Mar 8, 2014, at 6:29 AM, Stéphane Guedon
steph...@22decembre.eu wrote:
Notably, the user fails to auth and do login (with openbsd
login
system AND webpages) eventhough password is correct according
to
ldap itself !
That's a lot more moving parts than just passwords in LDAP.
Yes, but passwords are the first things to change to secure your
users/install.
I am currently working on a little webpage in python to allow
easy
ldap management (add/remove users and groups, passwords update).
Have you
checked your configuration of all those moving parts? Looked at
logs? You don't even mention what else you're using, much less
how
they've been configured or what their logs report.
I am looking through logs and config since the beginning of the
day... Actually, asking help on forums or mailing lists is always
my last step in solving problems...
here is my config :
include schema/core.schema
include schema/cosine.schema
include schema/inetorgperson.schema
include schema/misc.schema
include schema/nis.schema
include schema/openldap.schema
loglevel256
pidfile run/slapd.pid
argsfilerun/slapd.args
allow bind_v2
password-hash {SHA}
##
## ### # BDB database definitions
##
## ###
databasebdb
suffix dc=22decembre,dc=eu
rootdn cn=admin,dc=22decembre,dc=eu
access to dn.base= by * read
access to dn.base=cn=Subschema by * read
#access to attrs=userpassword
# by self write
# by anonymous auth
# by * none
#rootpw secret
rootpw {SSHA}vdszl5a7z9UlAU6iHU0xlKJCY+Tpgmv+
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory data
# Indices to maintain
index objectClass eq
index uid eq
index uidNumber eq
index gidNumber eq
index memberUid eq
index homeDirectory eq
index loginShell eq
index cn,gn,mail pres,eq,sub
##
I have tried to disable all acl (so default policy : everything
readable). But still no possible to logon.
Here is what I get when trying to using the login_ldap with
debugging
# /usr/local/libexec/auth/login_-ldap -d -s login stephane ldap
Password:
load_ssl_certs says:
cacert none
cacertdir none
usercert none
userkey none
parse_server_line buf = localhost
parse_server_line port == NULL, will use default
parse_server_line mode == NULL, will use default
host localhost, port 389, version 3
setting cert info
clearing ssl set
connect success!
set version to 3
defaults:
basedn ou=users,dc=22decembre,dc=eu
binddn none
bindpw none
set timeout sec 60, usec 6
set noref 0
set keepcreds 0
bind success!
usearch:
ufilter ((objectclass=posixAccount)(uid=stephane))
scope: sub
0: search (ou=users,dc=22decembre,dc=eu,
((objectclass=posixAccount) (uid=stephane)))
1: msgid 0, type 64
1: SEARCH_ENTRY userdn uid=stephane,ou=users,dc=22decembre,dc=eu
1: msgid 1, type 65
1: returning userdn = uid=stephane,ou=users,dc=22decembre,dc=eu
userdn uid=stephane,ou=users,dc=22decembre,dc=eu
user bind failed, dn: uid=stephane,ou=users,dc=22decembre,dc=eu
reject
when using the one in /usr/libexec/auth/login_... instead of
/usr/local/libexec... it works !
and I can start ypldap !
But why can't I authenticate (using ssh or login) on the system ? Do
I really have to go through ypldap ? Sounds not efficient to have
an intermediate !
And still having problem with my php scripts, which I am debugging
now.
found the thing...
when I use 127.0.0.1 in php scripts, I can use ldap.
if the script is running with 'localhost' then, no ldap data...
Any idea why ?
I have checked host resolution...
telnet localhost ldap gives the good behavior
# netstat -at|grep ldap
tcp 0 0 localhost.29434localhost.ldap
TIME_WAIT
tcp 0 0 *.ldap *.*
LISTEN
tcp 0 0 localhost.ldap *.*
LISTEN
tcp6 0 0 *.ldap *.*
LISTEN
tcp6 0 0 localhost.ldap *.*
LISTEN
0xfe812e35d938 dgram 0 0 0xfe812de95288
0x00x00x0 /var/openldap-data/dev/log
Thanks for your help and answers. Please
Re: openldap password fails to update
On 03/08/2014 03:11 PM, Stéphane Guedon wrote: when I use 127.0.0.1 in php scripts, I can use ldap. if the script is running with 'localhost' then, no ldap data... Any idea why ? I have checked host resolution... telnet localhost ldap gives the good behavior Is PHP running inside a chroot? Does that chroot have an /etc/hosts with an entry for localhost? -- Matthew Weigel hacker unique idempot . ent
openldap password fails to update
Hello everybody. I am currently finishing my openbsd server. Most of installation gone pretty well :-). I run now in openldap. I successfully installed the server and launched it in chroot for security. My problem is weird : using ldapadd, I can add peoples and stuff. ldapadd -x -D cn=admin,dc=22decembre,dc=eu -w secret -f stef.ldif adding new entry uid=test,ou=users,dc=22decembre,dc=eu But when I try to change this user password it fails : # ldappasswd -x -v -D uid=test,ou=users,dc=22decembre,dc=eu \ -w somesecret -s anothersec ldap_initialize( DEFAULT ) Result: Other (e.g., implementation specific) error (80) Additional info: password hash failed and when looking in logs I don't see why it fails ! Mar 7 10:29:35 blackblock slapd[26351]: = slap_access_allowed: auth access granted by auth(=xd) Mar 7 10:29:35 blackblock slapd[26351]: = access_allowed: auth access granted by auth(=xd) Mar 7 10:29:35 blackblock slapd[26351]: conn=1014 op=0 BIND dn=uid=test,ou=users,dc=22decembre,dc=eu mech=SIMPLE ssf=0 Mar 7 10:29:35 blackblock slapd[26351]: do_bind: v3 bind: uid=test,ou=users,dc=22decembre,dc=eu to uid=test,ou=users,dc=22decembre,dc=eu Mar 7 10:29:35 blackblock slapd[26351]: send_ldap_result: conn=1014 op=0 p=3 Mar 7 10:29:35 blackblock slapd[26351]: send_ldap_result: err=0 matched= text= Mar 7 10:29:35 blackblock slapd[26351]: send_ldap_response: msgid=1 tag=97 err=0 Mar 7 10:29:35 blackblock slapd[26351]: conn=1014 op=0 RESULT tag=97 err=0 text= Mar 7 10:29:35 blackblock slapd[26351]: daemon: activity on 1 descriptor Mar 7 10:29:35 blackblock slapd[26351]: daemon: activity on: Mar 7 10:29:35 blackblock slapd[26351]: 22r Mar 7 10:29:35 blackblock slapd[26351]: Mar 7 10:29:35 blackblock slapd[26351]: daemon: read activity on 22 Mar 7 10:29:35 blackblock slapd[26351]: daemon: select: listen=6 active_threads=0 tvp=NULL Mar 7 10:29:35 blackblock slapd[26351]: daemon: select: listen=7 active_threads=0 tvp=NULL Mar 7 10:29:35 blackblock slapd[26351]: connection_get(22) Mar 7 10:29:35 blackblock slapd[26351]: connection_get(22): got connid=1014 Mar 7 10:29:35 blackblock slapd[26351]: connection_read(22): checking for input on id=1014 Mar 7 10:29:35 blackblock slapd[26351]: op tag 0x77, time 1394184575 Mar 7 10:29:35 blackblock slapd[26351]: daemon: activity on 1 descriptor Mar 7 10:29:35 blackblock slapd[26351]: daemon: waked Mar 7 10:29:35 blackblock slapd[26351]: daemon: select: listen=6 active_threads=0 tvp=NULL Mar 7 10:29:35 blackblock slapd[26351]: daemon: select: listen=7 active_threads=0 tvp=NULL Mar 7 10:29:35 blackblock slapd[26351]: conn=1014 op=1 do_extended Mar 7 10:29:35 blackblock slapd[26351]: conn=1014 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.1 Mar 7 10:29:35 blackblock slapd[26351]: do_extended: oid=1.3.6.1.4.1.4203.1.11.1 Mar 7 10:29:35 blackblock slapd[26351]: conn=1014 op=1 PASSMOD new Mar 7 10:29:35 blackblock slapd[26351]: bdb_dn2entry(uid=test,ou=users,dc=22decembre,dc=eu) Mar 7 10:29:35 blackblock slapd[26351]: send_ldap_extended: err=80 oid= len=0 Mar 7 10:29:35 blackblock slapd[26351]: send_ldap_response: msgid=2 tag=120 err=80 Mar 7 10:29:35 blackblock slapd[26351]: conn=1014 op=1 RESULT oid= err=80 text=password hash failed Mar 7 10:29:35 blackblock slapd[26351]: daemon: activity on 1 descriptor Mar 7 10:29:35 blackblock slapd[26351]: daemon: activity on: Mar 7 10:29:35 blackblock slapd[26351]: 22r Mar 7 10:29:35 blackblock slapd[26351]: Mar 7 10:29:35 blackblock slapd[26351]: daemon: read activity on 22 Mar 7 10:29:35 blackblock slapd[26351]: daemon: select: listen=6 active_threads=0 tvp=NULL Mar 7 10:29:35 blackblock slapd[26351]: connection_get(22) Mar 7 10:29:35 blackblock slapd[26351]: daemon: select: listen=7 active_threads=0 tvp=NULL Mar 7 10:29:35 blackblock slapd[26351]: connection_get(22): got connid=1014 Mar 7 10:29:35 blackblock slapd[26351]: connection_read(22): checking for input on id=1014 Mar 7 10:29:35 blackblock slapd[26351]: op tag 0x42, time 1394184575 Mar 7 10:29:35 blackblock slapd[26351]: ber_get_next on fd 22 failed errno=0 (Undefined error: 0) Mar 7 10:29:35 blackblock slapd[26351]: connection_read(22): input error=-2 id=1014, closing. Mar 7 10:29:35 blackblock slapd[26351]: connection_closing: readying conn=1014 sd=22 for close Mar 7 10:29:35 blackblock slapd[26351]: daemon: activity on 1 descriptor Mar 7 10:29:35 blackblock slapd[26351]: daemon: waked Mar 7 10:29:35 blackblock slapd[26351]: daemon: select: listen=6 active_threads=0 tvp=NULL Mar 7 10:29:35 blackblock slapd[26351]: daemon: select: listen=7 active_threads=0 tvp=NULL Mar 7 10:29:35 blackblock slapd[26351]: connection_close: deferring conn=1014 sd=22 Mar 7 10:29:35 blackblock slapd[26351]: conn=1014 op=2 do_unbind Mar 7
Re: openldap password fails to update
On 03/07/2014 04:22 AM, Stéphane Guedon wrote:
# ldappasswd -x -v -D uid=test,ou=users,dc=22decembre,dc=eu \
-w somesecret -s anothersec
ldap_initialize( DEFAULT )
Result: Other (e.g., implementation specific) error (80)
Additional info: password hash failed
I'm sorry, it's not clear that this is an OpenBSD problem. See, for
example,
http://www.openldap.org/lists/openldap-technical/200902/msg00186.html
There's another thing strange, maybe related to the problem :
slappasswd never gives the same result !
# slappasswd
New password:
Re-enter new password:
{SSHA}8ip4+k3gVAN6Gggf2szhJxo052sI3Fyc
# slappasswd
New password:
Re-enter new password:
{SSHA}JvduTI/JAX1G9AhtlCYEjNHl/6DbE6hs
The whole point of salting is to make the hash different each time. A
random salt is used to alter the hash and then that salt is added to the
end of the hashed string before being base64-encoded to give you the
hash you see.
--
Matthew Weigel
hacker
unique idempot . ent
