4. Implementation

4.3.1.1. Adding Schemas

You need to make Jamm's schema file available, so copy the jamm.schema file in the Jamm distribution to /usr/local/etc/openldap/schema/jamm.schema. jamm.schema depends on cosine.schema and nis.schema. Add these lines to slapd.conf:

include                /usr/local/etc/openldap/schema/cosine.schema
include                /usr/local/etc/openldap/schema/nis.schema
include                /usr/local/etc/openldap/schema/jamm.schema

4.3.1.2. Adding a Database Definition

Next, you need to set up a database definition. You can do this with the following lines:

database      ldbm
directory     /usr/local/var/openldap-ldbm
suffix        "dc=myhosting,dc=example"

The database directive specifies the back-end type to use. You should use LDBM as the back-end database. The directory directive specifies the path to the LDBM database. The suffix directive specifies the root suffix for this database.

4.3.1.3. Creating the root User

The next few lines set up the "super user" or "root" account:

rootdn        "cn=Manager,dc=myhosting,dc=example"
rootpw        {SSHA}ra0sD47QP32ASAlaAhF8kgi+8Aflbgr7

The rootdn entry has complete access to the database, which is why the password is stored outside the actual database. The password in rootpw should always be stored in hashed format. Do not store the password in clear text. To convert the clear text password secret to a hashed format, use the slappasswd command:

% slappasswd
New password: secret
Re-enter new password: secret
{SSHA}ra0sD47QP32ASAlaAhF8kgi+8Aflbgr7

Take the output from slappasswd, and copy that into slapd.conf, as we did above.

4.3.1.4. Defining Indexes

To speed up searches, you should create indexes for commonly searched attributes. In OpenLDAP, you can not only choose which attributes to index, but you can choose which types of searches to index on. For example, if you index the field mail, you have the option of creating indexes for presence, equality, approximate, and/or substring searches. We want to create the following index policy:

• Create presence and equality indexes on objectClass.

• Create equality and substring indexes on mail and cn.

To implement this policy, add these lines to slapd.conf:

index   objectClass  pres,eq
index   mail,cn      eq,sub

4.3.1.5. Setting up Access Control

The last part in slapd.conf is the access control. You can define your own policy, be here's the one we've adopted and Jamm follows:

• The user can change any of their own attributes.

• Anyone in the postmaster group of the domain may change any user's attributes in their domain, including the password. This allows the postmaster to reset a users password if they forget it.

• Anonymous (non-authenticated) users may read all information, except the password attribute.

Access control statements are evaluated in order, so they should be defined from most specific to most general. Access to the password attribute, userPassword, is the most specific in our case, and hence it's specified first:

access to dn=".*,jvd=([^,]+),o=hosting,dc=myhosting,dc=example"
          attr=userPassword
        by self write
        by group/jammPostmaster/roleOccupant=\
            "cn=postmaster,jvd=$1,o=hosting,dc=myhosting,dc=example" write
        by anonymous auth
        by * none

Please note that the backslash in the above lines means that the line with the backslash and the following line are actually one. The lines are broken up here due to space concerns.

The access to line specifies what entries and attributes to which the following rules apply. The dn regular expression matches any entry in a domain of our hosting tree, and attr limits these rules to the userPassword attribute. Write access is granted to the user itself and anyone in the postmaster group. Anonymous users may only access this field when trying to authenticate. For all other cases, access is denied.

Next, all other attributes to entries in a domain's tree are specified:

access to dn=".*jvd=([^,]+),o=hosting,dc=myhosting,dc=example"
        by self write
        by group/jammPostmaster/roleOccupant=\
            "cn=postmaster,jvd=$1,o=hosting,dc=myhosting,dc=example" write
        by * read

Please note that the backslash in the above lines means that the line with the backslash and the following line are actually one. The lines are broken up here due to space concerns.

This access to line is very similar the previous one, except that there is no attr specification. Hence, this matches all other attributes other than userPassword. Again, write access is granted to the user and anyone in the postmaster group. Everyone is granted read access.

Finally, we provide read access to all other elements in the database:

access to *
        by * read

access to dn.regex=".*,jvd=([^,]+),o=hosting,dc=myhosting,dc=example"
          attr=userPassword
        by self write
        by group/jammPostmaster/roleOccupant.expand=\
            "cn=postmaster,jvd=$1,o=hosting,dc=myhosting,dc=example" write
        by anonymous auth
        by * none

access to dn.regex=".*jvd=([^,]+),o=hosting,dc=myhosting,dc=example"
        by self write
        by group/jammPostmaster/roleOccupant.expand=\
            "cn=postmaster,jvd=$1,o=hosting,dc=myhosting,dc=example" write
        by * read

