On Срд, 09 жні 2023, Amos via FreeIPA-users wrote:
We currently use (Free)IPA (what's provided by Redhat) in a forest
trust
relationship with our Active Directory domains. All accounts are defined in
AD with the necessary POSIX attributes. The only things locally defined
within IPA are the automounter maps, sudo rules, and HBAC rules. (I must
say, these HBAC rules work rather nicely!)
A research group wants to create their own OU in AD to manage and rely on
AD for authentication. Centralized sudo rule configuration is also
important to them. They would like to have internal DNS for their lab of
entirely Linux machines so that these systems are more easily accessible
from within the lab instead of relying exclusively on IP addresses. (We use
Infoblox for centralized DNS, but since this is a private lab, there's a
question as to whether to leverage our Infoblox DNS or to use DNS in their
own IPA instance.)
On one hand, it makes sense to set them up using IPA. If so, would these
servers be in a sub-domain of the central IPA? They would need to be able
to manage this instance of IPA, but we would not want them to have admin
rights on the central IPA servers. Under this scenario, would the trust to
AD remain?
I'm fairly comfortable with the principles behind IPA, but only so far as
we're talking about the global environment. Setting things up in
semi-connected labs like this would be new to us, at least since we moved
to IPA.
There is some pressure to have their lab bind directly to AD. I pointed out
that currently there would be no way to centrally manage the sudo rules.
However, we're also currently considering adding the sudo schema to AD,
which if we did, might take care of that.
So, I'm just trying to wrap my head around all the possible approaches and
weigh the pros and cons with either approach. Any insight would be greatly
appreciated.
My suggestion would be for them to stand up their own IPA deployment,
unrelated to yours. This way they can configure their own trust to AD
and settings they need.
You would not be able to establish trust between yours IPA setup and
theirs, as we don't support yet IPA-IPA trust.
Giving them administrative permissions in your IPA setup only for a
subset of objects is not really viable. IPA is not designed with the
concept of having separate administrators for individual objects. If you
are an admin for, say, HBAC rules, you manage all of them.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland