|
Hi Simon "sss_cache –E" did the job. So everything works right now. Thanks a lot! Tibor Von: Dudas Tibor ABRAXAS
Hi Simon Now it works: [root@testldapclient01 log]# grep testldapclient sudo_debug.log Mar 24 09:39:54 sudo[16089] <- sudo_new_key_val_v1 @ ./key_val.c:56 := host=testldapclient01.as.mydomain.ch Mar 24 09:39:54 sudo[16089] user_info: host=testldapclient01.as.mydomain.ch Mar 24 09:39:54 sudo[16089] keep HOSTNAME=testldapclient01.as.mydomain.ch: YES Mar 24 09:39:54 sudo[16089] sudo_putenv: HOSTNAME=testldapclient01.as.mydomain.ch Mar 24 09:39:54 sudo[16089] netgroup ABX_server_test matches (testldapclient01.as.mydomain.ch|testldapclient01, , as.abraxas.ch): true @ netgr_matches()
./match.c:1228 I checked last time yesterday at 11am. It failed. Today I checked again at 9am. It works. Neither I nor anyone else changed sth. It seems that sth was cached. How can I disable caching
for testing purposes? Thanks a lot, Tibor Von: Dudas Tibor ABRAXAS
Hi Simon On the server: [root@testldap01 ~]# rpm -qa 389* 389-ds-base-1.4.4.17-1.module_el8+13163+e27841f7.x86_64 389-ds-base-libs-1.4.4.17-1.module_el8+13163+e27841f7.x86_64 On the client: [root@testldapclient01 log]# rpm -qa *ldap* openldap-clients-2.4.44-24.el7_9.x86_64 openldap-devel-2.4.44-24.el7_9.x86_64 python-ldap-2.4.15-2.el7.x86_64 openldap-2.4.44-24.el7_9.x86_64 nss-pam-ldapd-0.8.13-25.el7.x86_64 sssd-ldap-1.16.4-37.el7_8.3.x86_64 The sudo logs say according to
A.2. Troubleshooting sudo with SSSD and sudo Debugging Logs Red Hat Enterprise Linux 7 |
Red Hat Customer Portal: [root@testldapclient01 log]# grep testldapclient01 sudo_debug.log Mar 23 09:56:53 sudo[22331] <- sudo_new_key_val_v1 @ ./key_val.c:56 := host=testldapclient01.as.mydomain.ch Mar 23 09:56:53 sudo[22331] user_info: host=testldapclient01.as.mydomain.ch Mar 23 09:56:53 sudo[22331] keep HOSTNAME=testldapclient01.as.mydomain.ch: YES Mar 23 09:56:53 sudo[22331] sudo_putenv: HOSTNAME=testldapclient01.as.mydomain.ch Mar 23 09:56:53 sudo[22331] netgroup ABX_server_test matches (testldapclient01.as.mydomain.ch|testldapclient01, , as.mydomain.ch): false
@ netgr_matches() ./match.c:1228 Mar 23 09:56:53 sudo[22331] host testldapclient01 matches sudoers pattern +ABX_server_test: false @ hostname_matches() ./match.c:997 The client can resolve the referenced netgroup: [root@testldapclient01 log]# getent netgroup ABX_server_test ABX_server_test (testldapclient01,-,-) (testldapclient01.as.mydomain.ch,-,-) As I interpret the logs: 1.
The client sees, that the hostname it is installed on is testldapclient01.as.mydomain.ch. (sudo_putenv: HOSTNAME=testldapclient01.as.mydomain.ch) 2.
The client sees the referenced netgroup ABX_server_test with the server testldapclient01.as.mydomain.ch within. 3.
The client compares the system hostname with the hostname in the netgroup and finds no match. To exclude typos, I copied the return of the hostname command in the referenced netgroup of my Apache Studio. I do not understand, why
there is no match, as the hostnames are identical. If I set the hostname directly in the Apache Studio SUDOers group with the attribute sudoHost, it works. If I set +ABX_server_test,
it fails. Further logs ·
Messages: Mar 23 09:56:38 testldapclient01 sssd[be[LDAP]]: Starting up Mar 23 09:56:38 testldapclient01 sssd[be[LDAP]]: Your configuration uses the autofs provider with schema
set to rfc2307 and default attribute mappings. The default map has changed in this release, please make sure the configuration matches the server attributes. The other logfiles contain no information regarding the hostname. I could solve the same issue with the sudoUser attribute, by renaming the netgroup. Renaming the netgroup for the sudoHost did not help. My netgroup entry is
Thanks a lot. If you need any more information or logs, please let me know. Sincerely,
Tibor Von: Simon Pichugin <spichugi@xxxxxxxxxx>
Hi Tibor, To give you more helpful advice, we'll need more info. What package versions do you use? Can you attach your server (access and error logs) and SSSD logs? Also, it'll be helpful to see your netgroup entry and other related configuration. Sincerely, Simon P.S. I'd recommend also asking on sssd-users@xxxxxxxxxxxxxxxxxxxxxx as they would have more experience with this kind of issue, AFAIK. On Tue, Mar 22, 2022 at 5:48 AM Dudas Tibor ABRAXAS <Tibor.Dudas@xxxxxxxxxx> wrote:
|
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
