Description of problem: When setting up an ldap account an extra line "krb5_realm = EXAMPLE.COM and krb5_kdcip = kerberos.example.com" is added to sssd.conf which breaks it's functionality Version-Release number of selected component (if applicable): setuptool-1.19.10-1.fc13.x86_64 How reproducible: Always Steps to Reproduce: 1.run setup 2.configure for ldap auth 3.try logging in for example via ssh Actual results: Ldap authentication fails Expected results: Ldap auth working. Additional info: Removing those lines and restarting sssd fixes this problem.
The 'setup' command is merely running authconfig-tui, so I'm reassigning this bug. Can you indicate which version of the 'authconfig' package you have installed?
authconfig-6.1.4-2.fc13.x86_64
How exactly did you use the tool? And can you please attach the broken sssd config file?
I ran setup User Information hash Use LDAP Authentication hash Use MD5 Passwords hash Use Shadow Passwords hash Use Ldap Authentication hash Local authorization is sufficient Select Next hash Use TLS Server ldap://ldap1.example.com ldap://ldap2.example.com Base DN dc=example,dc=com I updated to sssd 1.2.2-18 in koji ran setup again and I now can log in all thou "krb5_realm = EXAMPLE.COM krb5" and_"kdcip = kerberos.example.com" lines get added to the sssd.conf"
Created attachment 436254 [details] sssd.conf that gets created
Stephen, can authconfig depend on sssd tolerating options from different providers than configured?
Sorry, this bug had fallen off my radar. No, SSSD will not tolerate options from different providers than configured, however the krb5_kdcip and krb5_realm options are permissible for the LDAP provider, so they are coincidentally acceptable. Specifically, it is possible to set up the LDAP provider to use GSSAPI-encrypted communications to the LDAP server in place of LDAPS or TLS (this is not a configuration currently supported in authconfig, as it requires additional manual steps of creating a keytab). Authconfig should probably suppress this output from the sssd.conf file unless the option 'ldap_sasl_mech' is detected in the config file and is set to 'gssapi' (case-insensitive). This is the only case in which the krb5_kdcip and krb5_realm options are valid for the LDAP provider without the kerberos provider being active for authentication.
(In reply to comment #7) > Sorry, this bug had fallen off my radar. > > No, SSSD will not tolerate options from different providers than configured, > however the krb5_kdcip and krb5_realm options are permissible for the LDAP > provider, so they are coincidentally acceptable. Actually authconfig will not add options that would not be allowed by SSSDConfig module so I think we are safe here. > Specifically, it is possible to set up the LDAP provider to use > GSSAPI-encrypted communications to the LDAP server in place of LDAPS or TLS > (this is not a configuration currently supported in authconfig, as it requires > additional manual steps of creating a keytab). > > Authconfig should probably suppress this output from the sssd.conf file unless > the option 'ldap_sasl_mech' is detected in the config file and is set to > 'gssapi' (case-insensitive). This is the only case in which the krb5_kdcip and > krb5_realm options are valid for the LDAP provider without the kerberos > provider being active for authentication. But I suppose these options are harmless and no-op if the ldap_sasl_mech is not set to gssapi. Please, correct me if they are not harmless in such case. I'm closing the bug as the real problem of ldap auth not working is already fixed with the current sssd.
(In reply to comment #8) > But I suppose these options are harmless and no-op if the ldap_sasl_mech is not > set to gssapi. Please, correct me if they are not harmless in such case. Sure, they are harmless (just slightly confusing).