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.
Also, is this something we should file a ticket for so that downstreams
can be aware of this possibility?
I think this is better added to some multi-domain setup how-to. Because
for this we in general recommend to use different keytabs for each
domain. And if one of the domains where you use an alternative keytab is
from an AD forest and you want to access other domains in the forest as
well you have to set the inherit option. Do you know if we have a how-to
like this? If yes, I'd be happy to add a paragraph with the explanation.
HTH
bye,
Sumit
> _______________________________________________
> sssd-devel mailing list
> sssd-devel(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org