On Sun, 2015-02-01 at 17:49 +0200, Alexander Bokovoy wrote:
> 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.

Wow! From all this it really sounds like adding a replica in to an IPA
domain where adtrust has been run could have a few edge cases. For
example, what would happen if I create a new account on a replica
without adtrust? Would sidgen run on the adtrust machine when it get's
the record replicated to it?

What does one need to do to setup my new replica as a potential adtrust
replica? For example, I am about to decommission my old master, so I
would like the adtrust setup to available on the new master. Is it just
a case of running the adtrust-install tool again?


> 
> 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.

What are the domain controller duties separate from the ID resolution
tasks? What components carry out the id resolution?

> 
> 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.
> 

This should be configured on replicas added to the network if adtrust
has been run already. Perhaps this is something to consider also?
Consistency through out the domain is a good thing. 

> 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).
> 


Thanks for your time.

Sincerely,

William

-- 
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

Reply via email to