[Freeipa-devel] WIP: ipa trust command

[Sumit Bose]

On Tue, Dec 13, 2011 at 07:08:24PM +0200, Alexander Bokovoy wrote:
> On Tue, 13 Dec 2011, Simo Sorce wrote:
> > On Mon, 2011-12-12 at 22:27 +0200, Alexander Bokovoy wrote:
> > > On Mon, 12 Dec 2011, Sumit Bose wrote:
> > > > > --password <Value> [type-specific parameters]
> > > > > 
> > > > > Creates a trust between FreeIPA realm and another realm of selected 
> > > > > type. Only 'ads' type is currently supported.
> > > > > 
> > > > > For 'ads' type running `ipa trust-add' would be equivalent to 
> > > > > following sequence:
> > > > >  * ipa-adtrust-install
> > > > >  * net rpc trust create
> > > > 
> > > > As Simo already mentioned theses should be two separate step and `ipa
> > > > trust-add' should just check is the needed components to create AD
> > > > trusts are already installed on the IPA server.
> > > See my answer to Simo, I think we can substantially improve this 
> > > situation.
> > > 
> > > > Additionally I think we need some commands to define a UID range for the
> > > > trusted domains, especially for AD trusts. For the domain given with the
> > > > `ipa trust-add' command we could just use another command line option.
> > > > But if this domain already has trusts to other domains it will become
> > > > difficult to handle this with options to `ipa trust-add'. So I would
> > > > suggest to add a new command to the `ipa trust' family which can set UID
> > > > ranges for domains before the trust is created. If the trust is already
> > > > created we may still allow to change the range but with a strong warning
> > > > that existing UIDs and GIDs will change.
> > > Ok, this would qualify for ipa trust-add options for UID/GID ranges 
> > > and would also warrant addition of ipa trust-mod that Rob has proposed.
> > > 
> > > What else except UID/GID ranges could be modified?
> > 
> > 
> > Ok we had a discussion this morning about how to handle this.
> > 
> > We decided to do a few things to simplify installing and managing the
> > problem when multiple replicas are involved.
> > 
> > 1. We will fold back as much as possible into ipa-server-install (and
> > update scripts for 2 -> 3 updates), in particular we will move generic
> > ACI creation (including additional ACI for a new group called Trusts
> > Admins), and the creation of a system user called adtrust and associated
> > DS user under uid=adtrust,cn=sysaccount,cn=etc,
> > 
> > 2. We will preconfigure DS so that SASL/EXTERNAL authentication with
> > that user results in using the uid=adtrust DN that will have also
> > pre-assigned ACIs
> > 
> > 3. We will change samba's ipasm to use the adtrust user and
> > SASL/EXTERNAL auth to access DS in order to have privilege separation.
> > This means smbd keeps operating as a restricted user but will not need a
> > password to be set via smbpasswd -e
> > 
> > 4. We change ipa-adtrust-install to ipa-adtrust-enable, this script will
> > verify the necessary trust objects are in place and enables starting the
> > adtrust service (smbd daemon, cldap plugin, ...) It also adds the server
> > to the _msdcs DNS hive.
> > 
> > 5. Each ipa server admins need to use as a bridge to/from AD will need
> > to be 'activated' by running ipa-adtrust-enable once for now. We can
> > also consider automatically running it by passing a --enable-adtrust
> > parameter to ipa-replica-install
> > 
> > 6. We change ipa-replica-manage to make sure _msdcs records are also
> > deleted when a replica is removed.
> > 
> > 
> > This should be all, please send corrections if I forgot something.
> 'ipa trust' family of commands will be used to manage trust 
> information after configuration -- listing existing trusts, removing 
> and modifying them.
> 
> In addition, 'ipa trust-add' will do similar ground work 
> when configuring AD trusts on the master -- it will ensure all needed 
> records are in LDAP (or will create them) and will ask admin to use 
> ipa-adtrust-enable to actually activate the trust. All this is due to 
> the fact that we need to start/restart services with root privileges.
> 
> This way we can have a common CLI that will stay the same for all 
> future trust variants and instruct admins how to activate actual trust 
> relationship once it is configured.
> 
> If we'll find solutions to automate activation process, we can then 
> replace the instructions with the actual calls to activation.

Simo, Alexander thank you for the summary.

I have an open ticket (#1614) which I planned to add to
ipa-adtrust-install but which might be better solved elsewhere whit the
current plans.

In ticket #1614 a DNS plugin configuration shall be created to add SIDs
to IPA user which should be used in the trusted AD domain as well. We
can create the DNA configuration with the initial setup of the IPA
domain, but since we current store SID strings in the related attribute
the domain SID of the IPA domain must be know. I can think of two was to
solve this. One would be to not store the SID string, but only the RID
part of the SID and let the ipasam plugin  add the domain SID when
needed. The other that we create the ipaNTDomainAttrs object during the
initial setup as well. I would prefer the second one. The only problem
here is that we need a flat name (aka NetBIOS name) for the domain.
ipa-adtrust-install has some logic to derive this from the IPA domain
name, but there might be circumstances where we have to ask the user to
provide a flat name. If this is acceptable I would vote to add the
creation of the ipaNTDomainAttrs object to the initial setup of the
IPA domain as well.

Which way would you prefer?

bye,
Sumit

> -- 
> / Alexander Bokovoy
> 
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel