Re: [Freeipa-devel] [RFE] Multiple trust servers per realm

2013-04-02 Thread Tomas Babej

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

Hi,

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

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:
==
__NOTOC__

= 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 ttipa-adtrust-install/tt ran on the FreeIPA server, the server
can handle requests from trusted domains by means of Samba project's
ttsmbd/tt and ttwinbindd/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 ttwinbindd/tt process is required to
contact the trusted domain's domain controllers and Global Catalog
servers.

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 ttcifs/hostname@REALM/tt, identified in LDAP
  as ttkrbprincipalname=cifs/hostname@REALM/tt.

* All identities are members of ttcn=adtrust
  agents/tt,ttcn=sysaccounts/tt,ttcn=etc/tt,tt$SUFFIX/tt.
  Thus, all replica servers can see what other servers are providing
  domain controller service.

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

* ttipa-adtrust-install/tt should be able to detect other DCs by
  looking at existing identities as members of the ttcn=adtrust
  agents/tt,ttcn=sysaccounts/tt,ttcn=etc/tt,tt$SUFFIX/tt
  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 ttipa dnsrecord-mod/tt commands should be used for this
  purpose, operating on SRV records for tt_msdcs/tt and default site
  configuration.

* There are trust properties that are global for the realm. Some of them
  are modifiable, some not. Thus, ttipa trustconfig-show/tt and
  ttipa 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 ttipa trustconfig/tt commands design are available at
http://www.freeipa.org/page/V3/Trust_config_command
Details on additional domain suffixes handling are available at
http://www.freeipa.org/page/V3/Domain_suffixes

= Implementation =
Implementation-wise there are three parts:

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


Re: [Freeipa-devel] [RFE] Multiple trust servers per realm

2013-04-02 Thread Martin Kosek
On 04/02/2013 11:19 AM, Tomas Babej wrote:
 On Fri 08 Mar 2013 02:16:26 PM CET, Alexander Bokovoy wrote:
 Hi,

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

 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:
 ==
 __NOTOC__

 = 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 ttipa-adtrust-install/tt ran on the FreeIPA server, the server
 can handle requests from trusted domains by means of Samba project's
 ttsmbd/tt and ttwinbindd/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 ttwinbindd/tt process is required to
 contact the trusted domain's domain controllers and Global Catalog
 servers.

 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 ttcifs/hostname@REALM/tt, identified in LDAP
   as ttkrbprincipalname=cifs/hostname@REALM/tt.

 * All identities are members of ttcn=adtrust
   agents/tt,ttcn=sysaccounts/tt,ttcn=etc/tt,tt$SUFFIX/tt.
   Thus, all replica servers can see what other servers are providing
   domain controller service.

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

 * ttipa-adtrust-install/tt should be able to detect other DCs by
   looking at existing identities as members of the ttcn=adtrust
   agents/tt,ttcn=sysaccounts/tt,ttcn=etc/tt,tt$SUFFIX/tt
   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 ttipa dnsrecord-mod/tt commands should be used for this
   purpose, operating on SRV records for tt_msdcs/tt and default site
   configuration.

 * There are trust properties that are global for the realm. Some of them
   are modifiable, some not. Thus, ttipa trustconfig-show/tt and
   ttipa 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 ttipa trustconfig/tt commands design are available at
 http://www.freeipa.org/page/V3/Trust_config_command
 Details on additional domain suffixes handling are available at
 http://www.freeipa.org/page/V3/Domain_suffixes

 = Implementation =
 Implementation-wise there are three parts:

 * ttipa-adtrust-install/tt:
 ** Gather list of CIFS services that are also members of