Home

Search Posts:

Archives

Login

January 2014

S M T W H F S
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31

Our maintenance ran out on the commercial Linux mail/groupware package (SuSE OpenExchange) which had all this stuff bundled, so it's time to restart from scratch. OpenXchange, the open source core of the SuSE offering (which is now owned by Netline) is the product of choice. This time our ldap database will also serve as the backend for a samba3 domain controller, which will be a ldap slave, and will authenticate OS X and unix machines. Sound like fun? You betcha. The goal here is really to provide a scalable centeralized authentication service and groupware portal that will work for various OSes and clients, effectively an open source (mostly, except for java) alternative to proprietary solutions like MS Server 2003.

Problems going in:

- I'm most familiar with Exim as an MTA. I'm competent with Sendmail. I know very little about Postfix except what I had to pick up to add some functionality to our previous solution
- OpenXchange has shitty documentation
- I'm more familiar with the Courier IMAP daemon, which is signifigantly more simple than Cyrus
- We need to migrate the mail spools from an existing IMAP server
- LDAP. I've been running LDAP already, but we've got a whole new set of requirements at this point, and I'm going to have to migrate over an existing LDAP database and add in new fields. Will I be able to populate them with what I need via a script? I think this will require something beyond bash, so it may be time to learn perl.

Given that, it's tempting to ask why the hell I've chosen this combo - a good question, but the answer is that a lot of the setup is required by openxchange. For the things I *do* have some say over (MTA and IMAP daemon), I felt it was better to use what SuSE themselves decided were the best options in their commercial product. Plus, at the end of the day, I'll know a lot more stuff.

Step 1: Choose a distribution.

There are a few valid options here:

Debian Stable (Sarge). I love Debian.
CentOS 3.x (RHEL 3 clone). CentOS is solid, and I already run this.
CentOS 4.x (RHEL 4 clone). No experience with 4, but presumably it'll be easy to pick up.
FreeBSD 5.4 RELEASE. I've used it in testing environments, never in production.

I opted for Debian, mainly because it's the easier to configure and maintain. There's a strong case to be made for CentOS 4 (3 I ruled out due to ancient versions of LDAP) since RHEL is pretty ubiquitous these days, but the lack of needed packages in that distribution means it would require more time to maintain. FreeBSD has all the packages, but of all the options I'm the least familiar with it, and the chance of stuff from ports breaking seems much higher than having breakage in Debian Stable or CentOS (since their packages are frozen and are only updated for critical bug fixes or security updates).

Step 1: Install Debian.

Easy. You should have no issues with this. Despite the grief it gets and the lack of any sort of GUI, Debian's installer is fast and effective. I always just do a minimal install and add what I need after the fact.

Step 2: Install Packages

There are quite a few things we'll specifically need here (along with all the dependencies that aptitude automatically manages), so we'll use aptitude to get this stuff. Note that you need to pull from "contrib" for at least some of these packages (and maybe non-free too, I always pull from both so...):

postfix cyrus21-imapd cyrus21-pop3 cyrus21-admin slapd ldap-utils gq libnss-ldap libpam-ldap xfree86-common xutils clamav-daemon amavisd-new sasl-bin xbase-clients

For Open-Xchange (more on this later) we'll need:

apache2-mpm-prefork apache2-prefork-dev libapache2-mod-php4 tomcat4 tomcat4-admin ant java-package

apache2-prefork-dev is needed to compile a mod_jk (needed for java, more on that later).

Debconf is going to ask a bunch of stuff, so answer to the best of your ability with the knowledge that you'll have to reconfigure everything at some point. Most of those packages are self explanatory, but gq you may not know - it's an X11 ldap browser. This is why we've got the X stuff in here as well, if you're curious.

Step 3 - Get stuff

Lots and lots of stuff needed here. You'll want to refer to this howto for the full list. This is a great resourse for getting OX itself up and running as well, but we'll need some of this stuff to configure LDAP initially - namely we want to get the schema from the openxchange tarball.

