[Freeipa-devel] WIP: ipa trust command

Wed Dec 14 14:45:08 UTC 2011

On Wed, Dec 14, 2011 at 08:31:57AM -0500, Simo Sorce wrote:
> On Wed, 2011-12-14 at 14:12 +0100, Sumit Bose wrote:
> > 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?
> 
> No I meant the SID of users and groups.

ok, I would very much favor this approach it will make things much
easier. But iirc the idea was rejected some time ago, because we
couldn't agree on a good algorithm which can remove the conflicts when
uid and gid are the same. What would you suggest? Adding the highest bit
for groups? uid*2 for users, (gid*2)+1 for groups? ... ?

bye,
Sumit

> 
> > Currently I didn't set a
> > uidNumber/gidNumber for this users, because for my tests so far I didn't
> > needed it.
> 
> That user can have assigned a SID that is very low, so it is assured to
> be out of the randomly chosen ranges.
> 
> > And since uidNumber/gidNumber and the SID will be handle
> > independently by the DNA plugin there would be a small chance for a
> > collision.
> 
> Thing is, if you want to use DNA we have to be careful as it needs to be
> enabled ast the same time for all servers or risk getting some users w/o
> the NT SID.
> 
> If we want to delay storing SIDs after adtrusts are enabled (probably a
> good idea as this will be the same situation as  a v2 to v3 upgrade)
> then we need to make sure the DNA plugin is completely reconfigured from
> the public shared tree and not partly configured in cn=config.
> 
> We will also need a fixup task to generate SIDs for all users/groups
> that predates the activation of the NT SID creation in DNA.
> 
> Simo.
> 
> -- 
> Simo Sorce * Red Hat, Inc * New York
> 