Authorization in Microservices Landscape

Overview

This article outlines a high-level design of authentication and authorization options in Azure per a typical SPA use case interacting with multiple microservices. Compares API gateway pattern versus a direct client-to-API communication in microservices environment.

Use Case

A user should be able to request the following information:

1. User profile via Azure Graph API.
2. User documents via SharePoint Online API.
3. Aggregated data from two other internal systems.

                +----------------------+
            +-> | Azure Graph API      |
            |   +----------------------+
+---------+ |   +----------------------+
| browser |-+-> | Azure SharePoint API |
+---------+ |   +----------------------+
            |   +----------------------+     +--------+
            +-> | App API              |---> | API #1 |
                +----------------------+     +--------+
  +---------------------------+       |      +--------+
  |Microsoft Identity Platform|       +----> | API #2 |
  +---------------------------+              +--------+

Convenient Remote Access with SSH Config

If you are working with a lot of remote ssh hosts it becomes hard to remember all that host specific information: username, ip address, identity file, non-standard port or local/remote port forwarding. ssh_config to rescue. Here is a sample to give you an idea (file ~/.ssh/config):

Compression yes
IdentityFile ~/.ssh/id_rsa
LogLevel ERROR
Port 22

Host h1
    HostName 192.168.91.57
    User master
    IdentityFile ~/.ssh/h1.pem

Host db1
    HostName usca45d1.example.com
    User pg
    LocalForward 5432 127.0.0.1:5432

The above configuration let me access those hosts simply by name, e.g.:

ssh h1
scp schema.sql db1:~/

How to manage Git or Mercurial repositories

Managing version control repositories can be a challenge in multi-user environment especially when simplification of user collaboration is your goal. There are usually two primary concerns while considering enterprise deployment for version control repositories: access control and safety of your data. Both are not directly addressed by version control itself, thus a sort of security facade is necessary.

How to create Jail in FreeBSD

Operating system virtualization is the most effective way to utilize your system resources, jails let you setup isolated mini-systems. Jails are explains well in handbook however, from practical standpoint of view, the presented material is incomplete. Here we will setup few scrips that follow handbook's 'Application of Jails' article and enhance with few missing features. Let note preliminary requirements:

1. Name: j0.dev.local
2. Ip Address: 192.168.10.41
3. Network Interface: em0

Rebuilding World and Kernel on FreeBSD

Building the world and kernel on FreeBSD is just few steps procedure. The Handbook explains everything in great details. Here is short version.

FreeBSD Binary/Security Updates

freebsd-update is a tool to fetch and update binary security patches for official releases. e.g. FreeBSD 9.0-RELEASE. Once you made fresh OS install this is the way to update your system quickly.

freebsd-update fetch
freebsd-update install

Note, this tool doesn't work if you build world/kernel from source.

How to setup HTTP Proxy in FreeBSD

The HTTP proxy is set through environment variable HTTP_PROXY. Environment variables can be controlled during user login. Assuming the proxy is proxy.somewhere.net:3128 ensure the following in /etc/login.conf:

:setenv=HTTP_PROXY=http\c//proxy.somewhere.net\c3128:\

Update login capability database:

cap_mkdb /etc/login.conf

Re-login and ensure it is properly set:

env | grep HTTP_PROXY

How to SU with no password in FreeBSD

You can allow user to switch to root account without password. You need to add user to wheel group:

pw usermod john -G wheel

and change pam policy (file /etc/pam.d/su):

#auth            requisite       pam_group.so            no_warn group=wheel root_only fail_safe ruser
auth            sufficient      pam_group.so            no_warn group=wheel root_only fail_safe ruser

It is necessary to re-login so new group membership take place. Issue the following command to check user group:

$ id
uid=1001(john) gid=1001(john) groups=1001(john),0(wheel)

Troubleshooting slapd error: too many open files

Debian testing comes with openldap (slapd package) version 2.4.28. I noticed that ldap clients start receiving error and cannot contact ldap service any more. While the slapd daemon was running I found a number of errors in syslog (file /var/log/syslog):

... ldap1 slapd[4894]: SASL [conn=1611] Failure: GSSAPI 
  Error: Unspecified GSS failure.  Minor code may 
  provide more information (Too many open files)
