[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: restrict host login based on group



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 <shamika.joshi@gmail.com> 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:
[root@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

[root@xrh3 openldap]# pwd
/usr/lib/openldap
[root@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 <adam@gradientzero.com> 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 <shamika.joshi@gmail.com> 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 <adam@gradientzero.com> 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