ISO-8859-1 Encoded Characters

1. Préambule

Configuration d’un poste client Mac OS X en liaison avec les services d’annuaire cn=Open Directory @ EPFL pour permettre l’identification, l’authentification et la gestion des préférences (MCX: Managed Client for X) avec ou sans certificat installé et configuré à travers un transport SSL/TLS sécurisant les transactions LDAP. Grossièrement, établir une liaison de confiance entre un poste client et un service d’annuaire. La configuration peut commencer comme dans la section « Configuration d’un poste client Mac OS X », et se poursuit avec des éléments supplémentaires activant un transport sécurisé avec un cetificat authentifiant le service d’annuaire, ou sans certificat engageant seulement le transport (transaction) sécurisé.

Comme le client LDAP sur Mac OS X n’est pas intégré à l’architecture Keychain, les configurations se passent à la ligne de commande (cli).

Un client Mac OS X peut se joindre à n’importe quel serveur, maître ou réplique, d’une infrastructure Open Directory. Une fois le client ainsi couplé au service d’annuaire, il utilise toujours le serveur auquel il s’est joint jusqu'à quand un des services (LDAP, serveur de mot de passe ou Kerberos) devient inaccessible. De façon générale il ne faut pas coupler un client sur un maître Open Directory, mais plutôt sur une réplique, ainsi le maître peut se dédier complètement aux tâches de réplication.

Tableau 1. Liste des serveurs LDAP et de leur certificat
Nom DNS (FQDN) Schémas Expiration du certificat

opendirectory.epfl.ch

Directory Services

31 janvier 2031

ldap.epfl.ch

NIS selon la RFC 2307

14 décembre 2014

Toutes les plateformes Unix (Solaris, GNU/Linux ou BSD) qui nécessitent une liaison sécurisée conjointe avec un annuaire peuvent reprendre quasiment intégralement cette méthode.

2. Les objectifs poursuivis

a)

Définir quelques types de liaison LDAP, mais seulement celles qui sont sécurisées;

b)

vers les annuaires de l'École: Open Directory et OpenLDAP, mais pas Active Directory;

c)

configuration de l’accès aux annuaires à l’aide du protocole SSL/TLS avec ou sans certificat;

d)

quel certificat utiliser pour quel service ({ opendirectory | ldap }.epfl.ch);

e)

pour les versions (supportées) Mac OS X 10.5[.8], 10.6[.8], 10.7[.4] et OS X 10.8[.2].

3. Accès sécurisé avec certificats

Installer le certificat SSL/TLS et configurer le comportement par défaut du système d’exploitation afin que tout le trafic de données, entre le poste client et le service LDAP, soit sécurisé en ajoutant la vérification de l’authenticité du service LDAP par le certificat.

Note Un certificat est une clé numériquement signée par une entité digne de notre confiance.

Cette marche à suivre permet d’installer un ou deux certificats en fonction du ou des annuaires auxquelles le poste client doit s’adressé. Le certificat EPFL est installé pour le cas le plus courant d’un poste client Mac OS X devant se joindre au service d’annuaire cn=Open Directory @ EPFL. Dans certains cas particuliers le poste client installe le certificat QuoVadis afin de garantir un trafic de données sécurisé avec OpenLDAP. Dans de rares cas où le poste client nécessite une liaison dual vers un Open Directory et un OpenLDAP, les deux certificats cités précédemment sont installés. Le tableau résume le certificat à installer en fonction de l’annuaire vers lequel le poste client s’adressera.

Tableau 2. Un poste client, un certificat vers un annuaire

opendirectory

ldap

Certificat EPFL

QuoVadis Root CA

QuoVadis SSL ICA

OS X 10.8

◉

◉

◎

Mac OS X 10.7

◉

◉

◉

Mac OS X 10.6

◉

◉

◎

Mac OS X 10.5

◉

◉

◎
Astuce

Mac OS X 10.7 est en mesure de s’adresser à OpenLDAP avec un ou l’autre des certificats QuoVadis (Root CA ou SSL ICA).

  1. Obtenir le certificat auprès de l’Autorité de Certification de l’EPFL, ou ceux de l’Autorité de Certification QuoVadis, sous la forme d’un fichier binaire portant en général l’extension .CER (format DER, Definite Encoding Rules), ou directement au format PEM (Privacy Enhanced Mail). Le certificat public est récupérée en formant une partie de son nom avec sa date d’expiration: 

    % curl -o EPFL-2031-01-CA.pem http://certauth.epfl.ch/epflca.pem
