On Fri 08 Mar 2013 02:16:26 PM CET, Alexander Bokovoy wrote:

http://www.freeipa.org/page/V3/MultipleTrustServers covers RFE to have
multiple domain controllers exposed to trusted domains.

Attached patch also implements needed changes for ipa-adtrust-install
part. Global trust configuration options are already implemented and
available in git master, while Web UI support for them needs to be

The patch attached actually fixes our current (rather wrong) way of
exposing all LDAP- and Kerberos-related SRV records to default site
configuration and _msdcs SRV namespace. This was wrong because it
assumed that all servers mentioned in SRV records could be domain
controllers, that is, they are usable to contact over SMB protocol.
The latter isn't true until we ran ipa-adtrust-install on them.

The patch only exposes those servers which manage cifs/fqdn@REALM
services and only if those services are also members of cn=adtrust
agents container. This is fairly strict filter and it allows also to
have other types of SMB servers as part of the realm.

Below is a copy of the RFE:

= Overview =

Ticket [https://fedorahosted.org/freeipa/ticket/2189 #2189];

Each FreeIPA server in the realm has potential to serve as domain
controller in the cross-forest realm trust. This page outlines design
for implementing multiple servers support in FreeIPA.

= Use Cases =

Once <tt>ipa-adtrust-install</tt> ran on the FreeIPA server, the server
can handle requests from trusted domains by means of Samba project's
<tt>smbd</tt> and <tt>winbindd</tt> daemons.

Hosts in FreeIPA realm may be enrolled against specific FreeIPA replica
server. User from trusted domain can access these hosts and their
identities will be resolved against the replica. However, if replica
server does not have trust support configured, these identities will not
be processed since running <tt>winbindd</tt> process is required to
contact the trusted domain's domain controllers and Global Catalog

Domain controllers are advertised to clients via SRV records in DNS.
Since replica servers may be arranged in a specific topology, adding new
domain controller would need to respect the topology design. It means
priority/weight of the domain controller compared to other domain
controllers should be adjustable. Prime use case for this is branch
office deployments.

= Design=
* Each domain controller uses separate identity and service key to talk
  to FreeIPA LDAP server. The identity is tied to the server hostname.

* Service principal is <tt>cifs/hostname@REALM</tt>, identified in LDAP
  as <tt>krbprincipalname=cifs/hostname@REALM</tt>.

* All identities are members of <tt>cn=adtrust
  Thus, all replica servers can see what other servers are providing
  domain controller service.

* Replica server only becomes domain controller when
  <tt>ipa-adtrust-install</tt> utility was executed on it. It means all
  DC setup is delivered via the <tt>ipa-adtrust-install</tt>.

* <tt>ipa-adtrust-install</tt> should be able to detect other DCs by
  looking at existing identities as members of the <tt>cn=adtrust
  tree and modify list of SRV records under <tt>_msdcs</tt> and default
  site configuration if DNS is controlled by FreeIPA.

* Domain Controller priority/weight can be modified at run time since it
  only affects SRV records in the DNS (if FreeIPA controls the DNS).
  Normal <tt>ipa dnsrecord-mod</tt> commands should be used for this
  purpose, operating on SRV records for <tt>_msdcs</tt> and default site

* There are trust properties that are global for the realm. Some of them
  are modifiable, some not. Thus, <tt>ipa trustconfig-show</tt> and
  <tt>ipa trustconfig-mod</tt> should reflect both global and local
  settings (realm-wise and DC-wise).

* Following properties of the trust are global for the realm:
** NetBIOS domain name (read-only, affects existing trusts)
** Domain name (read-only, affects existing trusts)
** Domain GUID (read-only, informational)
** Additional domain suffixes exposed to the trusted party, handled as
   black list against global list of additional domains associated
with our
   or transitive realm, read/write
** Fallback primary group (read-write)

* Following properties of the trust are per Domain Controller:
** priority of the DC and GC services (read-write, DNS SRV record)

Details on <tt>ipa trustconfig</tt> commands design are available at
Details on additional domain suffixes handling are available at

= Implementation =
Implementation-wise there are three parts:

* <tt>ipa-adtrust-install</tt>:
** Gather list of CIFS services that are also members of <tt>cn=adtrust
   agents</tt> and add SRV records for them to _msdcs in


** Once Global Catalog Server implementation will be ready, configure
   its use as one of <tt>ADTrustInstance</tt> setup steps.

* <tt>IPA framework</tt>:
** Add display and modification of trust properties as <tt>ipa
   trustconfig-*</tt> commands, including listing DC and GC servers.
** NOTE: there is no need to modify trust creation procedure since it
appears that AD DC assumes LSA CreateTrustedDomainEx2 call comes from
the DC (in Windows the UI to establish trust is only on DC) and
therefore does not do DNS discovery during validation step. Since smbd
running on the same host that 'ipa trust-add' runs on will contact the
same host's LDAP server, there is no issue in replication at this stage.

* <tt>IPA Web UI</tt>
** Add support for <tt>ipa trustconfig-*</tt> to Web UI.

= Major configuration options and enablement =
No additional options to <tt>ipa-adtrust-install</tt>

= Replication =
All data is already in a replicated namespace.

= Updates and Upgrades =
No changes to schema, no need to run anything additional on updates or

= Dependencies =
No additional dependencies beyond AD trusts support

= External Impact =
Once <tt>ipa-adtrust-install</tt> install ran on replica, the replica
will be advertised via <tt>_msdcs</tt> SRV namespace as a domain

Freeipa-devel mailing list

I tested with various topologies with up to 8 replicas, worked fine, ACK.


Freeipa-devel mailing list

Reply via email to