Sudo in an Ldap environment

[Martin Simons]

Hi,

During the recent Cfengine course in LA Brian presented his "layered" approach, in which i.e. OS tasks were distinguished from Middle Ware.

I like the concept and I am working on a couple of bundles in a security and authorization layer. I encountered a nice article about the subject: Sudo using Ldap. On the other hand I read this warning unit_ldap.cf about using Ldap in a network for configuration tasks:

body common control
{
bundlesequence => { "ldap" , "followup"};
}

###################################################################################################
#  NOTE!! relying on LDAP or other network data without validation is EXTREMELY dangerous. 
#         You could destroy a system by assuming that the service will respond with a 
#         sensible result. Cfengine does not recommend reliance on network services in configuration.
###################################################################################################

So where should I go from here.

I like the Ldap solution very much and I don't see the problem where it comes to fetching the authorization details from a valid source like a centralized Dictionary over a secured channel.

Best regards,
Martin.

[Neil Watson]

On Tue, Mar 26, 2013 at 02:05:49AM -0700, Martin Simons wrote:
> # NOTE!! relying on LDAP or other network data without validation is EXTREMELY dangerous.
> # You could destroy a system by assuming that the service will respond with a
> # sensible result. Cfengine does not recommend reliance on network services in configuration.

In ideal settings Cfengine is configured so that the agent can repair
all of the host to its current policy without a network connection. Some
call this submarine mode. I believe the above warning points out that
the agent is less reliable if it requires external data. It's a warning
that you can ignore if you feel your reasons are valid and you accept
the risk.

--
Neil Watson
Linux/UNIX Consultant
http://watson-wilson.ca

[Brian Bennett]

I've used sudo-ldap for years. It works well with a few caveats.

1. Files should be listed before ldap in nsswitch.conf. This will allow the system to function without ldap. If ldap is listed first and is unavailable then the system will hang on the ldap timeout for each and every nsswitch lookup. This is a very painful situation, try to avoid it.

2. If you're using sudo-ldap you should not use TLS or SSL connections for ldap. There's an ordering issue between sudo-ldap and pam-ldap where ldap drops privileges to load the ssl code, then makes the connection and then is incapable of elevating user privileges upon success. The result is that sudo breaks entirely. If you need secure ldap connections do it through an stunnel wrapper.

I think the warning you encountered was referring to having CFEngine configuration data stored in ldap, which I would discourage also. But as far as using system authentication and authorization against ldap, I highly recommend it.

-- 

Brian

--
You received this message because you are subscribed to the Google Groups "help-cfengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to help-cfengin...@googlegroups.com.
To post to this group, send email to help-c...@googlegroups.com.
Visit this group at http://groups.google.com/group/help-cfengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Aleksey Tsalolikhin]

Would there be any impact to your production service if the supporting LDAP service was down? would anything break if sudo couldn't run, for example?

Aleksey

[Martin Simons]

Dear Aleksey,

 

Well no.

 

As a precaution there is aline like this in /etc/sudoers:

%adm ALL=NOPASSWD: ALL

 

The second fall back is the in LDAP you do not rely on one server only for the same reason you gave.

Like this:

URI ldaps://ldap1.webhuis.nl ldaps://ldap2.webhuis.nl

 

The issue that is left is the one raised by Brian. You should not use TLS / SSL because there is an ordering issue between sudo-ldap and pam-ldap. I am figuring out whether it is Cfengine that breaks ion the process or something else, matbe it is even distro related.

 

I would to allways have secure LDAP, which is obvious from my point of view.

 

Best regards,

Martin.

Op dinsdag 26 maart 2013 17:11:08 UTC+1 schreef atsaloli.tech het volgende:

[Brian Bennett]

This is why I recommend using stunnel. You can create a secure channel between the client systems and the ldap server, but both the client and server ldap configuration think they're using an unencrypted connection.

This isn't something that's distro dependent. It's a deep disagreement the OpenLDAP maintainers (who provide pam-ldap) and the sudo maintainers (who provide sudo-ldap). Each one emphatically states that the other is doing it wrong. I've had words with both sides and neither will budge. What we, the end users, are left with is either a broken system, an insecure system, or a hack. Given that situation, I highly recommend using stunnel to secure ldap connections.

CFEngine itself because it runs as root will be unaffected by an ldap outage. But that may not be the case for any applications running on the host.

--
Brian

[Neil Watson]

I have used stunnel in the past. It is easy to configure and use.
Cfengine can easily maintain it.

[Aleksey Tsalolikhin]

+1 for stunnel

--
You received this message because you are subscribed to the Google Groups "help-cfengine" group.

To unsubscribe from this group and stop receiving emails from it, send an email to help-cfengine+unsubscribe@googlegroups.com.

[Hans Spaans]

Reading this thread makes me wonder about a few things.

The first is that still advise is being given based on bugs from 2007-2009 and has an alternative for years now. Most distributions have implemented those alternatives and are now on the same level as commercial Unix vendors with LDAP. I really don't see any reason to use stunnel for this on Linux distributions.

The second this is the fallback what needs to happen when there is a LDAP-outage. This is mostly a policy decision with owner of the infrastructure and not primary a technical discussion to be honest. A policy that included where and how personal accounts and non-personal accounts are created and maintained.

--
Hans

Op dinsdag 26 maart 2013 19:51:15 UTC+1 schreef bahamat het volgende:

[Brian Bennett]

So are you saying this now works? Which side caved?

-- 

Brian

--