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
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@xxxxxxx> wrote:
> On 18 Jul 2019, at 02:56, Abhisheyk Deb <abhisheykdeb@xxxxxxxxx> 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@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
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
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
_______________________________________________ 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