A common feature with mail environments is to use distribution groups that you could add and remove group members from. This is fairly common among organizations. For example, one might have hq@example.net and a list of members stored in LDAP. I wanted to have the ability to use mail distribution groups with my OpenLDAP infrastructure. LDAP group members could then easily be removed or added using ldapmodify or Apache Directory Studio.

Postfix

First, we need to tell Postfix about our LDAP distribution group config.

  1. Open /etc/postfix/main.cf
  2. Edit the virtual_alias_maps line and put ldap:/etc/postfix/ldap/ldap-groups.cf after the aliases definition.
    virtual_alias_maps = ldap:/etc/postfix/ldap/ldap-aliases.cf,ldap:/etc/postfix/ldap/ldap-groups.cf

    Since the LDAP server is local I do not need TLS in ldap-groups.cf. The following is sufficient.

ldap-groups.cf

server_host = ldap://localhost
search_base = ou=Groups,ou=Mail,dc=example,dc=net
version = 3
bind = no
query_filter = mail=%s
result_attribute = mailGroupMember

The group attrributes can be loaded using postfix-book schema

An LDAP mail distribution group could look like this.

dn: mail=hq@example.email,ou=Groups,ou=Mail,dc=example,dc=net
objectClass: top
objectClass: organizationalPerson
objectClass: PostfixBookMailAccount
mail: hq@example.email
mailEnabled: TRUE
mailUidNumber: 5000
mailGidNumber: 5000
cn: hq
sn: group
description: hq@example.email distribution group
mailGroupMember: user1@example.email
mailGroupMember: user2@example.email
mailGroupMember: user3@example.email
mailGroupMember: user4@example.email
mailGroupMember: user5@example.email
mailGroupMember: user6@example.email

So now, when an email is sent to hq@example.email that email will land in every group member's Inbox. Each group member will be defined by the mailGroupMember attribute.

Once you have this configured it is a good idea to tail the logs and send a test mail to the group. If everything is setup correctly the mail logs will show the email delivered to all group members.

Intro

S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard for public key encryption and signing of MIME data. S/MIME is on an IETF standards track and defined in a number of documents, most importantly RFCs 3369, 3370, 3850 and 3851. It was originally developed by RSA Data Security Inc. and the original specification used the IETF MIME specification with the de facto industry standard PKCS#7 secure message format. Change control to S/MIME has since been vested in the IETF and the specification is now layered on Cryptographic Message Syntax, an IETF specification that is identical in most respects with PKCS #7. S/MIME functionality is built into the majority of modern email software and interoperates between them.

S/MIME provides several cryptographic security services for electronic messaging communication. Some of these include

  • Authentication
  • Message integrity
  • Non-repudiation of origin (using digital signatures)
  • Privacy
  • Data security (using encryption)
  • S/MIME specifies the MIME type application/pkcs7-mime (smime-type "enveloped-data") for data enveloping (encrypting) where the whole (prepared) MIME entity to be enveloped is encrypted and packed into an object which subsequently is inserted into an application/pkcs7-mime MIME entity.

Obtain Email Certificate

COMODO offers free email certificates that are valid for 1 year. Their email certificate application only asks for some basic info including a revocation password in the event you need to revoke the certificate. Make sure to not use Google Chrome because Google has removed key generation from the popular web browser. Instead, I found using Firefox and presumably other web browsers works just fine. When completing the application using Firefox a drop-down dialog message will appear to confirm the certificate was successfully installed.

In Firefox Preferences -> Advanced -> Certificates select View Certificates to open the Certificate Manager. Under Your Certificates we will see the COMODO CA Limited email certificate. Select the email address right below the Certificate Name and then the Backup... button. The format will default to PKCS12. This is the format we want so it can be imported into a mail client such as Mozilla Thunderbird. This also works fine with Microsoft Outlook, Apple Mail as of 10.12 Sierra and probably others.

Thunderbird

With Thunderbird we can go into Account Settings -> Security.

Thunderbird S/MIME

When you click the Select button under Digital Signing the certificate will be found. If you have more than 1 certificate you should be able to select the one you want. Using the above settings will always make outgoing email messages signed with S/MIME.

We can verify an email message gets signed using our proud COMODO email certificate.

S/MIME signed

For the most part mail forwarding is not too common within my Infrastructure. With Sieve deployed in my environment using the ManageSieve protocol - mail users are able to easily setup a redirect to their preferred email address. This all works fine, but I also wanted to have the ability to setup mail forwarding directly within OpenLDAP.

Today I went ahead and pushed a commit for postfix-book.schema to include a mailForwardingAddress attribute. The existing PostfixBookMailForward objectClass contains our mailForwardingAddress attribute, respectively.

Forwarding

Assuming the schema is loaded into your environment, we can now tell Postfix to use LDAP mail forwarding.

