#3668 Add domain enforcement option to `pam_sss.so`
Closed: wontfix a year ago by pbrezina. Opened 3 years ago by lukasjuhrich.


We want to use the nginx module auth_pam to configure multiple instances of HTTP basic auth access control. Every such instance points to the same LDAP but differs in the required (memberOf=) attribute filters (effectively checking IPA privileges).

The setup we tried is as follows.

For each basic auth instance, we have a pam service:


auth required pam_sss.so domains=dom-http-wiki
account required pam_sss.so domains=dom-http-wiki

…restricting access to an application domain (the precise config is not actually relevant to the problem, but here for the sake of completeness):


domain_type = application
krb5_realm = OUR-KRB-REALM
id_provider = ldap
auth_provider = ldap
access_provider = ldap
chpass_provider = none
sudo_provider = none
selinux_provider = none
autofs_provider = none
ldap_uri = ldaps://our.idm.server
ldap_sasl_mech = GSSAPI
ldap_tls_cacert = /etc/ipa/ca.crt
ldap_search_base = cn=users,cn=accounts,dc=our-domain,dc=de
ldap_schema = IPA
ldap_access_filter = (memberOf=cn=Wiki-Zugang,cn=privileges,cn=pbac,dc=our-domain,dc=de)
ldap_deref = never
krb5_server = our.idm.server
krb5_kpasswd = our.idm.server

This is our /etc/sssd/sssd.conf:

config_file_version = 2
services = nss, pam, ssh, sudo, ifp

domains = IPA, dom-http-wiki, dom-http-sipa-testing


offline_credentials_expiration = 31
offline_failed_login_attempts = 5
pam_app_services = http-wiki, http-sipa-testing

# […]
# this is not relevant for this issue.


Using domains imposes only a restriction. The basic auth works if the domain is set explicitly, such as username@dom-http-wiki, but if one only uses username, the default domain is used. This is undesirable as it only enables at most one basic auth to work without domain suffix, namely the one where the domain restriction and the default domain coincide.


It would be most convenient to have a parameter enforce_domain that, instead of the default domain, uses the domain given as parameter value. Glancing through the source code I see two strategies of achieving that:

  1. Just manually adding the @domain-Suffix to the given user before issuing the pam message (I mean the thing triggered in src/sss_client/pam_sss.c:send_and_receive and going through the /var/lib/sss/pipes/pam socket)
  2. Letting the pamsrv.c responder handle that: Adding to the message an item SSS_PAM_ITEM_ENFORCED_DOMAIN, adding a field enforced_domain to the pam_items struct (i.e., in complete analogy with how pi->requested_domains is handled), adding that domain to the request context, and introducing a new parameter enforced_domain in sss_parse_name_for_domain that actually implements that enforcing and fails hard if it's not consistent with any given domains or if the name already has a domain appended.


If there is any different or easier way to achieve what we want, I'll gladly look into it. I'm new to the code base so I hope I looked in the right spots. If I manage to get a working build on our debian test system I will try some things out. I can't promise I can open a PR but I will try when I find time.

If I read https://pagure.io/SSSD/sssd/issue/1021 and https://pagure.io/docs/SSSD/sssd/ correctly just using the pam_sss domains option should do what you are looking for. So we might have a regression here.

I don't think it's a regression, maybe missing functionality or omission. But if I remember correctly, the qualified names were required for this feature to work.

Metadata Update from @pbrezina:
- Issue tagged with: Canditate to close

a year ago

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

a year 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/4687

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.