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 questions below!

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: https://github.com/jhrozek/pam_hbac - it contains documentation on how to compile and use the module. 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 # PATH=$PATH:/opt/csw/bin # export M4=/opt/csw/bin/gm4 # autoconf -o configure # autoreconf -i # ./configure AR=/opt/csw/bin/gar --with-pammoddir=/usr/lib/security --sysconfdir=/etc/ --disable-ssl --disable-man-pages # make # 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). https://www.linuxguideandhints.com/centos/freeipa.html#legacy-client-setup - 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!

-L