access to *
        by * read

4.3.2.1. Creating the Base Directory

The first step is to create a base tree structure with our root node, the hosting organization, and an entry for the rootdn. Create a file called base.ldif with the following contents:

dn: dc=myhosting, dc=example
objectClass: top
objectClass: domain
domainComponent: myhosting

dn: cn=Manager, dc=myhosting, dc=example
objectClass: top
objectClass: organizationalRole
cn: Manager

dn: o=hosting, dc=myhosting, dc=example
objectClass: top
objectClass: organization
o: hosting

Now use ldapadd, binding as the root user, to add this LDIF:

$ ldapadd -x -D "cn=Manager,dc=myhosting,dc=example" -w secret -f base.ldif
adding new entry "dc=myhosting, dc=example"
adding new entry "cn=Manager, dc=myhosting, dc=example"
adding new entry "o=hosting, dc=myhosting, dc=example"

4.4.2.1. Procmail

Having Postfix use procmail for local delivery is easy. All you need to do is define the mailbox_command parameter in main.cf.

mailbox_command = /usr/bin/procmail

4.4.2.2. Configuring LDAP sources

You can easily define multiple LDAP sources. LDAP source parameters are documented in README_FILES/LDAP_README[15]. The parameter names follow the pattern of ldapsource_parameter. The LDAP source name is defined when it is first used. In main.cf, you'll need one LDAP source definition per each lookup.

domains_server_host = localhost
domains_search_base = o=hosting,dc=myhosting,dc=example
domains_query_filter = (&(objectClass=JammVirtualDomain)(jvd=%s)(accountActive=TRUE)(delete=FALSE))
domains_result_attribute = jvd
domains_bind = no
domains_scope = one

aliases_server_host = localhost
aliases_search_base = o=hosting,dc=myhosting,dc=example
aliases_query_filter = (&(objectClass=JammMailAlias)(mail=%s)(accountActive=TRUE))
aliases_result_attribute = maildrop
aliases_bind = no

accounts_server_host = localhost
accounts_search_base = o=hosting,dc=myhosting,dc=example
accounts_query_filter = (&(objectClass=JammMailAccount)(mail=%s)(accountActive=TRUE)(delete=FALSE))
accounts_result_attribute = mailbox
accounts_bind = no

accountsmap_server_host = localhost
accountsmap_search_base = o=hosting,dc=myhosting,dc=example
accountsmap_query_filter = (&(objectClass=JammMailAccount)(mail=%s)(accountActive=TRUE)(delete=FALSE))
accountsmap_result_attribute = mail
accountsmap_bind = no

4.4.2.3. The virtual alias maps

Now that the aliases and accountsmap LDAP sources are defined, we need to let Postfix know to use them. This is taken care of using the virtual_alias_maps parameter in main.cf

virtual_alias_maps = ldap:accountsmap, ldap:aliases

4.4.2.4. The virtual accounts

Telling Postfix about the virtual accounts is a bit trickier than the aliases. This is due to the fact that we need to define a lot of extra information about the virtual mail storage.

For this example, we assume that there is a vmail Unix account created that has a UID of 101, a GID of 101, and its home directory is /home/vmail. We will use the home directory of the vmail user as the place where we store our virtual mail repository.

virtual_transport = virtual
virtual_mailbox_base = /home/vmail/domains
virtual_mailbox_maps = ldap:accounts
virtual_mailbox_domains = ldap:domains
virtual_minimum_uid = 101
virtual_uid_maps = static:101
virtual_gid_maps = static:101

Most of the above is pretty straight forward, except for virtual_transport, virtual_minimum_uid, virtual_uid_maps, and virtual_gid_maps.

Postfix's modular nature allows you to specify different transports for different types of mail. The different transports are defined in the file /etc/postfix/master.cf. For virtual accounts, we want to use the virtual transport and set virtual_transport to specify this.

With the domains LDAP source defined, Postfix needs to be configured to use it. This is done by setting the virtual_mailbox_domains in main.cf to ldap:domains.

The Postfix documentation states "[virtual_minimum_uid] specifies a minimum UID that will be accepted as a return from a virtual_uid_maps lookup. Returned values less than this will be rejected, and the message will be deferred."[16] Since we have decided that all mail for virtual accounts will be stored using the vmail Unix account, we set the virtual_minimum_uid to be the UID of vmail. Also, we set the virtual_uid_maps and virtual_gid_maps to a special static map and hard code it to the UID and GID of the vmail user. All of the parameters shown here are fully documented in README_FILES/VIRTUAL_README[16] that comes with the Postfix source.