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