ldap, round 2
Posted Mon, 05 Dec 2005
I already know how to setup ldap databases and add objects. Now I needed to figure out how to secure it and hook it to kerberos. The following in my slapd.conf maps kerberos users to ldap objects.
authz-regexp uid=([^,]*),cn=gssapi,cn=auth "ldap:///ou=Users,dc=csh,dc=rit,dc=edu??sub?(uid=$1)"When you have kerberos ticket and authenticate using SASL, you will bind as 'uid=USER,cn=gssapi,cn=auth' - this is not the proper ldap object for any user on my system. Luckily, I can substitute this dn for a valid one using 'authz-regexp.' What this does, essentially, is do a subquery when you authenticate via SASL and looks for objects in the Users orgunit with a uid=USER. Very very helpful. Now I can get a kerberos ticket and ldap knows who I am:
nightfall(~)  % kinit [email protected]'s Password: kinit: NOTICE: ticket renewable lifetime is 0 nightfall(~)  % ldapwhoami SASL/GSSAPI authentication started SASL username: [email protected] SASL SSF: 56 SASL installing layers dn:cn=jordan sissel,ou=users,dc=csh,dc=rit,dc=edu Result: Success (0)Wonderful! The next step was to allow users to modify their own objects. A short ACL entry in slapd.conf fixes that.
access to attrs=gecos,description,loginShell,mail by self writeThis ACL ensures that users only have write access to themselves, and even then only to the attributes listed above. To test this, I did the following:
nightfall(~)  % ldapsearch -Q -LLL '(uid=psionic)' 'loginShell' dn: cn=Jordan Sissel,ou=Users,dc=csh,dc=rit,dc=edu loginShell: /test/baz/fizz nightfall(~)  % cat myldif dn: cn=jordan sissel,ou=users,dc=csh,dc=rit,dc=edu changetype: modify replace: loginShell loginShell: Happy Login Shell nightfall(~)  % ldapmodify -Q -f myldif modifying entry "cn=jordan sissel,ou=users,dc=csh,dc=rit,dc=edu" ghtfall(~)  !1! % !ldapse ldapsearch -Q -LLL '(uid=psionic)' 'loginShell' dn: cn=Jordan Sissel,ou=Users,dc=csh,dc=rit,dc=edu loginShell: Happy Login ShellUsers have write access to their own objects now. The next step is going to be getting SSL/TLS working. I made a brief attempt at doing that tonight but I failed. Getting some SSLv3 handshake error that is clearly PEBCAK on my part. Oh well, sleep now. More LDAP later.