Hi, "Andrew Bartlett" <[EMAIL PROTECTED]> wrote:
>> My solution is simple, but wrong - weaken of access restrictions to password >> attribute or bind to ldap as "manager" for all users. > >This is indeed the wrong solution, and unless your nss_ldap is much >buggier than the one used at every other site, I don't think this is the >issue. Maybe. I'm using Padl nss_ldap ver. 215. Which one are using you ? Or have I some misconfiguration of nss_ldap ? Here is my /etc/ldap.conf: host localhost base dc=setuza,dc=cz binddn cn=Manager,dc=setuza,dc=cz bindpw ##### rootbinddn cn=manager,dc=setuza,dc=cz nss_base_passwd dc=setuza,dc=cz?sub nss_base_shadow dc=setuza,dc=cz?sub nss_base_group ou=Groups,dc=setuza,dc=cz?one I done such experiment: In 1st try I remarked binddn and bindpw in /etc/ldap.conf => anonymous bind to ldap for non-root. Then I call: # getent passwd p01861;echo $? p01861:x:1001:513:System User:/dev/null:/bin/bash # In syslog occured lines: slapd[19983]: conn=3148 fd=16 ACCEPT from IP=127.0.0.1:50031 (IP=0.0.0.0:389) slapd[19986]: conn=3148 op=0 BIND dn="cn=manager,dc=setuza,dc=cz" method=128 slapd[19986]: conn=3148 op=0 BIND dn="cn=Manager,dc=setuza,dc=cz" mech=SIMPLE ssf=0 slapd[19986]: conn=3148 op=0 RESULT tag=97 err=0 text= slapd[28120]: conn=3148 op=1 SRCH base="dc=setuza,dc=cz" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=p01861))" slapd[28120]: conn=3148 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass slapd[28120]: conn=3148 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= slapd[19983]: conn=3148 fd=16 closed Then I called: # su bin -c 'getent passwd p01861;echo $?' 2 # And in syslog occured lines: slapd[19983]: conn=3166 fd=16 ACCEPT from IP=127.0.0.1:50049 (IP=0.0.0.0:389) slapd[19985]: conn=3166 op=0 BIND dn="cn=manager,dc=setuza,dc=cz" method=128 slapd[19985]: conn=3166 op=0 BIND dn="cn=Manager,dc=setuza,dc=cz" mech=SIMPLE ssf=0 slapd[19985]: conn=3166 op=0 RESULT tag=97 err=0 text= slapd[19986]: conn=3166 op=1 SRCH base="ou=Groups,dc=setuza,dc=cz" scope=1 deref=0 filter="(&(objectClass=posixGroup)(memberUid=bin))" slapd[19986]: conn=3166 op=1 SRCH attr=cn userPassword memberUid gidNumber slapd[19986]: conn=3166 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= slapd[19983]: conn=3166 fd=16 closed slapd[19983]: conn=3167 fd=16 ACCEPT from IP=127.0.0.1:50050 (IP=0.0.0.0:389) slapd[28120]: conn=3167 op=0 BIND dn="" method=128 slapd[28120]: conn=3167 op=0 RESULT tag=97 err=0 text= slapd[19985]: conn=3167 op=1 SRCH base="dc=setuza,dc=cz" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=p01861))" slapd[19985]: conn=3167 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass slapd[19985]: conn=3167 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= slapd[19983]: conn=3167 fd=16 closed On 2nd try - I unremarked binddn (manager dn) and bindpw in /etc/ldap.conf # getent passwd p01861;echo $? p01861:x:1001:513:System User:/dev/null:/bin/bash 0 # su bin -c 'getent passwd p01861;echo $?' p01861:x:1001:513:System User:/dev/null:/bin/bash 0 # I think, syslog entries are not necessary. Conclusion: nss_ldap library always require attribure userPassword without respect to access rights of caller or existence of aux shadowAccount objectclass in account entry. M. Vancl -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
