At my current workplace, we faced a somewhat similar issue. Our AD infrastructure never
had posix attributes assigned. Our LDAP and our AD were isolated but passwords were kept
up to date with another tool (that I don't manage). I'll try to answer your
1. In our case, since all of our attributes were already defined in LDAP and they were
based on employee ID's, it made it a little difficult to try to let the IPA-AD Trust
system automatically assign UID/GID numbers, simply because there'd be a lot of
confusion and a TON of cleanup across 5k+ servers. Having a mix of RHEL 5/6/7 and Solaris
10/11, it would have been extremely painful to convert home directories ID numbers and get
everything to the way it would have to be. We already had everything laid out by employee
ID so our decision was to enable POSIX across the trust and have the attributes populated
in AD and replicated against the global catalog. Our Windows team at first had issues with
this, but they were all for consolidation in the end. (Any extra data we had in LDAP were
custom attributes that our internal apps used and we forced them into using AD instead
with either groups or having a side database to handle whatever they were doing). This
effectively means we have only
administrative accounts in IPA. There are absolutely no "normal" accounts in
IPA whatsoever, mostly everything is in AD at this point and IPA manages the necessary
external groups, posix groups, host groups, sudo, hbac, etc.
2. In my opinion, it does not make sense to import your LDAP data into IPA, I would just
consolidate into AD to simplify account management overall. If you decide to import data
from LDAP into IPA, then your tools/connector will then have to manage IPA just like
you're already doing with LDAP. I don't see this headache being worth it, but
that's just based on my personal experience. (Note that this does not affect your
ability to have a trust if you go this route. I just don't see it being worth it to
having an account, let's say for you, on both sides. I don't see it causing
problems, I just see it being kind of redundant.)
3. In your case, since you already have them defined and may want ID's to be the same
across campus as they already are, you would import them into AD and have the trust with
posix (uidnumber, gidnumber, loginshell, unixhomedirectory). If you attempt to import
"some" of the data from LDAP into AD for example but don't have posix turned
on, those attributes are ignored completely. There's absolutely no way around this.
You need to pick one or the other. In my case, we picked posix since everything is already
laid out a very (unfortunately) specific way. If we were starting fresh at the time, I
would've just used the range that IPA generates.
3a. If you use posix on the trust, your sssd.conf on the IPA masters should have
subdomain_homedir = %o under [domain...] to have the unixhomedirectory attribute honored.
Just a heads up. Otherwise you get /home/ad.domain/username for your AD users.
4. Solaris 10 and 11 definitely can support HBAC! Check out this git repo:
- it contains documentation on how to compile and use
10. This module on version 1.1 works without issues (1.2 release is broken presently).
You will need to compile it using the OpenCSW packages though. If you can figure out how
to get it to compile using the native tools/packages, let me know (because I couldn't
figure it out). I also use the sudo package from OpenCSW since for some reason the sudo
directly from the maintainer doesn't want to work for some wacky reason. I didn't
have the patience to figure it out.
You can compile pam_hbac on Solaris 10 like this:
# /opt/csw/bin/pkgutil -i -y libnet ar binutils gcc4g++ glib2 libglib2_dev gmake
# export M4=/opt/csw/bin/gm4
# autoconf -o configure
# autoreconf -i
# ./configure AR=/opt/csw/bin/gar --with-pammoddir=/usr/lib/security --sysconfdir=/etc/
# make install
11. I don't know if 1.1 works for Solaris 11. I was never able to get it tested
before because of some domain resolution order fun and a bug that took Oracle 5 months to
get me a proper fix. I have heard that without domain resolution order on, it works
flawlessly. 1.2 seems to segfault and I'm currently working with the module maintainer
to try and resolve the underlying issues. (Also, SRU 29, you won't regret updating to
this if you plan on having a trust with domain resolution order turned on - in fact if you
don't get at least this SRU, AD users group membership *will not work at all* when
using domain resolution order). The built in sudo will work against IPA when configured
correctly. There is a readme in the repo on how to compile on Solaris 11.
You can actually check here for some Solaris steps if you need a guide (I don't have
HBAC stuff yet on it).
- There might
be better guides out there for this, but this is how I was able to get things to work.
Note: I only mention sudo because you can control if sudo can be used (as a pam service)
in IPA. And putting the necessary line in your pam configuration can help with this.
5. For my current workplace, it was difficult. Because of how everything was setup by the
people before me, everything was in such a mess that the mere transition to IPA-AD was a
painful. We had to do a slow approach because we knew we were going to run into some major
heartaches. I will say that once you get through the pain, you end up realizing it was
worth it in the end. I did a similar transition as a volunteer for a community college I
used to teach at part time and it was actually fairly easy using posix since things were
already laid out in a more stable manner (much to my surprise).
6. If I had a chance to do it differently, I would've forced everything into the IPA
ID range scheme so we wouldn't have to manage it in AD's GC and force them into
that business. Plus, our account provisioning tools wouldn't have needed the
customization. Honestly, the pain of managing UID/GID's seriously sucks. We were lucky
enough to have employee ID's to base them off of - but other places either have a
different scheme or no scheme at all.
Hope this was of help to you!