On Wed, 14 Dec 2011, 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? I'm also preferring the second approach. I think we can opt to provide a separate option in ipa-server-install to specify a flat name as we now always show a summary of configuration before going into actual install. This means that generated name could be checked prior to install and overriden. -- / Alexander Bokovoy
_______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
