You are aware that you can move into the sysadm_r role as staff_u right?
For example, the following below would work.
myuser ALL=(ALL) TYPE=sysadm_t ROLE=sysadm_r PASSWD: ALL
This will allow you to do (almost) what you can do as root as unconfined.
Oh and one final tip. Using su is a bit tricky with RBAC (it does a lot of stuff which gets it into all sorts of places). Instead you can use the runuser command which does the same thing without a lot of su overheads.
I actually restrict su use in sudoers like so;
%wheel ALL=(ALL) TYPE=sysadm_t ROLE=sysadm_r NOPASSWD: ALL, ! /bin/su
Because by default the SELinux policy doesn't allow the sudo transition to manage the necessary signals. Really people should probably just use sudo -i anyway.
I normally hardlink runuser to ru as a two-letter replacement for people who prefer to run sudo su - out of a bad habit (like me!).
Firstly, I will use FreeIPA and Red Hat Enterprise IdM interchangeably. If this causes discomfort, let me suggest a drink.
FreeIPA should be a separate Kerberos realm from Active Directory, and should use a separate DNS zone corresponding to the Krb5 realm. If your AD Domain uses the DNS zone "domain.com" with child zones "dev" and "prd", you would want to create a new DNS zone called something like "idm.domain.com", and any sub-realms under it. You would want to create a Krb5 realm called "IDM.DOMAIN.COM", with all UPNs as USER@IDM.DOMAIN.COM and all SPNs as HOST/SERVER123.IDM.DOMAIN.COM or the like (perhaps WWW/SERVER123.PRD.IDM.DOMAIN.COM).
You can use the same DNS zone as AD, but it is a REALLY bad idea. Not only do you lose service discovery using DNS, you have to do manual mappings, and will likely have hard-to-troubleshoot problems of clients attempting to pass a Krb token that is inappropriate to the servers in the IdM realm
You will need to work with the AD team at least briefly to have them setup a cross-realm trust. They may want it to be a one-way trust, where AD is the Trusted domain and FreeIPA is the Trusting domain. In most cases, this should not be a problem.
At this time, the version of FreeIPA that ships with RHEL 7 does not support establishing trust with the forest-apex AD domain and traversing downward to child domains for authentication. I am told in RHEL 7u1, this will be remedied, as transitive trust support will be added to FreeIPA, but I am not holding my breath until I see the feature-list a day after code-freeze. As a work-around, you should be able to setup the trust to the child domain where user principals are genned.
I am working on a similar effort. Good luck, let us know how this works out. I am lucky enough to have the AD team as an element on my team (and they sit right across from me). We roll up to the same leader at the team level (squad-sized unit) and we have a lot of support from our division leader, who wants to see this integration succeed.
Best Answer
As long as all those systems are enrolled to IPA realm EXAMPLE.COM and use sssd, the scenario should work.
SSSD pulls in all domains defined on IPA and maps them to IPA realm. Alternatively you can map them to IPA realm yourself if no SSSD is in use. It is all in krb5.conf. Hence, IPA systems can be in any domains, krb5.conf contains domain/realm mapping for this purpose, all they need to know is how to find IPA's KDC, the systems themselves do not have to belong to "exmpale.com" domain.
Hope this helps.