sssd/ldap new group membership and cache(s)
by Thomas HUMMEL
Hello,
I'm using sssd-2.2.3 on CentOS 8.2.2004 with an ldap (actually the ldap
exposed by an Active Directory server) backend.
This works fine but I'm having a hard time trying to figure out how
different caches actually work. I've read about the different *cache*
directives in sssd.conf(5).
I'm trying to understand what exactly happens when I:
- add a group membership for a user in the ldap directory
- then test different combinations of 'id' or 'id <user>' commands
and opening or not of a new shell (via ssh) regarding the delay for the
new membership to appear (or not ?) on the client
# My setup :
- 2 domains are defined but only one is used :
domains = foo_home
- auth provider is ldap with the AD schema :
auth_provider = ldap
ldap_schema = AD
- initially, no *cache* directive is present
- on Centos 8.2 nsswitch is configured with sss first :
passwd: sss files systemd
group: sss files systemd
# My understanding is that (but I might be wrong):
1) there's caching of user/group resolutions somewhere else (glibc ?
shell ?) from sssd
2) running 'id' is different from running 'id <user>' (as with the
latter there is name resolution involved ?)
3) sssd.conf directives I might be interested in tweaking in my case are
the domain-scope ones below:
entry_cache_timeout
entry_cache_user_timeout
entry_cache_group_timeout
but mostly entry_cache_user_timeout
So I added, as a test,
entry_cache_user_timeout = 5
# What I experience
I'm starting with a new sssd instance without cache :
# sss_cache -E
# systemctl stop sssd
# sss_cache -E
# rm /var/lib/sss/db/*
# systemctl start sssd
Note: I'm not sure if sss_cache acts upon offline sssd
1) shell A, logged in as user foo : id | grep -i 'new_group' or id foo |
grep -i 'new_group' does not match anything
2) add 'foo' into 'new_group' on the ldap backend
3)
a) test 1
after 5 minutes:
- shell A : id foo | grep -i 'new_group' shows the new group
membership
- but shell A : id | grep -i 'new-group' still does not match
anything
b) test 2
user foo logs into shell B:
- in shell B : id | grep -i 'new_group' and id foo | grep -i
'new_group' *both* show the new membership
- in shell A : id | grep -i 'new_group' still does not show the
new membership, but id foo | grep -i 'new_group' does
Can you help me explain what exactly is going on and what cache(s)
is(are) involved in each case ?
Thanks for your help
--
Thomas HUMMEL
aa
3 years, 4 months
file provider with multiple kerberos realms
by Techie
Main goal is to authenticate against multiple Kerberos Realms, AD domains
without joining the Linux box to AD.
We have an AD forest with 2 trusted domains and as a result 2 kerberos
realms, 1 per domain. On RHEL5,6,7 I used pam_krb5 for authentication and
passwd/group files for the user store. This allowed me to authenticate
against AD for users in the passwd file that match the KBR5 principal. In
system-auth/password-auth I would stack pam entries for each KRB5 REALM
Parent: EXAMPLE.COM
Domain1: ADA.EXAMPLE.COM
Domain2:ADB.EXAMPLE.COM
passwd user: joe_doe
krb5 principal: joe_doe(a)ADA.EXAMPLE.COM
passwd user: joe_blow
krb5 principal: joe_blow(a)ADB.EXAMPLE.COM
system-auth
auth sufficient pam_krb5.so realm=ADA.EXAMPLE.COM use_first_pass
auth sufficient pam_krb5.so realm=ADB.EXAMPLE.COM use_first_pass
In this case either joe_doe or joe_blow can log in via AD credentials and
pam would iterate through the stacked pam_krb5 entries to locate the
matching krb5 principal
I am trying to replicate this on redhat enterprise linux 8. I am aware
pam_krb5 is not an option and that sssd is the default for this use case.
What I cannot figure out is how to authenticate against multiple Domains in
SSSD. If I define 1 domain in sssd.conf with id_provider = files. I can
authenticate fine against the single domain/kerberos5 realm.
If I add multiple domains, sssd does not iterate through them, it fails if
it does not find the user in the first domain.
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
domains = ADA.EXAMPLE.COM,ADB.EXAMPLE.COM
[pam]
#pam_local_domains = all
[domain/ADA.EXAMPLE.COM]
id_provider = files
auth_provider=krb5
krb5_server = adadc.ada.example.com
krb5_kpasswd = adadc.ada.example.com
krb5_realm = ADA.EXAMPLE.COM
dns_discovery_domain =ADA.EXAMPLE.COM
krb5_validate = false
[domain/ADB.EXAMPLE.COM
id_provider = files
auth_provider=krb5
krb5_server = adbdc.adb.example.com
krb5_kpasswd = adbdc.adb.example.com
krb5_realm =ADB.EXAMPLE.COM
dns_discovery_domain = ADB.EXAMPLE.COM
krb5_validate = false
Is what I am attempting possible without joining AD and using the provider
of AD? I would like to avoid this at all costs.
Thanks
3 years, 4 months
sssd-krb5, krb5_ccachedir, DIR-cache-store...
by Jostein Fossheim
We are working with several kerberos-REALMS and are trying to get our clients to store their kerberos tickets in a DIRECTORY. This seems to work nicely for clients not authenticating at login, with the following configuration set in /etc/krb5.conf.
...
[libdefaults]
...
default_ccache_name = DIR:/tmp/krb5cc_%{uid}
...
user@server:~$ klist
Ticket cache: DIR::/tmp/krb5cc_888/tkt
Default principal: user@REALM
Valid starting Expires Service principal
09/22/19 17:35:50 09/23/19 17:35:48 krbtgt/user@REALM
Each ticket is stored in a separate file.
For clients using sssd for login, I want to set up the same behavior. But when I attempt to login the system creates an "/tmp/krb5cc_${UiD}" - but here the directory don't get the excutable bit set (that is the directory get 0600-permission), and the login fails.
In the man-page from Debian-buster (sssd-version: 1.16.3), there are to settings that seems to regulate this behaviour :
krb5_ccachedir (string)
Directory to store credential caches. All the substitution sequences of krb5_ccname_template can be used here, too, except %d and %P. The directory is created as private and owned by the user, with permissions set to 0700.
Default: /tmp
krb5_ccname_template (string)
Location of the user's credential cache. Three credential cache types are currently supported: "FILE", "DIR" and "KEYRING:persistent". The cache can be specified either as TYPE:RESIDUAL, or as an absolute path, which implies the "FILE" type. In the template, the following sequences are substituted:
[...]
If the template ends with 'XXXXXX' mkstemp(3) is used to create a unique filename in a safe way.
When using KEYRING types, the only supported mechanism is "KEYRING:persistent:%U", which uses the Linux kernel keyring to store credentials on a per-UID basis. This is also the recommended choice, as it is the most secure and predictable method.
The default value for the credential cache name is sourced from the profile stored in the system wide krb5.conf configuration file in the [libdefaults] section. The option name is default_ccache_name. See krb5.conf(5)'s PARAMETER EXPANSION paragraph for additional information on the expansion format defined by krb5.conf.
NOTE: Please be aware that libkrb5 ccache expansion template from krb5.conf(5) uses different expansion sequences than SSSD.
Default: (from libkrb5)
...
I have tried to both set and unset, the two parameters in question like this:
krb5_ccachedir = /tmp/krb5cc_%U
krb5_ccname_template = DIR: %d
krb5_ccname_template = DIR:%d/krb5cc_%U_XXXXXX
But the configuration-options seems to be ignored, no matter what I do, and I have the same behavior: A non-executable directory is created and the user is unable to login.
If I set the +x bit on the directory manually as the root-user, everything works.
3 years, 4 months
Re: initgroups is taking longer with sssd-1.16.5-10.el7_9.5
by Sanjay Agrawal
resending
Sanjay Agrawal
On Wednesday, December 2, 2020, 03:41:36 PM EST, Sanjay Agrawal <sanjayagrawal(a)yahoo.com> wrote:
Hi,
we are seeing an issue with newer version of sssd with centos 7.9 sssd version 1.16.5-10.el7_9.5.x86_64, where Initgroups is taking much longer compared to
previous version. Can you please look into it. Following are details, including a sample program to reproduce the issue with old and new version.
Sample Program: get_user_groups.py
- it just call getgrouplist of a user supplied using libc
Old env -
OS Linux 3.10.0-1127.19.1.el7.x86_64 #1 SMP Wed Aug 26 11:48:49 BST 2020 x86_64 x86_64 x86_64 GNU/Linux
SSSD Version - 1.16.4-37.el7_8.4.x86_64
Sample log file - sssd_nss-old.log
Flamegraph - flamgraph_sssd_nss-old.svg
ID 879 'Initgroups by name' testuser1@example
starttime Tue Dec 1 18:36:42:092541 2020
endtime Tue Dec 1 18:36:42:124463 2020
lookup_time 0.031922 sec
New env
OS Linux 3.10.0-1160.6.1.el7.x86_64 #1 SMP Wed Nov 18 22:40:48 GMT 2020 x86_64 x86_64 x86_64 GNU/Linux
SSSD Version - 1.16.5-10.el7_9.5.x86_64
Sample log file - sssd_nss-new.log
Flamegraph - flamgraph_sssd_nss-new.svg
ID 776 'Initgroups by name' testuser1@example
starttime 2020-12-01 17:31:24:328419
endtime 2020-12-01 17:31:24:451778
lookup_time 0.123359 sec
It seem to be due to addtional .1 second taken during following two trace (from sssd_nss-new.log)
(2020-12-01 17:31:24:355458): [nss] [cache_req_done] (0x0400): CR #776: Finished: Success
(2020-12-01 17:31:24:451727): [nss] [sysdb_search_group_by_id] (0x0400): No such entry
(2020-12-01 17:31:24:451757): [nss] [nss_protocol_fill_initgr] (0x0080): Unable to find primary gid [2]: No such file or directory
It may be related to following change, which seems to ref to sysdb_search_group_by_id
nss: use real primary gid if the value is overriden · SSSD/sssd@80e6f71
|
|
|
| | |
|
|
|
| |
nss: use real primary gid if the value is overriden · SSSD/sssd@80e6f71
SYSDB_PRIMARY_GROUP_GIDNUM contains original primary group id from AD because any possible override may not be k...
|
|
|
Sanjay Agrawal
3 years, 4 months
Sporadic Issue When Searching Active Directory for a Valid User, "returned 0 results", Restarting SSSD Resolves
by J. Adam Craig
Hello!
I am currently troubleshooting a very mysterious and difficult to tack down
issue with SSSD running on RHEL/CentOS 7.x and 8.x (SSSD ver. 1.16.5
and 2.2.3). The EL 7.x and 8.x systems are attached to a Windows Active
Directory domain using 'adcli'. We used this guide (
https://access.redhat.com/solutions/2653771), with some minor tweaks
appropriate for our Active Directory environment and security requirements
to set this up.
The vast majority of the time, the configuration works as expected.
However, occasionally, we experience sporadic and temporary issues where
users attempting to authenticate using valid Active Directory credentials
(via SSH) are unable to login.
When the issue presents itself, if we leave an affected system alone and do
nothing, the issue will eventually self-correct and users are able to
authenticate as expected. We have also discovered that we can manually
"fix" the issue by either (1) restarting SSSD with 'sudo systemctl restart
sssd' or (2) by running a 'kdestroy'/'kinit' sequence as the 'root' user on
the affected system like so:
# kdestroy -A ; kinit -k 'MYSERVER$(a)MYDOMAIN.EXAMPLE.COM'
At times when the issue is occurring, we observe the following messages in
'/var/log/sssd/sssd_MYDOMAIN.example.com.log' (debug_level 9):
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[dp_get_account_info_handler] (0x0200): Got request for
[0x1][BE_REQ_USER][name=someuser(a)mydomain.example.com]
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]] [dp_attach_req] (0x0400):
DP Request [Account #6104]: New request. Flags [0x0001].
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]] [dp_attach_req] (0x0400):
Number of active DP request: 1
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]] [sss_domain_get_state]
(0x1000): Domain MYDOMAIN.example.com is Active
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]] [sss_domain_get_state]
(0x1000): Domain MYDOMAIN.example.com is Active
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]] [sdap_id_op_connect_step]
(0x4000): reusing cached connection
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sdap_search_user_next_base] (0x0400): Searching for users with base
[DC=MYDOMAIN,DC=example,DC=com]
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]] [sdap_print_server]
(0x2000): Searching 192.168.1.4:389
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
[(&(sAMAccountName=someuser)(objectclass=user)(sAMAccountName=*)(objectSID=*))][DC=MYDOMAIN,DC=example,DC=com].
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass]
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sAMAccountName]
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixUserPassword]
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber]
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber]
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos]
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixHomeDirectory]
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell]
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPrincipalName]
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [name]
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf]
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectGUID]
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectSID]
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [primaryGroupID]
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [whenChanged]
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged]
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires]
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl]
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs:
[userCertificate;binary]
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [mail]
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 26
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]] [sdap_op_add] (0x2000):
New operation 26 timeout 6
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]] [sdap_process_result]
(0x2000): Trace: sh[0x55ca2802d840], connected[1], ops[0x55ca28028ef0],
ldap[0x55ca27fe0610]
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]] [sdap_process_message]
(0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sdap_get_generic_op_finished] (0x0400): Search result: Referral(10),
0000202B: RefErr: DSID-0310074A, data 0, 1 access points
ref 1: 'MYDOMAIN.example.com'
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sdap_get_generic_ext_add_references] (0x1000): Additional References:
ldap://MYDOMAIN.example.com/DC=MYDOMAIN,DC=example,DC=com
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]] [sdap_op_destructor]
(0x2000): Operation 26 finished
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[generic_ext_search_handler] (0x4000): Request included referrals which
were ignored.
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[generic_ext_search_handler] (0x4000): Ref: ldap://
MYDOMAIN.example.com/DC=MYDOMAIN,DC=example,DC=com
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sdap_search_user_process] (0x0400): Search for users, returned 0 results.
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sdap_search_user_process] (0x2000): Retrieved total 0 users
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]] [sdap_id_op_done]
(0x4000): releasing operation connection
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]] [sysdb_search_by_name]
(0x0400): No such entry
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sysdb_cache_search_groups] (0x2000): Search groups with filter:
(&(objectCategory=group)(ghost=someuser(a)mydomain.example.com))
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[sysdb_cache_search_groups] (0x2000): No such entry
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]] [sysdb_delete_user]
(0x0400): Error: 2 (No such file or directory)
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]] [dp_req_done] (0x0400):
DP Request [Account #6104]: Request handler finished [0]: Success
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]] [_dp_req_recv] (0x0400):
DP Request [Account #6104]: Receiving request data.
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[dp_req_reply_list_success] (0x0400): DP Request [Account #6104]: Finished.
Success.
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]] [dp_req_reply_std]
(0x1000): DP Request [Account #6104]: Returning [Success]: 0,0,Success
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]]
[dp_table_value_destructor] (0x0400): Removing
[0:1:0x0001:1::MYDOMAIN.example.com:name=someuser@mydomain.example.com]
from reply table
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]] [dp_req_destructor]
(0x0400): DP Request [Account #6104]: Request removed.
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]] [dp_req_destructor]
(0x0400): Number of active DP request: 0
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]] [sdap_process_result]
(0x2000): Trace: sh[0x55ca2802d840], connected[1], ops[(nil)],
ldap[0x55ca27fe0610]
(2020-11-10 7:40:57): [be[MYDOMAIN.example.com]] [sdap_process_result]
(0x2000): Trace: end of ldap_result list
And the following corresponding messages in '/var/log/secure':
Nov 10 07:40:57 myserver sshd[755]: pam_unix(sshd:auth): check pass; user
unknown
Nov 10 07:40:57 myserver sshd[755]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.1.123
Nov 10 07:40:57 myserver sshd[755]: pam_sss(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.1.123
user=someuser
Nov 10 07:40:57 myserver sshd[755]: pam_sss(sshd:auth): received for user
someuser: 10 (User not known to the underlying authentication module)
Nov 10 07:40:59 myserver sshd[735]: error: PAM: User not known to the
underlying authentication module for illegal user someuser from
192.168.1.123
Nov 10 07:40:59 myserver sshd[735]: Failed keyboard-interactive/pam for
invalid user someuser from 192.168.1.123 port 53300 ssh2
Nov 10 07:40:59 myserver sshd[735]: Connection closed by 192.168.1.123 port
53300 [preauth]
The effective '/etc/sssd/sssd.conf' file is as follows:
[sssd]
domains = MYDOMAIN.example.com
config_file_version = 2
services = nss, pam
debug_level = 9
[domain/MYDOMAIN.example.com]
ad_domain = MYDOMAIN.example.com
krb5_realm = MYDOMAIN.EXAMPLE.COM
krb5_lifetime = 10h
subdomain_inherit = ignore_group_members, ldap_purge_cache_timeout
ignore_group_members = true
ldap_purge_cache_timeout = 0
realmd_tags = joined-with-adcli, manages-system
cache_credentials = false
id_provider = ad
krb5_store_password_if_offline = true
default_shell = /bin/bash
ldap_id_mapping = true
ldap_sasl_authid = MYSERVER$(a)MYDOMAIN.EXAMPLE.COM
ldap_use_tokengroups = true
use_fully_qualified_names = false
fallback_homedir = /home/%d/%u
access_provider = simple
simple_allow_groups = linux_admins
simple_allow_users = someuser, someuser2, someuser3
debug_level = 9
Running either of the following commands appears to correct the issue
(until it presents again at an unpredictable time):
# systemctl restart sssd
or
# kdestroy -A ; kinit -k 'MYSERVER$(a)MYDOMAIN.EXAMPLE.COM'
Any assistance or insight you can offer would be greatly appreciated. We
have run countless internet searches over recent weeks, as well as
consulted with Red Hat Support without breakthroughs, so I decided to take
this straight to the experts!
Best,
*J. Adam Craig*
Lead Unix Operating Systems Analyst
VCU Computer Center <https://www.ucc.vcu.edu/>
804.828.4886
jacraig(a)vcu.edu
<https://adminmicro2.questionpro.com/?t_340030260=J.%20Adam%20Craig&u_6597...>
*Don't be a phishing victim -- VCU and other reputable organisations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details,
visit **https://ts.vcu.edu/about-us/information-security/common-questions/what-is-phishing
<https://ts.vcu.edu/about-us/information-security/common-questions/what-is...>*
3 years, 4 months
Re: sssd upgrade from 2.2.3-20 to 2.3.0-9 breaks sudo
by Alexey Tikhonov
IIUC, socket activation should not work if service is in sssd.conf
If that's not the case in your setup, could you please open an upstream
issue?
On Mon, Nov 30, 2020 at 10:50 PM Mote, Todd <moter(a)austin.utexas.edu> wrote:
> We have an in-house created rpm that sets up everything needed for sssd,
> krb, the conf file, etc. due to having all the way from rhel6 to rhel 8 in
> our environment, and the rpm requires sssd >= 1.14 I think. RHEL 8
> installs sssd 2.2.3, sets up everything, adds all the files and all the
> paths for sudo to the cond files, etc., does the join, then at the end of
> the kickstart it does yum update and upgrades it to 2.3.0, and the system,
> after deployment, leaves sssd not working.
>
> This is how it looks just after deployment
>
> > systemctl status sssd-sudo
> ● sssd-sudo.service - SSSD Sudo Service responder
> Loaded: loaded (/usr/lib/systemd/system/sssd-sudo.service; indirect;
> vendor preset: disabled)
> Active: inactive (dead)
> Docs: man:sssd.conf(5)
> man:sssd-sudo(5)
>
> so seems to be disabled, but loaded?
>
> At this point, I can either downgrade to sssd 2.2.3, remove the db, and
> restart sssd, making no other changes, and sssd 2.2.3 loads and works as I
> expect it to
>
> Or
>
> I can edit sssd.conf and remove sudo as a service, remove the db, and
> restart sssd, making no other changes, and sssd 2.3.0 loads and works as I
> expect it to.
>
> Todd
>
>
> -----Original Message-----
> From: Alexey Tikhonov <atikhono(a)redhat.com>
> Sent: Monday, November 30, 2020 2:52 PM
> To: End-user discussions about the System Security Services Daemon <
> sssd-users(a)lists.fedorahosted.org>
> Subject: [SSSD-users] Re: sssd upgrade from 2.2.3-20 to 2.3.0-9 breaks sudo
>
> On Mon, Nov 30, 2020 at 9:37 PM Mote, Todd <moter(a)austin.utexas.edu>
> wrote:
> >
> > > Could you please set "debug_level = 9" in "[sudo]" section of
> /etc/sssd.conf, restart sssd and provide /var/log/sssd_sudo.log (sanitized
> if needed)?
> >
> > Here ya go.
>
> [sbus_dbus_request_name] (0x0020): Unable to request name on the system
> bus [3] This error code (3) stands for `DBUS_RELEASE_NAME_REPLY_NOT_OWNER `
> here.
> This is expected if you didn't disable systemd sssd-sudo service.
>
> Did you have it enabled when you upgraded?
>
>
> >
> > I did verify on a clean install that only removing "sudo" as a service
> from the sssd.conf file does in fact allow it to work again. Enabling the
> socket does not seem to be required.
> >
> > Todd
> >
> >
> > -----Original Message-----
> > From: Alexey Tikhonov <atikhono(a)redhat.com>
> > Sent: Monday, November 30, 2020 1:58 PM
> > To: End-user discussions about the System Security Services Daemon
> > <sssd-users(a)lists.fedorahosted.org>
> > Subject: [SSSD-users] Re: sssd upgrade from 2.2.3-20 to 2.3.0-9 breaks
> > sudo
> >
> > On Mon, Nov 30, 2020 at 8:43 PM Mote, Todd <moter(a)austin.utexas.edu>
> wrote:
> > >
> > > Hi all
> > >
> > >
> > >
> > > I updated my RHEL 8 test box today and got sssd-2.3.0-9.el8.x86_64 as
> an update from sssd-2.2.3-20.el8.x86_64. Prior to the upgrade everything
> worked fine. Immediately after upgrade sssd fails to restart the critical
> service [sudo], and fails to start sssd at all, as noted in journalctl -xe.
> >
> > Could you please set "debug_level = 9" in "[sudo]" section of
> /etc/sssd.conf, restart sssd and provide /var/log/sssd_sudo.log (sanitized
> if needed)?
> >
> > >
> > >
> > >
> > > Are there things that needs to be done to affect a successful upgrade
> from 2.2.3 to 2.3.0? a conf file change perhaps? I saw mentions of
> “required conf file changes” in other issues reported in github.
> > >
> > >
> > >
> > > Downgrading back to 2.2.3 and removing the database returns sssd to
> starting and working.
> > >
> > > Removing “sudo” as a service from sssd.conf allows sssd to start with
> 2.3.0-9 installed.
> > >
> > >
> > >
> > > I attempted to use “systemctl enable sssd-sudo” like the man page
> suggests and the result in the journal is “Dependency failed for SSSD Sudo
> Service responder socket.”
> > >
> > >
> > >
> > > I also noted this in the sssd-sudo man page: “It's important to
> > > note that on platforms where systemd is supported there's no need to
> > > add the "sudo" provider
> > >
> > > to the list of services, as it became optional. However,
> sssd-sudo.socket must be enabled instead.”
> > >
> > > having enabled the sockect and removed “sudo” from the list of
> services, it does seem to work and retrieve rules from AD for the user.
> > >
> > >
> > >
> > > Is all of this correct? Is removing “sudo” as a service the answer to
> this or is it just a workaround? If it is the solution, is there any
> documentation about changes to configurations from version to version like
> sudo no longer allowing the service to start if it’s explicitly listed as a
> service?
> > >
> > >
> > >
> > > Just trying to figure out the scope of what will need to change on my
> fleet. The evidence so far seems to point to just removing “sudo” as a
> service in sssd.conf. Is that enough? Should “systemctl enable sssd-sudo”
> be run as well?
> > >
> > >
> > >
> > > Thanks in advance for your insights.
> > >
> > >
> > >
> > > Todd
> > >
> > > _______________________________________________
> > > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
> > > unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> > > Fedora Code of Conduct:
> > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdo
> > > cs
> > > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=0
> > > 4%
> > > 7C01%7Cmoter%40austin.utexas.edu%7Cf01f8e8df12c460005a208d8956a3d92%
> > > 7C
> > > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637423630815484265%7CUnkn
> > > ow
> > > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> > > LC
> > > JXVCI6Mn0%3D%7C1000&sdata=oceNDHl05MPSDYn52tAb5Mnsqb0bnHKlAO1tpo
> > > aU
> > > hrE%3D&reserved=0 List Guidelines:
> > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffe
> > > do
> > > raproject.org%2Fwiki%2FMailing_list_guidelines&data=04%7C01%7Cmo
> > > te
> > > r%40austin.utexas.edu%7Cf01f8e8df12c460005a208d8956a3d92%7C31d7e2a5b
> > > dd
> > > 8414e9e97bea998ebdfe1%7C1%7C0%7C637423630815484265%7CUnknown%7CTWFpb
> > > GZ
> > > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> > > %3
> > > D%7C1000&sdata=WbMFjIprD%2BbYocMn0uoTgOscDL%2Fp4jlH7icPneGL3v8%3
> > > D&
> > > amp;reserved=0 List Archives:
> > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli
> > > st
> > > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahost
> > > ed
> > > .org&data=04%7C01%7Cmoter%40austin.utexas.edu%7Cf01f8e8df12c4600
> > > 05
> > > a208d8956a3d92%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C63742363
> > > 08
> > > 15484265%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> > > iL
> > > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Yl5fnjkNmK37oRoQFQhA1
> > > Sj
> > > XigQNO0orE4IY%2FRe%2FjgA%3D&reserved=0
> > _______________________________________________
> > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
> > unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> > Fedora Code of Conduct:
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
> > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=04%
> > 7C01%7Cmoter%40austin.utexas.edu%7C97c6c3a3314b4db7b1f908d89571dbb0%7C
> > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637423663534337090%7CUnknow
> > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> > JXVCI6Mn0%3D%7C1000&sdata=4cEksddCWG1FE2grSho5Rq1D8ozAvpYots4l5W1P
> > YZU%3D&reserved=0 List Guidelines:
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedo
> > raproject.org%2Fwiki%2FMailing_list_guidelines&data=04%7C01%7Cmote
> > r%40austin.utexas.edu%7C97c6c3a3314b4db7b1f908d89571dbb0%7C31d7e2a5bdd
> > 8414e9e97bea998ebdfe1%7C1%7C0%7C637423663534337090%7CUnknown%7CTWFpbGZ
> > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> > D%7C1000&sdata=B%2FMEGD4j2%2Ba9L0DJPhZVtAZqcff6lX5%2BqmwTCBLLEAw%3
> > D&reserved=0 List Archives:
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahosted
> > .org&data=04%7C01%7Cmoter%40austin.utexas.edu%7C97c6c3a3314b4db7b1
> > f908d89571dbb0%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C6374236635
> > 34347089%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=sH3ponuPgAATyTVWPnuJLkF
> > Z1aLkDfPpF2ViYV7ig2E%3D&reserved=0
> > >> This message is from an external sender. Learn more about why this <<
> > >> matters at https://links.utexas.edu/rtyclf. <<
> > _______________________________________________
> > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
> > unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> > Fedora Code of Conduct:
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
> > .fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=04%
> > 7C01%7Cmoter%40austin.utexas.edu%7C97c6c3a3314b4db7b1f908d89571dbb0%7C
> > 31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637423663534347089%7CUnknow
> > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> > JXVCI6Mn0%3D%7C1000&sdata=Y42vA1NdOaa5NAH3j3YanIsN5TAyKjMrNSsBH8OZ
> > Hn4%3D&reserved=0 List Guidelines:
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedo
> > raproject.org%2Fwiki%2FMailing_list_guidelines&data=04%7C01%7Cmote
> > r%40austin.utexas.edu%7C97c6c3a3314b4db7b1f908d89571dbb0%7C31d7e2a5bdd
> > 8414e9e97bea998ebdfe1%7C1%7C0%7C637423663534347089%7CUnknown%7CTWFpbGZ
> > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> > D%7C1000&sdata=NdyTXynsAzON%2B2bgwkLzn2vQ%2BuFXAYwVab7RBgEeHqE%3D&
> > amp;reserved=0 List Archives:
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> > s.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahosted
> > .org&data=04%7C01%7Cmoter%40austin.utexas.edu%7C97c6c3a3314b4db7b1
> > f908d89571dbb0%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C6374236635
> > 34347089%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=sH3ponuPgAATyTVWPnuJLkF
> > Z1aLkDfPpF2ViYV7ig2E%3D&reserved=0
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
> unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fe...
> List Guidelines:
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorap...
> List Archives:
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.f...
> >> This message is from an external sender. Learn more about why this <<
> >> matters at https://links.utexas.edu/rtyclf. <<
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
>
3 years, 4 months