On Wed, Jan 04, 2017 at 09:23:25AM +0100, Pavel Březina wrote: > On 01/03/2017 05:29 PM, Michal Židek wrote: > > > > > > On 01/03/2017 04:51 PM, Jakub Hrozek wrote: > > > On Tue, Jan 03, 2017 at 04:46:25PM +0100, Michal Židek wrote: > > > > Hi, > > > > > > > > for IPA provider, we plan to add the ability to configure > > > > trusted domains (currently AD domains) in a similar way the > > > > main domain is configured in sssd.conf. > > > > > > > > If ipadomain.test is the main IPA domain and addomain.test > > > > is the AD domain and there is IPA-AD trust extablished between > > > > the two, I think the way to configure addomain.test specific > > > > option could be: > > > > > > > > [domain/ipadomain.com] > > > > # the usual main domain configuration > > > > > > > > [domain/ipadomain.com/addomain.com] > > > > # configuration of trusted domain > > > > > > I like the general format of the configuration.
+1 > > > > > > > > > > > So, the main domain would be used as prefix in the > > > > section name where the trusted domain / subdomain > > > > is configured. > > > > > > > > I wanted to ask what other developers think about the > > > > format. Note that not all options that are available > > > > in the main domain will be available for the subdomain. > > > > > > Of course, options like id_provider will not be overridable. Maybe we I think id_provider (and the other providers as well) are not handled by a dp_option struct so I think we are safe here. In general I agree that it makes sense to check if really all provider specific options should be overridable. But I think we should just print a hint in the logs that the option might cause unexpected behaviour. > > > can extend the dp_opts array to indicate if the option is possible to be > > > overriden? > > > > That is an implementation detail. My main concern was that we often > > talk about "domain section of sssd.conf" and this looks > > like a domain section, but a lot of what was said about > > domain section (on list, forums, etc.) does not apply to > > this section and that concerned me a little. But OTOH I do > > not think the confusion would be big and of course it will > > be explained in the man page together with list of options that > > are available for this "subdomain" section. > > How about [trust/ipadomain.com:addomain.com]. I would rather avoid using the > term subdomain here since even though we use this term inside sssd, > technically it is not a subdomain and you can have a child domain in > sssd.conf and parent domain discovered by trust which may be misleading. I would avoid the keyword 'subdomain' as well, but I like the [domain/ipadomain.com/addomain.com] scheme better. First because I think it is more straight forward and obvious. And second 'trust' might make people think of some hierarchy which we do not have in SSSD. Everything which is discovered via the configured domain is a "subdomain" from the SSSD point of view. E.g. in the IPA case both the forest root addomain.com and any domain in the forest like child.addomain.com are just subdomains. From the IPA perspective only the forest root addomain.com is trusted. We might get questions if [trust/ipadomain.com:child.addomain.com] or [trust/addomain.com:child.addomain.com] is the right way to configure child.addomain.com because it is only trusted explicitly by addomain.com and not by ipadomain.com. bye, Sumit > > > > > Michal > > _______________________________________________ > > sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org > > To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org > _______________________________________________ > sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org > To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