Step 3 - Configure slapd.conf

If you haven't done this before, this is a great chance to learn. I'm migrating from an existing ldap server so I'm able to slapcat on the old one and slapadd on the new one, modifying and adding fields as needed - but starting from scratch is beyond the scope of this entry and is best acheived by using other resources.

However as I mentioned above we'll need to add the schema from the openxchange tarball, which is in /open-xchange-0.8.0-2/system/setup/openxchange.schema. Copy that to your /etc/ldap/schema/ directory and add it (along with other needed schemas, such as samba.schema) in your slapd.conf file.

Step 3 - PAM / NSS

Ah this one's a lot of fun. Once you have a working ldap directory, it's time to get it to work on all this jazz.

Let's hit NSS first. debconf would've helped set up /etc/libnss-ldap.conf, but it's important that it's set up properly. Make sure the entries match your environment:

host 127.0.0.1
base dc=yourdomain,dc=tld
ldap_version 3
pam_min_uid 10

If you've got entries with "posixAccount" attributes in different LDAP leaves (I have such a leaf for samba machines, which for some reason are added with this attribute - maybe a bug in the idealx samba scripts, though), you can restrict which leaves are searched with the following entries:

nss_base_passwd ou=Users,
nss_base_shadow ou=Users,
nss_base_group ou=Groups,

Now, edit /etc/nsswitch.conf so it'll check against ldap:

passwd: ldap files
group: ldap files
shadow: ldap files

Ready for PAM? I knew you were. First up is /etc/pam_ldap.conf, which can be set up exactly the same as /etc/libnss-ldap.conf. Confused? You might well be, on most distributions these two things are configured from the same file, usually /etc/ldap.conf, but debian allows you to configure them independently. You could just symlink one to the other if you felt like it. I'm assuming this is done so you could (for example) have pam actually bind with admin rights (to change passwords and such) and have nss use anonymous lookups.

Once you have a working /etc/pam_ldap.conf, you need to set up pam itself to use ldap. Debian's pam.d contains 4 "common" config files referenced by other pam service entries, so setting those up should get any debian service working properly.

In /etc/pam.d/common-account:

account sufficient pam_ldap.so
account required pam_unix.so

It'll check LDAP first, and account info from that is sufficient. If not it'll fallover to the local account database.

There's also /etc/pam.d/common-auth:

auth sufficient pam_ldap.so
auth required pam_unix.so nullok_secure use_first_pass

Same basic deal, this is for authentication. I have no idea what "nullok_secure" is, but it's always been present in any "auth required pam_unix.so" statement I've seen, so we keep it. Pam tries to auth against ldap first in this setup, and if it fails it'll fall back to local unix accounts. The "use_first_pass" directive tells pam to just use the password that failed against ldap for local accounts, and if you don't have it you'll be prompted twice when trying to log on as a UNIX account (such as, most notably, root). You don't want that to happen.

Now /etc/pam.d/common-passwd:

password sufficient pam_ldap.so
password required pam_unix.so use_first_pass nullok obscure min=4 max=8 md5

Same basic muckity muck here.

I also edited /etc/pam.d/common-session:

session optional pam_ldap.so
session sufficient pam_unix.so

I've read that you don't need that, but what the hell. Let's go all out.

That should do it for PAM. Make sure you can log in from both local and LDAP accounts, and you can check to make sure stuff works with "getent passwd"

Postfix

Fun fun... let's get started.

Debian Postfix runs chrooted, which is a blessing and a curse. Aside from standard postfix stuff (debconf gets you started) we need to make it work with LDAP, saslauthd, amavis, clamav, and spamassasin, and we want it to provide smtp auth. A lot of stuff going on here.

Let's look at

New Comment

Author (required)

Email (required)

Url

Spam validation (required)
Enter the sum of 7 and 6:

Body (required)

Comments |Back