[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: ACL/anonymous bind problems
Hey Matt - thanks for the reply. I have set up a seperate user now
to authenticate, but I still need to allow that user read access to the
userPassword field in the ACL for authentication to work, so it does
look like padl's pam module wants read access.
It's still the lesser of the evils I have to choose from. Does anyone
know what the minimum permissions are that I can use on the /etc/ldap.conf
file without running into problems? Also is there a way aside from clear
text to specify the bindpw in /etc/ldap.conf? Otherwise I am pretty much
back to having a hole where any user can see what the Authenticator password
is and use that to do binds with, which would allow them to see anyone's
userPassword. Thanks again,
Michael
-----Original Message-----
From: M Butcher [mailto:mbutcher@grcomputing.net]
Sent: Wednesday, May 21, 2003 4:59 PM
To: Lawrence, Mike (White ""Plains)
Cc: openldap-software@OpenLDAP.org
Subject: 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>
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.