Re: test my LDAP server ONLY using ssh?

["Brian K. Jones" <jonesy@CS.Princeton.EDU>]

On Thu, 2003-01-23 at 14:10, Tony Earnshaw wrote:

> 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.
> 
I copied yours.  I don't have that directory.

> 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'm not trying to do an ldapsearch of any kind.  I'm simply trying to
ssh to the ldap server from my workstation, and have the ssh daemon look
to the ldap server for the authentication information.  
> 

> > 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

Nothing has EVER told me that, which makes everything much more
annoying.  ldap.conf doesn't tell me that - man ldap.conf doesn't tell
me that, the OpenLDAP administrator's guide hasn't told me that, the
securityfocus and linux magazine tutorials haven't told me that...

In addition, why am I going to bother moving to ldap if at some point I
have to have a password somewhere in clear text?  One of the goals of
the whole migration is to eventually make it so that a user can't
effectively do a 'cat /etc/passwd', or 'ypcat passwd' and get anything
useful.  There are security reasons for migrating from nis to ldap, so
how is this acceptable in any environment?

> 
> > 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.

This entry absolutely exists.  I've been testing with this user since
day 1.  Unfortunately, I can't show you entries like I could yesterday,
because in the process of getting ssh working, I've apparently broken
everything else.  I have no idea how this happened, but I'm thinking
about just blowing this whole thing away and starting over.
> 
> > 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.

It's there.  There are other issues, evidently.

> 
> > "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.

No, that guy was the 'Manager' user, and his entry, indeed, begins with
cn, not uid.  The regular users who were migrated over from NIS all
begin with uid. 

> > access to *
> >         by * read
> >         by anonymous auth
> >         by users read
> 
> O.k., make sure the dn agrees with what's in ldap.conf.

I'm not sure I know what you mean here.