• chevron_right

      Configure OpenLDAP to use Kerberos as password backend

      Adrien Dorsaz · community.adorsaz.ch / debian-stretch · Friday, 1 February, 2019 - 11:10 · 5 minutes

    This text reports what I've done to use Kerberos as password backend for my OpenLDAP installation. It was tried on a Debian Stretch 9.



    apt install krb5-kdc krb5-admin-server

    apt will ask you the name of your default kerberos realm.

    I've decided to use example.org (in lowercase), because, even if it's not the usual case as explained by apt, I know I'll forgot to use the uppercase notation. Furthermore, I have a specific domain which is only used by LDAP and Kerberos, so I think I'll have no confusion.

    Configure Kerberos

    I've just followed my Kerberos Installation resource (linked at the end of the article). So I notice here just what I've done, I can't fully explain every steps.

    First, we need to configure the Kerberos server by modifying /etc/krb5.conf to add our realm:

                    default_realm = example.org
                    example.org = {
                            kdc = kdc.example.org
                            admin_server = kdc.example.org
                            default_domain = example.org
                    .example.com = example.org
                    example.com = example.org

    To define the kdc and admin_server, you can also simply use the localhost domain. If you do as me, you'll need to create DNS resources for kdc.example.org.

    Then, you need to check the realm has been well installed in /etc/krb5conf/kdc.conf. For me, apt has put:

        kdc_ports = 750,88
        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 aes128-cts:normal
            default_principal_flags = +preauth

    Now, the kerberos is well configured, we can create the realm:

    kdb5_util create -s

    Then, we use the kadmin.local shell to list principals and create first users:

    kadmin.local:  listprincs
    kadmin.local:  ank adrien/admin@example.org
    WARNING: no policy specified for adrien/admin@example.org; defaulting to no policy
    Enter password for principal "adrien/admin@example.org": 
    Re-enter password for principal "adrien/admin@example.org": 
    Principal "adrien/admin@example.org" created.
    kadmin.local:  ank adrien@example.org
    WARNING: no policy specified for adrien@example.org; defaulting to no policy
    Enter password for principal "adrien@example.org": 
    Re-enter password for principal "adrien@example.org": 
    Principal "adrien@example.org" created.

    Create the kadmin keytab as explained in the MIT documentation:

    kadmin.local:  ktadd -k /etc/krb5kdc/kadm5.keytab kadmin/admin kadmin/changepw
    Entry for principal kadmin/admin with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5kdc/kadm5.keytab.
    Entry for principal kadmin/admin with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5kdc/kadm5.keytab.
    Entry for principal kadmin/changepw with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5kdc/kadm5.keytab.
    Entry for principal kadmin/changepw with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5kdc/kadm5.keytab.

    Finally, edit the file /etc/krb5kdc/kadm5.acl to set up users with admin rights:

    */admin@example.org *

    Restart kerberos services:

    systemctl restart krb5-kdc krb5-admin-server

    Check with a client

    On another computer, try to get a kerberos ticket with the client.

    First, install the client: apt install krb5-user

    Then, try to authenticate: kinit adrien@example.org

    On success, you can list current tickets with klist:

    # klist
    Ticket cache: FILE:/tmp/krb5cc_1000
    Default principal: adrien@example.org
    Valid starting       Expires              Service principal
    01. 02. 19 11:30:25  01. 02. 19 21:30:25  krbtgt/example.org@example.org
        renew until 02. 02. 19 11:30:03

    To clean the ticket from the client, use: kdestroy.

    Cyrus SASL


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

    Configure Cryus SASL

    Edit the service environment variables in /etc/default/saslauthd with:

    export KRB5_KTNAME

    According to the value of KRB5_KTNAME above, we'll create a new user and its keytab file with kadmin.local:

    kadmin.local:  addprinc -randkey host/localhost
    WARNING: no policy specified for host/localhost@example.org; defaulting to no policy
    Principal "host/localhost@example.org" created.
    kadmin.local:  ktadd -k /etc/localhost.keytab host/localhost
    Entry for principal host/localhost with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/etc/localhost.keytab.
    Entry for principal host/localhost with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:/etc/localhost.keytab.

    Finally, restart the saslauthd service: systemctl restart saslauthd

    Check saslauthd configuration

    There's a little command to check if you can connect with your user through Cyrus SASL:

    # testsaslauthd -u adrien@example.org -p 'your password in clear text'
    0: OK "Success."

    On authentication error, the output will be 0: NO "authentication failed".

    If you see other errors, like one with connect() fail, check the daemon saslauthd use the right keytab file and it has access to it.


    Endly, we are in the final part of the documentation. We just need now to say to OpenLDAP that it can use saslauthd as external authentication mechanism and configure our first user to use it.

    Enable Cyrus SASL backend

    We need to create a /etc/ldap/sasl2/slapd.conf with these values:

    # PLAIN is used by saslauthd
    # EXTERNAL is required for local root auth
    mech_list: PLAIN EXTERNAL
    pwcheck_method: saslauthd
    saslauthd_path: /var/run/saslauthd/mux

    Note that OpenLDAP will need access to /var/run/saslauthd/mux. On my installation, the access to the content of /var/run/saslauthd/ is allowed only to users inside the sasl group, so we add openldap to this group:

    adduser openldap sasl

    Finally, restart the slapd service: systemctl restart slapd

    Modify user to use the SASL backend

    Now, we need to modify the adrien@example.org user to authenticate through SASL. That's simply done by setting the prefix {SASL} followed by the kerberos user name (with realm) inside the userPassword attribute.

    For example, I've made this ldif file:

    # adrien, people, example.org
    dn: uid=adrien,ou=people,dc=example,dc=org
    changetype: modify
    replace: userPassword
    userPassword: {SASL}adrien@example.org

    Note that to apply this ldif you need to use a user with modification rights on userPassword attribute (the user itself or an administrator).

    ldapmodify -f 01_adrien_password.ldif -D "uid=adrien,ou=people,dc=example,dc=org" -w 'your old LDAP password in clear text'

    Finally, to check the new password is well set, you can simply try to do a search inside your LDAP directory:

     # ldapsearch -D "uid=adrien,ou=people,dc=example,dc=org" -w 'your new password in clear text' -b '' -s base
    # extended LDIF
    # LDAPv3
    # base <> with scope baseObject
    # filter: (objectclass=*)
    # requesting: ALL
    objectClass: top
    objectClass: OpenLDAProotDSE
    # search result
    search: 2
    result: 0 Success
    # numResponses: 2
    # numEntries: 1

    Well done, that was a big job to retrieve every steps to do, thanks a lot of people who documented their steps ! I hope this document will help someone in the future :)


    1. Kerberos installation
    2. OpenLDAP with external password backend through sasl2authd
    3. OpenLDAP documentation for Pass-Through authentication
    4. OpenLDAP Authentication With Kerberos Backend Using SASL
    • chevron_right

      Installation de FusionDirectory

      Adrien Dorsaz · community.adorsaz.ch / debian-stretch · Thursday, 14 September, 2017 - 13:02 edit · 3 minutes

    Debian Stretch a une version relativement récente de Fusion Directory (1.0.19 qui date de début 2017), mais suite à quelques soucis avec celui-ci, j'ai préféré installer directement la version de Fusion Directory.

    Je profite de l'installation du service sur mon serveur pour prendre note des éléments utiles pour ce contexte.

    La documentation officielle de FusionDirectory se trouve sur leur wiki, en particulier les pages d'installation pour Debian.

    Installation d'un serveur LDAP

    La documentation propose d'installer OpenLDAP. L'installation se passe simplement avec les paquets Debian. Elle vous demandera de saisir un mot de passe pour l'administrateur du service LDAP.

    sudo apt install slapd ldap-utils

    Configuration d'OpenLDAP

    Après avoir installé le service, il faut le reconfigurer pour renseigner votre nom de domaine LDAP:

    sudo dpkg-reconfigure slapd

    La configuration pose ces questions:

    1. « Voulez-vous omettre la configuration d'OpenLDAP ? » Réponse : Non
    2. « Nom de domaine : » Réponse : votre nom de domaine selon l'explication du message (par exemple, « adorsaz.org »). Faites-attention, ce sera la racine de votre configuration, tout y sera lié.
    3. « Nom d'entité : » Réponse: je ne sais pas très bien, la documentation de FusionDirectory propose de mettre le sous-domaine (donc « adorsaz » pour moi)

    Ensuite, saisissez à nouveau le mot de passe administrateur choisi (deux fois).

    Questions suivantes:

    1. « Module de base de données à utiliser :» Réponse : suivez la recommandation MDB (la documentation de Fusion Directory est un peu vieille et recommande HDB, car MDB n'était pas proposé avant).
    2. « Faut-il supprimer la base de données lors de la purge du paquet ? » Réponse : selon vos besoins, j'ai choisi « Oui » car je m'attends à ce qu'une purge d'un paquet efface tout.
    3. « Faut-il déplacer l'ancienne base de données ? » Réponse : j'ai dit oui, car l'ancienne base était vide.

    Pour être sûr qu'OpenLDAP est en fonction, utilisez la commande systemctl status slapd.

    Ajout des dépots FusionDirectory

    Pour récupérer directement la dernière version de FusionDirectory, il vous faut mettre dans votre fichier /etc/apt/sources.list, les lignes suivantes:

    # main fusion directory
    deb http://repos.fusiondirectory.org/fusiondirectory-current/debian-jessie jessie main
    # fusiondirectory extra repository
    deb http://repos.fusiondirectory.org/fusiondirectory-extra/debian-jessie jessie main

    Ajoutez bien les 2 répertoires, même si le second s'appelle extra. Il contient des dépendances nécessaires aux outils de FusionDirectory.

    Bien que ce soit écrit jessie dans les lignes, les paquets peuvent être installés sur Debian Stretch pour l'instant d'après mon expérience.

    Cette petite ambiguïté est finalement pratique pour installer facilement FusionDirectory et ses dépendances aux dernières versions:

    apt install -t jessie -f fusiondirectory fusiondirectory-schema

    Configuration du schéma LDAP pour FusionDirectory

    Pour configurer FusionDirectory dans votre nouvelle base LDAP, il faut installer le paquet fusiondirectory-schema (voir ci-dessus).

    Vous pouvez lister les schémas installés avec la commande suivante:

    sudo fusiondirectory-insert-schema -l

    FusionDirectory a besoin au moins d'installer les schémas suivants dans cet ordre:

    # Schémas pour OpenLDAP:
    sudo fusiondirectory-insert-schema /etc/ldap/schema/core.schema
    sudo fusiondirectory-insert-schema /etc/ldap/schema/cosine.schema
    sudo fusiondirectory-insert-schema /etc/ldap/schema/nis.schema
    sudo fusiondirectory-insert-schema /etc/ldap/schema/inetorgperson.schema
    # Schémas pour FusionDirectory
    sudo fusiondirectory-insert-schema /etc/ldap/schema/fusiondirectory/core-fd-conf.schema
    sudo fusiondirectory-insert-schema /etc/ldap/schema/fusiondirectory/core-fd.schema
    sudo fusiondirectory-insert-schema /etc/ldap/schema/fusiondirectory/ldapns.schema
    sudo fusiondirectory-insert-schema /etc/ldap/schema/fusiondirectory/template-fd.schema

    Quand vous installerez de nouveaux plugins pour FusionDirectory, vous aurez aussi sûrement besoin d'installer les schémas des plugins (un de configuration et un autre système).

    Attention, lors des mises à jour de FusionDirectory, il faut bien lire les guides de migrations sur leur Wiki pour vérfier si des schémas doivent être mis à jour.

    Installation de FusionDirectory

    La commande d'installation du paquet de FusionDirectory aura installé et préparé le site web qui permettra d'accéder à FusionDirectory.

    Ajustez la configuration Apache2 et PHP à vos usages (personnellement, j'utilise php-fpm pour servir mes sites).

    Ensuite, accédez au lien que vous aurez configuré et suivez les instructions d'installation.

    Enfin, vous pourrez modifier les paramétrages de Fusion Directory.

    Activation du module OpenLDAP memberOf à faire avant de créer les groupes

    La configuration d'OpenLDAP par défaut ne vous permettra pas de faire des recherches du style les membres du groupe xmpp-user peuvent se connecter à mon serveur XMPP.

    Pour pouvoir effectuer cette requête, il faut modifier la configuration d'OpenLDAP pour:

    1. Demander de charger le module memberOf
    2. Demander de charger le module d'intégrité des données
    3. Configurer le module memberOf
    4. Configurer le module d'intégrité

    Pour sa configuraiton, OpenLDAP passe par l'utilisation de la commande ldapmodify et des fichiers de configurations *.ldiff.