Hi,
On Sun, 01 Feb 2015, William wrote:
Hi,
I have a single master instance of IPA 3.3.5 at the moment. I have
configured this with IPA adtrust and run the adtrust preparation. I am
about to add a second replica.
The documentation[0][1] doesn't really go into what happens in this
circumstance. Do I need to make any configuration on the replica once I
have installed it? Or does the replica information file hint to the
ipa-replica-installer that adtrust components must be configured? IE can
my new replica act as a trust master, and will it correctly update
attributes such as iPAntpassword?
No, it will not. Although information about trust setup is in the
replicated subtree, the plugins which get configured for the trust case are
configured in cn=config which is not in the replicated subtree, thus
they will need to be configured explicitly with ipa-adtrust-install on
each replica which will provide services to IPA clients accessible by AD
users.
Password generation will be performed on such non-configured replica,
though, because our password plugin will be able to generate ipaNTHash
attribute for any user that has ipaNTSecurityIdentifier attribute.
However, ipaNTSecurityIdentifier attribute is populated by sidgen plugin
which is only activated when ipa-adtrust-install was run.
Additionally, extdom plugin is what SSSD on IPA clients uses to request
SID to name and name to SID resolution for AD users. It is also
configured with the help of ipa-adtrust-install.
Now, there is something interesting you've reminded me about by pointing
to the ticket below:
[0] http://www.freeipa.org/page/V3/MultipleTrustServers
[1] https://fedorahosted.org/freeipa/ticket/2189
This ticket concerns enabling multiple IPA masters as domain controllers
from Active Directory point of view. After running ipa-adtrust-install,
the domain controllers will be advertised in the DNS service records and
they will be contacted by AD DC at the point of validating trust (part
of 'ipa trust-add' sequence).
What I realized now is that with FreeIPA 3.3+ we moved ID resolution
fully to SSSD and we technically don't need to run full 'domain
controller' stack (e.g. Samba) on a master that only wants to resolve
IDs rather than participating in a balancing of the domain controller
duties.
For such operation we could have a scaled-down version of
ipa-adtrust-install which doesn't install Samba and configure it for use
as a DC. Rather, it would install and configure required plugins
(sidgen, extdom, but not cldap) to allow KDC to issue proper MS-PAC
information to the master's host/fqdn@REALM key -- this is what will
enable SSSD on the master to gain access to AD LDAP/Global Catalog over
the trust.
Such a lightweight configured 'domain controller' would only be able to
resolve AD user/group identities but this is just what needed in
majority of deployments. As result, with this approach we can also solve
an issue of forced install of Samba on each master -- something we were
looking to fix.
We would still need to make sure we are falling back to a proper master
to act on trust-related management operations with IPA CLI and web UI
because without enabled Samba on the master we wouldn't be able to
establish trust at all (or change few other bits).
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
