[Freeipa-devel] WIP: ipa trust command

[Sumit Bose]

On Wed, Dec 14, 2011 at 07:45:53AM -0500, Simo Sorce wrote:
> On Wed, 2011-12-14 at 10:23 +0100, Sumit Bose wrote:
> > 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?
> 
> We can also generate the SID algorithmically from the
> uidNumber/gidNumber

Do you mean the SID of the trusted domain user? Currently I didn't set a
uidNumber/gidNumber for this users, because for my tests so far I didn't
needed it. And since uidNumber/gidNumber and the SID will be handle
independently by the DNA plugin there would be a small chance for a
collision.

bye,
Sumit

> 
> Simo.
> 
> -- 
> Simo Sorce * Red Hat, Inc * New York
>