#1931 cannot login to the 1st domain when 2 domains are configured in sssd
Closed: Fixed None Opened 9 years ago by jhrozek.

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):

How reproducible:

Steps to Reproduce:

# cat /etc/sssd/sssd.conf

domains = ad.baseos.qe, security.baseos.qe
config_file_version = 2
services = nss, pam

default_shell = /bin/bash

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

ad_domain = 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
# getent passwd Bender@security.baseos.qe

$ ssh Bender@security.baseos.qe@
Bender@security.baseos.qe@'s password:
Last login: Thu May 16 17:23:59 2013 from
[bender@security.baseos.qe@pkis ~]$ exit
Connection to closed.
$ ssh Bender@ad.baseos.qe@
Bender@ad.baseos.qe@'s password:
Permission denied, please try again.

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

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:

  1. 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.

  2. 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

5 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.