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:
Related upstream ticket: https://fedorahosted.org/sssd/ticket/479
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] secure log
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?