On Mon, Dec 12, 2016 at 11:21:31AM -0800, Omen Wild wrote:
Quoting Sumit Bose <sbose(a)redhat.com> on Sat, Dec 10 17:56:
>
> It it (again) about Kerberos ticket validation. If you set
> 'krb5_validate = False' in the [domain/...] section of sssd.conf
> authentication should work (with the correct password :-).
Awesome, this worked!
> It looks like realmd's backend (adcli or net ads) has put the
> RestrictedKrbHost/phys-adtest(a)TOU.T3.UCDAVIS.EDU at the end of
> /etc/krb5.keytab but the DC of
TOU.T3.UCDAVIS.EDU does not know this
> principal. Can you check if the host entry for your host in AD has
> servicePrincipalName entries for all entries in /etc/krb5.keytab (klist
> -k) except for the one with the '$' at the end of the hostname?
Hmmm, the host entry in AD actually has nothing in servicePrincipalName: <not
set>.
hmm, in theory the attribute should be filled during the join with
values matching the keytab entry. You can try to add the entries
manually. Here at least 'RestrictedKrbHost/phys-adtest' and
'RestrictedKrbHost/phys-adtest.tou.t3.ucdavis.edu' should be added.
You can check if it is working or not without SSSD by calling:
kinit aduser(a)T3.UCDAVIS.EDU
kvno RestrictedKrbHost/phys-adtest(a)TOU.T3.UCDAVIS.EDU
or
kvno 'RestrictedKrbHost/phys-adtest.tou.t3.ucdavis.edu(a)TOU.T3.UCDAVIS.EDU'
I noticed all the entries in `klist -k` have ALL CAPS, i.e.:
RestrictedKrbHost/phys-adtest(a)TOU.T3.UCDAVIS.EDU
However, `realm list` shows a mixed case:
----- Begin quote realm list -----
root@phys-adtest:/var/log/sssd# realm list
tou.T3.UCDAVIS.EDU
type: kerberos
realm-name:
TOU.T3.UCDAVIS.EDU
domain-name:
tou.t3.ucdavis.edu
configured: kerberos-member
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
login-formats: %U(a)tou.t3.ucdavis.edu
login-policy: allow-realm-logins
----- End quote realm list -----
The distinguishedName attribute has the same mixed case in the DC:
CN=phys-adtest,[snip],DC=tou,DC=T3,DC=UCDAVIS,DC=EDU
Could tou.T3 vs TOU.T3 cause this kind of issue? If so, is there a
workaround on the sssd side?
According to the related RFCs Kerberos is case-sensitive. But AD
typically treats the Kerberos principal case-insensitive which sometimes
might cause issues on a client. But here I think this is not the reason
for the issues you see (it the missing servicePrincipalName, see above).
In my experience when creating the domain AD will always upper-case all
characters in the domain name to create the Kerberos realm, so the all
upper-case version is the canonical form and is always safe to use.
Since SSSD picks an entry from the keytab here which should be created
by the membership software (adcli or net ads) together with
servicePrincipalName value the case should in general always match.
HTH
bye,
Sumit
--
Omen Wild
Systems Administrator
Metro Cluster
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org