> On 18 Jul 2019, at 21:51, Abhisheyk Deb <abhisheyk...@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 <wbr...@suse.de> wrote: > > > > On 18 Jul 2019, at 02:56, Abhisheyk Deb <abhisheyk...@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-le...@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.org > > — > 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-le...@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.org > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@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.org — 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-le...@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.org
