Does sssd use initgroups?
by Spike White
All,
sssd front-end, AD back-end. Does sssd use initgroups to use initial
group membership?
I was recently debugging a sssd connection problem in the
/var/log/sssd/sssd* logs (debug level 9). and I thought I saw a reference
to initgroups. or getgrouplist().
my /etc/nsswitch.conf file has:
passwd: files systemd sss
group: files systemd sss
Should I also have a line with:
initgroups: files systemd sss
Spike White
3 years, 8 months
id_provider=ldap with auth_provider=proxy
by Jonathon Anderson
I'm working a RHEL7.6 case (02704264, if that's useful to anyone)
where the tech is claiming that our domain setup of id_provider=ldap
with auth_provider=proxy doesn't work. This is counter to our past and
current experience, but I'm afraid of this being a red herring that
will block us from troubleshooting the hanging issue we're
experiencing.
The tech is citing table 7.1 at
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...,
which lists "Available Combinations of Identity and Authentication
Providers" and, since this combination isn't listed, they're saying
this combination doesn't work.
We use auth_provider=proxy to dispatch auth through a Duo authentication proxy.
Can someone confirm whether there's any reason this shouldn't work?
Again, it *does* work, but we're experiencing a failure mode where
sssd becomes unresponsive after some time or event, as yet
undetermined.
Thanks for your help.
~jonathon
3 years, 8 months
Announcing SSSD 2.3.1
by Pavel Březina
# SSSD 2.3.1
The SSSD team is proud to announce the release of version 2.3.1 of the
System Security Services Daemon. The tarball can be downloaded from:
https://github.com/SSSD/sssd/releases/tag/sssd-2_3_1
See the full release notes at:
https://sssd.io/docs/users/relnotes/notes_2_3_1
RPM packages will be made available for Fedora shortly.
## Feedback
Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
## Highlights
### New features
- Domains can be now explicitly enabled or disabled using `enable` option in
domain section. This can be especially used in configuration snippets.
- New configuration options `memcache_size_passwd`, `memcache_size_group`,
`memcache_size_initgroups` that can be used to control memory cache size.
### Notable bug fixes
- Fixed several regressions in GPO processing introduced in sssd-2.3.0
- Fixed regression in PAM responder: failures in cache only lookups are
no longer considered fatal
- Fixed regression in proxy provider: `pwfield=x` is now default value
only for `sssd-shadowutils` target
### Packaging changes
- `libwbclient` is now deprecated and is not being built by default (use
`--with-libwibclient` to build it)
### Documentation Changes
- Added option `memcache_size_passwd`
- Added option `memcache_size_group`
- Added option `memcache_size_initgroups`
- Added option `enable` in domain sections
- Minor text improvements
3 years, 8 months
users unable to log in when root partition is full
by Gidon
Hi.
We have been using sssd for quite a while to join our servers to active directory.
However when root partition (using installation default partition scheme) fills up, active directory users are not able to login, and we are forced to use local users to login and clear the partition.
Obviously Ideally, we shouldn't reach this situation at all, but mistakes \ issues happen, and when it does administrative users (from active directory) should still be able to login and resolve the issue.
Therefor I am in search of a solution that will allow active directory users to still be able to login in when the system partition is full.
I found this thread https://bugzilla.redhat.com/show_bug.cgi?id=849538#c16 (that also points to https://github.com/SSSD/sssd/issues/2254)
and the recommended solution is to put /var/lib/sss on a separate partition, which I have. However, even then the issue persists.
Any other suggestions?
3 years, 9 months
sssd backend lookup fails with empty cache
by Jerry Morey
Hi,
I have a weird situation when a user launches a Slurm interactive job on a new compute node with empty sssd cache. I'm not sure if its an issue with Slurm or SSSD/NSS. Below is the output of the Slurm session originated on node ip-0A0B0004 and starting interactive node ip-0A0B0006 by user1 with uid 705601104:
>[user1@ip-0A0B0004 ~]$ srun -p lowmem -w lowmem-2 --pty bash
/usr/bin/id: cannot find name for group ID 705600513
/usr/bin/id: cannot find name for user ID 705601104
[I have no name!@ip-0A0B0006 ~]$
From this node I can successfully id user1 or any other AD user (this populates my cache and subsequent Slurm sessions for any user will resolve):
[I have no name!@ip-0A0B0006 ~]$ id user1
uid=705601104(user1) gid=705600513 groups=705600513,705601103(group1)
[I have no name!@ip-0A0B0006 ~]$
Here is the relevant session from my sssd_nss.log:
(Fri Jul 10 22:47:58 2020) [sssd[nss]] [cache_req_send] (0x0400): CR #0: New request 'User by ID'
(Fri Jul 10 22:47:58 2020) [sssd[nss]] [cache_req_select_domains] (0x0400): CR #0: Performing a multi-domain search
(Fri Jul 10 22:47:58 2020) [sssd[nss]] [cache_req_search_domains] (0x0400): CR #0: Search will check the cache and check the data provider
(Fri Jul 10 22:47:58 2020) [sssd[nss]] [cache_req_set_domain] (0x0400): CR #0: Using domain [jmorey.net]
(Fri Jul 10 22:47:58 2020) [sssd[nss]] [cache_req_search_send] (0x0400): CR #0: Looking up UID:705601104@jmorey.net
(Fri Jul 10 22:47:58 2020) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #0: Checking negative cache for [UID:705601104@jmorey.net]
(Fri Jul 10 22:47:58 2020) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #0: [UID:705601104@jmorey.net] is not present in negative cache
(Fri Jul 10 22:47:58 2020) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #0: Looking up [UID:705601104@jmorey.net] in cache
(Fri Jul 10 22:47:58 2020) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #0: Object [UID:705601104@jmorey.net] was not found in cache
(Fri Jul 10 22:47:58 2020) [sssd[nss]] [cache_req_search_dp] (0x0400): CR #0: Looking up [UID:705601104@jmorey.net] in data provider
(Fri Jul 10 22:47:58 2020) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x562848473820:1:705601104@jmorey.net]
(Fri Jul 10 22:47:58 2020) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [jmorey.net][0x1][BE_REQ_USER][idnumber=705601104:-]
(Fri Jul 10 22:47:58 2020) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x562848473820:1:705601104@jmorey.net]
(Fri Jul 10 22:47:58 2020)
(Fri Jul 10 22:47:58 2020) [sssd[nss]] [cache_req_common_dp_recv] (0x0040): CR #0: Data Provider Error: 3, 0, Success
(Fri Jul 10 22:47:58 2020) [sssd[nss]] [cache_req_common_dp_recv] (0x0400): CR #0: Due to an error we will return cached data
(Fri Jul 10 22:47:58 2020) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #0: Looking up [UID:705601104@jmorey.net] in cache
(Fri Jul 10 22:47:58 2020) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #0: Object [UID:705601104@jmorey.net] was not found in cache
(Fri Jul 10 22:47:58 2020) [sssd[nss]] [cache_req_process_result] (0x0400): CR #0: Finished: Not found
To my inexperienced eye it looks like it is communicating with the backend but receives some kind of error so it reverts to the cache, which is empty. The other oddity is the 'User by id' request that is trying to resolve based on the uid not the name. While this is happening I can successfully resolve user1 using SSH to the same node.
The SSH session:
(Mon Jul 13 20:30:27 2020) [sssd[nss]] [cache_req_send] (0x0400): CR #6: New request 'User by name'
(Mon Jul 13 20:30:27 2020) [sssd[nss]] [cache_req_process_input] (0x0400): CR #6: Parsing input name [user1]
(Mon Jul 13 20:30:27 2020) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'user1' matched without domain, user is user1
(Mon Jul 13 20:30:27 2020) [sssd[nss]] [cache_req_set_name] (0x0400): CR #6: Setting name [user1]
(Mon Jul 13 20:30:27 2020) [sssd[nss]] [cache_req_select_domains] (0x0400): CR #6: Performing a multi-domain search
(Mon Jul 13 20:30:27 2020) [sssd[nss]] [cache_req_search_domains] (0x0400): CR #6: Search will check the cache and check the data provider
(Mon Jul 13 20:30:27 2020) [sssd[nss]] [cache_req_set_domain] (0x0400): CR #6: Using domain [jmorey.net] (Mon Jul 13 20:30:27 2020) [sssd[nss]] [cache_req_prepare_domain_data] (0x0400): CR #6: Preparing input data for domain [jmorey.net] rules
(Mon Jul 13 20:30:27 2020) [sssd[nss]] [cache_req_search_send] (0x0400): CR #6: Looking up user1(a)jmorey.net
(Mon Jul 13 20:30:27 2020) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #6: Checking negative cache for [user1(a)jmorey.net]
(Mon Jul 13 20:30:27 2020) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #6: [user1(a)jmorey.net] is not present in negative cache
(Mon Jul 13 20:30:27 2020) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #6: Looking up [user1(a)jmorey.net] in cache
(Mon Jul 13 20:30:27 2020) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #6: Object [user1(a)jmorey.net] was not found in cache
(Mon Jul 13 20:30:27 2020) [sssd[nss]] [cache_req_search_dp] (0x0400): CR #6: Looking up [user1(a)jmorey.net] in data provider
(Mon Jul 13 20:30:27 2020) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x564629422820:1:user1@jmorey.net@jmorey.net]
(Mon Jul 13 20:30:27 2020) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [jmorey.net][0x1][BE_REQ_USER][name=user1@jmorey.net:-]
(Mon Jul 13 20:30:27 2020) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x564629422820:1:user1@jmorey.net@jmorey.net]
(Mon Jul 13 20:30:27 2020) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 0 errno: 0 error message: Success
(Mon Jul 13 20:30:27 2020) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #6: Looking up [user1(a)jmorey.net] in cache
(Mon Jul 13 20:30:27 2020) [sssd[nss]] [cache_req_search_ncache_filter] (0x0400): CR #6: This request type does not support filtering result by negative cache
(Mon Jul 13 20:30:27 2020) [sssd[nss]] [cache_req_search_done] (0x0400): CR #6: Returning updated object [user1(a)jmorey.net]
(Mon Jul 13 20:30:27 2020) [sssd[nss]] [cache_req_create_and_add_result] (0x0400): CR #6: Found 1 entries in domain jmorey.net
(Mon Jul 13 20:30:27 2020) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x564629422820:1:user1@jmorey.net@jmorey.net]
(Mon Jul 13 20:30:27 2020) [sssd[nss]] [cache_req_done] (0x0400): CR #6: Finished: Success
Here is my sssd.conf:
[sssd]
config_file_version = 2
services = nss,pam
domains = jmorey.net
[nss]
filter_users = root
filter_groups = root
debug_level = 7
[pam]
[domain/jmorey.net]
id_provider = ldap
auth_provider = ldap
access_provider = ldap
debug_level = 7
dns_discovery_domain = jmorey.net
enumerate = False
cache_credentials = True
case_sensitive = false
ldap_schema = ad
ldap_uri = ldaps://jmorey-novo-ad.jmorey.net
ldap_user_search_base = cn=Users,dc=jmorey,dc=net
ldap_group_search_base = cn=group1,cn=Users,dc=jmorey,dc=net
ldap_referrals = False
ldap_tls_reqcert = never
ldap_use_tokengroups = True
ldap_id_mapping = True
override_homedir = /mnt/exports/shared/home/%u
fallback_homedir = /shared/home/%u
default_shell = /bin/bash
ldap_access_order = filter, expire
ldap_account_expire_policy = ad
ldap_access_filter = (|(memberOf=cn=group1,cn=Users,dc=jmorey,dc=net))
ldap_default_bind_dn = cn=user 1,cn=Users,dc=jmorey,dc=net
ldap_default_authtok_type = password
ldap_default_authtok =
thanks,
Jerry
3 years, 9 months
Should sssd be escaping this LDAP query?
by Shane Frasier
Hello,
I am using FreeIPA and I have users who authenticate into our environment using their PIV (smartcard) certificates. Everything works great for users who happen to be "full" employees, but contractors' certificates never match. They authenticate in two ways:
* Via a call to ipa certmap-match for VPN access.
* Via kinit.
"Full" employees have certificates issues by:
OU=DHS CA4,OU=Certification Authorities,OU=Department of Homeland Security,O=U.S. Government,C=US
Their certificates are issued to, for example:
CN=JOHN J SMITH+UID=0123456789.DHS HQ,OU=People,OU=DHS HQ,OU=Department of Homeland Security,O=U.S. Government,C=US
Contractors have certificates issued by:
OU=DHS CA4,OU=Certification Authorities,OU=Department of Homeland Security,O=U.S. Government,C=US
Their certificates are issued to, for example:
CN=MAX M MUSTERMANN (affiliate)+UID=0123456789.DHS HQ,OU=People,OU=DHS HQ,OU=Department of Homeland Security,O=U.S. Government,C=US
Note the "(affiliate)" that appears in the contractors' certificates.
I have the usual certificate mapping rule:
(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})
I also have a simple matching rule:
<ISSUER>O=U.S. Government
I currently have the following four certificate mapping data entries for each user:
* X509:<I>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=Certification Authorities,OU=DHS CA4<S>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=DHS HQ,OU=People,CN=MAX M MUSTERMANN (affiliate)+UID=0123456789.DHS HQ
* X509:<I>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=Certification Authorities,OU=DHS CA4<S>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=DHS HQ,OU=People,CN=MAX M MUSTERMANN (affiliate),UID=0123456789.DHS HQ
* X509:<I>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=Certification Authorities,OU=DHS CA4<S>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=DHS HQ,OU=People,UID=0123456789.DHS HQ+CN=MAX M MUSTERMANN (affiliate)
* X509:<I>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=Certification Authorities,OU=DHS CA4<S>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=DHS HQ,OU=People,UID=0123456789.DHS HQ,CN=MAX M MUSTERMANN (affiliate)
After doIng some digging, it looks like sssd is performing this LDAP query:
ldapsearch -b "cn=accounts,dc=staging,dc=cool,dc=cyber,dc=dhs,dc=gov" "(&(ipaCertMapData=X509:<I>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=Certification Authorities,OU=DHS CA4<S>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=DHS HQ,OU=People,CN=MAX M MUSTERMANN (affiliate),UID=0123456789.DHS HQ)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))"
This query always fails. I believe this is because of the parentheses in the subject name because if I manually escape the parentheses surrounding "affiliate" as seen below, then the ldapsearch command finds the user:
ldapsearch -b "cn=accounts,dc=staging,dc=cool,dc=cyber,dc=dhs,dc=gov" "(&(ipaCertMapData=X509:<I>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=Certification Authorities,OU=DHS CA4<S>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=DHS HQ,OU=People,CN=MAX M MUSTERMANN \(affiliate\),UID=0123456789.DHS HQ)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))"
I brought up this issue in the FreeIPA Users mailing list, and they recommended that I post it here too since sssd is what is actually generating these LDAP queries. How do I get FreeIPA/sssd to inject those escapes into the LDAP query?
Thank you,
Shane
3 years, 9 months
Can enumeration scope for the SSSD be controlled?
by Lawrence Kearney
Hello and I hope all is well for everyone and everyone is staying healthy.
The issue being experienced is actually a bug in another application being
resolved by turning enumeration on. Specifically some versions of SLURM.
https://bugs.schedmd.com/show_bug.cgi?id=9318
https://bugs.schedmd.com/show_bug.cgi?id=9374
The job owner on the compute does end up going to "nobody" and turning
enumeration on does resolve it. Obviously the solution is for the SLURM
developers to fix the bug. In the interim I wanted to know if there was a
way to control the scope of enumeration for the SSSD. I'm assuming the
search base used is irrelevant in the context of enumeration.
Thank you to everyone as always,
-- lawrence
3 years, 9 months
sssd backend still offline when 389 server comes back online
by Nicolas Martin
Hello,
Using sssd with credentials caching, I encounter the following problem:
When the 389 server is offline, users with cached credentials can login;
users without cached credentials cannot login (normal behavior)
When the 389 server comes back online, users with cached credentials can
login; users without cached credentials still cannot login.
Only restarting the sssd service will allow users without cached
credentials to login.
Is there a timeout to configure or any setting in sssd configuration ?
I'm using sssd-1.16.2-13.el7_6.8.x86_64 (RHEL 7U6).
I have the following configuration:
[domain/default]
cache_credentials = True
ldap_search_base = dc=XXX
krb5_realm = EXAMPLE.COM
krb5_server = kerberos.example.com
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldaps://YYY
ldap_tls_cacertdir = /etc/openldap/cacerts
[sssd]
services = nss, pam
config_file_version = 2
domains = default
[nss]
[pam]
[sudo]
[autofs]
[ssh]
[pac]
3 years, 9 months
Generic error message when password change fails with 389 server
by Nicolas Martin
Hello,
Using sssd together with 389 directory server (password expiration policy
and history activated), changing user password with the passwd command will
print the error message:
Password change failed. Server message: Failed to update password
passwd: Authentication token is no longer valid; new one required
in the following cases:
- password has been changed less than a day ago
- password is in 389 server history
- password does not meet syntax constraints in 389 server
Since 389 server does say why it rejects passwords, is there a
configuration on sssd side to have more details about why the password is
rejected ?
I'm using sssd-1.16.2-13.el7_6.8.x86_64 (RHEL 7U6).
I have the following configuration:
[domain/default]
cache_credentials = True
ldap_search_base = dc=XXX
krb5_realm = EXAMPLE.COM
krb5_server = kerberos.example.com
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldaps://YYY
ldap_tls_cacertdir = /etc/openldap/cacerts
[sssd]
services = nss, pam
config_file_version = 2
domains = default
[nss]
[pam]
[sudo]
[autofs]
[ssh]
[pac]
3 years, 9 months