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
