We have a requirement to segregate different types of users, including customers, administrators, clients, and infrastructure hosts, into separate realms or unique IPA installations. While this is potentially feasible through the Trust feature, considering its ongoing development state, we're looking for alternative solutions. (see pic https://imgur.com/a/uqtbjly)
Our objectives are:
1) Admin users within the ADMIN.NOVALOCAL realm should secure sudo access to hosts within the realms of CUSTOMER1.NOVALOCAL and CUSTOMER2.NOVALOCAL. 2) Admin users should also possess the capability to manage IPA entities within both customer installations of FreeIPA.
We possess a rudimentary understanding of how to tackle the second objective. However, for the first one, our strategy is less clear. One available method is to instantiate hosts with a custom PAM configuration and administer access to administrators via the pam_ldap module. But we are also open to better suggestions if anyone can put forward.
On Суб, 16 вер 2023, dweller dweller via FreeIPA-users wrote:
We have a requirement to segregate different types of users, including customers, administrators, clients, and infrastructure hosts, into separate realms or unique IPA installations. While this is potentially feasible through the Trust feature, considering its ongoing development state, we're looking for alternative solutions. (see pic https://imgur.com/a/uqtbjly)
Our objectives are:
- Admin users within the ADMIN.NOVALOCAL realm should secure sudo
access to hosts within the realms of CUSTOMER1.NOVALOCAL and CUSTOMER2.NOVALOCAL. 2) Admin users should also possess the capability to manage IPA entities within both customer installations of FreeIPA.
We possess a rudimentary understanding of how to tackle the second objective. However, for the first one, our strategy is less clear. One available method is to instantiate hosts with a custom PAM configuration and administer access to administrators via the pam_ldap module. But we are also open to better suggestions if anyone can put forward.
FreeIPA does not support trust between several FreeIPA deployments at this moment.
There is no way to use a separate 'administrative' IPA deployment to manage individual independent IPA deployments. The only way is to introduce administrative accounts/groups into those customers' IPA deployments and set rules for them there. This would mean no administrative deployment is involved, really, but administrative objects are forcibly added to the customer deployment instead.
Obviously, you can tie in resources with a custom setup but there is no guarantee on how secure this would actually be in your specific case. Any development like this sounds to me as a custom consulting gig that somebody should be responsible for.
Alexander, thank you for explanation. Maybe you can consult on where can a newbee that want to contribute implementing Global Catalog within FreeIPA in order to support IPA-IPA trust relationtship should start?
Are those open issues are the main factor that held implementation of that feature? https://pagure.io/freeipa/roadmap/Global%20Catalog%20and%20IPA-IPA%20trust/
On Пан, 25 вер 2023, dweller dweller via FreeIPA-users wrote:
Alexander, thank you for explanation. Maybe you can consult on where can a newbee that want to contribute implementing Global Catalog within FreeIPA in order to support IPA-IPA trust relationtship should start?
Are those open issues are the main factor that held implementation of that feature? https://pagure.io/freeipa/roadmap/Global%20Catalog%20and%20IPA-IPA%20trust/
These are essential to implement. The rest is not yet filed because there is a need to investigate missing elements once we finished with these issues. There is a need to add a new mode to SSSD to support IPA subdomain type but this needs to come once we cleared up our side.
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
dweller dweller