Justin Ryan wrote:

On Mon, Sep 15, 2008 at 5:37 PM, Nick Rathkenick.rathke@gmail.com wrote:

...

HI,

I have what I hope is an easy question ( and I hope this is the right place to post this ).

I have a situation where we are using openldap and a large number of users who also have local root level access to their own workstations.

Is there a way in ldap to allow root access without letting them su to another user ? Is there some ACL that I can put into place that would prevent this ?

You want the root account to be stored in LDAP, or to give some people access to sudo, but only to root?

Once you give away root, usually all bets are off, but you might find that SElinux or AppArmor can help with this, if you control sudo's behaviour, or somesuch.

You can configure any authorization you want based on some attributes in LDAP, but you need some software to implement that - libnss_ldap doesn't do that for you. ;)

All of the above is true. Once you give someone root access, whether their credentials came from LDAP, local files, NIS, or wherever is totally irrelevant. As such, the original question (can I compartmentalize superuser access) really has nothing to do with LDAP.

PS - I hope you are using something more secure than LDAP to store your secrets, like Kerberos, esp if you are granting root access. Once you're mucking with LDAP, KRB5 is not much trouble at all and available trouble-free on most GNU/Linux distros which support LDAP.

That's a pretty empty statement. "More secure than LDAP" creates the false implication that there is something inherently insecure about LDAP storage. In fact anything stored in LDAP is as secure as you choose to make it. And of course, there are plenty of sites out there running Kerberos using LDAP as the data store of their KDC.

Facts are good. FUD is not.

Justin Ryan wrote:

On Mon, Sep 15, 2008 at 9:43 PM, Howard Chuhyc@symas.com wrote:

...

That's a pretty empty statement. "More secure than LDAP" creates the false implication that there is something inherently insecure about LDAP storage. In fact anything stored in LDAP is as secure as you choose to make it. And of course, there are plenty of sites out there running Kerberos using LDAP as the data store of their KDC.

Using LDAP as the data store for your KDC reduces its' security.

To call such a statement empty and FUDly is pretty rude - it's fact.

Utter nonsense. You're spouting FUD, and that's the fact.

LDAP is a directory, it's designed for tracking information about things. It can store secrets, but it isn't designed, like Kerberos, to carefully control access to secrets. If your Kerberos secrets are stored in LDAP, you are losing some of what Kerberos gives you.

OpenLDAP has far finer-grained access control than any KDC. None of the KDC's data or methods are lost when using LDAP as the data store. If you believe a KDC that uses OpenLDAP as its data store is inherently less secure than using some other database mechanism, you simply don't understand how to configure OpenLDAP.

If you're such an expert on what LDAP is designed for, and the security requirements of a Kerberos KDC, please enumerate for us what security features you believe are missing?

From the KDC's perspective, there is no functional difference between a Heimdal KDC backed by slapd on ldapi:// vs the KDC backed by its own BerkeleyDB database. On the other hand, you gain the ability to perform secure, reliable, transparent replication of the credential store to other KDCs. And you also can use ACLs to permit/deny access to any elements of the KDC data, down to the individual value if necessary. The ACL mechanism in Heimdal itself is quite primitive in comparison.

"Justin Ryan" justizin@vongogo.org writes:

Using LDAP as the data store for your KDC reduces its' security.

I respect that the OpenLDAP community works hard that OpenLDAP is a secure solution for centralized authentication on its' own, but respectfully, it would scare me if the OpenLDAP community was not aware that LDAP was not intended to be an authentication store. LDAP's job is Authorization.

This is a really bad argument against using OpenLDAP as a KDC data store. LDAP has a very rich security and authorization model and has been used to store secure data, such as password hashes, for many years. The server is most certainly designed to support this. In fact, LDAP directories often store data that from a regulatory perspective is even more sensitive than passwords (such as social security numbers or HIPAA/FERPA data).

You can very legitimately argue that putting the KDC data store in an LDAP server increases the overall complexity of your Kerberos KDC. It does do that; it introduces many thousands of lines of additional code into your environment, and LDAP replication is a lot more complex (and hence more could go wrong) than simple full kprop replication, and probably more complex even than hprop incremental replication. In return for that additional complexity, you get a lot of additional features (including richer fine-grained access control and other security features), which may or may not be of interest to you. You have to make that tradeoff based on the needs of your site, and if none of the features of an LDAP backend are useful to you, it's always better to default to minimizing complexity.

But this is not because OpenLDAP is somehow insecure. It's only a general point about complexity in security systems, and a general principle that, all other things being equal, running fewer lines of code is better. The OpenLDAP code, line for line, is probably just as secure as your existing KDC code. (And I only don't say something stronger because I have a great deal of respect for the security design of Heimdal.)