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