Hello list, here's the situation:
I have a large number of {centos,rhel}{4,5} hosts on which I will be configuring ldap authentication
via nss_ldap. Hosts are segregated onto different groups according to their function. This is based
on their ip address and FQDN. For instance:
Group "A": red team: 10.10.0.0/16, dbhost_01.nyc.red, wwhost_01.nyc.red, aphost_03.nyc.red,
Group "B": blueteam: 10.20.0.0/16, dbhost_01.nyc.blue, wwhost_03.nyc.blue, aphost_01.nyc.blue,
Group "C": greenteam 10.30.0.0/16, dbhost_01.nyc.green, wwhost_03.nyc.green, aphost_01.nyc.green,
etc.
My intention is to control host access entirely from ldap, using a single ldap.conf for all servers.
Nss_ldap provides a "pam_check_host_attr" hook where the host in question will check its FQDN
against the entry's "host" attribute. The entry
dn: uid=mhalpern,ou=people,dc=foo.com
host: dbhost_01.nyc.red
host: dbhost_02.nyc.red
would then be able to login to either one of these two hosts. At first I thought it should be really
simple: I should be able define a container which specifies the different host groups, and use
classes of service to pull in the rest of the information. This solution would be ideal for me, as
users are also segregated into groups.
To this effect I configured classes of service (and roles...) in a variety of combinations, with
limited amount of success. Although I was able to make these "profile expansions" work as
advertised, I could not get them to append values to the existing attribute set. For instance, a
lookup on uid=mhalpern,ou=people,dc=foo.com with the following entries:
dn: uid=mhalpern,ou=people,dc=foo.com
ou=blue
host: dbhost_01.nyc.red
...
cn=cosTemplate,ou=people,dc=foo.com
cosAttribute: host
cosSpecifier: ou
...
dn: blue,cn=cosTemplate,ou=people,dc=foo.com
host: dbhost_01.nyc.blue
host: dbhost_02.nyc.blue
host: dbhost_03.nyc.blue
would render
dn: uid=mhalpern,ou=people,dc=foo.com
ou=blue
host: dbhost_01.nyc.red
and I would expect:
dn: uid=mhalpern,ou=people,dc=foo.com
ou=blue
host: dbhost_01.nyc.red
host: dbhost_01.nyc.blue
host: dbhost_02.nyc.blue
host: dbhost_03.nyc.blue
because classes of service are designed to replace, or be the default value of a particular
attribute. I am open to any solutions to this problem... how have other people approached this issue?
Thanks for any suggestions.
--
Marcelo Nicol?s Halpern
Systems Administrator
