Nous allons tout d\u2019abord v\u00e9rifier si le service ypbind (le client NIS) est d\u00e9marr\u00e9 et fonctionnel sur le syst\u00e8me en ex\u00e9cutant la commande: systemctl status ypbind \u2013l<\/strong><\/p>\n si vous obtenez quelque chose qui ressemble \u00e0 cela:<\/p>\n c\u2019est que le service n\u2019est pas d\u00e9marr\u00e9, et si il n\u2019est pas d\u00e9marr\u00e9, il y a de fortes chances pour que ce soit tout simplement parce que les packages ne soient pas install\u00e9s.<\/p>\n Un tentative de d\u00e9marrage infructueuse via la commande systemctl start ypbind \u2013l<\/strong> vous confirmera que les packages ne sont pas pr\u00e9sents:<\/p>\n Pour installer les packages n\u00e9cessaires \u00e0 l\u2019ex\u00e9cution du client NIS, ex\u00e9cuter la commande suivante: dnf -y install ypbind rpcbind<\/strong><\/p>\n Si rpcbind est d\u00e9j\u00e0 install\u00e9, vous obtiendrez le message suivant, ce n\u2019est pas bien grave:<\/p>\n Dans tous les cas, vous devriez obtenir quelque chose comme cela apr\u00e8s l\u2019installation des paquets:<\/p>\n Apr\u00e8s installation des paquets, je vous conseille un petit red\u00e9marrage du syst\u00e8me. (pas purement techniquement obligatoire, mais bon\u2026)<\/p>\n Que vous ayez d\u00e9j\u00e0 un client NIS fonctionnel sur la machine ou que vous veniez de l\u2019installer, il faut maintenant arr\u00eater le service ypbind sur le syst\u00e8me via la commande: systemctl status ypbind \u2013l<\/strong><\/p>\n Ensuite, nous allons supprimer tous les fichiers qui peuvent se trouver dans le r\u00e9pertoire var\/yp\/binding via la commande: rm -rf \/var\/yp\/binding\/*<\/strong><\/p>\n Il faut maintenant d\u00e9finir le nom de domaine NIS auquel le client devra se r\u00e9f\u00e9rer, par d\u00e9faut le nom de domaine NIS est le nom de la zone Centrify dans laquelle le syst\u00e8me et la NIS Gateway se trouvent, dans notre exemple il se nomme donc arizona<\/strong>. Pour ce, ex\u00e9cuter la commande suivante: domainname arizona<\/strong><\/p>\n Puis \u00e9diter le fichier \/etc\/yp.conf<\/strong> 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<\/strong><\/p>\n Exemple avec l\u2019\u00e9diteur nano:<\/p>\n avec nano, apr\u00e8s \u00e9dition du fichier, Ctrl+O & Ctrl+X<\/p>\n Ensuite, d\u00e9marrer le service ypbind via la commande: systemctl start ypbind \u2013l<\/strong><\/p>\n Vous pouvez aussi v\u00e9rifier le statut du service via la commande: systemctl status ypbind \u2013l<\/strong><\/p>\n Note<\/u>: si le client NIS ne peut pas atteindre le service NIS de la NIS Gateway, alors le service client ne d\u00e9marre pas. Si vous avez une erreur au d\u00e9marrage, la premi\u00e8re chose \u00e0 faire est de d\u00e9sactiver le firewall sur le serveur portant la NIS Gateway afin de v\u00e9rifier si le probl\u00e8me vient du filtrage du firewall. (commande pour arr\u00eater le firewall sur fedora: systemctl stop firewalld \u2013l<\/strong>)<\/p>\n Donc jusque ici, tout va bien, nous avons un service NIS Gateway op\u00e9rationnel et un client NIS qui est capable d\u2019interroger le service NIS Gateway – reste maintenant \u00e0 publier des maps NIS dans Active Directory afin de voir si nous sommes capables d\u2019y acc\u00e9der via la commande ypcat !<\/p>\n Pour publier des maps NIS dans Active Directory, nous allons simplement utiliser l\u2019outil graphique Centrify Access Manager \u2013 Lancer l\u2019outil, puis se rendre dans la zone (arizona<\/strong>, dans notre exemple) puis \u2018Unix Data\u2019, puis s\u00e9lectionner le noeud \u2018NIS maps\u2019. R\u00e9aliser un clic-droit sur le noeud et choisir \u2018Nouveau \/ Generic Map\u2019:<\/p>\n Dans notre exemple, nous allons simplement cr\u00e9er une map g\u00e9n\u00e9rique, c\u2019est \u00e0 dire une map pour stocker des informations texte sans relation directe avec des \u00e9l\u00e9ments utilis\u00e9s par le syst\u00e8me. Vous pouvez bien sur cr\u00e9er des maps plus \u2018classiques\u2019 telle que Automount ou Netgroup par exemple.<\/p>\n Exemple de notre map:<\/p>\n Notre map se nomme donc test<\/strong> et contient une cl\u00e9 test01<\/strong> de valeur test0101<\/strong><\/p>\n Depuis le client NIS, ex\u00e9cuter la commande suivante: ypcat test<\/strong> \u2013 vous devez obtenir les valeurs de la map tel que:<\/p>\n Ca y est, ca fonctionne !<\/p>\n La commande ypwhich<\/strong> vous confirmera le nom du serveur NIS (la NIS Gateway) que le client utilise:<\/p>\n Pour aller un peu plus loin dans la compr\u00e9hension, ex\u00e9cuter la commande ypwhich \u2013m<\/strong> qui permet d\u2019afficher la liste des maps et le serveur NIS Master pour chaque map:<\/p>\n Nous pouvons constater deux \u00e9l\u00e9ments:<\/p>\n (1) d\u2019un point de vue du client NIS, la NIS Gateway est vue comme le Master NIS<\/p>\n (2) alors que nous n\u2019avons cr\u00e9\u00e9e qu\u2019une seule map NIS (test) au niveau d\u2019Active Directory, le client NIS per\u00e7oit quatre autres maps NIS: passwd.byuid \/ passwd.byname \/ group.byname \/ group.bygid \u2013 ces quatre maps NIS sont les maps dites \u2018implicites\u2019, c\u2019est \u00e0 dire qu\u2019elles sont g\u00e9n\u00e9r\u00e9es automatiquement par la NIS Gateway pour des besoins syst\u00e8mes en fonction des profils UNIX et des groupes UNIX qui sont pr\u00e9sents 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\u00e8mes UNIX)<\/p>\n Gr\u00e2ce \u00e0 la commande ypwhich \u2013x<\/strong> nous pouvons visualiser les correspondances entre les alias de nom de maps NIS (accessibles via la commande ypwhich) et le nom r\u00e9el technique de certaines maps NIS:<\/p>\n Si maintenant nous ex\u00e9cutons la commande ypcat passwd<\/strong> nous afficherons alors le contenu de la map NIS implicite passwd.byname<\/strong> qui contient une repr\u00e9sentation des profils UNIX pr\u00e9sents dans la zone \u2018arizona\u2019:<\/p>\n Effectivement, si nous utilisons l\u2019outil graphique de gestion Centrify Access Manager et si nous regardons la liste des profils UNIX effectifs dans cette zone \u2018arizona\u2019, nous retrouvons bien la m\u00eame liste de comptes:<\/p>\n Regardons maintenant \u00e0 quoi ressemble le stockage des maps NIS dans Active Directory. Pour cela, vous pouvez utiliser l\u2019ADUC de Microsoft ou un client LDAP basique.<\/p>\n Si nous regardons dans le container des zones, nous retrouvons l\u2019ensemble de nos zones Centrify. Il suffit de s\u00e9lectionner la zone \u2018arizona\u2019, puis le container NisMaps. Nous retrouvons \u00e0 l\u2019int\u00e9rieur de ce container la map NIS que nous avons cr\u00e9\u00e9e, c\u2019est \u00e0 dire la map nomm\u00e9e\u00a0 \u2018test\u2019.<\/p>\n Sous le container de la map \u2018test\u2019, nous retrouvons notre entr\u00e9e nomm\u00e9e \u2018test01\u2019:<\/p>\n Si nous regardons les propri\u00e9t\u00e9s de cette objet \u2018test01\u2019 (avec ADUC, r\u00e9aliser un clic-droit puis choisir \u2018Propri\u00e9t\u00e9s\u2019), nous pouvons visualiser les diff\u00e9rentes valeurs des diff\u00e9rents attributs de cet objet (avec ADUC, via l\u2019\u00e9diteur d\u2019attributs):<\/p>\n Si nous regardons sp\u00e9cifiquement trois attributs, nous retrouvons les valeurs que nous avons renseign\u00e9es lorsque nous avons cr\u00e9\u00e9 l\u2019entr\u00e9e dans la map NIS, pour rappel:<\/p>\n Voici les trois attributs:<\/p>\n KEY: (description)<\/p>\n VALUE: (adminDescription)<\/p>\n COMMENTS: (wWWHomePage)<\/p>\n![\"capture20160406205428817\"](\"http:\/\/identitycosmos.com\/wp-content\/uploads\/2016\/04\/capture20160406205428817.png\" "\\"capture20160406205428817\\"")
<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n