Bug 697057 - kpasswd fails when using sssd and kadmin server != kdc server
Summary: kpasswd fails when using sssd and kadmin server != kdc server
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: sssd
Version: 14
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Stephen Gallagher
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 698723 698724
TreeView+ depends on / blocked
 
Reported: 2011-04-15 17:32 UTC by Daniel Piddock
Modified: 2011-05-05 18:23 UTC (History)
5 users (show)

Fixed In Version: sssd-1.5.7-1.fc14
Clone Of:
: 698723 698724 (view as bug list)
Environment:
Last Closed: 2011-05-05 18:23:59 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Daniel Piddock 2011-04-15 17:32:18 UTC
Description of problem:
kpasswd fails with the error: "kpasswd: Cannot contact any KDC for requested realm changing password" if sssd is used with krb backend and the kadmin service is not running on the KDCs.

Version-Release number of selected component (if applicable):
sssd-1.5.4-1.fc14
krb5-workstation-1.8.2-9.fc14

How reproducible:
Almost every time, predictable.

Steps to Reproduce:
1. System with sssd using krb5 as auth backend. kpasswd service on a different server to the KDC
2. Run 'kpasswd' as a user
3. Enter passwords
  
Actual results:
"kpasswd: Cannot contact any KDC for requested realm changing password"

Expected results:
kpasswd sends a change password request to the kadmin server.

Additional info:
kpasswd is looking for /var/lib/sss/pubconf/kdcinfo.$REALM, if not found it falls back to the traditional method of using /etc/krb5.conf and then DNS lookup. Which works.

If kdcinfo.$REALM exists, kpasswd then looks for /var/lib/sss/pubconf/kpasswdinfo.$REALM, which never gets created. kpasswd uses the addresses from kdcinfo.$REALM as the kadmin server, which isn't running the kpasswd service. Hence fail.

The file in /var/lib/sss/pubconf/ is only created after sssd-krb5 is poked in the right way, e.g. an auth attempt. After restarting sssd the directory is empty.

/etc/sssd/sssd.conf contains:
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
domains = default
[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
[pam]
reconnection_retries = 3
[domain/default]
cache_credentials = True
debug_level = 0
id_provider = ldap
ldap_uri = ldaps://ldap-auth.mydomain
ldap_id_use_start_tls = False
ldap_search_base = dc=decisionsoft,dc=com
chpass_provider = krb5
auth_provider = krb5
krb5_realm = MYREALM
krb5_kpasswd = kerberos-master.mydomain
krb5_server = kerberos.mydomain

Comment 1 Fedora Update System 2011-04-25 12:08:23 UTC
sssd-1.5.6.1-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/sssd-1.5.6.1-1.fc14

Comment 2 Fedora Update System 2011-04-30 23:20:01 UTC
Package sssd-1.5.7-1.fc14:
* should fix your issue,
* was pushed to the Fedora 14 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing sssd-1.5.7-1.fc14'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/sssd-1.5.7-1.fc14
then log in and leave karma (feedback).

Comment 3 Fedora Update System 2011-05-05 18:23:50 UTC
sssd-1.5.7-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.


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