On Mon, Oct 23, 2017 at 06:47:53PM +0200, Jeremy Monnet wrote:
> On Mon, Oct 23, 2017 at 4:55 PM, Jeremy Monnet <jmon...@gmail.com> wrote:
>
> >
> >> This sounds wrong:
> >> [sdap_kinit_send] (0x0400): Attempting kinit (default,
> >> host/<servername>.<subdomain>.<domain>, <SUBDOMAIN>.<DOMAIN>, 86400)
> >> with AD, you normally want to use the SHORTNAME$REALM principal, not the
> >> host/hostname principal, because the latter is only a service principal,
> >> not a user/computer one.
> >>
> >> But since you're using id_provider=ad, then sssd should have already
> >> picked
> >> up that principal..is the SHORTNAME$@REALM principal in your keytab at
> >> all?
> >>
> > Yes, it is
> >
> > root@servername:~# klist -k
> > Keytab name: FILE:/etc/krb5.keytab
> > KVNO Principal
> > ---- ------------------------------------------------------------
> > --------------
> > 2 host/servername.sub1.example....@sub1.example.com
> > 2 host/servername.sub1.example....@sub1.example.com
> > 2 host/servername.sub1.example....@sub1.example.com
> > 2 host/servername.sub1.example....@sub1.example.com
> > 2 host/servername.sub1.example....@sub1.example.com
> > 2 host/servern...@sub1.example.com
> > 2 host/servern...@sub1.example.com
> > 2 host/servern...@sub1.example.com
> > 2 host/servern...@sub1.example.com
> > 2 host/servern...@sub1.example.com
> > 2 SERVERNAME$@SUB1.EXAMPLE.COM
> > 2 SERVERNAME$@SUB1.EXAMPLE.COM
> > 2 SERVERNAME$@SUB1.EXAMPLE.COM
> > 2 SERVERNAME$@SUB1.EXAMPLE.COM
> > 2 SERVERNAME$@SUB1.EXAMPLE.COM
> >
> >
> > Some more information (in case that would help...)
>
> 1 AD forest with multiple domains : example.com and sub1.example.com
> 2 users : my_u...@example.com, testu...@sub1.example.com
> 2 servers setup the same way (same adcli commands to get the krb5.keytab,
> same resolv.conf/hosts/sssd.conf etc), but 1 is ubuntu 14 with
> sssd 1.11.8-0ubunt, 1 is ubuntu 16 with sssd 1.13.4-1ubunt
>
> (BTW I have about 15 other linuces (RHEL6/RHEL7/ubuntu14) that are
> connected only to example.com and working OK. Only these 2 servers are
> members of sub1.example.com with a need to authenticate also users from
> example.com)
>
> On these 2 servers, authentication works for testu...@sub1.example.com. I
> can authenticate with my_u...@example.com on the ubuntu 14 with sssd
> 1.11.But I cannot authenticate with my_u...@example.com on the ubuntu 16
> with sssd 1.13.
This is quite a new version, which already supports discovering trusted
domains in the same forest, so defining the root domain (example.com)
shouldn't be even required. The subdomain provider (which defaults to "ad",
same as the id_provider's value) should discover example.com on its own.
(Actually, with your setup, I would even think the explicitly defined
example.com domain is ignored at sssd would query the autodiscovered
subdomain of sub1.example.com if you ask it for any entry from example.com)
>
> sssd.conf for both servers :
> [sssd]
> config_file_version = 2
> debug_level =0
> domains = sub1.example.com,example.com
> services = nss, pam
>
> [domain/example.com]
> enumerate = true
> dns_discovery_domain = cy2._sites.example.com
> debug_level = 9
> id_provider = ad
> access_provider = ad
> ldap_id_mapping = false
>
> [domain/sub1.example.com]
> enumerate = true
> dns_discovery_domain = cy2._sites.sub1.example.com
It's easier to use:
ad_site = cy2
with a recent version. But I guess this won't work with 1.11..
> debug_level = 7
> id_provider = ad
> access_provider = ad
> ldap_id_mapping = false
>
> I have played with ad_hostname, ldap_sasl_authid, ldap_sasl_realm with
> little succes (I am not even sure ldap_sasl_* variables are useful with
> id_provider =ad...)
>
> There is only one tiny difference I see in the SPN's : my ubuntu 16 is the
> only of my servers that has a host/SERVERNAME SPN, all the others have
> HOST/SERVERNAME (Capital HOST). I cannot not understand though why that
> would allow the auth to the subdomain but not to the main, but I know
> kerberos is very sensible to the case, so just in case. And anyway, that is
> coherent with the keytab.
First, sssd should not select the host/hostname principal to connect to
AD LDAP, but it should use the SHORTNAME$@REALM principal. You can search
for messages from "select_principal_from_keytab" to see what principal did
SSSD match, for example this is how my setup looks like:
(Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]] [sdap_set_sasl_options]
(0x0100): Will look for adclient.win.trust.t...@win.trust.test in default keytab
(Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]]
[select_principal_from_keytab] (0x0200): trying to select the most appropriate
principal from keytab
(Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]]
[find_principal_in_keytab] (0x4000): Trying to find principal
adclient.win.trust.t...@win.trust.test in keytab.
(Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]]
[find_principal_in_keytab] (0x0400): No principal matching
adclient.win.trust.t...@win.trust.test found in keytab.
(Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]]
[find_principal_in_keytab] (0x4000): Trying to find principal
ADCLIENT$@WIN.TRUST.TEST in keytab.
(Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]] [match_principal]
(0x1000): Principal matched to the sample (ADCLIENT$@WIN.TRUST.TEST).
(Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]]
[select_principal_from_keytab] (0x0200): Selected primary: ADCLIENT$
(Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]]
[select_principal_from_keytab] (0x0200): Selected realm: WIN.TRUST.TEST
(Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]] [sdap_set_sasl_options]
(0x0100): Option ldap_sasl_authid set to ADCLIENT$
(Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]] [sdap_set_sasl_options]
(0x0100): Option ldap_sasl_realm set to WIN.TRUST.TEST
I would also discourage enumerate=True, currently the performance is not
the best with large domains..
So all in all, I would check which principal does sssd choose..trimming
the config file by disabling the root domain and disabling enumeration
might help as well, at least as far as log files readability goes.
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
