On 12/02/2011 09:58 AM, Jayavant Patil wrote:
On Fri, Dec 2, 2011 at 12:19 PM, Jayavant Patil
<[email protected] <mailto:[email protected]>> wrote:
On Thu, Dec 1, 2011 at 7:12 PM, Jayavant Patil
<[email protected] <mailto:[email protected]>>
wrote:
On Wed, 30 Nov 2011 14:18:00 +0100 Raffael Sahli
<[email protected] <mailto:[email protected]>> wrote:
>On 11/30/2011 01:48 PM, Jayavant Patil wrote:
>
>
> >>On 11/30/2011 08:01 AM, Jayavant Patil wrote:
> >>
> >>
> >> On Tue, Nov 29, 2011 at 6:26 PM, Jayavant Patil
> >> <[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>> wrote:
> >>
> >>
> >> >>Mon, 28 Nov 2011 11:25:16 +0100 Raffael Sahli
> >> <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>> wrote:
> >> >>Hi
> >>
> >> >>I think you mean SSL connection or the STARTTLS Layer...?
> >> >>Please read the manual
http://www.openldap.org/doc/admin24/tls.html
> >> >Ok.
> >>
> >> >>And tree security:
> >> >>On my server, a client user can only see his own object:
> >> >Are you using simple authentication mechanism?
> >>
> >> >>Maybe create a rule like this:
> >> >>access to filter=(objectClass=
> >> >>simpleSecurityObject)
> >> >> by self read
> >> >> by * none
> >>
> >> >I am not getting what the ACL rule specifies. Any
suggestions?
> >>
> >>
> >> I have two users ldap_6 and ldap_7. I want to
restrict a user to
> >> see his own data only.
> >> In slapd.conf, I specified the rule as follows:
> >> access to *
> >> by self write
> >> by * none
> >>
> >> But ldap_6 can see the ldap_7 user entries (or vice
versa) with
> >> $ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
> >> "ou=People,dc=abc,dc=com" "uid=ldap_7"
> >>
> >> Any suggestions?
> >>
> >On Wed, 30 Nov 2011 08:38:32 +0100 Raffael Sahli
> <[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> wrote:
> >Yes, that's exactly the rule I wrote above.
>
> >access to filter=(objectClass=
> >simpleSecurityObject)
> > by self read
> > by * none
>
>
> >Maybe you have to change the objectClass to posixAccount,
or both or
> >whatever....
>
> >access to
> >filter=(|(objectClass=
simpleSecurityObject)(objectClass=posixAccount))
> > by self read
> > by * none
>
>
> >Just add this rule before the global rule "access to *"
>
>
> >>ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
> >>"ou=People,dc=abc,dc=com" "uid=ldap_7"
>
> >And if you search like this with bind "admin dn", you will
see every
> >object....
> >You have to bind with user ldap_6 and not with root
> But anyway client user knows the admin dn and
rootbindpassword. So,
> with this he will look into all directory information to
which he is
> not supposed to do.
> e.g. ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -w cluster
>
> So, how to avoid this?
>
>>>Why client user knows the admin dn and pw????????
>>Because /etc/ldap.conf file on client contains admin dn and pw.
>>Each user information in the directory contains the
following entries(here, e.g. ldap_6)
>>dn: uid=ldap_6,ou=People,dc=abc,dc=com
>>uid: ldap_6
>>cn: ldap_6
>>sn: ldap_6
>>mail: [email protected] <mailto:[email protected]>
>>objectClass: person
>>objectClass: organizationalPerson
>>objectClass: inetOrgPerson
>>objectClass: posixAccount
>>objectClass: top
>>objectClass: shadowAccount
>>objectClass: hostObject
>>objectClass: simpleSecurityObject
>>shadowLastChange: 13998
>>shadowMax: 99999
>>shadowWarning: 7
>>loginShell: /bin/bash
>>uidNumber: 514
>>gidNumber: 514
>>homeDirectory: /home/ldap_6
>>host: *
>>userPassword::
e2NyeXB0fSQxJGRUb1p6bVp5JGY2VFF5UWMxNndSbjdLcHpnMUlsdS8=
>>So, what should be the ACL rule so that each user can see
his data only? I tried but not getting the required, even
>>the user himself is unable to see his own data.
--
Thanks & Regards,
Jayavant Ningoji Patil
Engineer: System Software
Computational Research Laboratories Ltd.
Pune-411 004.
Maharashtra, India.
+91 9923536030.
>The user itself is unable to see its own info.
>[ldap_6@client]$ ldapsearch -x -v -b "dc=abc,dc=com"
"(cn=ldap_6)" -h server
>ldap_initialize( ldap://server )
>filter: (cn=ldap_6)
>requesting: All userApplication attributes
># extended LDIF
>#
># LDAPv3
># base <dc=abc,dc=com> with scope subtree
># filter: (cn=ldap_6)
># requesting: ALL
>#
># search result
>search: 2
>result: 32 No such object
># numResponses: 1
--
Thanks & Regards,
Jayavant Ningoji Patil
Engineer: System Software
Computational Research Laboratories Ltd.
Pune-411 004.
Maharashtra, India.
+91 9923536030.
Can you show me your server as well as client side configuration settings?
--
Thanks & Regards,
Jayavant Ningoji Patil
Engineer: System Software
Computational Research Laboratories Ltd.
Pune-411 004.
Maharashtra, India.
+91 9923536030.
Hmm, I think It's the best to start simple.
Just create two ACL Rules like this in your slapd configuration
#access only own user object and service user under ou=system
access to filter=(objectClass=person)
by self read
by dn.children="ou=system,dc=mydomain,dc=com" read
by * none
#All others are readable to everybody
access to *
by * read
And client config ( It's on Debian! )
NSS (Example configuration):
/etc/libnss-ldap.conf
#LDAP Servers
#------------------------------------
uri ldap://myldapserver:389
base dc=mydomain,dc=com
rootbinddn cn=admin,dc=mydomain,dc=com
#TLS
#------------------------------------
tls_cacertfile /etc/ldap/ssl/cacert.pem
tls_cert /etc/ldap/ssl/cert.pem
tls_key /etc/ldap/ssl/key.pem
ssl start_tls
scope sub
bind_policy soft
#NSS settings
#------------------------------------
nss_base_passwd dc=mydomain,dc=com?sub
nss_base_shadow dc=mydomain,dc=com?sub
nss_base_group dc=mydomain,dc=com?sub
And the bind password is in the file /etc/libnss-ldap.secret (Root
access only!)
And I don't have ldap pam, just kerberos.... But the pam_ldap config is
identic to nss ldap
And for the rest, RTFM!
--
Raffael Sahli
[email protected]
Switzerland
