Fields changed

description: Hi,

I'm not sure if this is a defect, an enhancement, or a bad configuration on my part. I'm trying to get sssd configured to use two different kerberos realms. The university I work at has two realms: one for university faculty/staff/students and one for external accounts. Usernames are unique between the two. In the past, I have just configured pam to check the faculty/staff/student realm first and then try the external realm, which has worked out well. All passwd/group information is stored in the same LDAP database on my own systems (basically, if a user from either realm gets access to my systems, they get an account created within my own LDAP database and authentication is performed against the central kerberos realms).

With sssd, I thought I could just create two domains, one for each kerberos realm, and things would work similar to how they did with pam_krb5 (if the first failed, the second would be tried):

---8<---
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
debug_level = 0
domains = dce,fops

[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3

[pam]
reconnection_retries = 3

[domain/dce]
auth_provider = krb5
cache_credentials = True
ldap_id_use_start_tls = False
debug_level = 5
krb5_kpasswd = sherlock.aset.psu.edu
ldap_search_base = dc=hpc,dc=aset,dc=psu,dc=edu
krb5_realm = dce.psu.edu
chpass_provider = none
id_provider = ldap
min_id = 500
ldap_uri = ldap://ldap128.hpc.aset.psu.edu
krb5_kdcip = fido.aset.psu.edu,sparky.offsite.psu.edu,scooby.aset.psu.edu
ldap_tls_cacertdir = /etc/openldap/cacerts

[domain/fops]
auth_provider = krb5
cache_credentials = True
ldap_id_use_start_tls = False
debug_level = 0
krb5_kpasswd = f09n01.cac.psu.edu
ldap_search_base = dc=hpc,dc=aset,dc=psu,dc=edu
krb5_realm = fops.psu.edu
chpass_provider = none
id_provider = ldap
min_id = 500
ldap_uri = ldap://ldap128.hpc.aset.psu.edu
krb5_kdcip = f09n01.cac.psu.edu,fps.aset.psu.edu,rover.offsite.psu.edu
ldap_tls_cacertdir = /etc/openldap/cacerts
---8<---

Unfortunately, the first domain listed in the 'domains' line is used and it seems like the second one is never tried. Either one does work if it is listed first. I have run this on debug level 5 and have not seen any sign of an attempted authentication on the second domain in its log file.

My question is this: should this work and if not, is there a way to make it work?

Many thanks,

--
Jason Holmes
=> Hi,

I'm not sure if this is a defect, an enhancement, or a bad configuration on my part. I'm trying to get sssd configured to use two different kerberos realms. The university I work at has two realms: one for university faculty/staff/students and one for external accounts. Usernames are unique between the two. In the past, I have just configured pam to check the faculty/staff/student realm first and then try the external realm, which has worked out well. All passwd/group information is stored in the same LDAP database on my own systems (basically, if a user from either realm gets access to my systems, they get an account created within my own LDAP database and authentication is performed against the central kerberos realms).

With sssd, I thought I could just create two domains, one for each kerberos realm, and things would work similar to how they did with pam_krb5 (if the first failed, the second would be tried):

{{{
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
debug_level = 0
domains = dce,fops

[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3

[pam]
reconnection_retries = 3

[domain/dce]
auth_provider = krb5
cache_credentials = True
ldap_id_use_start_tls = False
debug_level = 5
krb5_kpasswd = sherlock.aset.psu.edu
ldap_search_base = dc=hpc,dc=aset,dc=psu,dc=edu
krb5_realm = dce.psu.edu
chpass_provider = none
id_provider = ldap
min_id = 500
ldap_uri = ldap://ldap128.hpc.aset.psu.edu
krb5_kdcip = fido.aset.psu.edu,sparky.offsite.psu.edu,scooby.aset.psu.edu
ldap_tls_cacertdir = /etc/openldap/cacerts

[domain/fops]
auth_provider = krb5
cache_credentials = True
ldap_id_use_start_tls = False
debug_level = 0
krb5_kpasswd = f09n01.cac.psu.edu
ldap_search_base = dc=hpc,dc=aset,dc=psu,dc=edu
krb5_realm = fops.psu.edu
chpass_provider = none
id_provider = ldap
min_id = 500
ldap_uri = ldap://ldap128.hpc.aset.psu.edu
krb5_kdcip = f09n01.cac.psu.edu,fps.aset.psu.edu,rover.offsite.psu.edu
ldap_tls_cacertdir = /etc/openldap/cacerts
}}}

Unfortunately, the first domain listed in the 'domains' line is used and it seems like the second one is never tried. Either one does work if it is listed first. I have run this on debug level 5 and have not seen any sign of an attempted authentication on the second domain in its log file.

My question is this: should this work and if not, is there a way to make it work?

Many thanks,

--
Jason Holmes

This is behaving by design. SSSD only fails over to a secondary domain if the user is not found in the primary domain. The idea is that an SSSD domain is expected to be a unique ID/auth pair. In other words, if we ask the first domain "Do you recognize this user?" and it says "yes", then we will accept its authentication backend as authoritative.

There are a few ways that you can work around this, however:

1. Use fully-qualified login names. If you specify user@SSSDDomain (e.g. mmouse@fops) as your login name, SSSD will recognize this as a request targeted specifically at the domain SSSDDomain (in this case, "fops").
2. Organize your LDAP server so that internal and external user accounts exist in a separate search base (e.g. ou=internal,dc=hpc,dc=aset,dc=psu,dc=edu and ou=external,dc=hpc,dc=aset,dc=psu,dc=edu). Setting those separate search bases would mean that SSSD would skip to the second domain if the user wasn't found in that search base in the first domain.
3. Separate your usernames into a separate LDAP server instance for internal and external

Alternately, you could open an enhancement request to allow filtering of usernames for identity (such as for a special attribute denoting internal or external users). This is not something we can do right now, however.

resolution: => invalid
status: new => closed

Fields changed

rhbz: => 0

Fields changed

milestone: NEEDS_TRIAGE => void

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/1676

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.