Hi,
We have a ldap group called *ldapadmin *defined on our LDAP servers running 389 Directory Server.
On the LDAP Client side. We have the following line added in */etc/sudoers* *%ldapadmin ALL=(ALL:ALL) ALL*
We are able to login as a LDAP user which is part of the *ldapadmin *group and are able to get sudo privileges for that user by calling sudo before a command.
Now these LDAP Client machines also have a local admin user which has been added to their local /etc/sudoers file.
If we get our LDAP Servers down and try to do sudo when we are logged in as the local admin user, we are seeing a delay before sudo command can finish.
When we remove the line *%ldapadmin ALL=(ALL:ALL) ALL *from */etc/sudoers*, the slowdowns do not happen anymore when we try to do sudo as the local admin user.
That means every time we are trying to do sudo, it is reading the sudoers file and on parsing the file when it comes across the line *%ldapadmin ALL=(ALL:ALL) ALL*, it is not able to find this group since it is not a local group, but a group present on a LDAP Server which is currently unavailable.
My question is why sudo command is trying to do a lookup for *ldapadmin *group when it is ran by the local admin user? Is there any way to bypass this check, because our LDAPClients have the need to have a local admin user. Any help would be appreciated.
Thank you Abhishek Deb
The one thing I would look at is your /etc/sssd/sssd.conf file. Assuming you are configured for LDAP, you could exclude the the local admin account in the [nss] section with the "filter_users" setting.
Example:
[nss] filter_users = root,nagios,local_admin_acct
That should get SSSD to not look up the user in LDAPS and hopefully expedite your login. Again, assuming you are using SSSD.
Paul M. Whitney, RHCSA, CISSP Chesapeake IT Consulting, Inc. 2680 Tobacco Rd Chesapeake Beach, MD 20732
Work: 443-492-2872 Cell: 410.493.9448 Email: paul.whitney@chesapeake-it.commailto:paul.whitney@chesapeake-it.com CONFIDENTIALITY NOTICE The information contained in this facsimile or electronic message is confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this facsimile message to the intended recipient, you are hereby notified that any dissemination, or copying of this communication is strictly prohibited. If this message contains non-public personal information about any consumer or customer of the sender or intended recipient, you are further prohibited under penalty of law from using or disclosing the information to any third party by provisions of the federal Gramm-Leach-Bliley Act. If you have received this facsimile or electronic message in error, please immediately notify us by telephone and return or destroy the original message to assure that it is not read, copied, or distributed by others.
________________________________ From: Abhisheyk Deb abhisheykdeb@gmail.com Sent: Wednesday, July 17, 2019 1:56 PM To: General discussion list for the 389 Directory server project. Subject: [389-users] LDAP Groups in sudoers file.
Hi,
We have a ldap group called ldapadmin defined on our LDAP servers running 389 Directory Server.
On the LDAP Client side. We have the following line added in /etc/sudoers %ldapadmin ALL=(ALL:ALL) ALL
We are able to login as a LDAP user which is part of the ldapadmin group and are able to get sudo privileges for that user by calling sudo before a command.
Now these LDAP Client machines also have a local admin user which has been added to their local /etc/sudoers file.
If we get our LDAP Servers down and try to do sudo when we are logged in as the local admin user, we are seeing a delay before sudo command can finish.
When we remove the line %ldapadmin ALL=(ALL:ALL) ALL from /etc/sudoers, the slowdowns do not happen anymore when we try to do sudo as the local admin user.
That means every time we are trying to do sudo, it is reading the sudoers file and on parsing the file when it comes across the line %ldapadmin ALL=(ALL:ALL) ALL, it is not able to find this group since it is not a local group, but a group present on a LDAP Server which is currently unavailable.
My question is why sudo command is trying to do a lookup for ldapadmin group when it is ran by the local admin user? Is there any way to bypass this check, because our LDAPClients have the need to have a local admin user. Any help would be appreciated.
Thank you Abhishek Deb
On 18 Jul 2019, at 02:56, Abhisheyk Deb abhisheykdeb@gmail.com wrote:
Hi,
We have a ldap group called ldapadmin defined on our LDAP servers running 389 Directory Server.
On the LDAP Client side. We have the following line added in /etc/sudoers %ldapadmin ALL=(ALL:ALL) ALL
We are able to login as a LDAP user which is part of the ldapadmin group and are able to get sudo privileges for that user by calling sudo before a command.
Now these LDAP Client machines also have a local admin user which has been added to their local /etc/sudoers file.
If we get our LDAP Servers down and try to do sudo when we are logged in as the local admin user, we are seeing a delay before sudo command can finish.
This sounds like an issue with your client. Can you provide your /etc/nsswitch.conf file contents?
If you see timeouts like this, you could be using padl_ldap instead of SSSD which has no cache, and it "blocks". It could also because because you have the nsswitch lines in the wrong order. For example:
%groups files ldap VS %grous ldap files
If you have the first lie (files then ldap), it checks local /etc/group first, then ldap.
If you have the latter, it checks LDAP first, which will block causing the timeout, then on failure, will check local files.
So provide this file (/etc/nsswitch.conf) and I can advise more.
Hope that helps!
When we remove the line %ldapadmin ALL=(ALL:ALL) ALL from /etc/sudoers, the slowdowns do not happen anymore when we try to do sudo as the local admin user.
That means every time we are trying to do sudo, it is reading the sudoers file and on parsing the file when it comes across the line %ldapadmin ALL=(ALL:ALL) ALL, it is not able to find this group since it is not a local group, but a group present on a LDAP Server which is currently unavailable.
My question is why sudo command is trying to do a lookup for ldapadmin group when it is ran by the local admin user? Is there any way to bypass this check, because our LDAPClients have the need to have a local admin user. Any help would be appreciated.
Thank you Abhishek Deb
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.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.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
Hi,
This our current /etc/nsswitch file
passwd: files ldap shadow: files ldap group: files ldap #initgroups: files
#hosts: db files nisplus nis dns hosts: files dns myhostname
# Example - obey only what nisplus tells us... #services: nisplus [NOTFOUND=return] files #networks: nisplus [NOTFOUND=return] files #protocols: nisplus [NOTFOUND=return] files #rpc: nisplus [NOTFOUND=return] files #ethers: nisplus [NOTFOUND=return] files #netmasks: nisplus [NOTFOUND=return] files
bootparams: nisplus [NOTFOUND=return] files
ethers: files netmasks: files networks: files protocols: files rpc: files services: files
netgroup: files ldap
publickey: nisplus
automount: files ldap aliases: files nisplus sudoers: files ldap
As you can see from the following:
group: files ldap sudoers: files ldap
Local admin can get everything resolved because it has its data in /etc/group as well as /etc/sudoers
And according to the manpage of nsswitch.conf, if a query is successful against the first DB, then the default behavior is to return. But it is still contacting the ldap server for sudo configuration, even though what is in sudo satisfies it.
Thank you Abhishek Deb
On Thu, Jul 18, 2019 at 1:34 AM William Brown wbrown@suse.de wrote:
On 18 Jul 2019, at 02:56, Abhisheyk Deb abhisheykdeb@gmail.com wrote:
Hi,
We have a ldap group called ldapadmin defined on our LDAP servers
running 389 Directory Server.
On the LDAP Client side. We have the following line added in /etc/sudoers %ldapadmin ALL=(ALL:ALL) ALL
We are able to login as a LDAP user which is part of the ldapadmin group
and are able to get sudo privileges for that user by calling sudo before a command.
Now these LDAP Client machines also have a local admin user which has
been added to their local /etc/sudoers file.
If we get our LDAP Servers down and try to do sudo when we are logged in
as the local admin user, we are seeing a delay before sudo command can finish.
This sounds like an issue with your client. Can you provide your /etc/nsswitch.conf file contents?
If you see timeouts like this, you could be using padl_ldap instead of SSSD which has no cache, and it "blocks". It could also because because you have the nsswitch lines in the wrong order. For example:
%groups files ldap VS %grous ldap files
If you have the first lie (files then ldap), it checks local /etc/group first, then ldap.
If you have the latter, it checks LDAP first, which will block causing the timeout, then on failure, will check local files.
So provide this file (/etc/nsswitch.conf) and I can advise more.
Hope that helps!
When we remove the line %ldapadmin ALL=(ALL:ALL) ALL from
/etc/sudoers, the slowdowns do not happen anymore when we try to do sudo as the local admin user.
That means every time we are trying to do sudo, it is reading the
sudoers file and on parsing the file when it comes across the line %ldapadmin ALL=(ALL:ALL) ALL, it is not able to find this group since it is not a local group, but a group present on a LDAP Server which is currently unavailable.
My question is why sudo command is trying to do a lookup for ldapadmin
group when it is ran by the local admin user? Is there any way to bypass this check, because our LDAPClients have the need to have a local admin user. Any help would be appreciated.
Thank you Abhishek Deb
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.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.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.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.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
On 18 Jul 2019, at 21:51, Abhisheyk Deb abhisheykdeb@gmail.com wrote:
Hi,
This our current /etc/nsswitch file
passwd: files ldap shadow: files ldap group: files ldap #initgroups: files
#hosts: db files nisplus nis dns hosts: files dns myhostname
# Example - obey only what nisplus tells us... #services: nisplus [NOTFOUND=return] files #networks: nisplus [NOTFOUND=return] files #protocols: nisplus [NOTFOUND=return] files #rpc: nisplus [NOTFOUND=return] files #ethers: nisplus [NOTFOUND=return] files #netmasks: nisplus [NOTFOUND=return] files
bootparams: nisplus [NOTFOUND=return] files
ethers: files netmasks: files networks: files protocols: files rpc: files services: files
netgroup: files ldap
publickey: nisplus
automount: files ldap aliases: files nisplus sudoers: files ldap
As you can see from the following:
group: files ldap sudoers: files ldap
Local admin can get everything resolved because it has its data in /etc/group as well as /etc/sudoers
And according to the manpage of nsswitch.conf, if a query is successful against the first DB, then the default behavior is to return. But it is still contacting the ldap server for sudo configuration, even though what is in sudo satisfies it.
Unless you have sudo rules in LDAP (you probably don't), the *group* is from ldap, you don't need ldap there. So try:
sudoers: files
Also, you should highly consider moving to SSSD - the "ldap" nsswitch and pam modules are really unmaintained these days.
Hope that helps,
Thank you Abhishek Deb
On Thu, Jul 18, 2019 at 1:34 AM William Brown wbrown@suse.de wrote:
On 18 Jul 2019, at 02:56, Abhisheyk Deb abhisheykdeb@gmail.com wrote:
Hi,
We have a ldap group called ldapadmin defined on our LDAP servers running 389 Directory Server.
On the LDAP Client side. We have the following line added in /etc/sudoers %ldapadmin ALL=(ALL:ALL) ALL
We are able to login as a LDAP user which is part of the ldapadmin group and are able to get sudo privileges for that user by calling sudo before a command.
Now these LDAP Client machines also have a local admin user which has been added to their local /etc/sudoers file.
If we get our LDAP Servers down and try to do sudo when we are logged in as the local admin user, we are seeing a delay before sudo command can finish.
This sounds like an issue with your client. Can you provide your /etc/nsswitch.conf file contents?
If you see timeouts like this, you could be using padl_ldap instead of SSSD which has no cache, and it "blocks". It could also because because you have the nsswitch lines in the wrong order. For example:
%groups files ldap VS %grous ldap files
If you have the first lie (files then ldap), it checks local /etc/group first, then ldap.
If you have the latter, it checks LDAP first, which will block causing the timeout, then on failure, will check local files.
So provide this file (/etc/nsswitch.conf) and I can advise more.
Hope that helps!
When we remove the line %ldapadmin ALL=(ALL:ALL) ALL from /etc/sudoers, the slowdowns do not happen anymore when we try to do sudo as the local admin user.
That means every time we are trying to do sudo, it is reading the sudoers file and on parsing the file when it comes across the line %ldapadmin ALL=(ALL:ALL) ALL, it is not able to find this group since it is not a local group, but a group present on a LDAP Server which is currently unavailable.
My question is why sudo command is trying to do a lookup for ldapadmin group when it is ran by the local admin user? Is there any way to bypass this check, because our LDAPClients have the need to have a local admin user. Any help would be appreciated.
Thank you Abhishek Deb
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.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.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.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.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.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.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
389-users@lists.fedoraproject.org
-
Abhisheyk Deb -
Paul Whitney -
William Brown