Motivation

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:

/etc/pam.d/http-wiki

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

/etc/sssd/conf.d/dom-http-wiki.conf

[domain/dom-http-wiki]
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:

[sssd]
config_file_version = 2
services = nss, pam, ssh, sudo, ifp

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

[nss]

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

[domain/IPA]
# […]
# this is not relevant for this issue.

Problem

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.

Proposal

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.

Remarks

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.