% curl -O http://rauth.epfl.ch/Quovadis_Root_CA_2.pem
% curl -O http://rauth.epfl.ch/Quovadis_Global_SSL_ICA.pem

  2. Lancer une requête LDAP sécurisée par TLS (LDAPS) confirmant que le client n’accepte pas de certificat auto-signé (pour l’heure, et jusqu’au mois d’avril 2012, OpenLDAP accepte des liaisons non sécurisées): 

    % ldapsearch -v -x -H ldaps://opendirectory.epfl.ch -b "dc=moda,dc=epfl,dc=ch"
ldap_initialize( ldaps://opendirectory.epfl.ch:636/??base )
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

% ldapsearch -v -x -H ldaps://ldap.epfl.ch -b "o=epfl,c=ch"
ldap_initialize( ldaps://ldap.epfl.ch:636/??base )
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

    Le résultat est explicite, ni le service LDAP sur opendirectory.epfl.ch ni celui sur ldap.epfl.ch ne peuvent être contacté !

    1. Plus simplement avec la commande: 

      % ldapsearch -v -x -H ldaps://opendirectory.epfl.ch
ldap_initialize( ldaps://opendirectory.epfl.ch:636/??base )
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

% ldapsearch -v -x -H ldaps://ldap.epfl.ch
ldap_initialize( ldaps://ldap.epfl.ch:636/??base )
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
      Note

      Les commandes en ligne (cli) préfixées par le signe % indique une commande lancée par n’importe quel catégorie d’utilisateur, et une commande préfixée par un signe # indique une commande à lancer par l’administrateur du système, habituellement root (sudo -s).

  3. Création du dossier d’accueil des certificats, et y placer ceux nécessaires (obtenu précédemment): 

    # mkdir /etc/openldap/Certs
# cp EPFL-2031-01-CA.pem /etc/openldap/Certs
# cp Quovadis_Root_CA_2.pem /etc/openldap/Certs
# cp Quovadis_Global_SSL_ICA.pem /etc/openldap/Certs
# chown -R root:wheel /etc/openldap/Certs
    Important

    Une mise à niveau du système efface le dossier d’accueil des certificats. Par exemple en évoluant de Snow Leopard (10.6) vers Lion (10.7) ou de Lion vers Mountain Lion (10.8). Deux options sont envisageables:

    1. Sauvegarder le dossier des certificats avant la mise à niveau et le restaurer ensuite à son emplacement d’origine.

    2. Placer d’emblée le dossier des certificats là où le processus de mise à niveau n’agit pas.

Astuce

Dans le cas plus général, donc moins idéal que celui de l’EPFL, le certificat récupéré peut être au format binaire DER dont les extensions usuelles sont: .der, .cert, .crt ou encore .cer, et doit être transcrit au format PEM à l’aide de la commande suivant (exemple):

% openssl x509 -inform der -outform pem < epflca.cer > epflca.pem

  1. Afin qu’OpenSSL puisse utiliser le certificat, l’empreinte numérique du certificat doit être produite et nommé particulièrement (par l’ajout à la fin de la valeur d’un < .0 >) pour être trouvée par le mécanisme d’utilisation de clés. L’empreinte numérique du certificat peut être produite de deux façons; par un script Apple ou par un commande standard respectivement.

    1. Par le script Mac OS X Serveur 

      # cd /etc/openldap/Certs
# /System/Library/OpenSSL/misc/c_hash *.pem
2f054c23.0 => EPFL-2031-01-CA.pem
797b9cad.0 => Quovadis_Global_SSL_ICA.pem
7a819ef2.0 => Quovadis_Root_CA_2.pem

# ln -s EPFL-2031-01-CA.pem 2f054c23.0
# ln -s Quovadis_Global_SSL_ICA.pem 797b9cad.0
# ln -s Quovadis_Root_CA_2.pem 7a819ef2.0

    2. En commandes standard (OpenSSL) 

      # openssl x509 -hash -noout -in EPFL-2031-01-CA.pem
2f054c23

# ln -s EPFL-2031-01-CA.pem 2f054c23.0

  2. Vérifier la validité des certificats (facultatif). La commande est interrompue avec la séquence de touche <ctrl><D>: 

    % openssl s_client -connect opendirectory.epfl.ch:636 -verify 10 \
    -CAfile /etc/openldap/Certs/2f054c23.0

% openssl s_client -connect ldap.epfl.ch:636 -verify 10 \
    -CAfile /etc/openldap/Certs/797b9cad.0

% openssl s_client -connect ldap.epfl.ch:636 -verify 10 \
    -CAfile /etc/openldap/Certs/7a819ef2.0

  3. Éditer le fichier de configuration LDAP pour vérifier que la valeur de la directive TLS_REQCERT soit sur demand, et ajouter la dernière ligne faisant référence à l’emplacement des certificats: 

    # vi /etc/openldap/ldap.conf
TLS_REQCERT     demand
TLS_CACERTDIR   /etc/openldap/Certs
    Note

    La vérification des certificats du client LDAP depuis Mac OS X v10.5 (client comme serveur) est très strict par défaut. Le fichier de configuration /etc/openldap/ldap.conf propose la directive suivante:

    TLS_REQCERT     demand

    Ainsi le client LDAP refuse d’entrer en session TLS avec le service LDAP si aucun certificat n’est fournit ou si le certificat fournit ne prouve pas l’authenticité du serveur LDAP auquel il s’adresse. (Par défaut avant Mac OS X v10.4 la directive TLS_REQCERT était never). La directive TLS_REQCERT peut-être changée de demand à never menant le client LDAP à ignorer la validité du certificat, mais ce n’est pas souhaitable. Il est de loin préférable et plus prudent d’indiquer où se trouvent les certificats auxquels on accorde notre confiance (page de manuel ldap.conf(5)). Le niveau de vérification never peut se justifier dans certain cas, impliquant une session TLS (liaison sécurisée) mais sans vérification de l’authenticité de serveur LDAP.

  4. Lancer une requête LDAP sécurisée par TLS (LDAPS) confirmant que le client accepte le certificat de l’Autorité de Certification de l’EPFL: 

    % ldapsearch -LLL -x -H ldaps://opendirectory.epfl.ch -b "dc=moda,dc=epfl,dc=ch" \
    cn='pascal fabbri' dn
dn: uid=fabbri,cn=users,dc=moda,dc=epfl,dc=ch

% ldapsearch -LLL -x -H ldaps://ldap.epfl.ch -b "o=epfl,c=ch" \
    cn='pascal fabbri' dn
dn: cn=Pascal Fabbri,ou=dit-sb,ou=p-dit,ou=p,o=epfl,c=ch

    1. Plus simplement avec la commande: 

      % ldapsearch -v -x -H ldaps://opendirectory.epfl.ch
ldap_initialize( ldaps://opendirectory.epfl.ch:636/??base )
filter: (objectclass=*)
requesting: All userApplication attributes
# extended LDIF
#
# LDAPv3
# base <> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object

# numResponses: 1

% ldapsearch -v -x -H ldaps://ldap.epfl.ch

  5. Avec Directory Utility engager la liaison sécurisée SSL (alias SSL/TLS) vers le serveur opendirectory.epfl.ch pour obtenir une ligne proche de celle-ci:

    Enable Configuration Name Server Name or IP Addresses LDAP Mapping SSL

    ◉

    Open Directory @ EPFL

    opendirectory.epfl.ch

    From Server

    ◉

  6. Et pour terminer, relancer le service d’annuaire sur le poste client, mais seulement sur Mac OS X 10.5 et 10.6, pas pour Lion (10.7) ou Mountain Lion (10.8). 

    # killall DirectoryService

À partir de maintenant le client est en mesure d'échanger des informations par le protocole LDAP sécurisé vers les deux serveurs qui ont chacun un certificat différent.

4. Accès sécurisé sans certificat

Le transport de données et les transactions sont sécurisés. La vérification des certificats du client LDAP depuis Mac OS X v10.5 est très strict par défaut, en raison de la valeur de la directive contenue dans le fichier de configuration LDAP:

TLS_REQCERT demand

La valeur demand rejette tous les certificats, y compris ceux auto-signés, tant qu’aucun certificat n’est installé et configuré spécifiquement pour le service LDAP auquel il s’adresse. Cette contrainte est présente depuis Mac OS X 10.5.

Pour revenir à un mode de fonctionnement plus souple, mais déconseillé en tous cas pour l’EPFL, on peut remplacer la valeur demand par never, ainsi le client LDAP bénéficie d’un trafic sécurisé, mais sans vérification de l’authenticité du serveur LDAP auquel il s’adresse.

  1. Lancer une requête LDAP sécurisée par TLS (LDAPS) confirmant que la session vers le service LDAP n’aboutit pas: 

    % ldapsearch -v -x -H ldaps://ldap.epfl.ch -b "o=epfl,c=ch"
ldap_initialize( ldaps://ldap.epfl.ch:636/??base )
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

  2. Éditer le fichier de configuration LDAP et remplacer la valeur demand de la directive TLS_REQCERT par never: 

    # vi /etc/openldap/ldap.conf
TLS_REQCERT never

  3. Lancer une requête LDAP sécurisée par TLS (LDAPS) confirmant une liaison sécurisée opérationnelle: 

    % ldapsearch -LLL -x -H ldaps://ldap.epfl.ch -b "o=epfl,c=ch" \
    cn='pascal fabbri' dn
dn: cn=Pascal Fabbri,ou=dit-sb,ou=p-dit,ou=p,o=epfl,c=ch

  4. Ne pas oublier avec Directory Utility d’engager la liaison SSL (alias SSL/TLS) vers le serveur ldap.epfl.ch pour obtenir une ligne proche de celle-ci:

    Enable Configuration Name Server Name or IP Addresses LDAP Mapping SSL

    ◉

    OpenLDAP @ EPFL

    ldap.epfl.ch

    RFC 2307 (Unix)

    ◉

    Search Base Suffix

    o=epfl,c=ch

  5. Et pour terminer, relancer le service d’annuaire sur le poste client, mais seulement sur Mac OS X 10.5 et 10.6, pas pour Lion (10.7) ou Mountain Lion (10.8). 

    # killall DirectoryService
Note

Pour forcer le client à dialoguer en LDAPS (SSL/TLS), sans modifier le service Open Directory @ EPFL, il est possible d’engager un filtre du type Firewall (page de manuel ipfw(8) jusqu'à 10.6 et pfctl(8) depuis 10.7) pour bloquer le port non sécurisé LDAP n° 389.

5. Exemple pratique

Cette configuration permet à un poste client v10.6.8 une liaison sécurisée à travers un transport SSL et un certificat vérifié vers un annuaire OpenLDAP.

Tableau 3. Caractéristiques de la liaison

version système du client

10.6.8

type de service d’annuaire

OpenLDAP

schéma LDAP

NIS selon la RFC 2307

échanges chiffrés

Secure Sockets Layer (SSL/TLS)

certificat

authenticité vérifié

  1. Le ou les certificats sont déjà installés et vérifiés avec au moins les deux lignes suivantes présentes dans le fichier de configuration LDAP /etc/openldap/ldap.conf: 

    TLS_REQCERT     demand
TLS_CACERTDIR   /etc/openldap/Certs

  2. Ajouter à l’annuaire local, dans la table Hosts, le nom et l’adresse de l’annuaire OpenLDAP à rejoindre: 

    # dscl localhost -create /Local/Default/Hosts/ldap.epfl.ch IPAddress 128.178.222.15
    Note

    De façon moins pérenne les hôtes (machines) et leur adresse IP peuvent aussi s’inscrire dans la table /etc/hosts selon la syntaxe habituel en vigueur avec Unix:

    # vi /etc/hosts
128.178.222.15  ldap.epfl.ch

    En règle générale il est souhaitable d’utiliser les tables organisées sous forme d’enregistrements dans l’annuaire local lorsqu’elles existent en lieu et place de celles habituellement logées sous /etc.

  3. Avec Directory Utility engager la liaison sécurisée vers le serveur ldap.epfl.ch en respectant les paramètres suivants:

    Enable Configuration Name Server Name or IP Addresses LDAP Mapping SSL

    ◉

    OpenLDAP @ EPFL

    ldap.epfl.ch

    RFC 2307 (Unix)

    ◉

    Search Base Suffix

    o=epfl,c=ch

    En sélectionnant Modifier…, l’onglet de Connexion doit au moins comporter les éléments suivants:

    ◉

    Encrypt using SSL

    ◎

    Use custom port [636]

    ◉

    Ignore server referrals

    Du côté des Règles de recherche, autant Authentification que Contact auront un chemin de recherche personnalisé incluant le domaine de répertoire nouvellement créé, à savoir /LDAPv3/ldap.epfl.ch.

  4. On terminera en relançant le service d’annuaire. 

    # killall DirectoryService