> On 18 Jul 2019, at 21:51, Abhisheyk Deb <abhisheykdeb@xxxxxxxxx> 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@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 — 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
