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

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

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

Vakio-ominaisuudet kaikille asiakkailla:

• Käyttäjätunnukset ja kotihakemistot: Jokainen käyttäjä saa oman tunnuksen ja kotihakemiston. Koneelta kuin koneelta pääsee siis omiin tiedostoihin käsiksi.
• Yhteiset kansiot: Koululle voidaan luoda yhteisiä kansioita käyttäjäryhmien mukaan. Esimerkiksi opettajilla voi siis olla oma jaettu kansio ja koulun atk-kerholla oma. Kansiot ja niiden käyttöoikeudet tehdään koulun tarpeiden mukaan.
• Varmistuspalvelu: Käyttäjien kansiot ja koulun yhteiset kansiot varmistetaan päivittäin. Tiedostot ovat siis turvassa.
• Käyttäjätietojen muokkaus web-selaimella: Uuden käyttäjän luonti tai salasanan vaihto toimii selaimen kautta. Tunnuksia ei siis tarvitse tilata puhelimella tai sähköpostilla tukipalvelun kautta. Opettaja-ryhmään kuuluvat käyttäjät voivat vaihtaa oppilaan salasanan – apua saa siis läheltä ja nopeasti.
• Ohjelmat käyttäjäryhmän tarpeiden mukaan: Valikossa näkyvät ohjelmat voidaan valita käyttäjäryhmän mukaan. Alakoululaisille ei näin tarvitse näkyä samoja ohjelmia kuin lukiolaisille. Myös ohjelmalistan muokkaukset hoituvat helposti web-selaimen kautta.
• Automatisoidut sammutukset: Koneita ei tarvitse manuaalisesti sammuttaa. Voitte itse päättää ajan, jonka jälkeen koneet sammuvat automatisoidusti, jos kukaan ei niitä käytä. Luonto ja lompakko kiittävät, kun sähköä säästyy.

Erikseen tilattavia lisäominaisuuksia:

• Käyttäjätunnukset web-sovelluksiin: Linux-palvelimen käyttäjäkantaa voi hyödyntää useat web-sovellukset kuten Moodle, wikit, sähköpostit jne. Näin oppilailla on vain yksi tunnus, joka toimii useissa järjestelmissä. Tämä helpottaa myös tunnusten ylläpitoa.
• Etäkäyttö: Myös kotoa pääsee käsiksi koulun kotihakemistoon ja tarvittaessa myös koulun ohjelmiin – kotikoneen käyttöjärjestelmästä riippumatta. Tiedostoja ei siis tarvitse enää usb-tikulla kantaa, jos kotoa nettiyhteys löytyy.
• Windows-yhteensopivuus: Koululle syystä tai toisesta jäävät windows-koneet voivat käyttää samoja käyttäjätunnuksia ja tallennustiloja kuin linux-päätteet.
• Info-tv: Koulujen info-taulut sisäiseen tiedottamiseen. Ruutujen sisältöä voidaan hallita web-selaimen kautta.
• Nettikulma: Raggarin kestävää tietotekniikkaa koulujen käytäville.

Eikä siinäkään vielä kaikki! Uusia ominaisuuksia on tulossa lisää, kun saamme lähitulevaisuudessa uudet versiot käyttäjien-, laitteiden- ja työpöydänhallinnasta käyttöön. Myös seuraava versio Ubuntusta (Lucid Lynx) tuonee mukanaan uudistuksia.

Eero Nukari, 050-529 4445, eero.nukari@opinsys.fi

Tällä viikolla Ruovedellä kokoontui nelisenkymmentä ihmistä tutustumaan Ruoveden Kirkonkylän koulun kärkikouluhankkeeseen. Tapahtuman parasta antia oli varmasti keskutelu oppilaskeskeisyydestä sekä opettajien aina muutoksessa tarvitsemasta koulutuksesta ja tuesta:  http://jarkitehdas.blogspot.com/

Opinsys osallistui tapahtumaan ja esitteli vieraille toteuttamaamme Linux-ratkaisua.  Oppilaiden ajatuksia ratkaisusta löytyy Ylen uutispätkästä 4min kohdalla:

Ylen verkkosivuilla uutisjuttu.

Uutisessa käy hyvin ilmi kuin Linuxilla toteutussa LTSP-ratkaisussa voidaan työpisteinä käyttää vanhatkin tietokoneet. Opinsysin kautta Ruovedenkin koulut ovat saaneet lisää tietokoneita koulujen käyttöön ja oppilaiden iloksi.

Kiitokset vielä Vesalle, Jukalle ja Markukselle sekä koulun opettajille tapahtuman järjestämisestä!

18.2 järjestetään webinaari koulujen linux-ratkaisuihin liittyen.