... ldap1 slapd[4894]: warning: cannot open 
  /etc/hosts.allow: Too many open files
... ldap1 slapd[4894]: warning: cannot open 
  /etc/hosts.deny: Too many open files
... ldap1 slapd[4894]: SASL [conn=1611] Failure: GSSAPI
  Error: Unspecified GSS failure.  Minor code may
  provide more information (Too many open files)

Take a look at slapd process max open files soft limit:

cat /proc/`pidof slapd`/limits

Check number of files open by slapd process:

pidof slapd | xargs lsof -a -p | wc -l

The slapd process must not exceed max open files soft limit. Take a look at files opened by slapd process:

pidof slapd | xargs lsof -a -p | tail

Here is a sample output that shows there are a number of deleted files... actually one file /var/tmp/ldap_103.

slapd   4894 openldap  117u   REG  0,197 3371 705975 
  /var/tmp/ldap_103 (deleted)
slapd   4894 openldap  118u   REG  0,197 3371 705975 
  /var/tmp/ldap_103 (deleted)
slapd   4894 openldap  119u   REG  0,197 3371 705975 
  /var/tmp/ldap_103 (deleted)

There is definitely a bug in slapd that cause max open files limit exceed.

Recycle Process

We can write a script that does a check and restart daemon if it reaches certain limit (file /usr/local/sbin/slapd-restart).

#!/bin/sh

# Restart slapd daemon if it has open more than 512 files
if [ `pidof slapd | xargs lsof -a -p | wc -l` -gt 512 ]
then
    /etc/init.d/slapd restart
fi

Let cron run this script hourly:

ln -s /usr/local/sbin/slapd-restart \
  /etc/cron.hourly/slapd-restart

If slapd process exceed max open files soft limit too quickly consider schedule cron job more frequently.

Mount /var/tmp in tmpfs

While slapd process creates small files in /var/tmp quite quickly I found reasonable to mount it with tmpfs (file /etc/fstab):

tmpfs /var/tmp tmpfs noatime,nodev,noexec,nosuid,size=1M 0 0

Restart slapd daemon so changes take place:

/etc/init.d/slapd stop
# Ensure the /var/tmp is empty
rm /var/tmp/ldap_103
mount /var/tmp
/etc/init.d/slapd start
# Ensure the /var/tmp mounted
df -h | grep /var/tmp

Ensure the /var/tmp mounted:

tmpfs           1.0M  4.0K 1020K   1% /var/tmp

Regularly take a look a /var/log/syslog if there are any errors reported.

Gnome Keyring: Location

Gnome keyring can automatically unlock passwords stored in the keyring. Gnome keyring include the following components: pkcs11, gpg, secrets, ssh. You can take a look at various passwords and keys stored by running (Alt + F2) seahorse.
Various keyrings are unlocked during user login. You can control which one by reviewing gnome startup application preferences, take a look by running gnome-session-properties.
The problem I faced with was related to the fact that keyring daemon place it runtime data into $HOME/.cache/keyring-* directory and over time there are quite a lot of them there. So while these data are session specific I would think it is most appropriate to store this information somewhere in temporary storage (e.g. /tmp) so it cleaned up. Fortunately you can define environment variable $XDG_RUNTIME_DIR that points to /tmp and that get it solved.

echo "export XDG_RUNTIME_DIR=/tmp" > \
    /etc/profile.d/gnome-keyring.sh

The keyring daemon properly manage file permission so it owned and readable by user only. Once you reboot your computer the system level profile will setup environment variable for you so keyring cache will be created out there.

How to share network connection with iptables

While working in isolated environment you might need to share your machine internet connection with other computers or virtual machines (e.g. host only network in VirtualBox). Ensure you have iptables installed.

apt-get install iptables

There are two thing we need to do: let kernel know that it is permitted to forward network traffic.

echo "sysctl net.ipv4.ip_forward=1" >> \
    /etc/sysctl.d/ip_forward.conf

and apply masquerading for the interface that we what to share (eth0), add the following line to /etc/rc.local:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

You have to restart your computer so the changes take place during the next system boot.

How to rewrite all to https in nginx

