> Tech > Intégration des systèmes Unix, Linux et Macintosh dans Active Directory, mode d’emploi

Intégration des systèmes Unix, Linux et Macintosh dans Active Directory, mode d’emploi

Tech - Par iTPro - Publié le 09 mai 2011
email


La description complète des différentes possibilités, ainsi que les détails techniques pour chacune de ces orientations ne peuvent pas tenir dans cet article. Afin de réduire le spectre, nous réaliserons donc un focus sur l'intégration de la partie système d'exploitation, et parlerons beaucoup moins de l'intégration applicative.

/>

L'intégration d'un système non-Microsoft comporte globalement 3 composantes:
– La création du compte machine d'un point de vue LDAP
– la création des différents SPN pour les mécanismes Kerberos
– le paramétrage côté client du système d'exploitation

Création du compte machine

L'idée est ici d'avoir un compte machine qui représente le système Unix, Linux ou Macintosh dans Active Directory afin qu'il soit géré comme une ressource "classique" tel que le serait un compte machine représentant une machine Windows.

Il est tout à fait possible de réaliser cela en utilisant les services SAMBA sur un système non-Microsoft, permettant "l'émulation" d'un système Windows de la part d'un système Unix, Linux ou Macintosh. D'une certaine façon, Active Directory considère alors la machine comme une machine Windows. Il est alors possible de voir le compte machine dans Active Directory.

Création des différents SPN pour les mécanismes Kerberos

Afin de permettre le fonctionnement des mécanismes Kerberos, il est nécessaire de créer une entrée Kerberos dans le KDC en utilisant l'utilitaire ktpass.exe et de créer les ServicePrincipalNames (SPN) pour les différents services s'appuyant sur les mécanismes de tickets Kerberos en utilisant l'utilitaire setspn.exe. Il est alors tout à fait possible de visualiser les différents SPN via l'éditeur d'attributs de l'objet dans Active Directory.

Une fois les SPN créés, il est nécessaire d'exporter le fichier keytab depuis le KDC, le fichier keytab sera ensuite importé coté client – le mécanisme d'import peut être différent en fonction des systèmes d'exploitation.

Le paramétrage côté client du système d'exploitation

Les systèmes Unix utilisent deux notions complémentaires pour gérer les authentifications et les autorisations. Il s'agit des fichiers pam.conf gérant le paramétrage des modules PAM (Pluggable Authentication Modules) et nsswitch.conf (Name Service Switch).

Globalement, le fichier de configuration pam.conf indique aux systèmes vers quels modules se tourner pour gérer les différentes primitives liées à l'authentification au travers de quatre mécanismes (account, auth, password et session). Sur les systèmes plus récents, plusieurs fichiers présents dans le répertoire /etc/pam.d remplacent le fichier pam.conf.

Il s'agit alors de modifier le fichier pour lui indiquer les librairies à utiliser pour l'authentification, la syntaxe varie en fonction des systèmes, mais globalement, pour le mécanisme login-auth, l'idée est de fournir un PAM ressemblant à la syntaxe suivante: pam_kerberos_auth.so

Bien évidement, il faut au préalable que le système client possède les librairies Kerberos, librairies qui sont téléchargeables sur le site du MIT.

Il reste à noter que les notions de PAM différent fortement en fonction des différents systèmes de type Unix, notamment entre les systèmes Unix propriétaires et les systèmes Linux. De plus, IBM AIX possède son propre système de PAM nommé LAM.

Le fichier nsswitch.conf permet de fournir la liste des bases de comptes disponibles pour réaliser l'authentification (annuaires ou fichiers plats). Bien évidement, il existe des combinaisons heureuses ou malheureuses entre le fichier pam.conf et le fichier nsswitch.conf, certaines associations ne pouvant pas fonctionner ensemble, le fonctionnement du système peut s'en trouver déstabilisé ou carrément bloqué ! Il faut donc faire très attention…

Dans le fichier nsswitch.conf, la ligne commençant par passwd, représente la liste des annuaires pour la base de comptes, et l'ordre d'interrogation. Traditionnellement, la valeur files représente la base de comptes locale (le fichier /etc/passwd) mais il faudra ici remplacer les annuaires de type nis par une entrée de type ldap. De la même façon, la ligne commençant par shadow représente la liste des annuaires à consulter pour la vérification des mots de passe, il faudra également indiquer une entrée de type ldap.

L'ensemble des ces paramètres peuvent différer en fonction des systèmes d'exploitation de type Unix. Globalement la convention de nommage des fichiers de configuration, l'endroit ou les fichiers de configuration sont stockés et les paramétrages à l'intérieur des fichiers de configuration peuvent être sensiblement différents en fonction de Solaris, HP-UX, AIX, RedHat, Suse, FreeBSD ou même Mac OS X.

Première partie du dossier

Téléchargez gratuitement cette ressource

Endpoint Security : Guide de Mise en œuvre

Endpoint Security : Guide de Mise en œuvre

Détournement d’applications légitimes, élévation de privilèges, logiciels malveillants furtifs : comment les solutions de Endpoint Security permettent elles de faire face aux nouvelles techniques d'attaques complexes ? Découvrez, dans ce Guide Endpoint Security, les perspectives associées à leur mise en œuvre.

Tech - Par iTPro - Publié le 09 mai 2011