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

2. Load openssh-lpk-openldap.schema into OpenLDAP.

Inside sshd_config we have a couple of options

3. Use authorized_keys and LDAP: AuthorizedKeysFile .ssh/authorized_keys

4. Use only LDAP: AuthorizedKeysFile /dev/null

5. 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.

Intro

I have used Splunk for years and still use Splunk Enterprise at work and for my own use as part of the Free license group. With Splunk Free you have to keep your daily quota below 500 MB. Splunk Free is technically Splunk Enterprise, but with certain features disabled. In my own environment Splunk and Apache are external facing, so that means if someone knows the URL they can simply login without any kind of authentication since Splunk Free disables this. The following is a block of code that can be used with Apache 2.4.

Apache Config

Adjust /etc/httpd/conf/extra/splunk.conf to match your own environment as needed.

# LDAP auth
<proxy https://0.0.0.0:7000/*>
  Require all denied
  AuthName "This Splunk Restricted Area Requires LDAP Authentication"
  AuthType Basic
  AuthBasicProvider ldap
  AuthLDAPURL "ldap://127.0.0.1/ou=People,dc=domain,dc=net"
  Require ldap-group cn=splunk-staff,ou=Groups,dc=domain,dc=net
  AuthLDAPMaxSubGroupDepth 1
</proxy>

After reloading httpd we can see that visiting our Splunk page over SSL presents our login.

Intro

I wanted a quick way to monitor a remote Nagios host from a secondary Linux server in the event the primary Nagios instance became unavailabile for any number of reasons like httpd going down.

Check if host is alive

#!/usr/bin/env bash

# Monitor if remote service (ie httpd) is down
# and alert staff/admins. Useful in the event a Nagios
# instance is hosted on same http host

########
#Server
########
SERVER=''
HOST=''
PORT=80
SERVICE='httpd'
$(nc -z -w5 $SERVER $PORT)
result=$?

######
#Mail
######
MAILTO='admin@host'
MAILFROM='noreply@host'

###############################
#check remote host/port status
###############################
if [ "$result" != 0 ]; then

    mail -s "$SERVICE service on $HOST is not responding" -r "$MAILFROM" "$MAILTO"  <<END_OF_EMAIL
$SERVICE is not listening on $HOST port $PORT. Please check.
END_OF_EMAIL

fi

exit 0