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 > _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel