Re: Netrgoups referenced in the SUDOers Group do not work

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Simon

 

"sss_cache –E" did the job.

 

So everything works right now.

 

Thanks a lot!

Tibor

 

Von: Dudas Tibor ABRAXAS
Gesendet: Donnerstag, 24. März 2022 11:25
An: 'General discussion list for the 389 Directory server project.' <389-users@xxxxxxxxxxxxxxxxxxxxxxx>
Betreff: AW: [389-users] Re: Netrgoups referenced in the SUDOers Group do not work

 

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
Gesendet: Mittwoch, 23. März 2022 11:00
An: General discussion list for the 389 Directory server project. <389-users@xxxxxxxxxxxxxxxxxxxxxxx>
Betreff: AW: [389-users] Re: Netrgoups referenced in the SUDOers Group do not work

 

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>
Gesendet: Mittwoch, 23. März 2022 00:32
An: General discussion list for the 389 Directory server project. <389-users@xxxxxxxxxxxxxxxxxxxxxxx>
Betreff: [389-users] Re: Netrgoups referenced in the SUDOers Group do not work

 

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:

Hi

 

My SUDOers group works with a dedicated sudoUser given, but not if I reference a Netgroup with the User given there.

Same for sudoHost.

 

Works not:

 

Works:

 

The netgroups can be resolved on the 389ds client, though:

[root@testldapclient01 ~]# getent netgroup ABX_user_test

ABX_user_test         ( ,axtsc,)

 

[root@testldapclient01 ~]# getent netgroup ABX_server_test

ABX_server_test       (testldapclient01,-,-) (testldapclient01.mydomain.com,-,-)

 

Changes in the SUDOers Group work only with some delay. Restart of sssd and relogin does not help. So it is a bit clumsy to test. Any help is highly appreciated.

 

Thanks, Tibor

 

 

_______________________________________________
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

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

[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux