I am guessing you are either using RHEL5, Centos5 or some other RHEL5 based distro. I replaced the openldap that was on my centos5 machines with an newer version at 2.4.16+patches.
I have uploaded the rpms and srpms of what I used which you can do a drop in replacement of the RHEL5 based openldap rpms. http://www.gradientzero.com/openldap/ I do not remember for sure but I think I had to force one or 2 of the packages it get it to install but once everyhting is installed then it ran fine for me. I have 3 ldap servers using this version setup in a multi-master setup. Since I am doing a multimastet setup, I do not use slapd.conf but rather the slapd.d configuration directory though the dynlist overlay should work with slapd.conf as well. - Adam On Fri, Dec 11, 2009 at 1:55 AM, Shamika Joshi <[email protected]>wrote: > Hi Adam, > This is interesting, and I went ahead to try it out but I'm getting some > hickups here, when I enter following in my slapd.conf > overlay dynlist > dynlist-attrset groupOfNames labeledURI member > > it throws me following error: > [r...@xrh3 /]# service ldap start > Checking configuration files for slapd: *overlay "dynlist" not found* > slaptest: bad configuration file! [FAILED] > > without "overlay dynlist" slapd runs ok. > > dynlist.la and dynlist.so are in /usr/lib/openldap > > [r...@xrh3 openldap]# pwd > > > /usr/lib/openldap > [r...@xrh3 openldap]# ls -ltr|grep dynlist > > > -rwxr-xr-x 1 root root 877 Jan 21 2009 dynlist.la > -rwxr-xr-x 1 root root 18304 Jan 21 2009 dynlist-2.3.so.0.2.31 > lrwxrwxrwx 1 root root 21 Dec 11 12:30 dynlist-2.3.so.0 -> > dynlist-2.3.so.0.2.31 > > > I also tried changing permission of this dir from root to ldap. Could I be > missing something here? > > Below is my slapd.conf > > include /etc/openldap/schema/core.schema > include /etc/openldap/schema/cosine.schema > include /etc/openldap/schema/inetorgperson.schema > include /etc/openldap/schema/nis.schema > include /etc/openldap/schema/dnszone.schema > include /etc/openldap/schema/testobj.schema > include /etc/openldap/schema/dyngroup.schema > > allow bind_v2 bind_anon_cred bind_anon_dn update_anon > > pidfile /var/run/openldap/slapd.pid > argsfile /var/run/openldap/slapd.args > > modulepath /usr/lib/openldap > > moduleload dyngroup.la > moduleload dynlist.la > moduleload back-bdb > > #overlay dynlist > dynlist-attrset groupOfNames labeledURI member > access to * by * write > > database bdb > suffix dc=test,dc=com > rootdn cn=Manager,dc=test,dc=com > rootpw xxxxx > > directory /var/lib/ldap/test.com > > # Indices to maintain for this database > index objectClass eq,pres > index ou,cn,mail,surname,givenname eq,pres,sub > index uidNumber,gidNumber,loginShell eq,pres > index uid,memberUid eq,pres,sub > index nisMapName,nisMapEntry eq,pres,sub > > Packages that I'm using > openldap-2.3.43-3.el5 > openldap-servers-2.3.43-3.el5 > openldap-clients-2.3.43-3.el5 > openldap-servers-overlays-2.3.43-3.el5 > openldap-devel-2.3.43-3.el5 > > Thanks in advance > Shamika > > =============================================================================================== > > > > > On Fri, Dec 11, 2009 at 4:18 AM, Adam Hough <[email protected]> wrote: > >> There are other ways to populate the pam_groupdn that you have associated >> with each machine but those all correspond to some attribute in the user's >> profile. >> >> I have pam_groupdn setup like this >> >> /etc/ldap.conf: >> pam_groupdn cn=<GROUP_NAME>,ou=Systems,dc=domain,dc=com >> pam_member_attribute member >> >> cn=<GROUP_NAME>,ou=Systems,dc=domain,dc=com >> cn: <GROUP_NAME> >> objectClass: top >> objectClass: groupOfNames >> objectClass: labeledURIObject >> member: uid=nobody,ou=People, dc=domain,dc=com >> labeledURI: ldap:///ou=People,dc=domain,dc=com??one?(host=<type of >> system>) >> labeledURI: ldap:///ou=People,dc=domain,dc=com??one?(gidNumber=XXXX) >> >> So as you can see you can have as many labeledURI attributes as you want >> or need. I tend to use the host name function of what the host does. >> >> This is how my account profile would look: >> uid=<MYUSERID>,ou=People,dc=domain,dc=com >> host: "cluster" >> host: sysadmin >> >> So "cluster" is a compute cluster that we have and thus for all those >> machines the pam_groupdn cn="cluster",ou=Systems,dc=domain,dc=com, and for >> machines where only the sysadmins login to then pam_groupdn >> cn=sysadmin,ou=Systems,dc=domain,dc=com. >> >> As long as you can for a labeledURI: >> ldap:///ou=People,dc=domain,dc=com??one?<attribute>=<value>) type search you >> can use it to auto populate the group. >> >> Summary: >> * Do to not think of the host attribute as host = hostname but as host = >> type of machine and that you can have more then one labeledURI per group to >> help populate the group. >> * Use good gidNumbers for groups to help auto populate groupOfName style >> groups. >> >> >> >> - Adam >> >> >> >> On Wed, Dec 9, 2009 at 4:01 AM, Shamika Joshi <[email protected]>wrote: >> >>> Hi Adam, >>> I'm able to get host auth working by using host attribute.But the >>> drawback of that is everytime there a new machine, I have to add that host >>> to all the users I want to grant access to. If I decide to do it based on >>> group membership, I can use pam_groupdn but then it does not allow multiple >>> group entries there, plus it has to be managed on client side,which is even >>> more undesirable by any administrator. >>> >>> I went through this article but I'm not sure if it will work if I have >>> some members already associated with some groups. Like ldap1 & ldap2 members >>> of qagroup & ldap3 & ldap4 members of sysadmin, would this method allow me >>> to limit access based on their group membership?? if yes...could you briefly >>> explain with an example? >>> >>> Thank for your time in advance >>> Shamika >>> >>> >>> >>> On Wed, Dec 9, 2009 at 9:04 AM, Adam Hough <[email protected]>wrote: >>> >>>> Here is is the write up that I read to figure out how to do setup to >>>> auto-restrict users to certain hosts. >>>> >>>> >>>> http://www.hurricanelabs.com/september2009_login_security_using_openldap_and_pam >>>> >>>> >>>> >>> >> >
