?

Log in

No account? Create an account
Lord Yupa

February 2010

S M T W T F S
 123456
78910111213
14151617181920
21222324252627
28      
Powered by LiveJournal.com
Lord Yupa

LDAP + sudo == sysadmin happiness

Using the latest release of sudo, I was finally able to get sudo working with LDAP enabled on RHEL/CentOS 4. Previously, I had no trouble getting sudo working with LDAP on RHEL3 and RHEL5. However, when I added '--with-ldap' to the compile options on RHEL4, it completely broke sudo, preventing it from authenticating anything.

This is a huge win for us at work, because it makes handling sudo configurations significantly easier. Normally, you have to store the configuration in /etc/sudoers on every single box. With this, you can store your sudo configuration in LDAP, and have all of the sudo rules in a single centralized location. Update it once, and all configured machines will then pull it.

I've become a big fan of LDAP, and with sudo supporting it, I think that anyone using LDAP and not storing sudo information in LDAP is crazy.

Comments

You know, every time I try to do any research into LDAP, I run into a giant wall. All the descriptions are either too high-level (it's a directory service!) or too low-level (attribute formats), without any sort of medium-level bit. And that there doesn't seem to be any standard way to run these things. Grrr, so mostly LDAP just confuses me. :/

nscd?

Check nscd (Name Service Cache Daemon), if you haven't yet. It has a tendency to cache a lot of the things that get looked up via LDAP, especially user and group information.

If it's running, you can try shutting it off so all lookups will be repeated (increases traffic hitting LDAP server), or you can also potentially clear the local cache of a specific table, like nscd -i group or nscd -i passwd.

Re: nscd?

Darn, I was hoping that might do the trick. If I think of anything else, I'll let you know. I don't really use SuSE at all, though, so I'm not real familiar with it's quirks.

LDAP Confusion.

I know what you mean. I went through the same thing the first few times I looked at it.

A few things that helped me with it were:
  • Thinking of it fundamentally as a database. A slightly unusual database that isn't SQL related, is generally read significantly more frequently than it is written, but is still a database.

  • From a system administration perspective, seeing how common system files such as /etc/passwd and /etc/group map to LDAP, and also how some of the less common, but easily as useful system config files, like automountd/AutoFS configs and /etc/sudoers and also be
    mapped to LDAP.

  • From a user directory perspective, it can be interesting to see how users are stored, along with informaion about them. Using LDAP for a user directory is very common.

  • It's hierarchical or tree-like. There's an LDAP root (in most modern cases, based on a domain name), and everything else goes from that.

  • It is extremely extensible by defining new schemas. New schemas allow you to define new entries and attributes, giving you a level of flexibility not unlike what you get with XML. Writing LDAP schemas is definitely non-trivial, but it's what allows you to store arbitrary information in an LDAP database relatively easily (and in a fairly portable way).

Re: LDAP Confusion.

Tree-like: Why are trees useful for this sort of database?

Do you have an example of what an LDAP database looks like?
Another option is to put sudoers under revision control. Either have the change process push it out (if you need changes to be immediate cluster-wide), or have each node checkout (or check for changes) ever X amount of time.

So far, whenever anyone's suggested LDAP for me, I've ran across something intersecting my current knowledge, so I've never taken the time to learn it.