[389-users] Re: LDAP Groups in sudoers file.

[William Brown]

> On 18 Jul 2019, at 21:51, Abhisheyk Deb  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  wrote:
> 
> 
> > On 18 Jul 2019, at 02:56, Abhisheyk Deb  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: 
> 

[389-users] Re: LDAP Groups in sudoers file.

[Abhisheyk Deb]

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  wrote:

>
>
> > On 18 Jul 2019, at 02:56, Abhisheyk Deb  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

[389-users] Re: LDAP Groups in sudoers file.

[William Brown]

> On 18 Jul 2019, at 02:56, Abhisheyk Deb  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] Re: LDAP Groups in sudoers file.

[Abhisheyk Deb]

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 
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.whit...@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 
> *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@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: 

[389-users] Re: LDAP Groups in sudoers file.

[Paul Whitney]

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.whit...@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 
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@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