SSH Auth and Access Control Against Zimbra LDAP

SSH Auth and access control against Zimbra LDAP

   KB 21707        Last updated on 2015-07-13  

(0 votes)


LDAP is a great tool for controling SSH access to the servers in your environment. It allows for single passwords as well as granular access controls so your teams can have appropriate access, all from the same directory you already use for your email server.

This method uses /etc/passswd for user/group information and queries ldap for password authentication. It also allows for access control by assigning employeeType attributes to LDAP accounts as is appropriate.

The basic Flow is this:

  1. Setup PAM_ldap on the server users will be logging into
  2. Configure PAM for login and sshd
  3. Create the user accounts on the server being logged into.
  4. Apply employeeType attributes in LDAP per the pam_filter you setup in your PAM configuration



The actual authentication portion of this is pretty straight forward. First, you need to install the appropriate PAM module, and openldap-clients.

$ Sudo yum -y install pam_ldap
$ sudo yum -y install openldap-clients

Next, you'll need to configure PAM. There are several components to deal with here, but the big ones will be: /etc/pam_ldap.conf /etc/pam.d/login /etc/pam.d/sshd


Also note: It might be a good idea to leave an ssh session logged into root open in case you make a mistake. pam config changes do not invalidate existing sessions, so that session could be a lifeline in case something goes sideways.


Things you will need for the pam_ldap.conf: Binddn - Usually uid=zimbra,cn=admins,cn=zimbra bindpw - on your ldap server, zmlocalconfig -s ldap_root_password ldap uro - ldap:// Base dn - dc=domain,dc=com

Example pam_ldap.conf file

# @(#)$Id: ldap.conf,v 1.38 2006/05/15 08:13:31 lukeh Exp $
# This is the configuration file for the LDAP nameservice
# switch library and the LDAP PAM module.
# The man page for this file is pam_ldap(5)
# PADL Software

# Your LDAP server. Must be resolvable without using LDAP.
# Multiple hosts may be specified, each separated by a
# space. How long nss_ldap takes to failover depends on
# whether your LDAP client library supports configurable
# network or connect timeouts (see bind_timelimit).

# The distinguished name of the search base.
base dc=domain,dc=com

# Another way to specify your LDAP server is to provide an
# uri with the server name. This allows to use
# Unix Domain Sockets to connect to a local LDAP Server.
#uri ldap://
#uri ldaps://
#uri ldapi://%2fvar%2frun%2fldapi_sock/
# Note: %2f encodes the '/' used as directory separator
uri ldap://

# The distinguished name to bind to the server with.
# Optional: default is to bind anonymously.
binddn uid=zimbra,cn=admins,cn=zimbra

# The credentials to bind with.
# Optional: default is no credential.
bindpw <yourldappassword>

# The port.
# Optional: default is 389.
port 389

# Search timelimit
timelimit 30

# Bind/connect timelimit
bind_timelimit 30

# Filter to AND with uid=%s
pam_filter &(|(employeeType=globaladmin)(employeeType=mailadmin))(zimbraAccountStatus=active)

# The user ID attribute (defaults to uid)
pam_login_attribute uid

# Use the OpenLDAP password change
# extended operation to update the password.
pam_password exop

# OpenLDAP SSL mechanism
# start_tls mechanism uses the normal LDAP port, LDAPS typically 636
#ssl start_tls
#ssl on

Pam.d configuration

Example /etc/pam.d/login file

auth        required
auth        sufficient
auth        sufficient shadow use_first_pass
auth        required
account     sufficient
account     sufficient
account     required
session	    required

example /etc/pam.d/sshd

auth        required
auth        sufficient
auth        sufficient shadow use_first_pass
auth        required
account     sufficient
account     sufficient
account     required
session	    required

Once you have this config in place, you just need to create your users, so they've got an entry in /etc/passwd, and on the authenticating server side, you're done!

LDAP Setup

Before these users can login, you need to make sure you have added the proper attributes to those users in the zimbra ldap. If you'll note this line in the pam_ldap.conf file: pam_filter employeeType=mailadmin

In this case, we're filtering only the users who have an employeeType = mailadmin.

employeeType is an attribute of the inetOrgPerson object class. It is multi-valued, so you can assign as many of these as you want, allowing for granular access control to the systems in your environment. Note, if you have more than one, you'll need to update your pam_filter accordingly in the pam_ldap.conf.


To do that, let's use ldap modify. First, create an ldif file on the ldap server: /tmp/employeeType.ldif

It should look something like this:

Example Ldif

dn: uid=username,ou=people,dc=domain,dc=com
changetype: modify
add: employeeType
employeeType: mailadmin

And to modify the user, do this as the zimbra user:

source ~/bin/zmshutil
ldapmodify -x -h -D $zimbra_ldap_userdn -w $zimbra_ldap_password -f /tmp/emptype.ldif

You should see it modify that user, but if you want to check, you can do a zmprov sa to look for accounts that match:

zmprov sa employeeType=mailadmin

Once you've gotten the employee type added to the uses you wish to have ssh access, and you've made sure to create those users on the server, you should be good to go.

You can test by trying to ssh in as one of the users you setup. You'll use just the username, and the password will be the same as they use to login to their mailbox.

Security Considerations

Unless you have restricted key-based authentication for these users, you'll want to make sure you take some steps to make sure a disabled or otherwise disallowed user can not login to your server using public keys. Since the ldap method uses the "auth" step of PAM, and ssh key auth bypasses the auth step, you'll want to kill a session before it starts if the user isn't allowed.

To do that, you'll need two things: 1. A crontask that runs an ldapsearch against ldap to get a list of users with the correct employee types and writes that to a file 2. An addition to the /etc/pam.d/sshd configuration file.

Note: You may need to create /etc/sshd/sshd.allow yourself.

Killing key-based authentication after revoing user access in LDAP

example crontab entry

* * * * * ldapsearch -h -D "uid=zimbra,cn=admins,cn=zimbra" -w <yourldappassword -LLL "(&(|(employeeType=mailadmin)(employeeType=globaladmin))(zimbraAccountStatus=active))" |grep "uid:" |awk '{ print $2 }' > /etc/sshd/sshd.allow && echo "zimbra" >> /etc/sshd/sshd.allow && echo "root" >> /etc/sshd/sshd.allow

This crontab entry gets a list of all users with the "mailadmin" employee type, the "global admin employee type" which are active accounts and writes their usernames to the file /etc/sshd/sshd.allow. It ALSO writes "root" and "zimbra" to the file, but you can add any other non-ldap users appropriate for your environment as well.

Secondly, you'll need to add this line to the TOP of your /etc/pam.d/sshd file:

example entry into /etc/pam.d/sshd

account        required item=user sense=allow file=/etc/sshd/sshd.allow onerr=succeed

This like makes a positive match in the sshd.allow file required for login. If for some reason this step throws an error, it defaults to a return as successful. If, however, you would prefer that auth fail if there's an error here, you can change onerr to fail.

Verified Against: Zimbra Collaboration 7.0, 6.0 Date Created: 04/16/2014
Article ID: Date Modified: 2015-07-13

Try Zimbra

Try Zimbra Collaboration with a 60-day free trial.
Get it now »

Want to get involved?

You can contribute in the Community, Wiki, Code, or development of Zimlets.
Find out more. »

Looking for a Video?

Visit our YouTube channel to get the latest webinars, technology news, product overviews, and so much more.
Go to the YouTube channel »

Jump to: navigation, search