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.
-- 
/ Alexander Bokovoy

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to