[Freeipa-users] IPA-adtrust and addition of replicas

[Alexander Bokovoy]

On Mon, 02 Feb 2015, William wrote:
>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?
I think it might work. sidgen is a post operation and replication
protocol uses normal ldap_*_ext() API to send new objects.

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

>>
>> 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?
In discussing with Simo yesterday, we came to conclusion that we would
call a 'full' master that provides features for trust as a 'trust
controller'. Let's call the other configuration a 'trust agent'.

A trust controller is a FreeIPA master which hosts:
 - LDAP server with sigden, extdom, and cldap plugins
 - KDC with IPA driver
 - Samba configured with ipasam PASSDB module
 - SSSD with ipa_server_mode=True
 - Global Catalog instance (a separate LDAP instance with an
   AD-compatible schema)

A trust agent is a FreeIPA master which hosts
 - LDAP server with sigden and extdom
 - KDC with IPA driver
 - SSSD with ipa_server_mode=True

As you can see, trus agent is a master that relies on SSSD to do
resolution of IDs. Trust controller is used for managing trust: add
trust agreements, enable/disable separate domains from a trusted forest
to access FreeIPA resources, etc. Trust controller is also what Active
Directory's domain controllers contact when validating the trust by
means of SMB protocol using LSA calls which implies running a Samba server.

>> 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 at 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.
Exactly. Good suggestion. One thing we need to solve here is that
enabling sidgen and other components will require installing Samba
libraries. This is something to consider -- do we want these libraries
(not daemons) installed on every master?


-- 
/ Alexander Bokovoy