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
> >
> > loglevel 256
> >
> > pidfile run/slapd.pid
> > argsfile run/slapd.args
> > allow bind_v2
> > password-hash {SHA}
> >
> > ##################################################################
> > ## ### # BDB database definitions
> > ##################################################################
> > ## ###
> >
> > database bdb
> > 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 60000
> > 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.29434 localhost.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
0xfffffe812e35d938 dgram 0 0 0xfffffe812de95288
0x0 0x0 0x0 /var/openldap-data/dev/log
>
> 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
[demime 1.01d removed an attachment of type application/pgp-signature which had
a name of signature.asc]
