[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: ACL/anonymous bind problems
Interesting. Someone else (probably on this list) suggested to me that
pam_ldap was requiring read instead of auth for anonymous binds... and
that's a no-no, as it allows brute-force attacks on userPassword fields.
(e.g. auth solves the same problem that password shadow files do)
I highly recommend that you test out the other method I suggested. It's
better for security, anyway (as it allows you to block off as much as
you want from anonymous users without impacting PAM).
I basically set this up by adding an entry to the ldap like this:
dn: cn=Authenticator,dc=mydomain,dc=com
objectClass: person
cn: Authenticator
sn: Authenticator
description: Used for authentication to LDAP
userPassword:: [hashed password]
And set up my /etc/ldap.conf to include this:
binddn cn=authenticator,dc=mydomain,dc=com
bindpw secret # or whatever it is
My acl is just like yours, but with:
access to attr=userPassword
by self write
by anonymous auth
by cn=authenticator,dc=mydomain,dc=com auth
That works for me.
Matt
On Wed, 2003-05-21 at 12:53, Lawrence, Mike (White Plains) wrote:
> Hi - I've tried the second solution you proposed and still seem to be stuck
> with authentication not working. I turned up logging to -1 in slapd.conf
> and am noticing this showing up during a failed ssh login attempt:
>
> May 21 14:46:22 wp-app1 slapd[14907]: [ID 923158 local4.debug] =>
> access_allowed: read access to "uid=fred,ou=people,dc=webtech,dc=com"
> "userPassword" requested
> May 21 14:46:22 wp-app1 slapd[14907]: [ID 967793 local4.debug] => acl_get:
> [1] check attr userPassword
> May 21 14:46:22 wp-app1 slapd[14907]: [ID 155642 local4.debug] <= acl_get:
> [1] acl uid=fred,ou=people,dc=webtech,dc=com attr: userPassword
> May 21 14:46:22 wp-app1 slapd[14907]: [ID 971074 local4.debug] => acl_mask:
> access to entry "uid=fred,ou=people,dc=webtech,dc=com", attr "userPassword"
> requested
> May 21 14:46:22 wp-app1 slapd[14907]: [ID 488679 local4.debug] => acl_mask:
> to all values by "", (=n)
> May 21 14:46:22 wp-app1 slapd[14907]: [ID 704950 local4.debug] <= check
> a_dn_pat: self
> May 21 14:46:22 wp-app1 slapd[14907]: [ID 704950 local4.debug] <= check
> a_dn_pat: *
> May 21 14:46:22 wp-app1 slapd[14907]: [ID 279303 local4.debug] <= acl_mask:
> [2] applying auth(=x) (stop)
> May 21 14:46:22 wp-app1 slapd[14907]: [ID 804284 local4.debug] <= acl_mask:
> [2] mask: auth(=x)
> May 21 14:46:22 wp-app1 slapd[14907]: [ID 384072 local4.debug] =>
> access_allowed: read access denied by auth(=x)
> May 21 14:46:22 wp-app1 slapd[14907]: [ID 886347 local4.debug] acl: access
> to attribute userPassword not allowed
> ù
>
> If I turn on rootbinddn in /etc/ldap.conf, then I see this in the logs (and
> authentication works):
>
> May 21 14:54:25 wp-app1 slapd[14907]: [ID 923158 local4.debug] =>
> access_allowed: read access to "uid=fred,ou=people,dc=webtech,dc=com"
> "userPassword" requested
> May 21 14:54:25 wp-app1 slapd[14907]: [ID 592946 local4.debug] <= root
> access granted
>
> I'm not sure why it's asking for read access to userPassword in either case
> though
> as it should just need auth rights? Also who is (=x)? Is that the way it
> logs
> anonymous binds?
>
> I'll cut and paste my slapd.conf and ldap.conf below, I am totally stumped.
> Thanks!
>
>
> slapd.conf:
>
> include /opt/csw/etc/openldap/schema/core.schema
>
> pidfile /opt/csw/var/slapd.pid
> argsfile /opt/csw/var/slapd.args
> loglevel 32
>
> database bdb
> suffix "dc=webtech,dc=com"
> rootdn "cn=Manager,dc=webtech,dc=com"
>
> rootpw {crypt}secret
> directory /opt/csw/var/openldap-data
>
> index objectClass eq
> index cn pres,eq
>
> TLSCipherSuite HIGH:MEDIUM:+SSLv2
> TLSCertificateFile /opt/csw/etc/openldap/ldapcert.pem
> TLSCertificateKeyFile /opt/csw/etc/openldap/ldapkey.pem
> TLSCACertificateFile /opt/csw/etc/openldap/demoCA/cacert.pem
>
> include /opt/csw/etc/openldap/schema/cosine.schema
> include /opt/csw/etc/openldap/schema/nis.schema
> include /opt/csw/etc/openldap/schema/inetorgperson.schema
> include /opt/csw/etc/openldap/schema/solaris.schema
>
> password-hash {CRYPT}
>
> access to attr=userPassword
> by self write
> by anonymous auth
>
> access to * by * read
>
>
> /etc/ldap.conf:
>
>
> host 127.0.0.1
> base dc=webtech,dc=com
> uri ldap://127.0.0.1/
> ldap_version 3
>
> # rootbinddn cn=Manager,dc=webtech,dc=com
>
> port 389
> scope sub
> pam_password crypt
> nss_base_passwd ou=People,dc=webtech,dc=com?one
> nss_base_shadow ou=People,dc=webtech,dc=com?one
> nss_base_group ou=Group,dc=webtech,dc=com?one
> ssl start_tls
> ssl on
> tls_checkpeer yes
> tls_cacertfile /opt/csw/etc/openldap/demoCA/cacert.pem
> tls_ciphers TLSv1:HIGH:MEDIUM:+SSLv2:DES
>
>
> -----Original Message-----
> From: M Butcher [mailto:mbutcher@grcomputing.net]
> Sent: Wednesday, May 21, 2003 12:56 PM
> To: openldap-software@OpenLDAP.org
> Subject: Re: ACL/anonymous bind problems
>
>
> ACLs are evaluated from top to bottom, so you _definitely_ need to move
> the access to * by * down below the other rule.
>
> my _personal_ opinion is that the ideal way to set up pam_ldap is to
> create a specific user for pam_ldap to bind as. That user can do auth on
> userPassword, and no other users can.
>
> For instance, if I have pam_ldap bind as cn=pam,dc=mycompany,dc=com,
> then I can do:
>
> # Note: attr, not attrs
> access to attr=userPassword
> by self write
> by cn=pam,dc=mycompnay,dc=com auth
> by * none
>
> access to * by *
> # or whatever other rules you want.
>
> However, if you wanted to do it w/o needing an entry for pam_ldap, then
> you would do it this way:
>
> access to attr=userPassword
> by self write
> by anonymous auth
>
> access to * by *
>
>
> Matt
>
>
> On Wed, 2003-05-21 at 09:59, Lawrence, Mike (White Plains) wrote:
> > Hi - I seem to be stuck trying to get the right ACLs set up for my
> > slapd.conf. I am using Solaris 8 with
> > the padl pam and nss ldap modules. Right now all I am using it for is to
> > store the /etc/passwd and
> > /etc/shadow type information to let users authenticate against it with
> ssh.
> >
> > Basically I can't seem to find the right ACL that both stops people from
> > reading passwords other than
> > their own (say with an ldapsearch), yet also allows anonymous binds to
> work
> > through the padl pam
> > ldap module and ssh.
> >
> > If I use this set of ACLs:
> >
> > access to *
> > by * read
> >
> > access to attrs=userPassword
> > by self write
> > by * auth
> > by * none
> >
> > people can log in with the padl pam module using anonymous binds (meaning
> I
> > don't use a binddn/
> > bindpw pair in /etc/ldap.conf, nor rootbinddn with and /etc/ldap.secret)
> > with this set of ACLs, but
> > anyone can use ldapsearch and see the userPassword fields.
> >
> > But the problem is if I move the "access to * by * read" below the
> > userPassword ACLs as I've read
> > about from a few sources, then anonymous binds through the padl pam ldap
> > module become broken
> > (but are fixed if I use rootbinddn in /etc/ldap.conf with an
> > /etc/ldap.secret file).
> >
> > I really don't want to leave the directory manager password out in
> > /etc/ldap.secret, nor do I want ldapsearch
> > to show users what other users' userPassword fields are. Any suggestions
> as
> > to how to get out of this
> > predicament? Thanks!
> > This electronic message transmission contains information from the Company
> that may be proprietary, confidential and/or privileged.
> > The information is intended only for the use of the individual(s) or
> entity named above. If you are not the intended recipient, be
> > aware that any disclosure, copying or distribution or use of the contents
> of this information is prohibited. If you have received
> > this electronic transmission in error, please notify the sender
> immediately by replying to the address listed in the "From:" field.
--
M Butcher <mbutcher@grcomputing.net>