[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: test my LDAP server ONLY using ssh?

tor, 2003-01-23 kl. 18:36 skrev Brian K. Jones:

> Well, I can't log in via ssh, so I'd say 'no', but I don't know if it's
> due to an error in the specified file, or if I screwed something else
> up, which is why there was so much info in the original post.  

#%PAM-1.0
auth       required     /lib/security/pam_nologin.so
auth       sufficient    /lib/security/pam_ldap.so
auth       required     /lib/security/pam_unix_auth.so try_first_pass
account    sufficient   /lib/security/pam_ldap.so
account    required     /lib/security/pam_unix_acct.so
password   required     /lib/security/pam_cracklib.so
password   sufficient   /lib/security/pam_ldap.so
password   required     /lib/security/pam_pwdb.so use_first_pass
session    required     /lib/security/pam_unix_session.so

Mine from my /usr/share/doc/nss_ldap-189/pam.d directory. I'd compiled
and installed the stuff first :-) Everything in that directory works out
of the box.


> > > Jan 22 15:33:47 current slapd[4074]: conn=29 op=0 BIND dn="" method=128 
> > 
> > This is an anonymous bind. Is that what you want to find things with?
> > Difficult to know without knowing what your ACLs look like.
> 
> Do you mean that SSHD is binding to the server anonoymously?  So *me*
> and, separately, the *sshd* daemon have to bind to the ldap server?

If the sshd daemon is correctly configured for pam_ldap, then it will
*also* (i.e. not exclusively) use ldap to authenticate *ssh*
connections. It's got *nothing* to do with ldapsearch and what you're
trying to do. If you can ssh to the machine, it works.

> I suppose this makes some sense when you see the log entries that show a
> connection essentially coming in from the local host.  What's
> recommended procedure here?  I added 'binddn' to my /etc/ldap.conf file,

O.k.

> so now 'BIND dn=""' has an actual DN to bind with, but I don't know the
> proper syntax for ldap.conf to get this working.

You have to put the password of the cn or uid or whatever you use in the
dn in cleartext in /etc/ldap.secret. It tells you that in ldap.conf

> What I got after doing
> this was 
> =================================================================
> Jan 23 12:03:28 current slapd[5973]: conn=2 fd=12 ACCEPT from
> IP=128.112.6.64:39105 (IP=0.0.0.0:389) 
> 
> Jan 23 12:03:28 current slapd[6078]: conn=2 op=0 BIND
> dn="cn=daproot,dc=cs,dc=princeton,dc=edu" method=128 
> 
> Jan 23 12:03:28 current slapd[6078]: conn=2 op=0 RESULT tag=97 err=53
> text=unwilling to allow anonymous bind with non-empty DN 

He hasn't got a proper entry in the DIT, i.e., he has no valid record
with which to authenticate. He is not acknowledged.

> Now I googled for that 'non-empty DN' bit, and it returned NOTHING.  A
> search of this mailing list returned one thread, which provided a
> *little* help.

Just make a record for him with a proper dn.

> "The fast solution:
> Put the following line into slapd.conf:
> allow bind_v2 bind_anon_dn"
> 
> But this doesn't explain why the error occurs.

Oh yes it does. His dn probably begins with uid, not cn.

> The error apparently
> occurs because there's some sort of default set somewhere to bind
> anonymously, so I put "disallow bind_anon" in my /etc/ldap.conf file.

Why? It (AFAIK with 2.1.12) will have no effect.
 
> The hope is that since it doesn't allow anon binds with a non-empty dn,
> it will now be forced to use the non-empty dn to perform a
> 'non-anonymous' bind.  Now I get only slightly different, and,
> unbelievably, LESS useful log messages...
> 
> ====================================================================
> Jan 23 12:21:45 current slapd[6222]: conn=0 fd=12 ACCEPT from
> IP=128.112.6.64:39111 (IP=0.0.0.0:389) 
> 
> Jan 23 12:21:45 current slapd[6251]: conn=0 op=0 BIND
> dn="cn=daproot,dc=cs,dc=princeton,dc=edu" method=128 
> 
> Jan 23 12:21:45 current slapd[6251]: conn=0 op=0 RESULT tag=97 err=48

Error 48/49 means "Invalid credentials", i.e. the combination of dn and
password is incorrect.

> access to *
>         by * read
>         by anonymous auth
>         by users read

O.k., make sure the dn agrees with what's in ldap.conf.

> > Get GQ, compile it for Red Hat - jump from www.biot.com :-)
> 
> I HATE GQ.  THERE'S NO DOCS and I can't even connect to my server with
> it.

You can't connect to your server with *anything* at the moment, that's
not GQ's fault. And you don't need docs, you just point 'n click :-)

>   I hate it, I hate it, I hate it.  I'm tired of trying to figure out
> the syntax it's looking for for the configuration fields.

You just enter what you put in the ldif files, only it lets you see what
you're doing. Mind you, it does help to have a server connection first.

> I'm not up
> for trying to figure out the magical incantations with a GUI when the
> CLI tools are already known to work well. Not that I wouldn't LOVE a
> tool to make this stuff easier, but I don't think GQ is for me -
> personally.

Wait until the rest works. Then you'll see that GQ is more than just
useful.

Keep persevering!

Best,

Tony

-- 

Tony Earnshaw

When all's said and done ...
there's nothing left to say or do.

e-post:		tonni@billy.demon.nl
www:		http://www.billy.demon.nl