Lors des deux premiers posts, nous avons vu les bases de l’intégration du système supportant la NIS Gateway au sein d’Active Directory puis l’installation et le paramétrage de la NIS Gateway elle-même. Dans ce dernier article consacré à la Centrify NIS Gateway, nous allons voir la configuration d’un client NIS et quelques options de publication des maps NIS.
Tout d’abord, il faut bien comprendre que dans notre cas d’utilisation, deux composants sont utilisés sur le client Linux/UNIX:
– L’agent DirectControl de Centrify qui permet l’intégration dans Active Directory du système ainsi que les mécanisme d’authentification par Kerberos et de gestion des autorisations via LDAP
– Un client NIS générique (celui du système)
Dans ce scénario, nous conservant tous les avantages de sécurité apportés par l’agent Centrify et nous permettons l’utilisation des NIS Maps de façon classique. La différence est que les NIS maps sont stockées dans Active Directory. Ceci amène plusieurs avantages dont celui-ci extrêmement important de ne plus dépendre du NIS master unique mais d’avoir en fait le rôle de NIS master porté par les contrôleurs de domaine Active Directory, cela tombe bien, ils sont multi-maitres et la NIS Gateway agit alors en tant que NIS Slave et répond donc aux requêtes des clients NIS.
Il existe d’autres scénarios, où l’authentification peut aussi être réalisé via NIS (bon je n’aime pas dire authentification via NIS, car NIS n’est en fait pas un protocole d’authentification, mais c’est pour rendre les choses simples via la comparaison avec Kerberos) avec des maps NIS et des hash de mots de passe compatibles NIS stockés dans Active Directory. Nous ne parlerons pas ici de ce scénario car il est de moins en moins utilisé par les entreprises et surtout parce que le niveau de sécurité global n’est pas très bon –ok, meilleur qu’avec uniquement NIS, mais c’est pas terrible quand même).
Paramétrage du client NIS
Réaliser une connexion via root sur le système client NIS, dans notre exemple la machine nommée fedora23.
Nous allons tout d’abord vérifier si le service ypbind (le client NIS) est démarré et fonctionnel sur le système en exécutant la commande: systemctl status ypbind –l
si vous obtenez quelque chose qui ressemble à cela:
c’est que le service n’est pas démarré, et si il n’est pas démarré, il y a de fortes chances pour que ce soit tout simplement parce que les packages ne soient pas installés.
Un tentative de démarrage infructueuse via la commande systemctl start ypbind –l vous confirmera que les packages ne sont pas présents:
Pour installer les packages nécessaires à l’exécution du client NIS, exécuter la commande suivante: dnf -y install ypbind rpcbind
Si rpcbind est déjà installé, vous obtiendrez le message suivant, ce n’est pas bien grave:
Dans tous les cas, vous devriez obtenir quelque chose comme cela après l’installation des paquets:
Après installation des paquets, je vous conseille un petit redémarrage du système. (pas purement techniquement obligatoire, mais bon…)
Que vous ayez déjà un client NIS fonctionnel sur la machine ou que vous veniez de l’installer, il faut maintenant arrêter le service ypbind sur le système via la commande: systemctl status ypbind –l
Ensuite, nous allons supprimer tous les fichiers qui peuvent se trouver dans le répertoire var/yp/binding via la commande: rm -rf /var/yp/binding/*
Il faut maintenant définir le nom de domaine NIS auquel le client devra se référer, par défaut le nom de domaine NIS est le nom de la zone Centrify dans laquelle le système et la NIS Gateway se trouvent, dans notre exemple il se nomme donc arizona. Pour ce, exécuter la commande suivante: domainname arizona
Puis éditer le fichier /etc/yp.conf afin de renseigner le nom du domaine NIS ainsi que le nom de serveur de la NIS Gateway, dans notre exemple, il faut donc renseigner la ligne suivante: domain arizona server nisserver01
Exemple avec l’éditeur nano:
avec nano, après édition du fichier, Ctrl+O & Ctrl+X
Ensuite, démarrer le service ypbind via la commande: systemctl start ypbind –l
Vous pouvez aussi vérifier le statut du service via la commande: systemctl status ypbind –l
Note: si le client NIS ne peut pas atteindre le service NIS de la NIS Gateway, alors le service client ne démarre pas. Si vous avez une erreur au démarrage, la première chose à faire est de désactiver le firewall sur le serveur portant la NIS Gateway afin de vérifier si le problème vient du filtrage du firewall. (commande pour arrêter le firewall sur fedora: systemctl stop firewalld –l)
Donc jusque ici, tout va bien, nous avons un service NIS Gateway opérationnel et un client NIS qui est capable d’interroger le service NIS Gateway – reste maintenant à publier des maps NIS dans Active Directory afin de voir si nous sommes capables d’y accéder via la commande ypcat !
Pour publier des maps NIS dans Active Directory, nous allons simplement utiliser l’outil graphique Centrify Access Manager – Lancer l’outil, puis se rendre dans la zone (arizona, dans notre exemple) puis ‘Unix Data’, puis sélectionner le noeud ‘NIS maps’. Réaliser un clic-droit sur le noeud et choisir ‘Nouveau / Generic Map’:
Dans notre exemple, nous allons simplement créer une map générique, c’est à dire une map pour stocker des informations texte sans relation directe avec des éléments utilisés par le système. Vous pouvez bien sur créer des maps plus ‘classiques’ telle que Automount ou Netgroup par exemple.
Exemple de notre map:
Notre map se nomme donc test et contient une clé test01 de valeur test0101
Depuis le client NIS, exécuter la commande suivante: ypcat test – vous devez obtenir les valeurs de la map tel que:
Ca y est, ca fonctionne !
La commande ypwhich vous confirmera le nom du serveur NIS (la NIS Gateway) que le client utilise:
Pour aller un peu plus loin dans la compréhension, exécuter la commande ypwhich –m qui permet d’afficher la liste des maps et le serveur NIS Master pour chaque map:
Nous pouvons constater deux éléments:
(1) d’un point de vue du client NIS, la NIS Gateway est vue comme le Master NIS
(2) alors que nous n’avons créée qu’une seule map NIS (test) au niveau d’Active Directory, le client NIS perçoit quatre autres maps NIS: passwd.byuid / passwd.byname / group.byname / group.bygid – ces quatre maps NIS sont les maps dites ‘implicites’, c’est à dire qu’elles sont générées automatiquement par la NIS Gateway pour des besoins systèmes en fonction des profils UNIX et des groupes UNIX qui sont présents et actifs dans la zone Centrify arizona (pour rappel, avec la technologie Centrify, nous utilisons directement des comptes utilisateurs et des groupes Active Directory au niveau des systèmes UNIX)
Grâce à la commande ypwhich –x nous pouvons visualiser les correspondances entre les alias de nom de maps NIS (accessibles via la commande ypwhich) et le nom réel technique de certaines maps NIS:
Si maintenant nous exécutons la commande ypcat passwd nous afficherons alors le contenu de la map NIS implicite passwd.byname qui contient une représentation des profils UNIX présents dans la zone ‘arizona’:
Effectivement, si nous utilisons l’outil graphique de gestion Centrify Access Manager et si nous regardons la liste des profils UNIX effectifs dans cette zone ‘arizona’, nous retrouvons bien la même liste de comptes:
Regardons maintenant à quoi ressemble le stockage des maps NIS dans Active Directory. Pour cela, vous pouvez utiliser l’ADUC de Microsoft ou un client LDAP basique.
Si nous regardons dans le container des zones, nous retrouvons l’ensemble de nos zones Centrify. Il suffit de sélectionner la zone ‘arizona’, puis le container NisMaps. Nous retrouvons à l’intérieur de ce container la map NIS que nous avons créée, c’est à dire la map nommée ‘test’.
Sous le container de la map ‘test’, nous retrouvons notre entrée nommée ‘test01’:
Si nous regardons les propriétés de cette objet ‘test01’ (avec ADUC, réaliser un clic-droit puis choisir ‘Propriétés’), nous pouvons visualiser les différentes valeurs des différents attributs de cet objet (avec ADUC, via l’éditeur d’attributs):
Si nous regardons spécifiquement trois attributs, nous retrouvons les valeurs que nous avons renseignées lorsque nous avons créé l’entrée dans la map NIS, pour rappel:
Voici les trois attributs:
KEY: (description)
VALUE: (adminDescription)
COMMENTS: (wWWHomePage)
Bien évidement, vous pouvez utiliser les ACLs Active Directory pour donner des accès à une map NIS ou à une autre, ou même des accès spécifique à une entrée en particulier. Cela est très utile pour définir les groupes d’administrateur qui auront le droit de mettre à jour les entrées dans la maps NIS:
En effet, la différence pour les administrateur Unix sera l’interface qu’ils vont maintenant utiliser pour mettre à jours les entrées dans les maps NIS: ils pourront utiliser l’interface graphique Centrify, un browser LDAP ou des scripts LDAP. Nous pourrions même imaginer réaliser une interface dans un outil de gestion des identités comme MIM !
Ce tutoriel est terminé. N’hésitez pas à me contacter si vous avez des questions ou des interrogations existentielles sur ce type de solution !