10:56 a.m.
Apologies if this post is slightly off-topic, but I'd really like to pick
some brains....
Currently, we have two, main LDAP directory environments: AD and a cluster
of Solaris LDAP servers. The accounts are unified, and are managed via
Microsoft Identity Manager (with a connector for updating Solaris LDAP.)
We have hundreds of *nix hosts across campus, increasingly RHEL 7.{3,4},
but also Centos, and some Solaris 10, 11. These *nix boxes get naming
services from the Solaris LDAP servers. We have a handful of home
directory servers across campus. The Microsoft Identity Manager has rules
in it to define the LDAP:homeDirectory and AD:unixHomeDirectory fields
based on the person's department, etc. DNS/DHCP/IPAM is managed by an
Infoblox grid.
We are tasked with unifying our LDAP directory infrastructure, and
phasing-out the Solaris LDAP servers. I've been studying the documentation
for RedHat-IdM/FreeIPA, with the intention of setting up RH-IdM to have a
trust relationship with AD, with AD being primary for all account data. It
seems pretty clear to me that we have to populate the POSIX attributes into
AD (already doing), then replicate those values to the global catalog (not
done yet.) There's some reluctance to a) continue populating the POSIX
attributes into AD, and b) replicating those values to the global catalog.
The Windows team is concerned about attribute bloat, which I understand.
So, I was hoping to learn the following (feel free to reply directly to me):
1. How many folks have faced such a transition, and what was your approach?
2. I see RH-IdM can import data from our Sun/Solaris LDAP servers. If
we're planning on setting up a (one-way) trust with the AD servers, is
there any point in importing the Sun/Solaris LDAP data?
3. So that the UID/GID do not change across campus, do you recommend
populating the POSIX attributes in AD, and promoting those values to the
global catalog, then configure RH-IdM to use those POSIX values from AD?
(Though, perhaps we don't need AD:UIDNumber and AD:GIDNumber if we import
our current data from Sun/Solaris LDAP, then let IPA generate those values
going forward?)
4. Since legacy clients (including our Solaris 10 and Solaris 11 systems)
will not support HBAC, are there any recommendations on how to restrict
access to such systems? (I wrote a PAM module many years ago to achieve
that, but currently it relies on custom attributes in our Sun LDAP, and I
see that custom objectclasses/attributes will not be allowed to be loaded
into RH-IdM, so have to come up with something different.)
5. How successful was your migration to this new topology?
6. Did you learn anything during the transition that would lead you to do
it differently?
Thanks in advance!
Amos