Here we are going redirect all http traffic to https with nginx. I suppose you already have nginx installed, if not have a look here. We will store SSL certificates in /etc/nginx/ssl directory.

cd /etc/nginx
mkdir ssl
openssl req -new -x509 -sha256 -days 9999 -nodes \
    -out ssl/cert.pem -keyout ssl/cert.key
chown -R www-data:www-data ssl
chmod -R 700 ssl

Here is nginx configuration:

upstream backend {
    server 127.0.0.1:8080;
}

server {
    listen  *:80;
    return 301 https://$host$request_uri;
    #if ( $scheme = "http" ) {
    #    rewrite  ^/(.*)$  https://$host/$1 permanent;
    #}
}

server {
    listen  *:443;

    ssl on;
    ssl_protocols TLSv1;
    ssl_certificate /etc/nginx/ssl/cert.pem;
    ssl_certificate_key /etc/nginx/ssl/cert.key;

    location / {
        proxy_pass http://backend;
    }
}

You have to reload nginx so the changes take place.

How to chroot SFTP (Secure File Transfer)

SFTP (SSH File Transfer Protocol) is a network protocol that provides file transfer functionality over reliable data stream. It has nothing related with old ftp protocol however it treated as a secure replacement. Here we are going to achieve the following:

1. Service root directory: /srv/sftp
2. Each user must have isolated sftp location, e.g. /srv/sftp/user1
3. User top level directory include directories: files, archive
4. User session is chrooted
5. User is limited to sftp only, no shell, no ssh access

If you have ssh installed, you have sftp. Just in case:

apt-get -y install ssh

SSH Configuration for SFTP

You need to ensure the sftp subsystem is enabled in ssh. We are going to use internal-sftp implementation, that is in-process ssh subsystem (file /etc/ssh/sshd_config):

#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp

Let use sftp group to identify users for sftp. Here is a matching rule for ssh, add it at the end of /etc/ssh/sshd_config file:

Match group sftp
    ChrootDirectory /srv/sftp/%u
    X11Forwarding no
    AllowTcpForwarding no
    MaxAuthTries 2
    ForceCommand internal-sftp

Restart ssh so the changes take place:

/etc/init.d/ssh restart

Users

Let create a security group for our sftp users:

groupadd sftp

Here is a script that does the rest (file sftp-add.sh).

#!/bin/bash

sftproot=/srv/sftp

genpasswd() {
    local l=$1
    [ "$l" == "" ] && l=20
    tr -dc A-Za-z0-9_ < /dev/urandom \
        | head -c ${l} | xargs
}

if [ -z $1 ]; then 
    echo "Usage $0 username"
    exit 1
fi

# 1. User is created with home directory set to /, 
# this is the directory sftp change once chroot.
# 2. User added to group sftp.
# 3. Do not create home directory.
# 4. User has no shell, ssh login impossible.
useradd -d / -G sftp -M -s /bin/false $1

echo "Auto generated password:"
genpasswd
passwd $1

