Red Hat Bugzilla – Bug 600381
sssd-krb5 sends wrong SRV-queries
Last modified: 2010-12-23 13:35:20 EST
Description of problem:
I configured the following domain in sssd:
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 = 188.8.131.52" everything works fine.
Version-Release number of selected component (if applicable):
Remove the parameter krb5_kdcip and sssd-krb5 can't find KDCs
sssd-krb5 sends wrong queries to dns
sssd-krb5 should be able to use dns for KDC discovery
Related upstream ticket:
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.
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.
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.
Can you please elaborate on "if I do so sssd stops working"?
Created attachment 421307 [details]
Log of a working configuration
Created attachment 421309 [details]
Log with [domain/DE01.APMN.ORG] - not working
I attached the sanitized logs (IP addresses and login changed). I hope it's not a dull configuration issue :)
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)
Created attachment 421326 [details]
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.
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.
Renee, can you identify whether the problem you're seeing exists on sssd-1.3.0-36.fc13?