How?

We can create ldap-forward.cf in /etc/postfix/ldap with something like

server_host = ldap://ldap.example.com/
search_base = ou=Mail,dc=example,dc=com
version = 3
bind = no
query_filter = (&(|(mailAlias=%s)(mail=%s))(objectClass=PostfixBookMailForward))
result_attribute = mailForwardingAddress

The query_filter will match a user's primary mail address or any mail aliases while the result_attribute is the forwarded email address.

The main.cf file should have the ldap-forward.cf file defined in virtual_alias_maps using proxy:ldap:/etc/postfix/ldap/ldap-forward.cf

virtual_alias_maps = ldap:/etc/postfix/ldap/ldap-aliases.cf,ldap:/etc/postfix/ldap/ldap-groups.cf proxy:ldap:/etc/postfix/ldap/ldap-forward.cf

To verify mail forwarding we can see that our forwarded email address does get returned when querying the primary or alias email address.

postmap -q me@example.email ldap:/etc/postfix/ldap/ldap-forward.cf
forwarduser@somewhere.email

Originally I researched a bit to get ideas and started writing a tool to add email user accounts in LDAP. That eventualy manfested into another separate script which creates email distribution groups. While one could just as easily use phpLDAPadmin, Apache Directory Studio and others by giving a .ldif file - I wanted something with less overhead, so I began to write a script that was specific to only adding LDAP email users and distribution groups interactively. In a nutshell these scripts use an LDIF template to help create the email user account or email distribution group on the fly. There is no need to ever manually edit a .ldif file since all you do is give some preliminary info and be done with it.

Email Users

Invoking the script as root or sudo will run through the following.

# ./add_ldap_mail_user.sh
First Name: Jane
Last Name: Doe
User Name [uid]: jane.doe

==================
 MAIL DOMAIN MENU
==================
domain1.com
domain2.com
domain3.com
domain4.email
domain5.email
domain6.email
domain7.me
domain8.net

Enter the domain to use for the mail account: domain4.email
creating mail account on domain4.email
adding new entry "uid=jane.doe,ou=Mail,dc=example,dc=com"

modifying entry "cn=vmail,ou=Groups,c=example,dc=com"

Successfully added Mail account

We can see our new email user gets added to an LDAP group. Note that this is a standard groupOfNames group and not an email distribution group.

Email Welcome Message

When an LDAP email user is added, a welcome email message is sent to the newly created user's Inbox. A default html and plain text email template are available to use. It is also easy to have your own customizable email templates.

Email Distribution Groups

Invoking the script will run through the following to create an email distribution group.

# ./add_ldap_mail_group.sh
Email Group Name: engineers

==================
 MAIL DOMAIN MENU
==================
domain1.com
domain2.com
domain3.com
domain4.email
domain5.email
domain6.email
domain7.me
domain8.net

Enter the domain to use for the mail group: domain4.email
creating mail group on domain4.email
adding new entry "cn=engineers,ou=Groups,ou=Mail,dc=example,dc=com"

Successfully added Email Distribution Group

Group members can be added using the mailGroupMember attribute provided by postfix-book.schema, respectively.

Contact

Comments, improvements, PRs and everything else should be directed on GitHub.

PRs welcome.

Intro

I stumbled across openssh-ldap-publickey while looking to setup SSH keys in LDAP and found the setup to be a breeze. The project provides a wrapper for OpenSSH to store public keys inside the OpenLDAP entry. Here I will document the steps I went through to get SSH key auth working with OpenLDAP.

LDAP SSH Steps

  1. First install some dependencies. Here are the Arch Linux package names and designated repos.

Update 09/22/17: For those on Arch Linux, I created an Arch PKGBUILD that can be used to install openssh-ldap-publickey and dependencies.

community/perl-net-ldap-server 0.43-3 [installed]
  Perl extension for LDAP server side protocol handling

aur/pear-net-ldap2 2.2.0-3 [installed] (1) (0.41)
  Object oriented interface for searching and manipulating LDAP-entries

aur/pear-net-ldap3 1.0.4-2 [installed] (1) (0.41)
  Object oriented interface for searching and manipulating LDAP-entries
  1. Load openssh-lpk-openldap.schema into OpenLDAP.

Inside sshd_config we have a couple of options

  1. Use authorized_keys and LDAP: AuthorizedKeysFile .ssh/authorized_keys
  2. Use only LDAP: AuthorizedKeysFile /dev/null

  3. Include these two lines
    AuthorizedKeysCommand /usr/local/bin/openssh-ldap-publickey
    AuthorizedKeysCommandUser nobody

LDAP SSH Users

A typical LDAP People record can now have a new objectClass ldapPublicKey and attribute sshPublicKey in which case a user's public key can be attached to the sshPublicKey attribute.