On Tue, Feb 23, 2016 at 12:02:04PM +0100, Jakub Hrozek wrote: > On Tue, Feb 23, 2016 at 10:57:18AM +0100, Sumit Bose wrote: > > On Tue, Feb 23, 2016 at 10:41:37AM +0100, Jakub Hrozek wrote: > > > On Wed, Feb 17, 2016 at 05:44:51PM +0100, Sumit Bose wrote: > > > > Hi, > > > > > > > > if a different keytab than /etc/krb5.keytab is used e.g. with the AD > > > > provider the subdomains still try to use keys from /etc/krb5.keytab to > > > > connect to e.g. the LDAP server of the subdomain. But id > > > > /etc/krb5.keytab is not present or does not contain suitable keys this > > > > will fails. As a work-around it might be possible to change > > > > default_keytab_name in /etc/krb5.conf but this will change the default > > > > globally and only works for a single file. If e.g. there are 2 AD > > > > domains with alternative keytabs configured this won't work. > > > > > > > > The attached patch allows to inherit the setting of ldap_krb5_keytab (or > > > > krb5_keytab) to the subdomains. > > > > > > The patch is of course correct (I'm just running CI tests now), but I > > > wonder what is the use-case? I thought that since the subdomains were > > > trusting each other in a direct integration scenario, we could always > > > use the keys from the main domain we're enrolled with? > > > > Yes, but if the keys for the main domain are not in the default > > /etc/krb5.keytab but in say /etc/my_dom.keytab the alternative keytab > > will be only used when accessing the LDAP service from the main domain > > but not when accessing the child domain. Since the keytab option is > > unset for the child domains the default (/etc/krb5.keytab) will be used. > > > > The use-case for an alternative keytab is a multi-domain setup where > > SSSD is joined to different forests which do not trust each other. > > Thank you for the explanation. > > ACK > > CI: http://sssd-ci.duckdns.org/logs/job/37/62/summary.html
* master: 763f24777fe3c9be4efe495077e7bb1feb99a3bd _______________________________________________ sssd-devel mailing list [email protected] https://lists.fedorahosted.org/admin/lists/[email protected]
