Learn more about these different git repos.
Other Git URLs
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:
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
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)
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:
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.
to comment on this ticket.