Suomen avoimen lähdekoodin keskuksen (COSS:in) oppilaitoksiin erikoistunut siipi EduCOSS järjestää 18.2 webinaarin teemalla ”Minkälaiseen LTSP-ratkaisuun Kemi on päätymässä?”.  Lisätietoja ja ilmottautumiset webinaarin löytyvät EduCOSS:in blogista.  Webinaarin promoottorina toimii koulujen open source -ratkaisujen erikoismies Elias Aarnio. Case Kemiä esittelee hankkeen puuhamies Antti Turunen. Luonnollisesti myös Opinsysiltä olemme webinaarissa mukana.

Eero Nukari, eero.nukari@opinsys.fi, 050-529 4445

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

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

Perjantai
10.30-11.30  Kärkikoulu Ruovedeltä tavattavissa Opinsysin osastolla

13.00-14.00  Kärkikoulu Kauniaisista tavattavissa Opinsysin osastolla

14.15–15.00  Parhaat toimintamalli, Lankinen – Linden – Vahtivuori-Hänninen. Messukeskuksen salissa 1.

Lauantai

10.30-11.30  Kärkikoulu Ruovedeltä tavattavissa Opinsysin osastolla

12.00-13.00  Kärkikoulu Kauniaisista tavattavissa Opinsysin osastolla

13.00–13.45  Tieto- ja viestintätekniikka koulun arjessa -hankkeen tuloksista, Vahtivuori-Hänninen & Kankaanranta. Sali 2.

The following documents were used:

• Ubuntu’s OpenLDAP documentation for Karmic
• HowtoForge’s article on installing OpenLDAP on Karmic
• gnutls manual: Invoking certtool
• GnuTLS howto on Ubuntuforums

There are various tutorials around the net telling how to make self-signed certificates using openssl. Googling reveals quite a few problems with using self-signed certificates created with openssl with debian’s and ubuntu’s slapd that uses gnutls. For this example I’ll use the certtool that comes with the gnutls-bin.

The goal here is to create CA (ca.edu.example.org) and sign the server key with the CA. The client can then use the CA certificate to check the validity of the server key (ldap.edu.example.org) that is used by the slapd daemon.

To get started the gnutls-bin package needs to be installed:

sudo apt-get install gnutls-bin

First the CA key needs to be created and signed:

certtool --generate-privkey --outfile slapd-ca-key.pem
certtool --generate-self-signed --load-privkey slapd-ca-key.pem \
--outfile slapd-ca-cert.pem

This asks questions about the usage of the certificate. To get a ten year one I used the following options:

Common name: ca.edu.example.org
The certificate will expire in (days): 3650

Does the certificate belong to an authority? (y/N): y
Path length constraint (decimal, -1 for no constraint): -1
Will the certificate be used to sign other certificates? (y/N): y

Next create the server key and certificate:

certtool --generate-privkey --outfile slapd-server.key
certtool --generate-certificate --load-privkey slapd-server.key \
--outfile slapd-server.crt --load-ca-certificate slapd-ca-cert.pem \
 --load-ca-privkey slapd-ca-key.pem

The common name needs to be ldap.edu.example.org for the slapd certificate:

Common name: ldap.edu.example.org
The certificate will expire in (days): 3650
Will the certificate be used for signing (required for TLS)? (y/N): y
Will the certificate be used for encryption (not required for TLS)? (y/N): y

The files slapd-ca-cert.pem slapd-server.{crt|key} need to be copied to /etc/ssl/certs/ where slapd can load them:

sudo install -D -o openldap -g openldap -m 600 slapd-server.crt \
             /etc/ssl/certs/slapd-server.crt
sudo install -D -o openldap -g openldap -m 600 slapd-server.key \
             /etc/ssl/certs/slapd-server.key

#!/bin/sh

ldapmodify -Y EXTERNAL -H ldapi:/// << EOF
dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/slapd-ca-cert.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/slapd-server.crt
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/certs/slapd-server.key
EOF

On the client copy ca-cert.pem to /etc/ldap/ssl:

sudo install -o root -g root -m 644 slapd-ca-cert.pem \
             /etc/ssl/certs/slapd-ca-cert.pem

URI ldap://ldap.edu.example.org/
TLS_CACERT /etc/ssl/certs/slapd-ca-cert.pem

Now we can check that TLS works:

ldapsearch -x -h ldap.edu.example.org -ZZ -b dc=edu,dc=example,dc=org

It should return the organizationalUnits created earlier.

Thanks for all the people who have documented the various tools needed to get this working! Next it's time to get to see how the kerberos setup has changed..

Veli-Matti Lintu