mkdir -p $sftproot/$1/{files,archive}
# Chroot directory must be owned by root
chown root:$1 $sftproot/$1 
# User has read-only access
chmod -R 750 $sftproot/$1
# User owns everything below chroot directory
chown $1:$1 $sftproot/$1/*

Just invoke it this way:

./sftp-add.sh user1

Now you should be able use sftp.

How to chroot ntp in Debian

Here are few simple steps to chroot ntp in debian. Add the following to file /usr/local/sbin/chroot-ntp and execute (alternatively you can download script from bitbucket site here):

#!/bin/bash

/etc/init.d/ntp stop

rootfs=/var/chroot/ntp
mkdir -p $rootfs/{etc,var/lib/ntp,var/log}

mv /etc/ntp.conf $rootfs/etc
ln -s $rootfs/etc/ntp.conf /etc/ntp.conf

if [ -e /var/lib/ntp/ntp.drift ]; then
    mv /var/lib/ntp/ntp.drift $rootfs/var/lib/ntp
fi
ln -s $rootfs/var/lib/ntp/ntp.drift \
    /var/lib/ntp/ntp.drift
chown -R ntp:ntp $rootfs/var/lib/ntp

mv /var/log/ntpstats $rootfs/var/log
ln -s $rootfs/var/log/ntpstats /var/log/ntpstats
chown -R ntp:ntp $rootfs/var/log/ntpstats

sed -e "s,'-g','-4 -i /var/chroot/ntp -g'," \
    /etc/default/ntp > /tmp/x && \
    mv /tmp/x /etc/default/ntp

sed -e "s,restrict -6,#restrict -6," \
    -e "s,restrict ::1,#restrict ::1," \
    /etc/ntp.conf > /tmp/x && \
    mv /tmp/x /etc/ntp.conf

/etc/init.d/ntp start

Verify that ntp uses the chroot (file /etc/default/ntp):

NTPD_OPTS='-4 -i /var/chroot/ntp -g'

Exim4 SSL/TLS Configuration

Here we are going configure exim4 to use SSL/TLS for incoming connections:

1. First of all let create an exim4 certificate request (see here how to create a certificate authority):

   openssl req -newkey rsa:2048 -keyout exim.key -out exim.csr -days 3650 -nodes
   

2. Now let sign it with our certificate authority:

   openssl ca -out exim.crt -infiles exim.csr
   

3. Here we get two important files: exim.key (that is private key) and exim.crt (x509 certificate file). Let copy them to /etc/exim4
4. Secure certificates:

   chown root:Debian-exim exim.key exim.crt
   chmod g=r,o= exim.key exim.crt
   

5. Enable exim4 daemon listening options for ports 25 and 465 (file /etc/default/exim4):

   SMTPLISTENEROPTIONS='-oX 465:25 -oP /var/run/exim4/exim.pid'
   

6. Turn on SSL/TLS option (new file /etc/exim4/conf.d/main/00_exim4-localmacros):

   MAIN_TLS_ENABLE = true
   

7. Restart exim4 and have a look at log file when you send a test message.

   /etc/init.d/exim4 restart
   echo test | mail -s "ssl/tls test" root@dev.local
   

   Here is what you will see in log file (/var/log/exim4/mainlog):

   ... P=esmtps X=TLS1.0:RSA_AES_256_CBC_SHA1:32 ...
   

   If for some reason you can not see esmtps message in log file it most likely it doesn't use SSL/TLS for local delivery, try from remote machine.

Alternative Certificate Location

You can specify any location for ssl/tls certificate (file /etc/exim4/conf.d/main/00_exim4-localmacros):

MAIN_TLS_CERTIFICATE=/etc/ssl/certs/mail.dev.local-cert.pem
MAIN_TLS_PRIVATEKEY=/etc/ssl/private/mail.dev.local-key.pem

This is useful when you host both SMTP and IMAP services on the same host. Note, group Debian-exim must have read access to both files.

Apache Basic Authentication over SSL with PAM Kerberos/LDAP

Suppose you already have a web site serving multiple subversion repositories over SSL (see here) and you would like add security on top of that, namely use Kerberos for authentication and LDAP for authorization. Before we proceed please ensure your machine is capable to authenticate against Kerberos/LDAP (see here). I will assume you saw the following:

• Serving Multiple SVN Repositories with Apache (see here)
• Debian OpenLDAP client with Kerberos (see here)

Dovecot with Kerberos Authentication

Dovecot authentication/authorization consists of two important parts: passdb and userdb; passdb is used to confirm user credentials are valid for access, while userdb determines how authenticated user is mapped to uid/gid (this is necessary since mail box is on file system).

In this post we take a look at Dovecot configuration when Kerberos is used for passdb role. We also take a look at few possibilities for userdb implementation.

Before we proceed with setup (let assume our client machine name is mail1.dev.local) you need to setup the following:

• Kerberos Client (look here).

Once the basic installation of the above is complete, here we go: Add imap service principal:

kadmin -p admin -q "addprinc -randkey imap/mail1.dev.local"

kadmin -p admin -q "ktadd imap/mail1.dev.local"

Dovecot V1.x Configuration

1. Configure dovecot to use gssapi for authentication (file /etc/dovecot/dovecot.conf):

   auth default {
     #mechanisms = plain
     mechanisms = gssapi
   }
   

If you want permit users to authenticate to dovecot using password (vs using transparent kerberos authentication via gssapi) than plain authentication mechanism must remain.
2. Restart dovecot:

   /etc/init.d/dovecot restart
   

Dovecot V2.0 Configuration

1. Install dovecot gssapi package:

   apt-get install dovecot-gssapi
   

2. Group dovecot need to have read permission on kerberos keytab file (/etc/krb5.keytab).

   chgrp dovecot /etc/krb5.keytab
   chmod g+r /etc/krb5.keytab
   

3. Ensure the following settings in authentication configuration (file /etc/dovecot/conf.d/10-auth.conf):

   # FQDN for the mail server
   auth_gssapi_hostname = mail1.dev.local
   
   # Locaction of keytab file
   auth_krb5_keytab = /etc/krb5.keytab
   
   auth_mechanisms = gssapi
   

4. Restart dovecot:

   /etc/init.d/dovecot restart
   

Virtual Hosting

While all users are authenticated against Kerberos, we can map mailbox access to a single local user/group, e.g. vmail. This scenario is implemented by dovecot userdb static configuration option.

# 1. User is created with home directory set 
# to /var/mail.
# 2. User added to group vmail.
# 3. Do not gcreate a home directory.
# 4. User has no shell, ssh login impossible.
groupadd vmail
useradd -d /var/mail -G vmail -M -s /bin/false vmail

Changes to dovecot configuration below:

auth default {
  mechanisms = gssapi
  userdb static {
    args = uid=vmail gid=vmail home=/var/mail/%u
  }
}

When you create a new mailbox vmail user must be an owner. Let create a mailbox for user1:

mkdir /var/mail/user1
chown vmail /var/mail/user1

On successful user1 authentication dovecote will populate all necessary files for mailbox.

Open LDAP

You can use Kerberos authentication together with LDAP authorization. In this case LDAP database will serve userdb purpose. You have to setup OpenLDAP client with Kerberos (see here). Ensure the following settings in dovecot configuration:

auth default {
  mechanisms = plain gssapi
  passdb pam {
  }
  userdb passwd {
  }
}

This approach uses PAM. When you create a mailbox for user ensure user account (uid defined LDAP) is an owner for mailbox.

How to add CA certificate to NSS Certificate DB

If you have created a Certificate Authority (see here), you probably want get rid of warnings the consumers shows to your users, e.g. email clients while accessing the mailbox. Here are few simple steps to add your local Certificate Authority to to NSS Certificate DB:

1. Copy CA certificate to known certificates:

   cp cacert.pem /etc/ssl/certs
   chmod go+r /etc/ssl/certs/cacert.pem
   

2. Let install a tools to manage NSS Certificate DB:

   apt-get install libnss3-tools
   

3. The default location of NSSDB is in $HOME/.pki/nssdb. If you do not have one yet issue the following command to create (see more baout certutil here):

   mkdir -p .pki/nssdb ; certutil -N -d sql:.pki/nssdb
   

4. Add CA certificate:

   certutil -d sql:.pki/nssdb -A -t "CT,c,c" -n DEV.LOCAL \
   -i /etc/ssl/certs/cacert.pem
   

Evolution email client

Nothing specific need to be done. It uses .pki/nssdb by default

Firefox/Iceweasel web browser

The idea here is to point existing nssdb files to one in .pki/nssdb:

cd .mozilla/firefox/your-profile/
rm cert9.db key4.db
ln -s ~/.pki/nssdb/key4.db .
ln -s ~/.pki/nssdb/cert9.db .

Thunderbird email client

Things you need to do are exactly the same as for firefox, with the only exception to change default directory to .thunderbird/your-profile instead.

Final Note

At this point you should be fine to see SSL content (web, mail, etc) without a security warning since your CA is trusted. Consider copy nss db to /etc/skel, so the new users will get it working automatically:

cp -r .pki /etc/skel

The first time a new user logging, the nssdb will be copied from skel directory and as result the user will get valid CA certificate. Read more here.

Debian OpenLDAP client with Kerberos

Before we proceed with client setup (let assume our client machine name is deby01.dev.local) you need to setup the following:

• Kerberos Client (look here).

Once the basic installation of the above is complete, here we go:

1. We need install few packages:

   apt-get -y install ldap-utils libpam-ldap \
   libsasl2-modules-gssapi-mit nscd libnss-ldap kstart
   

   During installation you will be prompted for few questions:
   • libnss-ldap

     LDAP server URI: ldap://ldapk1.dev.local/
     Distinguished name of the search base: dc=dev,dc=local
     LDAP version to use: 3
     cn=admin,ou=people,dc=dev,dc=local
     LDAP account for root: cn=admin,ou=people,dc=dev,dc=local
     LDAP root account password: <just hit enter>
     

   • libpam-ldap

     Allow LDAP admin account to behave like local root? No
     Does the LDAP database require login? No
     

2. Reconfigure libpam-runtime and disable LDAP Authentication:

   dpkg-reconfigure libpam-runtime
   

3. Configure kstart, add the following to /etc/inittab (It will check every 10 minutes of the Kerberos ticket needs to be renewed and set the ticket lifetime to 24 hours:

   KS:2345:respawn:/usr/bin/k5start -U -f /etc/krb5.keytab -K 10 -l 24h
   

   Force init to reload configuration:

   kill -HUP 1
   

   Ensure /tmp/krb5cc_0 file is created:

   ls -lh /tmp/krb5cc_0
   

4. Kerberise libnss-ldap (file /etc/libnss-ldap.conf), ensure the following:

   base dc=dev,dc=local
   uri ldap://ldapk1.dev.local/
   ldap_version 3
   rootbinddn cn=admin,ou=people,dc=dev,dc=local
   
   # Use SASL and GSSAPI and where to find the 
   # Kerberos ticket cache.
   use_sasl        on
   sasl_mech       gssapi
   krb5_ccname FILE:/tmp/krb5cc_0
   

5. Set defaults for LDAP clients (file /etc/ldap/ldap.conf). Note client configuration changes if ldap is configured via SSL (see here).

   BASE    dc=dev,dc=local
   URI     ldap://ldapk1.dev.local/
   SASL_MECH GSSAPI
   

6. Add LDAP support for login process by nscd (file /etc/nsswitch.conf):

   passwd:         compat ldap
   group:          compat ldap
   shadow:         compat ldap
   

7. Restart Name Service Cache daemon:

   /etc/init.d/nscd restart
   

8. Configure PAM to automatically create a user home directory (file /etc/pam.d/common-session):

   session  required  pam_mkhomedir.so
   

You should be ready to login with a user created in LDAP and password set in Kerberos.

Troubleshooting

• You might experience the following error while initializing kerberos ticket in Debian Gnome desktop:

  Cannot resolve network address for KDC in realm DEV.LOCAL
  

  This somehow conflicts with avahi-daemon, you will need disable it:

  rcconf --off avahi-daemon
  

• If you are using Debian Gnome desktop, have a look at Troubleshooting: dbus-daemon nss_ldap failed to bind to LDAP server, that you can find here.

Debian OpenLDAP with Kerberos Authentication

Before we proceed with ldap kerberization (let assume our server name is ldapk1.dev.local) you need to setup the following:

• OpenLDAP Server (look here).
• Kerberos Client (look here).

Once the basic installation of the above is complete, here we go:

Remove Authentication from LDAP

1. Since we are going to authenticate users with Kerberos we need to prohibit users access to password stored in ldap. Add the following to file access-passwd.ldif:

   dn: olcDatabase={1}hdb,cn=config
   changetype: modify
   #
   # Delete default user access to password
   delete: olcAccess
   olcAccess: {0}to attrs=userPassword,shadowLastChange
     by self write
     by anonymous auth
     by dn="cn=admin,dc=dev,dc=local" write
     by * none
   -
   # Prohibit access to password
   add: olcAccess
   olcAccess: {0}to attrs=userPassword,shadowLastChange
     by * none
   -
   # Only authenticated users have read access 
   # Anonymous users have no access. 
   add: olcAccess
   olcAccess: {1}to *
     by users read
     by * none
   

   and apply changes:

   ldapmodify -QY EXTERNAL -H ldapi:/// -f access-passwd.ldif
   

2. Delete admin account:

   ldapdelete -cxWD cn=admin,dc=dev,dc=local cn=admin,dc=dev,dc=local
   

   and it access rights in the directory (file access-noadmin.ldif):

   dn: olcDatabase={1}hdb,cn=config
   changetype: modify
   #
   # Revoke admin write rights to the directory
   delete: olcAccess
   olcAccess: {3}to *
     by self write
     by dn="cn=admin,dc=dev,dc=local" write
     by * read
   -
   # Move admin account to people unit
   replace: olcRootDN
   olcRootDN: uid=admin,ou=people,dc=dev,dc=local
   -
   # Remove admin password
   delete: olcRootPW
   

   and apply changes:

   ldapmodify -QY EXTERNAL -H ldapi:/// -f access-noadmin.ldif
   

Setup GSSAPI mapping between OpenLDAP and Kerberos

1. Install SASL module for Kerberos:

   apt-get install libsasl2-modules-gssapi-mit
   

2. Add ldap principal:

   kadmin -p admin -q "addprinc -randkey ldap/ldapk1.dev.local"
   
   kadmin -p admin -q "ktadd ldap/ldapk1.dev.local"
   

3. Allow openldap group (slapd service is running under openldap account) access kerberos information:

   chgrp openldap /etc/krb5.keytab
   chmod g+r,o= /etc/krb5.keytab
   ls -lh /etc/krb5.keytab 
   

4. Specify authentication mode (file /etc/ldap/ldap.conf):

   SASL_MECH GSSAPI
   

5. Setup SASL mapping between Kerberos and LDAP accounts (file auth-kerberos.ldif):

   dn: cn=config
   changetype: modify
   #
   # Regular expression that match a simple user name
   # provided by SASL and map it to ldap entry
   add: olcAuthzRegexp
   olcAuthzRegexp: uid=([^,]+),cn=dev.local,cn=gssapi,cn=auth
     uid=$1,ou=people,dc=dev,dc=local
   -
   # Specify SASL Kerberos realm
   add: olcSaslRealm
   olcSaslRealm: DEV.LOCAL
   

   and apply changes:

   ldapmodify -QY EXTERNAL -H ldapi:/// -f auth-kerberos.ldif
   

6. Restart OpenLDAP service:

   /etc/init.d/slapd restart
   

Verify settings

Verify above changes by querying config:

ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b \
cn=config "(|(cn=config)(olcDatabase={1}hdb))"

Here it is:

dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcLogLevel: stats
olcPidFile: /var/run/slapd/slapd.pid
olcToolThreads: 1
olcAuthzRegexp: {0}uid=([^,]+),cn=dev.local,cn=gssapi,cn=auth uid=$1,ou=people
 ,dc=dev,dc=local
olcSaslRealm: DEV.LOCAL

dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=dev,dc=local
olcAccess: {0}to attrs=userPassword,shadowLastChange by * none
olcAccess: {1}to dn.base="" by * read
olcLastMod: TRUE
olcDbCheckpoint: 512 30
olcDbConfig: {0}set_cachesize 0 2097152 0
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbIndex: objectClass eq
olcDbIndex: uid eq
olcDbIndex: cn eq
olcDbIndex: ou eq
olcDbIndex: dc eq
olcRootDN: uid=admin,ou=people,dc=dev,dc=local

Kerberos Authentication Test

1. Let ensure anonymous has no access

   ldapk1:~/ldap# ldapsearch -xLLL
   No such object (32)
   

2. Authenticate to Kerberos:

   kinit -p admin
   

3. Let make the search as authenticated user (you should be able to see organization units people and groups):

   ldapsearch -LLL
   

Troubleshooting

1. Cannot create replay cache: No such file or directory

   ldap1:~# ldapsearch -LLL
   SASL/GSSAPI authentication started
   ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) 
   error (80) additional info: SASL(-1): generic failure: GSSAPI Error: 
   Unspecified GSS failure.  Minor code may provide more information 
   (Cannot create replay cache: No such file or directory)
   

   The only way recover from this error:
   • Restart slapd daemon
   • Consider add cron job on reboot that restarts slapd (file /etc/cron.d/slapd)

     @reboot root /etc/init.d/slapd restart
     

While authentication provided by Kerberos is secure now, consider protect communication with OpenLDAP by SSL/TLS encryption (read how here).