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