Setting up Linux, OpenLDAP, Samba, Netatalk, and CyrusIMAP
Joe Rhodes Consulting LLC
May 3, 2003
Be able to store user/group account information for a small, simple organization in one place and utilize that information in all server processes, such as the mail server, windows file services, and Mac file services.
What it looks like
User and group accounts are set up using the friendly interface of Directory Administrator (DA). Ideally, this should be the ONLY step for creating new users. Once created, other systems will use that information, such as Samba, Netatalk, and Cyrus. Home directories and maiboxes will be created automagically the first time the user logs in.
I am by no means an expert. I'm almost positive there are serious flaws with the way I'm setting things up, and I encourage people who know more to let me know about them. This is more of a journal by someone who's figuring this out and trying to document it so I can do it again than an "expert" telling you how it should be done. My principal concern is the security of my setup. In several instances there are passwords left in clear test in config files. I'm sure there are other wholes. BE CAREFULL and don't take my word on this as gospel.
RedHat Linux 9 (only because that's what I'm using.)
Directory Administrator version 1.3.5 (the RPM is nice)
You'll need the source code for the following because we have some patching/configuring to do!
OpenLDAP version 2.1.17 from www.openldap.org
BerkeleyDB version 4.1.25 (required version for OpenLDAP)
Samba version 2.2.8
Cyrus SASL 2.1.13
Cyrus IMAP 2.1.13
OpenSSL 0.9.6j (Note, NOT version 0.9.7)
1. You know how to configure and compile source code.
2. You're willing to really read the docs that I mention before proceeding. :)
3. You have a local network that you relatively trust.
4. That you're not working on some huge eneterprise-wide system, but just a lil' operation for ma and pa at the country store.
First, install the DA rpm. It is linked against the OpenLDAP 2.0 libraries that ship with RedHat 8/9. We're going to rip that out later and replace it with the most current version, but once we do that, the RPM of DA won't install. However, it does seem to work fine once we're done.
Fire up DA and make sure it works. Good? Good!
Practically everything here relies on Berkeley DB in some way, so we'll start with that. Be warned--this may foul up some other software packages that are linked with the 4.0 libaries that RedHat ships with. I'm sure there's a more intelligent way to do this, but I'm just not that intelligent. So with that...
Unistall the BerkeleyDB rpms that RedHat ships with. Ignore dependencies. You might want to try without ignoring first, just so you can see all the stuff that it thinks will break when you do this. Most of this I'm going to replace with my own custome-compiled stuff anyway.
rpm -e --nodeps db4
rpm -e --nodeps db4-devel
rpm -e --nodes db4-utils
Now, decompress the 4.1.25 source and change into that directory. Following the instructions in the ./doc folder will make the libraries, but I ran into one hitch later that causes problems. Here's what I used as my ./configure variables to make it work:
(in the ./build_unix directory)
env LDFLAGS="-lpthread" ../dist/configure --enable-posixmutexes --prefix=/usr
This seems to be a RedHat specific issue, but I haven't really tested it elsewhere.
Note that this will slap down the DB4 libs almost exactly where the RPM had put them. It also makes it much easier when compiling other apps. You don't have to specify where your DB libs are, since they are in a pretty standard place.
now do a "make" and "make install". Hooray, we're done!
Next we need to set up Cyrus SASL, since a number of other things depend on that. Unpack the source code and configure. There is excelent documentation in their ./doc directory. Read it carefully. Here's my config line:
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --with-saslauthd --enable-krb4=no --enable-plain --enable-login --with-ldap=/usr
I'm not using Kerberos, and I want to put the libraries right where the redhat RPM had them. The --enable-login, as I recall, is a unsupported option for older MS mail clients. Seems Microsoft couldn't support the normal method of logging in but had to change one little detail to break things. Gee, never heard that story before. You may or may not need it. In the past, I've needed it, and so I keep doing it. That's all I'll say.
Now make and make install.
I'm going to make use of the saslauthd daemon. This little guy acts as a proxy between my LDAP server and my client SASL applications (such as CyrusIMAP and sendmail). You'll need a config file, /etc/saslauthd.conf. Here's mine:
# If I start the LDAP server to also listen on a Unix socket, such as /var/openldap/socket
# or some such, I could probably change that line. Unix sockets, when running on the same
# machine are much more efficient than going through the loopback interface. Haven't
# tried it yet, so I don't know.
Then, before you can use any SASL applications that will use the saslauthd service, you have to make sure it's started. I use: "saslauthd -a ldap". This is probably a good candidate to put in a system start up file.
Ok, this is a BIG project with lots and LOTS of hairly little details. First thing you should do is go to http://www.openldap.org and read through ALL the documentation. The Admin guide is very helpfull. And don't be tempted to just read the QuickStart guide. Read the full one first, refer back to the QuickStart when you need to. Also, make sure to read the FAQ's. There is some real gold there.
I'll tell you how I set up mine, but this is by no means guaranteed to work. (For me or for you!) Unpack the OpenLDAP source and run the ./configure command. Here's mine:
./configure --prefix=/usr --sysconfdir=/etc --enable-crypt --enable-spasswd --enable-bdb
Again, read the documentation carefully. Also, you may want to read what ./configure --help has to say about things as well. There may be features in there that you're interested in.
Set up your /etc/openldap/slapd.conf file. There are a HUGE number of things that go into this file, and this document is not even going to come close to explaining them, so I won't even try. PLEASE read up on all the openldap documentation and faq. At the minimum, you should be reading the man page for slapd.conf. Again, here's mine. YMMV:
##NOTE--This comes from the Samba 2.2.8 source
#Note: This has some potentially bad consequences, but it got around an error I was
#getting when trying to use inetorgperson and person object classes in the same object.
#Technically, doing this breaks true LDAPv3 support. But it worked for me.
allow bind_v2 #DA seems to need this. Won't bind as LDAPv3.
loglevel 256 #Probably want to change this later when you know it's all working.
checkpoint 32 15 #You read the faq on www.openldap.org, right?
index cn,sn,uid pres,eq,approx,sub
index objectClass eq
index memberUid eq
index gidNumber eq
index userPassword eq
Of course, I've omitted all the comments that the OpenLDAP folks have sprinkled into their sample config file.
There's another file, called DB_CONFIG that belongs in the directory where OpenLDAP will store its data bases. In my case, this was /var/openldap-data. This controlls (and overrides) some of the database parameters used by BerkeleyDB, which OpenLDAP uses to store it's data in. Some of these settings will have profound impacts on the speed and crash/data loss resistance of your LDAP system. Please read the FAQ on www.openldap.org. Ther is an entry there by Howard Chu that is very valuable. For what it's worth, here's mine:
set_cachesize 0 52428800 0
This sets my DB cache size to about 50ish MB, which seems appropriate for my machine, which has 512 MB of RAM, but has to do lots of other stuff too.
At this point, you can fire it up using /usr/libexec/slapd. I'd suggest throwing the -d 256 flag at it for now so you can see all the fun diagnostic messages live as they happen. When things are all settled down and working, you might want to put this in a system start up file, without the -d 256 of course.
Now we have to set up some basic stuff in our empty, pristine directory. Thing like our organization's name, and some organizational units, like People, Groups, Mounts, etc. I put the basic stuff into a file I called base.ldif and addedd it using the ldapadd command. Here's my basic set up ldif file:
o: Joe Rhodes Consulting LLC
This does nothing more than describe my organization and create three containers for me to put things in: Mounts, People, and Group. You can, of course have as many containers as you want and arrange them in all kinds of fascinating tree structures. I'm just not that creative. It may be worth your while to do this if you have a complex structure and want to keep them seperate. Say, for instance, you have multiple departments or geographical offices.
Add the entires in the ldif file by using this command
ldapadd -x -D "cn=admin,dc=joerhodes,dc=com" -W -f base.ldif
It will prompt you for your password. Enter in the password that you entered in your slapd.conf file. In this case, "SuperDuperSecret". It is highly suggested that you add an admin entry to your directory so you can take the password out of your slapd.conf file. It IS kind of a security risk just hanging out there in plain text, don't you think?
Adding users and groups
Now things start to get easier. (Well, for the moment.) Open up DA and set up a connection to use your handy new LDAP directory. Running DA on the same machine, this looks like:
search base: dc=joerhodes,dc=com
If all goes well, you should connect to your LDAP directory. From here, it's just point and click to add users and groups. One thing to mention: add at least one group first. (DUH! Yeah, I really didn't figure this out right away... :)
I'd strongly recommend that you do NOT give normal users a valid login shell. You have the password for your LDAP directory liberally sprinkled about in several config files about your system. It's just not worth having someone pull a root-expoit on you.
One of my uderlying assumptions with this setup is that it's for normal mortal end users sitting at their PC or Mac workstation, trying to use Linux as a server. I'm assuming that people are only going to be accessing my server via a interface such as Samba, Netatalk, NFS, or CyrusIMAP. This is almost certainly not a good way to set up a system where power users are going to be working at the console. If this is your goal, you should be getting advice from someone MUCH smarter than I.
OK, I'm going to toally ditch out on explaining this and just take the easy way out. Check out this very well written How-to:
This will show you how to set up your nss_ldap and pam_ldap stuff as well. One thing I will add is the automatic creation of home directories. There are also tons of good docs on their site and others on who to set up Samba. Google is your friend.
I'm also very partial to a book that goes by the title, "SAMBA essentials for Windows Administrators" by Gary Wilson. It's published by Prentice Hall. It's red.
Another thing I'll shamelessly suggest: SWAT. Learn it. Live it. Love it. I would actually make this one of the first things you get working after you've installed samba. It's THAT good.
Compiling samba required a few options to the ./configure script. Here are mine:
./configure --with-smbmount --with-ldapsam --with-acl-support --with-winbind
--with-winbind-ldap-hack --with-syslog --with-pam
Perhaps the most important one is --with-ldapsam, wich allows samba to get its passwords from the LDAP directory instead of it's normal /etc/samba/private/secrets file. Also, the --with-pam is necessary for a little trick involving auto-creating home directories. I explain that just below.
Hey, look. It's just below. I added this to my /etc/pamd.d/system-auth:
session required /lib/security/$ISA/pam_mkhomedir.so skel=/etc/skel umask=0077
It is the first "session" line in that file. In /etc/skel, you can make a directory structure that you want every user to have initially. So, for example, I have a "My Documents" folder here. For more info, Google for "pam_mkhomedir".
When you have all this set up, you should be able to log in from a Windows client as a user in your Directory. It should make the home directory on the fly as needed, with all the goodies that you put in the /etc/skel directory showing up in each user's home. You should also be able to log in at the linux console and have the same thing happen. Neto!
Quick note to further impress upon you the cool factor of Directory Administrator. When you check the "This user particiaptes in a Samba Domain", DA will automagically set the smb passwords in your directory for you. Nice, eh?
As long as you use DA to set and change passwords, you'll be fine. If, however, you use some OTHER method for doing this, the passwords could get out of sync. Technically, Samba is still using it's own passwords. (It has to to support encrypted logins from Windows clients, which is about all they will do without a reg hack.) My suggestion is to just always use DA and not worry about it.
Need to fill this in more.
For now, follow the directions at http://netatalk.sourceforge.net Since Netatalk uses PAM, it should be able to use the users in the directory from the steps used above to set up PAM. Now ain't that just handy?
Also would love to add some sections about integrating Mac OS X clients into LDAP and Netatalk. Haven't gotten there yet.
I LOVE cyrus IMAP. It takes care of a number of issues--it's really fast, it's "sealed", so users don't need a valid unix account, the mailboxes are kept away from the user home directories so they don't accientally delete thier INBOX. It handles concurrent logins to the same account well. It's really nice. BUT, it's harder to administer in that you have to manually create and delete mailboxes.
This is yet another piece of software that's far to complex for me to even begin to explain how to use. Thank goodness they've got great documentation also. What I will tell you is how I patched it so that it will automatically create the user accounts on the fly.
BIG NOTE: This will allow e-mail INBOXes and other mailboxes to be created when a user logs in the first time. It does NOT, however, deal with deleting mailboxes for users that are deleted from the directory. Although they will no longer be able to check their mail, mail will still be delivered to their INBOXes. Deleting these is still a manual job. Look at the cyradm utility, or the web version. I hear the web-cyradm really kicks ass. Havent' tried it myself.
Getting the patches:
There are two patches to get. They are, strangely, not part of the Cyrus package. I found them on the e-mail lists: Here's links to them, including the names of the people to thank for this handy feature:
Allow for auto-creation of INBOX and sub-mailboxes:
Allow for auto-creation of sub-mailboxes even with altnamespace turned on:
Applying these are somewhat tricky, because they were designed for CyrusIMAP 2.1.10. The first one, for auto-creation of INBOXes is pretty simple. Just go through an change all the "2.1.10" to "2.1.13" in the patch itself. Apply the patch as follows (in the directory just above the individual source files--so you should see /blah/cyrus-imap-2.1.13 ):
patch -p0 < autocreate.patch (or whatever you named the file from the e-mail above.)
This worked fine for the 2.1.12 IMAP source, but gave me some errors for the 2.1.13 source when patching the lmtp source. I really don't care about that, since that is a patch to have the mailboxes autocreate when a message is posted to the account. I don't want this, since I'm presently not using LDAP mail routing policies, and this would allow any mail send to any account on my system to have an INBOX created for it if it didn't exist. Can you imagine how much fun spammers would have with a system like this? Instead I rely on the user to log in first for the mailboxes to be created. I think that's a reasonable thing, don't you? Thought you might.
Now, the other patch I apply is to be able to auto-create the folders (and sub-folders) even when the altnamespace option is turned on. I like this option, since it shows all the client's sub folders, such as sent, drafts, etc. as being in the same place and on the same level as the user's INBOX. (In actuality, all the folders are sub-folders of the INBOX, such as INBOX.sent, INBOX.drafts, and so on.) I use Apple's Mail in OS X, and things look much nicer when I use the altnamespace. Soooo.....
The patch doesn't apply when using the patch command, probably because it was designed for an older version of the source. But since the text of the patch is pretty simply, I just did a search for the first line that get's deleted (marked by the - sign). That line is "len = strlen ("INBOX.") + strlen (p);". According to the patch file, you delete the four lines with the - sign, and replace them with the bunch of lines that have the plus sign. Simple cut and paste wored for me. Save your changes.
Now we have a fully patched version of Cyrus IMAP. We do a ./configure, make, make install. My ./configure line:
Again, here I defer to the really good instructions inclueded in the ./doc directory on how set up the rest of Cyrus IMAP. About the only thing I need to bring up is my /etc/imapd.conf file, which as some changes to work with the autocreate on login:
admins: root cyrus
#You HAVE to have the autocreatequota set to something other than 0
#to have autocreate on login work. Positive numbers will set the quota
#to that number. Negative numbers mean no quota.
autocreatefolders: SUB: Sent|SUB: Drafts|SUB: Trash
TODO: Add infomation about using IMAPS/SSL.
There should actually be a lot more in here. I direct your attention to "man imapd.conf". Specifically, I currently have no provisions for encryption. Using saslauthd, the only available login mechanism is plaintext.
Digest-MD5 and the like are only availabe if you use sasldb, which defeats the "one place, one password" theory. There is a way of hacking the sasl library to use LDAP instead of /etc/sasldb, but I just haven't gotten it to work--yet. Instead, I'll just plan on encrypting the whole session via TLS/SSL, then block out the non-secure IMAP ports on my firewall, preventing non-ssl encyrpted sessions from the outside network. You, of course, understand why it is so important to NOT SEND PASSWORDS OVER THE INTERNET IN CLEAR TEXT, right? Thought so. Many say it's a bad idea to send them over ANY network. I'm not going to say otherwise.
Start up the ol' master process and see what happens.
You might also want to tail the /var/log/imapd.log file so you can see what's going on. If you followed the documentation that came with CyrusIMAP, you will have all ready modified your /etc/syslogd.conf file to do this kind of loggin. Log in with your favourite client and see what happens. Hopefully it worked.
AMaViS and SpamAssassin
TODO. Ohhhh... Lot's to do I'm sure.