Bug 600381 - sssd-krb5 sends wrong SRV-queries
sssd-krb5 sends wrong SRV-queries
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: sssd (Show other bugs)
13
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Jakub Hrozek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-04 11:29 EDT by René
Modified: 2010-12-23 13:35 EST (History)
5 users (show)

See Also:
Fixed In Version: sssd-1.3.0-36.fc13
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-23 13:35:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Log of a working configuration (15.95 KB, application/octet-stream)
2010-06-04 13:46 EDT, René
no flags Details
Log with [domain/DE01.APMN.ORG] - not working (6.15 KB, application/octet-stream)
2010-06-04 13:48 EDT, René
no flags Details
secure log (2.70 KB, application/text)
2010-06-04 14:44 EDT, René
no flags Details

  None (edit)
Description René 2010-06-04 11:29:01 EDT
Description of problem:

I configured the following domain in sssd:

[domain/DE01]
min_id = 500
max_id = 10000
debug_level = 5
enumerate = false
id_provider = proxy
proxy_lib_name = files
auth_provider = krb5
krb5_realm = DE01.APMN.ORG
krb5_changepw_principle = kadmin/changepw
krb5_ccachedir = /tmp
krb5_ccname_template = FILE:%d/krb5cc_%U_XXXXXX
krb5_auth_timeout = 15
krb5_store_password_if_offline = true
cache_credentials = true

As you can see the realm is "DE01.APMN.ORG". This configuration isn't working, because sssd trims the realm in the dns query and therefore can't find the KDCs (tshark output):

0.000000 client-ip -> dns-host-ip DNS Standard query SRV _KERBEROS._tcp.DE01

As you can see, the realm is truncated after the first dot.

If I add "krb5_kdcip = 1.1.1.1" everything works fine.



Version-Release number of selected component (if applicable):

sssd-1.2.0-12.fc13.x86_64
sssd-client-1.2.0-12.fc13.x86_64

How reproducible:
Remove the parameter krb5_kdcip and sssd-krb5 can't find KDCs

  
Actual results:
sssd-krb5 sends wrong queries to dns

Expected results:
sssd-krb5 should be able to use dns for KDC discovery

Additional info:
Comment 1 Stephen Gallagher 2010-06-04 11:34:21 EDT
Related upstream ticket:
https://fedorahosted.org/sssd/ticket/479
Comment 2 Simo Sorce 2010-06-04 11:39:34 EDT
SSSD does not trim or truncate the realm, it doesn't use the realm at all for DNS discovery, it uses the domain name.
You named your domain "DE01", and that's what sssd uses.
Using the realm would be wrong for 2 reasons.
A) it would work only for kerberos stuff, when a realm is defined
B) REALM != DNS domain

We probably need to turn this bug into a documentation bug and make it clear that the domain name is what is used for automatic discovery.
Comment 3 Jakub Hrozek 2010-06-04 12:55:43 EDT
I agree that there is nothing to fix code-wise, but I also think that the documentation in section "service discovery" in the manual pages of states it clear that domain name is used. 

Rene, if there is anything unclear in the man pages, please shout and we can fix the documentation, otherwise I will close the bug.
Comment 4 René 2010-06-04 13:26:49 EDT
So if I get you right, I have to change the domain name to "[domain/DE01.APMN.ORG]" and of course "domains = DE01.APMN.ORG". I already tested it, but if I do so sssd stops working. What am I doing wrong?

BTW: I wasn't aware of RFC 2782 which is mentioned in the man page. I only knew RFC 4120 which states that the domain name to use for the automatic discovery RR is the _same_ as the realm.
Comment 5 Stephen Gallagher 2010-06-04 13:33:03 EDT
Can you please elaborate on "if I do so sssd stops working"?
Comment 6 René 2010-06-04 13:46:19 EDT
Created attachment 421307 [details]
Log of a working configuration
Comment 7 René 2010-06-04 13:48:04 EDT
Created attachment 421309 [details]
Log with [domain/DE01.APMN.ORG] - not working
Comment 8 René 2010-06-04 13:49:22 EDT
I attached the sanitized logs (IP addresses and login changed). I hope it's not a dull configuration issue :)
Comment 9 Stephen Gallagher 2010-06-04 14:01:47 EDT
The second log looks like it's working just fine... it's just never receiving an auth request. Can you check /var/log/secure to see if it's even trying to use pam_sss?

Also, if I might ask, why are you using local users with Kerberos authentication? Are you manually keeping your /etc/passwd file in sync with the Kerberos database? (Might be time to consider LDAP)
Comment 10 René 2010-06-04 14:44:14 EDT
Created attachment 421326 [details]
secure log
Comment 11 René 2010-06-04 15:11:10 EDT
I uploaded the logs. But I don't want to waste your time - if you think this
isn't a bug and just a mistake in my configs, I will sleep about it and try it
again tomorrow. Configuring the KDCs manually isn't such a big issue.
Particularly in regard to the amount of hosts we will have to configure.

Regarding your remark to consider using LDAP: We already use a LDAP directory -
unfortunately it's an Active Directory without SFU etc. - we only use a handful
Fedora machines and have to comply to several security standards. So we have to
use the AD for our user accounts and of course we need Kerberos to access our
systems. I know there are better solutions than using /etc/passwd, but for now
it's the one with the least amount of effort and discussions ;-)

Using sssd would just make the offline usage easier and we wouldn't have to
kinit each time etc.
Comment 12 Ian Dall 2010-09-02 10:09:15 EDT
This may not be relevant, but check that your DNS has both _kerberos._udp and _kerberos._tcp entries. I had only the former and while kinit would work fine, sssd would not operate with just the udp service. RFC4120 is clear that both the udp and tcp entries are required.
Comment 13 Stephen Gallagher 2010-11-09 11:43:46 EST
Renee, can you identify whether the problem you're seeing exists on sssd-1.3.0-36.fc13?

Note You need to log in before you can comment on or make changes to this bug.