SSSD / sssd

#2310 Wrong principal selected for AD authentication with lowercase machine account
Closed: wontfix by pbrezina. Opened by krissn.

Closed: wontfix
Reopen Issue

I've recently upgraded a Gentoo machine from sssd-1.8.6 to 1.9.6 and encountered a problem when trying to authenticate to an AD domain.

For version 1.8.6 sssd has used the hostname$@DOMAIN.NAME principal to retrieve a TGT for LDAP access. After upgrading to 1.9.6 I noticed that I wasn't able to authenticate any more. After enabling debug I noticed this in the log:

(Wed Apr  9 13:50:25 2014) [sssd[be[S3]]] [ad_set_search_bases] (0x0100): Search base not set. SSSD will attempt to discover it later, when connecting to the LDAP server.
(Wed Apr  9 13:50:25 2014) [sssd[be[S3]]] [ad_get_id_options] (0x0100): Option krb5_realm set to DOMAIN.NAME.COM
(Wed Apr  9 13:50:25 2014) [sssd[be[S3]]] [sdap_set_sasl_options] (0x0100): Will look for somehost.domain.name.com@DOMAIN.NAME.COM in default keytab
(Wed Apr  9 13:50:25 2014) [sssd[be[S3]]] [select_principal_from_keytab] (0x0200): trying to select the most appropriate principal from keytab
(Wed Apr  9 13:50:25 2014) [sssd[be[S3]]] [find_principal_in_keytab] (0x0400): No principal matching somehost.domain.name.com@DOMAIN.NAME.COM found in keytab.
(Wed Apr  9 13:50:25 2014) [sssd[be[S3]]] [find_principal_in_keytab] (0x0400): No principal matching SOMEHOST$@DOMAIN.NAME.COM found in keytab.
(Wed Apr  9 13:50:25 2014) [sssd[be[S3]]] [match_principal] (0x1000): Principal matched to the sample (host/somehost.domain.name.com@DOMAIN.NAME.COM).
(Wed Apr  9 13:50:25 2014) [sssd[be[S3]]] [select_principal_from_keytab] (0x0200): Selected primary: host/somehost.domain.name.com
(Wed Apr  9 13:50:25 2014) [sssd[be[S3]]] [select_principal_from_keytab] (0x0200): Selected realm: DOMAIN.NAME.COM
(Wed Apr  9 13:50:25 2014) [sssd[be[S3]]] [sdap_set_sasl_options] (0x0100): Option ldap_sasl_authid set to host/somehost.domain.name.com
(Wed Apr  9 13:50:25 2014) [sssd[be[S3]]] [sdap_set_sasl_options] (0x0100): Option ldap_sasl_realm set to DOMAIN.NAME.COM

When looking for a principal in the keytab sssd is looking at the SOMEHOST$@DOMAIN.NAME.COM, which it assumes is the machine account. Unfortunately this is not the case, as my keytab says this:

# klist -k | uniq
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   2 nfs/somehost.domain.name.com@DOMAIN.NAME.COM
   2 nfs/somehost@DOMAIN.NAME.COM
   2 http/somehost.domain.name.com@DOMAIN.NAME.COM
   2 http/somehost@DOMAIN.NAME.COM
   2 host/somehost.domain.name.com@DOMAIN.NAME.COM
   2 host/somehost@DOMAIN.NAME.COM
   2 ftp/somehost.domain.name.com@DOMAIN.NAME.COM
   2 ftp/somehost@DOMAIN.NAME.COM
   2 cifs/somehost.domain.name.com@DOMAIN.NAME.COM
   2 cifs/somehost@DOMAIN.NAME.COM
   2 somehost$@DOMAIN.NAME.COM
   2 root/somehost.domain.name.com@DOMAIN.NAME.COM

The case-sensitive match doesn't pick up the somehost$@DOMAIN.NAME.COM principal and continues to search until it finds the host/somehost.domain.name.com@DOMAIN.NAME.COM principal. This one however cannot be used to obtain a TGT from AD:

# kinit -k host/somehost.domain.name.com
kinit: Client 'host/somehost.domain.name.com@DOMAIN.NAME.COM' not found in Kerberos database while getting initial credentials

This is related to https://fedorahosted.org/sssd/ticket/1740 and changes introduced in commit 4ee7f390af4193656c1e6ba45c9c3c14dd64a8a9

Did you create the keytab manually or did you use a tool? The reason I'm asking is that the typical tools like Samba's net utility or realmd will create upper-case names, because the name is based on the NetBIOS name which is typically upper-case in AD.

Can you try and see if the following is working without issues. First call

kinit -k somehost$@DOMAIN.NAME.COM

and then

kvno cifs/somehost@DOMAIN.NAME.COM

to get a service ticket?

Fields changed

owner: somebody => sbose
status: new => assigned

The keytab was created using CentrifyDC. All of the hosts I know that have been joined to the domain using this tool have lower-case machine names.

# kinit -k somehost\$@DOMAIN.NAME.COM
# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: somehost$@DOMAIN.NAME.COM
Valid starting       Expires              Service principal
04/11/2014 08:22:25  04/11/2014 18:22:25  krbtgt/DOMAIN.NAME.COM@DOMAIN.NAME.COM
        renew until 04/12/2014 08:22:25
# kvno cifs/somehost@DOMAIN.NAME.COM
cifs/somehost@DOMAIN.NAME.COM: kvno = 2
# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: somehost$@DOMAIN.NAME.COM
Valid starting       Expires              Service principal
04/11/2014 08:22:25  04/11/2014 18:22:25  krbtgt/DOMAIN.NAME.COM@DOMAIN.NAME.COM
        renew until 04/12/2014 08:22:25
04/11/2014 08:22:51  04/11/2014 18:22:25  cifs/somehost@DOMAIN.NAME.COM
        renew until 04/12/2014 08:22:25

The proposed solution was to do a case-insensitive comparison in the AD provider only. But unfortunately the next upstream release (1.12) is already packed, so I'm moving the ticket to 1.13 for now.

In the meantime, can you test if specifying the correct principal with ldap_sasl_authid would work for you?

milestone: NEEDS_TRIAGE => SSSD 1.13 beta

I have checked the ldap_sasl_authid option and I confirm that this workaround works fine.

Fields changed

rhbz: => 0

Fields changed

mark: => 0

Fields changed

milestone: SSSD 1.13 beta => SSSD 1.13 backlog

Mass-moving tickets not planned for the 1.13 release to 1.14

milestone: SSSD 1.13 backlog => SSSD 1.14 beta

Fields changed

priority: major => minor
sensitive: => 0

Even the 1.14 bucket is getting quite big and there is a workaround, pushing out..

milestone: SSSD 1.14 beta => SSSD 1.15 beta

Metadata Update from @krissn:
- Issue assigned to sbose
- Issue set to the milestone: SSSD Future releases (no date set yet)

Metadata Update from @thalman:
- Custom field design_review reset (from 0)
- Custom field mark reset (from 0)
- Custom field patch reset (from 0)
- Custom field review reset (from 0)
- Custom field sensitive reset (from 0)
- Custom field testsupdated reset (from 0)
- Issue close_status updated to: None
- Issue tagged with: Canditate to close

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/3352

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.
Metadata

Candidate to close

None
None
High
defect
SSSD
1.9.6
false
false
0
false
false
defect
SSSD
1.9.6
false
false
0
false
false
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.