sssd-users December 2020

sssd-users@lists.fedorahosted.org

13 participants
16 discussions

sssd/ldap new group membership and cache(s)
by Thomas HUMMEL 18 Dec '20

18 Dec '20

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

2 4

file provider with multiple kerberos realms
by Techie 18 Dec '20

18 Dec '20

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

2 3

sssd-krb5, krb5_ccachedir, DIR-cache-store...
by Jostein Fossheim 15 Dec '20

15 Dec '20

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.

4 5

Re: initgroups is taking longer with sssd-1.16.5-10.el7_9.5
by Sanjay Agrawal 15 Dec '20

15 Dec '20

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 6

Sporadic Issue When Searching Active Directory for a Valid User, "returned 0 results", Restarting SSSD Resolves
by J. Adam Craig 03 Dec '20

03 Dec '20

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_659770…> *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-p…>*

4 10

Re: sssd upgrade from 2.2.3-20 to 2.3.0-9 breaks sudo
by Alexey Tikhonov 02 Dec '20

02 Dec '20

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.fedo… > List Guidelines: > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorapro… > List Archives: > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fed… > >> 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.fedorahosted.… >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users December 2020