On ti, 12 kesä 2018, Chris Dagdigian via FreeIPA-users wrote:
Hi folks,
Tried to find this in the FreeIPA and RHEL IDM docs but could not find
my answer with any specificity ...
I have a user account called "idmbind" inside an AD controller for a
domain that we integrate with our linux fleet in AWS
Because this domain is non-essential and we had full control we got
lazy and just made the "idmbind" account as privileged as possible --
it's currently part of the "Domain Admin" and "Enterprise Admin"
groups
Now that crunch time is over we are auditing all our AD user accounts.
I've been specifically asked:
"Does your idmbind user really need Enterprise Admin group membership?"
"Does your idmbind user really need Domain Admin group membership?"
Is there a concise answer somewhere on what permissions/roles the
local AD user account needs to have when we use that username and
password to set up 1-way and 2-way trusts with FreeIPA? The docs and
screenshots show the words "domain administrator" but I'm wondering if
the requirements are more specific.
I figure "Domain Admin yes, Enterprise Admin no" may be the proper
answer but looking for a more authoritative voice, thanks!
What do you use this
'idmbind' account for?
If you are using it to establish trust to AD which is a one-time
operation, then by Microsoft's own requirements that account should be a
member of Enterprise Admin group in the AD forest _or_ a member of
Domain Admins group in the forest root domain for AD forest.
https://docs.microsoft.com/en-us/windows/security/identity-protection/acc...
https://docs.microsoft.com/en-us/windows/security/identity-protection/acc...
See details at
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows...
----
To create a forest trust, the administrator creating the trust must be a
member of the Domain Admins group (in the forest root domain) or the
Enterprise Admins group in Active Directory. Each trust is assigned a
password that the administrators in both forests must know. Members of
Enterprise Admins in both forests can create the trusts in both forests
at once and, in this scenario, a password that is cryptographically
random is automatically generated and written for both forests.
Members of the Incoming Forest Trust Builders group can create one-way,
incoming forest trusts. For example, members of this group residing in
Forest A can create a one-way, incoming forest trust from Forest B. This
one-way, incoming forest trust allows users in Forest A to access
resources located in Forest B. Members of this group are granted the
permission Create Inbound Forest Trust on the forest root domain. This
group has no default members.
----
As you can see, for one-way trust there is another group that could be
used but we never tested whether those permissions would be enough.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland