In earlier posting I went through the setup for using SASL to get rid of one password, but that left us still with Samba passwords to be changed separately. As one commenter noted, there has been for a long time an OpenLDAP overlay called smbk5pwd that syncs Heimdal kerberos and Samba passwords automatically when the password is changed in OpenLDAP. It works by intercepting the ldap exop password change operations and doing its own magic. We’ve been using MIT Kerberos until now and as it is the better maintained kerberos implementation in Ubuntu, we wanted to keep using it.

As there was no existing solution like smbk5pwd for it, we decided to implement one. smbk5pwd modifies the kerberos keys directly in the database, but we were not brave enough to try the same with MIT Kerberos and instead chose to use kadmind to create the principals in ldap. This approach uses extra network connections and it is possible that changing password fails because connecting kadmind fails or kadmind cannot connect back to ldap. Having a system where ldap server connects to kerberos server that connects back to ldap is not an optimal solution, but so far we haven’t seen problems arising from this. On the other hand not having to deal with kerberos internals is a definite plus.

If you are brave enough, here are quick instructions on how to use the overlay. This is now the first version of the overlay and it has not been in production use anywhere. It’s still missing features and ACLs need to be checked out, so this is work in progress.

Installation instructions

The source code for smbkrb5pwd overlay is available here.

To compile the overlay the easiest way is to get the full source code for OpenLDAP and place the smbkrb5pwd directory under contrib/slapd-modules directory. After compiling OpenLDAP normally the overlay can be compiled simply by:

cd contrib/slapd-modules

make
sudo cp .libs/* /usr/lib/ldap/

A precompiled version of smbkrb5pwd for Ubuntu 10.04 (Lucid Lynx) is available from Opinsys PPA in Launchpad:

sudo apt-get install slapd-smbkrb5pwd

To configure the overlay, the module needs to be loaded and configured for the database.

dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module
olcModulepath: /usr/lib/ldap
olcModuleload: {0}back_hdb
olcModuleload: {1}smbkrb5pwd

dn: olcOverlay={0}smbkrb5pwd
objectClass: olcOverlayConfig
objectClass: olcSmbKrb5PwdConfig
olcOverlay: {0}smbkrb5pwd
olcSmbKrb5PwdEnable: samba
olcSmbKrb5PwdEnable: krb5
olcSmbKrb5PwdMustChange: 2592012
olcSmbKrb5PwdKrb5Realm: EDU.EXAMPLE.ORG
olcSmbKrb5PwdRequiredClass: posixAccount

The overlay accepts the following configuration attributes:

smbkrb5pwd connects to kadmind using a principal found in keytab file /etc/ldap/slapd.d/openldap-krb5.keytab. The keytab is searched for principal that has name smbkrb5pwd/FQDN@REALM. Note that “hostname -f” should return fqdn. One way to achieve this is to put fqdn as the first name in /etc/hosts for the server’s ip address (here 10.11.12.13):

10.11.12.13   server.edu.example.org server

Creating the principal and exporting it to a keytab file can be done with the following commands:

sudo kadmin.local -q "addprinc -randkey smbkrb5pwd/server.edu.example.org@EDU.EXAMPLE.ORG"
sudo kadmin.local -q "ktadd -e des-cbc-crc:normal -k /etc/ldap/slapd.d/openldap-krb5.keytab \
 smbkrb5pwd/server.edu.example.org@EDU.EXAMPLE.ORG"

sudo chown openldap.openldap /etc/ldap/slapd.d/openldap-krb5.keytab

The overlay activates itself when an password change exop request is made. This can be done for example with ldappasswd command:

ldappasswd -x -D uid=admin,ou=people,dc=edu,dc=example,dc=org -W \
 uid=user1,ou=people,dc=edu,dc=example,dc=org

smbkrb5pwd writes debug information to slapd’s logfile which is normally /var/log/syslog in Ubuntu.

Happy hacking!

Veli-Matti Lintu

I described some of the problems around the topic in my earlier blog postings:

• User management rethought
• Shared and personal laptops in schools

What we currently need for ourselves is a dead simple user management tool that allows centralised management of the servers, but allows the administration access for the users to be split between schools. Usually there are a few people in every school who are responsible for managing the users for their own school. Often a single directory has user information for multiple schools and for various reasons it is not always desirable to show the user information for administrators in other schools. And of course everything on the web should integrate to it automatically. We are itching to do something about this.

A common situation that we have right now in schools is something like this. Several schools share an ltsp cluster and an authentication server. Single server manages users for several schools and web applications hosted elsewhere authenticate against the district’s server.

I had a quick look at different blueprints around the topic in Launchpad and found the following. I’m sure there are many more around the topic, but these describe the problem area quite well. Unfortunately only a few features have been implemented.

Looking at the blueprints above it’s clear that Puppet is the tool of choice for configuration management. Based on my good experiences with Puppet I’m excited to see what comes out of it as more and more people start using it. For identity management there is no clear winner. There’s no common understanding about “standard” LDAP directory structure either. We have looked at many tools, but either they don’t support kerberos or they are all too technical. The end-user should not have to even know that there is LDAP in the background. Simplicity rules.

We have years old tools to manage our setups, but our goal is to make everything better integrated with Ubuntu/Edubuntu. Many of the tools need rewriting and we are now in the process looking at what has changed since the original tools were written years ago and put all our knowledge into improving the situation. The earlier blog entries about OpenLDAP are part of the process.

Our plan regarding user management tools for our environments looks something like this:

1. Get a working set of scripts to setup OpenLDAP and MIT kerberos for school usage (based on the earlier blog articles) – similar to what openldap-dit does
2. Create a web based tool to manage LDAP/Kerberos users in easy fashion
3. Solution for password synchronisation problem (userPassword in LDAP, samba password and kerberos password should all be updated at once)
4. Make LTSP servers and laptops authenticate against OpenLDAP/Kerberos (pam-ldapd, nss-ldapd, sssd)
5. Write LDAP/kerberos configuration instructions for Moodle/Mediawiki/Zimbra/other common web applications used in schools
6. Create CAS/OpenID server with kerberos SSO support (Firefox can be used to pass the kerberos ticket to the web server that turns it to web login)

We’ve been working on steps 1-3 already and we should be able to release something working really soon now. It’s been a rough road at times, but we are getting there.

There are still open questions like choice between Heimdal and MIT kerberos server. E.g. OpenLDAP has smbk5pwd overlay for Heimdal, but we are looking if a similar solution for MIT kerberos would be possible.

Veli-Matti Lintu

The problem of an accessible home directory could perhaps be solved satisfactorily with network filesystems such as NFSv4 or AFS, or alternatively with a synchronisation tool such as unison. But even a more essential problem is user management. How is it decided who may login into a laptop, and how is she authenticated and her user information (such as her name, but possibly other information) transmitted to the laptop?

With centralized directory services containing user information, such as NIS or LDAP, one way of solving the problem could be to replicate all data to laptops. We could run an LDAP slave server on every laptop, but that would not be very secure in case we stored the (hashed) password data in LDAP, because all the password hashes of all users would thus exists on every laptop. The LDAP slave servers would also need a relatively unrestricted access to the master LDAP server, to synchronise their contents. We have not tried to do this with laptops in Opinsys, and probably never will.

What we have previously done: we perform authentication on laptops against a web server through an SSL-protected http-connection. The web server performs further authentication against Kerberos/LDAP. In case this authentication is successful, the web server sends information about user’s name (and login), that is then used as a new user is created on the laptop. The authentication token (a password) is stored on the laptop in a hashed format, permitting logins when a laptop is not connected to any network.

This means that any user who has a login and knows his password may pick a shared laptop and login, and in case the network is up and the services work, he may login later to the same laptop, even when the network is down. But the way this is currently done is a kind of a hack: we do this with some PAM and Perl trickery, and we don’t support removing users, or changing their information, or including any information about their group memberships. Kerberos tickets are not received on the laptop, even though they might be useful on some circumstances. This scheme is not bad because it does work for most cases, but it could definitely be better.

SSSD — a solution

Enter System Security Services Daemon, or SSSD for short. This software is a Fedora subproject and is still quite new. I do recommend exercising at least some caution when picking a new technology, especially when it provides some critical and security related functionality. Thus, do not blindly try this without evaluating first whether or not SSSD really fits your needs. But SSSD does seem to provide functionality which fits very well with the shared laptop concept. Simply put, SSSD provides access to remote authentication servers and directories such as Kerberos and LDAP, and caches information so that it can be used when network is down. It does need direct access to these services, but problems that exist in our current HTTPS/PAM/Perl-hack should be no more — as a whole it appears to provide what we need with a more clean design.

SSSD provides access to remote authentication servers and directories such as Kerberos and LDAP, and caches information so that it can be used when network is down.

What follows are some simple instructions on settings up SSSD on Ubuntu, version 10.04 (Lucid Lynx). Hopefully this will be of some use for people using other systems as well. Currently, if you are using Kerberos, I recommend getting sssd packages from our Launchpad repository because of this problem. The same problem is also referred to in this post by an SSSD developer. There is also another problem relating to Kerberos support in the Ubuntu repository package, which probably deserves a bug report… If you do not use Kerberos, the current SSSD packages in Ubuntu repositories should be fine.

Next, we install the SSSD package:

sudo apt-get install sssd

Configuration for SSSD is done in /etc/sssd/sssd.conf. sssd.conf(5) manual page should tell you most of what you need about configuration parameters, but do check out at least sssd-krb5(5) and sssd-ldap(5) as well. (Thankfully some people still write decent manual pages — the one true documentation format for unix systems.) Here we set up an sss domain named KRBLDAP.EDU.EXAMPLE.ORG which uses Kerberos for authentication and LDAP for user information. Edit “domains” line in /etc/sssd/sssd.conf:

domains = KRBLDAP.EDU.EXAMPLE.ORG

In the same file we should tell sssd what this domain actually means. We make it use kerberos.edu.example.org as the Kerberos server, using EDU.EXAMPLE.ORG as the Kerberos realm, and ldap.edu.example.org as the ldap server. Note that KRBLDAP.EDU.EXAMPLE.ORG is an arbitrary string and it does not need to be related in any way to the Kerberos realm, but for clarity this is perhaps a good naming scheme. Setting up Kerberos and LDAP servers are beyond the scope of this blog posting. Do check out the meaning of the following options from the manual pages, and add this to /etc/sssd/sssd.conf:

[domain/KRBLDAP.EDU.EXAMPLE.ORG]
auth_provider = krb5
krb5_kdcip = kerberos.edu.example.org
krb5_realm = EDU.EXAMPLE.ORG
id_provider = ldap
ldap_uri = ldap://ldap.edu.example.org
ldap_search_base = dc=edu,dc=example,dc=org
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/ssl/certs/slapd-ca-cert.pem
cache_credentials = true
enumerate = true

Restart sssd after editing the configuration:

sudo service sssd restart

Now that we have sssd up and running, it is time to configure NSS and PAM to use it. One way to achieve this is to use the auth-client-config package:

sudo apt-get install auth-client-config

Write the following sss authentication profile into /etc/auth-client-config/profile.d/sss:

[sss]
nss_passwd=     passwd:         compat sss
nss_group=      group:          compat sss
nss_shadow=     shadow:         compat
nss_netgroup=   netgroup:       nis

pam_auth=       auth    [success=3 default=ignore]      pam_unix.so nullok_secure try_first_pass
                auth    requisite                       pam_succeed_if.so uid >= 500 quiet
                auth    [success=1 default=ignore]      pam_sss.so use_first_pass
                auth    requisite                       pam_deny.so
                auth    required                        pam_permit.so

pam_account=    account required                                        pam_unix.so
                account sufficient                                      pam_localuser.so
                account sufficient                                      pam_succeed_if.so uid < 500 quiet
                account [default=bad success=ok user_unknown=ignore]    pam_sss.so
                account required                                        pam_permit.so

pam_password=   password        sufficient      pam_unix.so obscure sha512
                password        sufficient      pam_sss.so use_authtok
                password        required        pam_deny.so

pam_session=    session required                        pam_mkhomedir.so skel=/etc/skel/ umask=0077
                session optional                        pam_keyinit.so revoke
                session required                        pam_limits.so
                session [success=1 default=ignore]      pam_sss.so
                session required                        pam_unix.so

Note that editing NSS and PAM settings can be rather dangerous! I suggest you keep a root shell open while doing this, and be ready to revert the changes in case something goes wrong. Once you are properly prepared, do this:

sudo auth-client-config -n -a -p sss

Nothing actually happened, which is okay, now read the auth-client-config(8) manual page on how to fix the above command to do some actual changes, and while at it also check out how to back out the changes with the same command, because you just might need that.

Now it should work. Test it with getent, test it with su, try to login through gdm with users that are listed in LDAP. Yet often we do not get it right the first time, which means it may be time to run sssd interactively with some debugging options on.

sudo service sssd stop
sudo sssd -i -d 4

Here, the -d switch may take any value between 0 and 10 (inclusive) — this controls debug output level. This allows you to see what sssd is doing as you login, or lookup a username, or whatever it is that you are doing that is somehow sssd related.

There is quite a bit more to sssd than this short introduction. So far the version 1.0.2 seems pretty good — at least the project has some decent documentation and sssd problems are rather easy to debug, so perhaps also you might want to give it a try?

Juha Erkkilä

I assume that you have installed Ubuntu 10.04 (Lucid) and have configured the OpenLDAP server with the following instructions (Server setup): Setting up OpenLDAP on Ubuntu 10.04 Alpha 2 (Lucid)

We have to add some access rules to slapd configurations so that ActiveLdap will work. This is not necessarily the right way to do this but with these simple changes we can make ActiveLdap work. Don’t do this to the production server if you don’t know what it means.

modify_acls.ldif:

dn: olcDatabase={-1}frontend,cn=config
add: olcAccess
olcAccess: {1}to dn.base=cn=subschema by * read
olcAccess: {2}to dn.base= by * read

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f modify_acls.ldif

Now we can start to make preparations for the new Rails project. In this example I use Ubuntu 10.04 Alpha 3 (Lucid)

Install the following packages from Ubuntu repositories:

sudo apt-get install ruby rubygems rake ruby-dev irb libxml2-dev libxslt-dev libopenssl-ruby

The following gems are needed:

sudo gem install rails cucumber-rails webrat activeldap ruby-net-ldap

Add the gem binaries to PATH:

echo "PATH=\$PATH:/var/lib/gems/1.8/bin" >> ~/.bashrc

Create new rails project:

rails user-management

As the next step, generate new REST resources with scaffold. This command also performs database migration. This is good because then we can verify that the Cucumber step passed correctly in the typical use case (using an sqlite database). We use the posixAccount objectClass (LDAP) attribute name. Thus we don't have to rename the attribute as we introduce ActiveLdap.

./script/generate scaffold User cn:string uid:string uidNumber:integer gidNumber:integer \
homeDirectory:string

Create tables to the test database:

RAILS_ENV=test rake db:migrate

Cucumber initialization:

./script/generate cucumber
echo "default: --format pretty features" >> cucumber.yml

Generate User feature:

./script/generate feature User cn:string uid:string uidNumber:integer gidNumber:integer \
homeDirectory:string

Edit manage_users.feature file and replace the following content:

features/manage_users.feature:

Feature: Manage users
  In order to manage authorization
  User
  wants to add, remove, and organize users

  Scenario: Add new user
    Given I am on the new user page
    When I fill in "Cn" with "Joe Taylor"
    And I fill in "Uid" with "joe"
    And I fill in "Uidnumber" with "11001"
    And I fill in "Gidnumber" with "11001"
    And I fill in "Homedirectory" with "/home/joe"
    And I press "Create"
    Then I should see "Joe Taylor"
    And I should see "joe"
    And I should see "11001"
    And I should see "11001"
    And I should see "/home/joe"

Now you can run Cucumber

cucumber

..and the result should be one passed scenario.

Now we have User resource and we can test that it works. Data was stored in the sqlite database and in the next step we switch to ActiveLdap and LDAP storage.

Add following line to config/environment.rb:

config.gem 'activeldap', :lib => 'active_ldap'

Initialize ActiveLdap:

./script/generate scaffold_active_ldap

Edit config/ldap.yml file and add the following content:

cucumber:
  host: localhost
  base: dc=edu,dc=example,dc=org
  bind_dn: uid=admin,ou=People,dc=edu,dc=example,dc=org
  password: example

Modify app/models/user.rb file and replace it with the following content:

class User < ActiveLdap::Base
  ldap_mapping( :dn_attribute => "uid",
                :prefix => "ou=People",
                :classes => ['top', 'posixAccount', 'account'] )
end

OpenLDAP does not support a transaction system such as in a typical SQL-database. This is why we need use Before hook. First we have to clear the data so that the test scenario works correctly.

Edit features/step_definitions/user_steps.rb file and add following content:

Before do |scenario|
  User.all.each do |u|
    u.destroy
  end
end

It should now work. Run cucumber command:

cucumber

..and the result should be one passed scenario.

Add the following LDAP specific scenario. Edit features/manage_users.feature file and add the following content:

  Scenario: Add dupplicate distinguishedName
    Given the following users:
    | cn         | Uid | Uidnumber | Gidnumber | Homedirectory |
    | Joe Taylor | joe |     11001 |     11001 | /home/joe     |
    And I am on the new user page
    When I fill in "Cn" with "Joe Wilson"
    And I fill in "Uid" with "joe"
    And I fill in "Uidnumber" with "11002"
    And I fill in "Gidnumber" with "11001"
    And I fill in "Homedirectory" with "/home/joew"
    And I press "Create"
    Then I should see "distinguishedName is duplicated"
    When I fill in "Uid" with "joew"
    And I press "Create"
    Then I should see "Joe Wilson"
    And I should see "joew"
    And I should see "11002"
    And I should see "11001"
    And I should see "/home/joew"

DN duplicates are not allowed on the LDAP-server. This scenario ensures that the LDAP-server behaves like this.

Run cucumber command.

Result should be following:

2 scenarios (2 passed)
27 steps (27 passed)

Jouni Korhonen

Now that MIT Kerberos is running using OpenLDAP as storage backend, the next logical step is to make OpenLDAP use MIT Kerberos as its password backend. If one needs both kerberos ja ldap bind authentication working, it’s really easy to get some of those passwords out of sync. Users are usually not happy if they suddenly start having randomly different passwords for different services when they change their password. Until now I’ve been using tools that always update the different passwords (userPassword in ldap, ntml hash for samba and kerberos) at the same time, but sometimes there have been problems making sure that all actually changed.

To make syncing possible, I’ll be going through the steps to get OpenLDAP to forward the ldap binds to SASL which in turn forwards them to Kerberos using GSSAPI. This solution works when there is need to support ldap binds for applications that don’t support kerberos directly. This shouldn’t be mistaken for real kerberos authentication as this solution still needs the user password to be sent to OpenLDAP over the wire.

The following documents tell more background information and were used to do the configuration described in this posting:

• Wikipedia on SASL
• RFC #4422 – Simple Authentication and Security Layer (SASL)
• OpenLDAP’s Pass-Through authentication

Simple Authentication and Security Layer (SASL) is one of the mysterious acronyms that pop up once in a while, but often one really cannot figure out what it does. SASL makes it possible to authenticate connection based protocols with any authentication method that the server and client both support. This means that the protocol itself does not need to define all the authentication methods that can be used.

What I’ll be using here is OpenLDAP’s pass-through authentication that replaces the user’s password with instructions to use SASL, e.g.:

userPassword: {SASL}username@REALM

This tells OpenLDAP that that password is not local, but instead SASL authentication should be made with username@REALM. On Debian/Ubuntu usually the Cyrus-SASL implementation is used. More information about the Pass-Through authentication is available in the OpenLDAP manual.

To get started with the setup you should have working OpenLDAP + MIT kerberos setup as described in the earlier postings. On top of these the following packages are needed on the machine running OpenLDAP server:

sudo apt-get install sasl2-bin libsasl2-modules-gssapi-mit

To configure saslauthd I used the following settings. From the Ubuntu Lucid defaults I had to change START and MECHANISMS lines.
/etc/default/saslauthd

START=yes
DESC="SASL Authentication Daemon"
NAME="saslauthd"
MECHANISMS="kerberos5"
MECH_OPTIONS=""
THREADS=5
OPTIONS="-c -m /var/run/saslauthd"

The default installation gives only sasl group access to the socket directory:

user@server:~$ ls -ld /var/run/saslauthd
drwx--x--- 2 root sasl 140 2010-03-04 09:47 /var/run/saslauthd

Adding the openldap user to the sasl group gives it access to the socket:

sudo adduser openldap sasl

To get make sure that SASL is installed correctly, run the following command to test the authentication:

testsaslauthd -u user@EDU.EXAMPLE.ORG -p userpassword

If everything works, you should see something like this:

0: OK "Success."

If something went wrong the answer is something like this:

0: NO "authentication failed"

Next test that slapd authentication works:

ldapsearch -D uid=user,ou=people,dc=edu,dc=example,dc=org -W -b dc=edu,dc=example,dc=org

The search should return results normally and authentication should happen against the kerberos server. If authentication doesn’t work, check the /var/log/kdc.log (on debian/ubuntu) and try running saslauthd from command line in debug mode:

sudo /usr/sbin/saslauthd -a kerberos5 -m /var/run/saslauthd -d

Now I’m just left with the problem of having the ntml hashed password for samba in the ldap directory, but at least there’s one less password to manage. Any ideas for the next step?

Veli-Matti Lintu

• Part 1 – OpenLDAP setup
• Part 2 – SSL/TLS
• Part 3 – Schemas for samba, autofs and kerberos
• Part 4 – Kerberos setup
• Part 5 – DNS settings for kerberos using dnsmasq
• Part 6 – NFSv4 with kerberos
• Part 7 – Autofs

After getting NFSv4 working, it’d be of course nice to automatically mount the nfs exported home directories. In this part I’m going through the steps to get school specific home directories mounted from a central server. Using autofs is an alternative to defining the mounted directories in /etc/fstab. It mounts the directories automatically when they are needed instead of doing it at boot time. This especially handy in situations where some servers are not immediately available after boot because of network issues. Also the number of mounts is kept down when not needed, which has helped with server stability issues. Autofs mountpoints can be configured either statically for every client or centrally in ldap. Ldap configuration allows one to easily add new mountpoints without modifying every client separately.

In this setup there’s a single file server that has a separate subdirectory under /home for every school. The directories are:

• server:/home/school1
• server:/home/school2
• server:/home/school3

The autofs.schema was installed in part 3 of this series. In addition to autofs-ldap package, also some entries are needed in ldap. First the basic data that autofs uses to recognize that it is configured:

#!/bin/sh

ldapadd -D uid=admin,ou=People,dc=edu,dc=example,dc=org -x -W << EOF
dn: ou=Automount,dc=edu,dc=example,dc=org
ou: Automount
objectClass: top
objectClass: organizationalUnit

dn: ou=auto.master,ou=Automount,dc=edu,dc=example,dc=org
ou: auto.master
objectClass: top
objectClass: automountMap
EOF

We want to use autofs to mount directories under /home, so it needs to be defined:

#!/bin/sh

ldapadd -D uid=admin,ou=People,dc=edu,dc=example,dc=org -x -W << EOF
dn: cn=/home,ou=auto.master,ou=Automount,dc=edu,dc=example,dc=org
cn: /home
objectClass: top
objectClass: automount
automountInformation: ldap:ou=auto.home,ou=Automount,dc=edu,dc=example,dc=org rsize=8192,wsize=8192
EOF

This tells autofs to look for individual directories under the suffix ou=auto.home,ou=Automount,dc=edu,dc=example,dc=org. The directories are then defined under the defined suffix:

#!/bin/sh

ldapadd -D uid=admin,ou=People,dc=edu,dc=example,dc=org -x -W << EOF
dn: ou=auto.home,ou=Automount,dc=edu,dc=example,dc=org
ou: auto.home
objectClass: top
objectClass: automountMap

dn: cn=school1,ou=auto.home,ou=Automount,dc=edu,dc=example,dc=org
cn: school1
objectClass: top
objectClass: automount
automountInformation: -fstype=nfs4,rw,sec=krb5 server.edu.example.org:/home/school1

dn: cn=school2,ou=auto.home,ou=Automount,dc=edu,dc=example,dc=org
cn: school2
objectClass: top
objectClass: automount
automountInformation: -fstype=nfs4,rw,sec=krb5 server.edu.example.org:/home/school2

dn: cn=school3,ou=auto.home,ou=Automount,dc=edu,dc=example,dc=org
cn: school3
objectClass: top
objectClass: automount
automountInformation: -fstype=nfs4,rw,sec=krb5 server.edu.example.org:/home/school3
EOF

Now the server side should be rocking and the clients need to be instructed to look for mountpoints in ldap. First autofs needs to be installed on the client machine:

sudo apt-get install autofs5-ldap ldap-utils

And the following settings instructs autofs to use ldap as data storage and where in the ldap tree the information is stored:

/etc/nsswitch.conf

  automount: ldap

/etc/default/autofs

TIMEOUT=60
LDAP_URI=ldap://ldap.edu.example.org/
SEARCH_BASE="ou=auto.master,ou=Automount,dc=edu,dc=example,dc=org"

MAP_OBJECT_CLASS="automountMap"
ENTRY_OBJECT_CLASS="automount"
MAP_ATTRIBUTE="ou"
ENTRY_ATTRIBUTE="cn"
VALUE_ATTRIBUTE="automountInformation"

Next restart /etc/init.d/autofs and /home/school{1|2|3} should mount automatically.

Veli-Matti Lintu

• Part 1 – OpenLDAP setup
• Part 2 – SSL/TLS
• Part 3 – Schemas for samba, autofs and kerberos
• Part 4 – Kerberos setup
• Part 5 – DNS settings for kerberos using dnsmasq
• Part 6 – NFSv4 with kerberos
• Part 7 – Autofs

Next it’s time to finally get files moving between the servers. For this we use NFSv4 that supports kerberos out-of-the-box also in Ubuntu. This part is based on the newest Lucid packages in the repositories, which should be pretty close to alpha 3 now.

The following documents were used to get the configuration working:

• https://help.ubuntu.com/community/NFSv4Howto
• MIT Kerberos manual: Hostnames for KDCs
• Doug Potter: Kerberos/LDAP/NFSv4 HOWTO

The goal of the setup is to have a single file server that shares the following directories to clients over NFSv4 with kerberos authentication:

• /home/school1
• /home/school2
• /home/school3

The server will not allow root to access other users’ files which makes it possible to export the shares in potentially hostile environments as the compromise of a single client host does not expose all contents of the file server.

Server settings

The following packages are needed on the server:

apt-get install nfs-kernel-server nfs-common

Unlike NFSv3, NFSv4 uses a separate directory structure to share the directories. The actual content is mounted with mount –bind under this directory. Here we place the directories under /export:

sudo mkdir /export
sudo mkdir /export/home

Then we instruct in /etc/fstab that /home should be mounted under /export/home. The following should be added in bottom of /etc/fstab:

/etc/fstab

/home    /export/home   none    bind  0  0

After this /export/home can be mounted with the following command and it is also automatically mounted when the system boots:

sudo mount /export/home

Next configure the exports in /etc/exports to be exported to all nfs4 clients using kerberos:

/etc/exports

/export         gss/krb5(rw,fsid=0,async,subtree_check,no_root_squash,crossmnt)
/export/home    gss/krb5(rw,async,subtree_check,no_root_squash)
/export/home/school1	gss/krb5(rw,async,subtree_check,root_squash,crossmnt)
/export/home/school2	gss/krb5(rw,async,subtree_check,root_squash,crossmnt)
/export/home/school3	gss/krb5(rw,async,subtree_check,root_squash,crossmnt)

Next configure NFS to use kerberos:

/etc/default/nfs-common

NEED_STATD=
STATDOPTS=
NEED_IDMAPD=yes
NEED_GSSD=yes

/etc/default/nfs-kernel-server

RPCNFSDCOUNT=10
RPCNFSDPRIORITY=0
RPCMOUNTDOPTS=
NEED_SVCGSSD=yes
RPCSVCGSSDOPTS=

idmapd.conf needs to configured with proper Domain name for user/group name mappings:
/etc/idmapd.conf

[General]

Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = EDU.EXAMPLE.ORG

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

The NFS server version in Lucid supports only DES encryption which is not enabled by default. There is more information available in the bug reports:

• Bug report in Launchpad
• Bug report in Debian bug tracker

For now DES can be enabled with the following settings:
/etc/krb5.conf

[libdefaults]
  allow_weak_crypto = true
  default_tgs_enctypes = des-cbc-crc
  default_tkt_enctypes = des-cbc-crc

Next we need to create kerberos principals for the server and the clients. In this example all the principals are created on the server and copied to the clients. It is also possible to use kadmin remotely from the client machines.

sudo kadmin.local -q "addprinc -randkey nfs/server.edu.example.org"
sudo kadmin.local -q "ktadd -e des-cbc-crc:normal nfs/server.edu.example.org"

sudo kadmin.local -q "addprinc -randkey nfs/client1.edu.example.org"
sudo kadmin.local -q "ktadd -e des-cbc-crc:normal -k client1.keytab nfs/client1.edu.example.org"

sudo kadmin.local -q "addprinc -randkey nfs/client2.edu.example.org"
sudo kadmin.local -q "ktadd -e des-cbc-crc:normal -k client2.keytab nfs/client2.edu.example.org"

Now copy the client1.keytab and client2.keytab to /etc/krb5.keytab on the client machines and make them only readable by root.

The server should now be ready after restarting the services:

sudo service gssd start
sudo service rpc_pipefs start
sudo /usr/sbin/rpc.gssd
sudo service idmapd start

sudo /etc/init.d/nfs-kernel-server restart

The server functionality can be tested by trying to mount one of the exported shares locally:

sudo mount -t nfs4 -o sec=krb5 server.edu.example.org:/home/school1 /mnt

Client settings

The following packages are needed on the client machines:

apt-get install nfs-common krb5-user

To avoid having to configure the kerberos server settings on each client separately, one can use DNS to store the settings as described in the previous posting.

/etc/krb5.conf

[libdefaults]
  default_realm = EDU.EXAMPLE.ORG
  allow_weak_crypto = true
  default_tgs_enctypes = des-cbc-crc
  default_tkt_enctypes = des-cbc-crc
  dns_lookup_kdc = true
  dns_lookup_realm = true

/etc/default/nfs-common – idmapd and gssd need to be enabled

NEED_STATD=
STATDOPTS=
NEED_IDMAPD=yes
NEED_GSSD=yes
RPCGSSDOPTS="-vvv -rrr"  # for debugging

/etc/idmapd.conf – Domain must match the name defined on the server for user and group name mapping to work

[General]

Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = EDU.EXAMPLE.ORG

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

After configuration nfs-common needs to be restarted (modules need to be loaded if they haven’t been loaded automatically):

sudo modprobe nfs
sudo modprobe rpcsec_gss_krb5

sudo service idmapd start
sudo service gssd start
sudo service portmap restart

Mounting the share should now work with mount command:

sudo mount -t nfs4 -o sec=krb5 server.edu.example.org:/home/school1 /home/school1

If there are problems, restarting the client machine may help as sometimes picking up the kerberos setting hasn’t worked for me. I’m probably missing some service that requires restarting..

At this point we have no kerberos ticket, so the user should not be able to enter his own home directory:

user$ cd /home/school1/user
-bash: cd: /home/school1/user: Permission denied

After getting the ticket it should work:

user$ kinit user@EDU.EXAMPLE.ORG
Password for user@EDU.EXAMPLE.ORG:
user$ cd /home/school1/user

Root squash should also prevent root from entering directories for other users on the client machine:

user$ cd /home/school1/otheruser
-bash: cd: /home/school1/otheruser: Permission denied

# cd /home/school1/otheruser
-bash: cd: /home/school1/otheruser: Permission denied

Now give it a reboot and try again. Everything should be now working.

Veli-Matti Lintu

• Part 1 – OpenLDAP setup
• Part 2 – SSL/TLS
• Part 3 – Schemas for samba, autofs and kerberos
• Part 4 – Kerberos setup
• Part 5 – DNS settings for kerberos using dnsmasq
• Part 6 – NFSv4 with kerberos
• Part 7 – Autofs

Kerberos requires every client to know where the server is located. This can be done either by using /etc/krb5.conf file or using DNS to distribute the information. Using DNS makes it easier to do changes in the network settings as not every client needs to be updated. Next we aim to minimize the amount of configuration needed for every client so configuring DNS properly is a logical first step.

The following documents were used to get the configuration working:

• https://help.ubuntu.com/community/NFSv4Howto
• MIT Kerberos manual: Hostnames for KDCs
• Doug Potter: Kerberos/LDAP/NFSv4 HOWTO

The goal of the setup is to have a single file server that shares the following directories to clients over NFSv4 with kerberos authentication:

• /home/school1
• /home/school2
• /home/school3

The server will not allow root to access other users’ files which makes it possible to export the shares in potentially hostile environments as the compromise of a single client host does not expose all contents of the file server.

The domain name used is edu.example.org and the NFS server will be the same machine as the kerberos server. The names used in this example map to following IPs:

• server.edu.example.org – 10.0.0.1
• ldap.edu.example.org – 10.0.0.1
• kerberos.edu.example.org – 10.0.0.1
• client1.edu.example.org – 10.0.0.10
• client2.edu.example.org – 10.0.0.11

DNS settings

Before we start with the NFS setup, we need to make sure that name resolution for the server and clients works with fully qualified domain names (fqdn). Also reverse mappings need to be working for NFSv4+krb5 to work properly.

There are many DNS servers that can be used. Here we use dnsmasq:

sudo apt-get install dnsmasq

/etc/dnsmasq.conf

domain-needed
domain=edu.example.org

ptr-record=1.0.0.10.in-addr.arpa.,"server.edu.example.org"
address=/server.edu.example.org/10.0.0.1

ptr-record=10.0.0.10.in-addr.arpa.,"client1.edu.example.org"
address=/client1.edu.example.org/10.0.0.10

ptr-record=11.0.0.10.in-addr.arpa.,"client2.edu.example.org"
address=/client2.edu.example.org/10.0.0.11

After restarting dnsmasq and configuring it to be used in /etc/resolv.conf, it should resolve names properly both ways:

$ nslookup server.edu.example.org

Server:		127.0.0.1
Address:	127.0.0.1#53

Name:	server.edu.example.org
Address: 10.0.0.1

$ nslookup 10.0.0.1

Server:		127.0.0.1
Address:	127.0.0.1#53

1.0.0.10.in-addr.arpa	name = server.edu.example.org.

Make sure that also the client machine names resolve correctly.

In addition to having DNS server configured properly, if the /etc/hosts file has names configured, make sure that the FQDN is before the shortname, e.g.:

10.0.0.1 server.edu.example.org server
10.0.0.10 client1.edu.example.org client1
10.0.0.11 client2.edu.example.org client2

This makes sure that host mappings are not done from /etc/hosts using the shortname of the server.

While we are at it, let’s also add the SRV records for kerberos so that we don’t need to configure kerberos realms for every client separately:

/etc/dnsmasq.conf

address=/kerberos.edu.example.org/10.0.0.1
address=/ldap.edu.example.org/10.0.0.1

txt-record=_kerberos.edu.example.org,"EDU.EXAMPLE.ORG"
srv-host=_kerberos._udp.edu.example.org,"kerberos.edu.example.org",88
srv-host=_kerberos._tcp.edu.example.org,"kerberos.edu.example.org",88
srv-host=_kerberos-master._udp.edu.example.org,kerberos."edu.example.org",88
srv-host=_kerberos-adm._tcp.edu.example.org,"kerberos.edu.example.org",749
srv-host=_kpasswd._udp.edu.example.org,"kerberos.edu.example.org",464

Clients can now find the kerberos server automatically when the realm is given (e.g. kinit testuser@EDU.EXAMPLE.ORG). To set default realm, /etc/krb5.conf can be used:

[libdefaults]
        default_realm = EDU.EXAMPLE.ORG
	dns_lookup_kdc = true
	dns_lookup_realm = true

Now the name server should be ready for the actual setup. The actual NFSv4+kerberos setup is described in the next part.

Veli-Matti Lintu

• Part 1 – OpenLDAP setup
• Part 2 – SSL/TLS
• Part 3 – Schemas for samba, autofs and kerberos
• Part 4 – Kerberos setup
• Part 5 – DNS settings for kerberos using dnsmasq
• Part 6 – NFSv4 with kerberos
• Part 7 – Autofs

After getting OpenLDAP running properly and the schemas in place, the next step is to get Kerberos and AutoFS running on top of it to enable centrally managed automatic NFSv4+kerberos mounts to user home directories. Here we setup kerberos using OpenLDAP as the backend to store the principals. This allows one to easily replicate the data to slave servers.

The following documents were used to get the configuration working:

• Ubuntu SingleSignOn manual page

This example uses kerberos realm EDU.EXAMPLE.ORG and the kdc uses fqdn kerberos.edu.example.org. The ldap database used is the same as configured in the earlier postings in this blog.

The following packages are needed to get kerberos working with ldap backend:

sudo apt-get install krb5-kdc-ldap krb5-kdc krb5-admin-server krb5-config krb5-user

/etc/krb5.conf configures the database location that is needed before initializing the ldap database. In this example the ldap connection does not use TLS as both are running on the same server.

[libdefaults]
        default_realm = EDU.EXAMPLE.ORG

[realms]
         EDU.EXAMPLE.ORG = {
             kdc = kerberos.edu.example.org
             admin_server = kerberos.edu.example.org
             master_kdc = kerberos.edu.example.org
             default_domain = edu.example.org
             database_module = ldap_edu.example.org
         }

[domain_realm]
         .edu.example.org = EDU.EXAMPLE.ORG
         edu.example.org = EDU.EXAMPLE.ORG

[dbmodules]
        ldap_edu.example.org = {
               db_library = kldap
               ldap_kerberos_container_dn = cn=krbcontainer,dc=edu,dc=example,dc=org
               ldap_kdc_dn = uid=admin,ou=People,dc=edu,dc=example,dc=org
               ldap_kadmind_dn = uid=admin,ou=People,dc=edu,dc=example,dc=org
               ldap_service_password_file = /etc/krb5.secrets
               ldap_servers = ldap://127.0.0.1
               ldap_conns_per_server = 5
        }

To get the kerberos database initialized in the ldap directory, kdb5_ldap_util is used with valid ldap credentials. Kerberos will use these credentials to create the initial entries. Also KDC database master key is set at this point. Make it difficult and write it down somewhere.

sudo kdb5_ldap_util -D uid=admin,ou=People,dc=edu,dc=example,dc=org \
create -subtrees dc=edu,dc=example,dc=org -s -H ldap://localhost -r EDU.EXAMPLE.ORG

Password for "uid=admin,ou=People,dc=edu,dc=example,dc=org":
Initializing database for realm 'EDU.EXAMPLE.ORG'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:

Kerberos container is missing. Creating now...

Some hints for potential errors:

• “kdb5_ldap_util: Kerberos container location not specified while reading kerberos container information” – /etc/krb5.conf has
  something wrong so that the realm doesn’t map to any databases
• Server is unwilling to perform – the ldap suffix configured for the realm is probably not valid

Next the ldap user and password are stored for KDC to access and create principals:

sudo kdb5_ldap_util -D uid=admin,ou=People,dc=edu,dc=example,dc=org \
  stashsrvpw -f /etc/krb5.secrets uid=admin,ou=People,dc=edu,dc=example,dc=org

Create an admin user named john who can modify the database:

sudo kadmin.local -q "addprinc john/admin@EDU.EXAMPLE.ORG

Finally give the user access rights in /etc/krb5kdc/kadm5.acl:

*/admin *

KDC is configured in /etc/krb5kdc/kdc.conf with fairly basic configuration:

[kdcdefaults]
    kdc_ports = 750,88

[realms]
    EDU.EXAMPLE.ORG = {
        database_name = /var/lib/krb5kdc/principal
        admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
        acl_file = /etc/krb5kdc/kadm5.acl
        key_stash_file = /etc/krb5kdc/stash
        kdc_ports = 750,88
        max_life = 10h 0m 0s
        max_renewable_life = 7d 0h 0m 0s
        master_key_type = des3-hmac-sha1
        supported_enctypes = aes256-cts:normal arcfour-hmac:normal des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3
        default_principal_flags = +preauth
    }

After restarting krb5-kdc and krb5-admin-server one should be able to run kinit and get a kerberos ticket:

$ kinit john/admin
Password for john/admin@EDU.EXAMPLE.ORG:
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: john/admin@EDU.EXAMPLE.ORG

Valid starting     Expires            Service principal
01/28/10 03:10:20  01/29/10 03:10:20  krbtgt/EDU.EXAMPLE.ORG@EDU.EXAMPLE.ORG

If you now dump the ldap database, the principal for john/admin is stored in dn: krbPrincipalName=john/admin@EDU.EXAMPLE.ORG,cn=EDU.EXAMPLE.ORG, cn=krbcontainer,dc=edu,dc=example,dc=org

More user principals can be added with kadmin and kadmin.local using the addprinc command. The Ubuntu SingleSignOn manual page has more information about that.

Desktop logins using kerberos

Getting client machines to do PAM authentication using kerberos is easy. The libpam-krb5 package is needed for this:

sudo apt-get install libpam-krb5

/etc/krb5.conf needs to be configured on the clients to point to the right server. This can be done also using proper name server settings to instruct the kerberos clients to contact the right server based on dns names.

[libdefaults]
        default_realm = EDU.EXAMPLE.ORG

[realms]
         EDU.EXAMPLE.ORG = {
             kdc = kerberos.edu.example.org
             admin_server = kerberos.edu.example.org
             master_kdc = kerberos.edu.example.org
             default_domain = edu.example.org
         }

On Lucid the PAM settings are added automagically and you should be ready to rock. Just make sure that the user you are authenticating as actually exists in /etc/passwd or ldap as kerberos does not provide nss services.

Veli-Matti Lintu

• Part 1 – OpenLDAP setup
• Part 2 – SSL/TLS
• Part 3 – Schemas for samba, autofs and kerberos
• Part 4 – Kerberos setup
• Part 5 – DNS settings for kerberos using dnsmasq
• Part 6 – NFSv4 with kerberos
• Part 7 – Autofs

In this part I’m setting up ldap schemas for samba, autofs and kerberos. This is needed before the actual configuration for these can be done. Unfortunately I could not find ldif files for OpenLDAP for these, so the schema files need to be converted to ldif files. The tutorial at help.ubuntu.com instructs to use the slaptest tool for this.

First get the tools and packages that contain the schemas that need to be converted. autofs.schema is in the autofs-ldap package, samba.schema is in the samba sources and kerberos.schema come with the krb5-kdc-ldap package.

sudo apt-get install dpkg-dev autofs-ldap krb5-kdc-ldap

apt-get source samba

cp ./samba-3.4.3/examples/LDAP/samba.schema .
cp /etc/ldap/schema/autofs.schema .
cp /usr/share/doc/krb5-kdc-ldap/kerberos.schema.gz .
gunzip kerberos.schema.gz

schema_convert.conf is a temporary file used to convert the schemas to ldif format:

include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/inetorgperson.schema
include samba.schema
include autofs.schema
include kerberos.schema

The actual conversion is done by running slaptest. It places the the resulting files under ldif_result directory. The files need to be cleaned a bit so that they are be imported. This is not exactly the nicest looking piece I’ve written, but it seems to do the trick.

mkdir ldif_result
slaptest -f schema_convert.conf -F ldif_result

