Learn more about these different git repos.
Other Git URLs
Ticket was cloned from Red Hat Bugzilla (product Fedora): Bug 963818
Description of problem: When 2 domains are configured in sssd only login as remote user works only for the 2nd one. This is doe to krb5_use_enterprise_principal, because when it is set to False the login starts to work. Version-Release number of selected component (if applicable): sssd-1.10.0-5.fc19.beta1 How reproducible: always Steps to Reproduce: # cat /etc/sssd/sssd.conf [sssd] domains = ad.baseos.qe, security.baseos.qe config_file_version = 2 services = nss, pam [nss] default_shell = /bin/bash [domain/ad.baseos.qe] ad_domain = ad.baseos.qe krb5_realm = AD.BASEOS.QE cache_credentials = True id_provider = ad krb5_store_password_if_offline = True ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%d/%u access_provider = ad [domain/security.baseos.qe] ad_domain = security.baseos.qe krb5_realm = SECURITY.BASEOS.QE cache_credentials = True id_provider = ad krb5_store_password_if_offline = True ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%d/%u access_provider = ad # getent passwd Bender@ad.baseos.qe bender@ad.baseos.qe:*:1197601112:1197600513:Bender:/home/ad.baseos.qe/bender:/b in/bash # getent passwd Bender@security.baseos.qe bender@security.baseos.qe:*:89801133:89800513:Bender:/home/security.baseos.qe/b ender:/bin/bash $ ssh Bender@security.baseos.qe@192.168.100.19 Bender@security.baseos.qe@192.168.100.19's password: Last login: Thu May 16 17:23:59 2013 from 192.168.100.1 [bender@security.baseos.qe@pkis ~]$ exit logout Connection to 192.168.100.19 closed. $ $ ssh Bender@ad.baseos.qe@192.168.100.19 Bender@ad.baseos.qe@192.168.100.19's password: Permission denied, please try again. ^C Setting krb5_use_enterprise_principal=False for booth domain in sssd.conf solves the problem.
Should be investigated in 1.10
blockedby: => blocking: => coverity: => design: => design_review: => 0 feature_milestone: => fedora_test_page: => milestone: NEEDS_TRIAGE => SSSD 1.10.0 owner: somebody => sbose review: True => 0 selected: => testsupdated: => 0
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=966557
rhbz: [https://bugzilla.redhat.com/show_bug.cgi?id=963818 963818] => [https://bugzilla.redhat.com/show_bug.cgi?id=963818 963818], [https://bugzilla.redhat.com/show_bug.cgi?id=966557 966557]
We think the bug might be fixed with the recent changes to the enterprise principals. Reporter was asked for more information in the bugzilla.
Moving to 1.10.1 until we have a response.
changelog: => milestone: SSSD 1.10.0 => SSSD 1.10.1
In https://bugzilla.redhat.com/show_bug.cgi?id=963818 two issue could be identified when SSSD was configured with two AD domains and enterprise principals were enabled for both domains. In this case there was a trust between both domains which mainly triggers the first issue. If there is no trust between the two AD domains the second issue would block authentication to one of the domains.
The two issues are:
The principal used in the TGS request was used to find a matching keytab entry for validation. Ideally a service principal from the realm of the user is taken for validation. When enterprise principals (or canonization) is used the realm of the principal used in the request and the realm in the returned ticket might differ. The realm from the ticket should be taken instead the one from the request.
When an enterprise principal is created the default realm is required and added to the given principal. As a result the TGS result is send to the KDC of the default realm. Currently the default realm is taken from krb5.conf (if it is not defined there, authentication fails). If there is more than one AD domains configured in SSSD this will in general fail because there is only one default realm which will only work for one of the two domains. the krb5_child should set the default realm explicitly if enterprise principals are used.
Fields changed
patch: 0 => 1 status: new => assigned
Considering that this is a regression and Sumit already has a patch I'd prefer fixing this issue before releasing 1.10.0
milestone: SSSD 1.10.1 => SSSD 1.10.0
resolution: => fixed status: assigned => closed
Metadata Update from @jhrozek: - Issue assigned to sbose - Issue set to the milestone: SSSD 1.10.0
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/2973
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.