Hi Paul,
Thank you for your reply, apparently the LDAP client was configured using
nslcd. We have a similar configuration file called /etc/nslcd.conf and a
parameter called nss_initgroups_ignoreusers which I have set to ALLLOCAL.
This can be useful in case of unavailability of the LDAP server, which is
what I want.
The value ALLLOCAL may be used. With that value nslcd builds a full list of
non-LDAP users on startup. This is what is written in the man page of
nslcd.conf. I have also restarted the nslcd service after the changed
configuration.
Plus I also changed the value of ALLLOCAL to an exact list of users, even
that did not help.
Even with all the changes, we are still getting a delay when doing sudo,
which means it may not be consulting this file at all.
Thank you
Abhishek Deb
On Wed, Jul 17, 2019 at 4:09 PM Paul Whitney <paul.whitney(a)chesapeake-it.com>
wrote:
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(a)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(a)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
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...