cat ldif_result/cn=config/cn=schema/cn=*samba.ldif | \
egrep -v structuralObjectClass\|entryUUID\|creatorsName  | \
egrep -v createTimestamp\|entryCSN\|modifiersName\|modifyTimestamp | \
sed 's/dn: cn={.}samba/dn: cn=samba,cn=schema,cn=config/g' | \
sed 's/{.}samba/samba/' > samba.ldif

cat ldif_result/cn=config/cn=schema/cn=*autofs.ldif | \
egrep -v structuralObjectClass\|entryUUID\|creatorsName  | \
egrep -v createTimestamp\|entryCSN\|modifiersName\|modifyTimestamp | \
sed 's/dn: cn={.}autofs/dn: cn=autofs,cn=schema,cn=config/g' | \
sed 's/{.}autofs/autofs/' > autofs.ldif

cat ldif_result/cn=config/cn=schema/cn=*kerberos.ldif | \
egrep -v structuralObjectClass\|entryUUID\|creatorsName  | \
egrep -v createTimestamp\|entryCSN\|modifiersName\|modifyTimestamp | \
sed 's/dn: cn={.}kerberos/dn: cn=kerberos,cn=schema,cn=config/g' | \
sed 's/{.}kerberos/kerberos/' > kerberos.ldif

sudo cp samba.ldif autofs.ldif kerberos.ldif /etc/ldap/schema/

The ldif files are now placed under /etc/ldap/schema/ and can be added using ldapadd:

sudo ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/samba.ldif
sudo ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/autofs.ldif
sudo ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/kerberos.ldif

Next it’s time to finally get to kerberos, I hope..

Veli-Matti Lintu