{"id":1390,"date":"2016-04-05T21:42:42","date_gmt":"2016-04-05T19:42:42","guid":{"rendered":"http:\/\/www.identitycosmos.com\/?p=1390"},"modified":"2016-04-05T21:42:42","modified_gmt":"2016-04-05T19:42:42","slug":"utilisation-dactive-directory-pour-le-stockage-des-maps-nis-unixlinux-via-la-centrify-nis-gateway-23","status":"publish","type":"post","link":"https:\/\/identitycosmos.com\/index.php\/2016\/04\/05\/utilisation-dactive-directory-pour-le-stockage-des-maps-nis-unixlinux-via-la-centrify-nis-gateway-23\/","title":{"rendered":"Utilisation d’Active Directory pour le stockage des maps NIS UNIX\/Linux via la Centrify NIS Gateway [2\/3]"},"content":{"rendered":"

 <\/p>\n

Lors de notre post pr\u00e9c\u00e9dent<\/a> nous avons vu comment installer l\u2019agent Centrify (adclient) et le package de la Centrify NIS Gateway (adnisd) sur le serveur qui publiera les maps NIS stock\u00e9es dans Active Directory.<\/p>\n

Nous allons maintenant voir comment activer l\u2019agent Centrify sur la NIS Gateway, comment r\u00e9aliser quelques GPOs depuis Active Directory pour param\u00e9trer la NIS Gateway et finir par des v\u00e9rifications locales \u00e0 faire sur la NIS Gateway.<\/p>\n

Tout d\u2019abord nous allons int\u00e9grer le futur serveur NIS dans Active Directory et le faire rejoindre une zone Centrify. Nous consid\u00e9rerons ici que la partie basique d\u2019une installation Centrify a d\u00e9j\u00e0 \u00e9t\u00e9 r\u00e9alis\u00e9e, et que des zones ont \u00e9t\u00e9 cr\u00e9\u00e9es. Je vous laisse jeter un \u0153il sur la documentation (notamment le Quick Start Guide) sur ces \u00e9tapes extr\u00eamement basiques. Dans notre exemple, la zone que nous allons rejoindre se nomme arizona.<\/p>\n

Tout d\u2019abord, se connecter en root sur le syst\u00e8mes (sur le futur serveur NIS donc) et ex\u00e9cuter cette commande pour rejoindre Active Directory et la zone nomm\u00e9e arizona:<\/p>\n

\"capture20160405142931118\"<\/a><\/p>\n

dans notre exemple: le domaine AD se nomme demo.local, la zone Centrify \u00e0 rejoindre se nomme arizona et le compte de service (Active Directory) ayant le droit de joindre une machine au domaine se nomme centrify \u2013 ensuite, le mot de passe AD pour le compte utilisateur\/administrateur centrify sera demand\u00e9:<\/p>\n

\"capture20160405142947712\"<\/a><\/p>\n

Apr\u00e8s quelques secondes, la fen\u00eatre suivante apparaitra, vous confirmant que l\u2019op\u00e9ration s\u2019est bien d\u00e9roul\u00e9e:<\/p>\n

\"capture20160405143023882\"<\/a><\/p>\n

Nous pourrions nous amuser \u00e0 ne red\u00e9marrer que certains services, mais allons red\u00e9marrer le serveur NIS, ce sera plus simple:<\/p>\n

\"capture20160405143109675\"<\/a><\/p>\n

Maintenant, laissons le syst\u00e8me Linux de c\u00f4t\u00e9 quelques instant et utilisons quelques outils de gestion propos\u00e9s par Centrify pour affiner notre configuration.<\/p>\n

Lancer l\u2019outil Centrify Access Manager, nous constatons qu\u2019une nouvelle machine a rejoint la zone arizona, il s\u2019agit de nisserver01, notre futur serveur NIS:<\/p>\n

\"capture20160405143154356\"<\/a><\/p>\n

Une autre vue, avec la liste des machines qui sont dans la zone Centrify, pour information, la machine fedora17 nous servira de client NIS (ypbind) pour les tests, pour que cela fonctionne il faut bien sur que la NIS Gateway et le client NIS soient dans la m\u00eame zone Centrify:<\/p>\n

\"capture20160405143220837\"<\/a><\/p>\n

Comme nous n\u2019avons pas sp\u00e9cifier de conteneur Active Directory sp\u00e9cifique lors de la jointure au domaine de la machine Linux (notre futur serveur NIS), l\u2019objet Computer le repr\u00e9sentant dans Active Directory s\u2019est cr\u00e9\u00e9 dans le conteneur par d\u00e9faut, si vous n\u2019avez pas fait de modification au niveau d\u2019Active Directory, vous retrouverez alors l\u2019objet Computer dans le conteneur nomm\u00e9 Computers:<\/p>\n

\"capture20160405143259227\"<\/a><\/p>\n

Pour la suite des tests, et notamment pour l\u2019application de certaines GPOs sur le serveur NIS lui-m\u00eame, nous allons cr\u00e9er une Unit\u00e9 d\u2019Organisation (UO) dans laquelle nous allons d\u00e9placer l\u2019objet AD repr\u00e9sentant le compte ordinateur du serveur NIS, dans notre exemple, l\u2019UO se nomme NIS_Gateway:<\/p>\n

\"capture20160405143414531\"<\/a><\/p>\n

Nous allons maintenant d\u00e9marrer notre serveur NIS. Une fois d\u00e9marr\u00e9 nous pourrions maintenant utiliser n\u2019importe quel compte AD ayant un profil UNIX dans la zone et ayant les droits de login pour nous authentifier sur le syst\u00e8me \u2013 pour plus de souplesse, nous continuerons d\u2019utiliser le compte root pour les diff\u00e9rentes manipulations.<\/p>\n

Si nous nous connectons sur le syst\u00e8me, et que nous tapons la commande adinfo<\/strong>, nous devons obtenir des informations sur l\u2019\u00e9tat du service adclient qui repr\u00e9sente le client AD du syst\u00e8me Linux:<\/p>\n

\"capture20160405143515949\"<\/a><\/p>\n

Le plus important est que l\u2019attribut \u2018CentrifyDC mode\u2019 est bien la valeur \u2018connected\u2019, cela signifie que le syst\u00e8me est bien connect\u00e9 \u00e0 Active Directory. A ce stade nous avons un serveur Linux int\u00e9gr\u00e9 dans Active Directory, dans une zone Centrify et qui est fonctionnel d\u2019un point de vue syst\u00e8me et totalement s\u00e9curis\u00e9 par l\u2019agent Centrify.<\/p>\n

Nous allons maintenant voir certains \u00e9l\u00e9ments sp\u00e9cifiques \u00e0 la partie NIS Gateway (adnisd).<\/p>\n

Tout d\u2019abord nous allons utiliser l\u2019outil d\u2019administration Centrify pour cr\u00e9er des GPOs sp\u00e9cifiques aux serveurs NIS qui s\u2019appliqueront \u00e0 notre serveur nisserver01. Centrify propose soit d\u2019int\u00e9grer directement des fichiers ADMX au niveau de la GPMC soit d\u2019installer un snap-in pr\u00e9sentant les GPOs sp\u00e9cifiques aux environnements Unix\/Linux et MacOS toujours au niveau de cette m\u00eame GPMC. Il faut bien sur au pr\u00e9alable avoir fait une de ces deux manipulations.<\/p>\n

Ouvrir la GPMC, se rendre sur le noeud Configuration ordinateur \/ Strat\u00e9gies \/ Mod\u00e8les d\u2019administration \/ Centrify Settings \/ DirectControl Settings \/ NIS Daemon Settings:<\/p>\n

\"capture20160405143959120\"<\/a><\/p>\n

Editer la propri\u00e9t\u00e9 \u2018Specify allowed client machines for NIS daemon\u2019 et renseigner la valeur 0\/0<\/strong>:<\/p>\n

\"capture20160405144020742\"<\/a><\/p>\n

En effet, par d\u00e9faut, le d\u00e9mon adnisd n\u2019accepte que les requ\u00eates locales, c\u2019est \u00e0 dire, les requ\u00eates NIS \u00e9mises depuis le serveur NIS lui-m\u00eame (je ne rentrerai pas dans les d\u00e9tails, mais cette configuration est utilis\u00e9e dans des cadres pr\u00e9cis de s\u00e9curit\u00e9), il faut donc sp\u00e9cifier les adresses IP qui auront le droit de lancer des requ\u00eates NIS vers notre NIS Gateway, si l\u2019on renseigne la valeur 0\/0, toutes les requ\u00eates NIS seront accept\u00e9es.<\/p>\n

Editer \u00e9galement la propri\u00e9t\u00e9s \u2018Specify NIS daemon update interval\u2019 et renseigner la valeur 60<\/strong>:<\/p>\n

\"capture20160405144101425\"<\/a><\/p>\n

Cette valeur (par d\u00e9faut sur 30 minutes) permet de sp\u00e9cifier l\u2019intervalle de rafraichissement des donn\u00e9es entre Active Directory et le cache local de la NIS Gateway. En effet, pour des raisons de performance, les informations des maps NIS stock\u00e9es dans Active Directory sont mises en cache au niveau de la NIS Gateway (comportement par d\u00e9faut), nous mettons ici la valeur sur 60 secondes afin de ne pas trop attendre entre les modifications faites dans Active Directory et leur synchronisation sur la NIS Gateway. En production, une valeur entre 15 et 30 minutes est tout \u00e0 fait acceptable.<\/p>\n

Valider la GPO, et refermer la console de gestion des GPOs Centrify.<\/p>\n

Pour mettre \u00e0 jour notre futur serveur NIS avec ces nouvelles valeurs de configuration (celles de la GPO), il faut se connecter sur le serveur NIS et ex\u00e9cuter la commande adgpupdate<\/strong> afin de forcer le rafraichissement de la GPO sur le syst\u00e8me Linux, sinon attendre la prochaine application des GPOs:<\/p>\n

\"capture20160405200401273\"<\/a><\/p>\n

Pour visualiser les GPOs qui sont bien appliqu\u00e9es sur le syst\u00e8me, ex\u00e9cuter la commande adgpresult<\/strong>, nous retrouvons bien les param\u00e8tres appliqu\u00e9s de notre GPO cr\u00e9\u00e9e pr\u00e9c\u00e9demment:<\/p>\n

\"capture20160405200555997\"<\/a><\/p>\n

Nous allons maintenant v\u00e9rifier quelques \u00e9l\u00e9ments au niveau de notre serveur NIS Gateway.<\/p>\n

Tout d\u2019abord pour qu\u2019un service NIS s\u2019ex\u00e9cute convenablement sur un syst\u00e8me, il faut que les services RPC soient op\u00e9rationnels. je ne rentrerais pas les d\u00e9tails, mais globalement le service RPC du serveur va recevoir la requ\u00eate, d\u00e9cider d\u2019un num\u00e9ro de port RPC pour la connexion cliente du client NIS et donc permettre la communication entre le client et le serveur. Il faut donc que RPC fonctionne correctement sur le serveur NIS, pour v\u00e9rifier cela, ex\u00e9cuter la commande  rpcinfo \u2013p localhost<\/strong><\/p>\n

\"capture20160405144954620\"<\/a><\/p>\n

Nous voyons ici 6 portmapper en attente de demande d\u2019\u00e9change RPC, tout va bien.<\/p>\n

Nous allons maintenant ex\u00e9cuter la commande systemctl status adnisd \u2013l <\/strong>afin de v\u00e9rifier que le service adnisd est bien d\u00e9marr\u00e9 et fonctionnel:<\/p>\n

\"capture20160405202502019\"<\/a><\/p>\n

Si jamais le service n\u2019est pas d\u00e9marr\u00e9, ex\u00e9cuter la commande systemctl start adnisd \u2013l <\/strong> pour le d\u00e9marrer.<\/p>\n

Le r\u00e9sultat de la commande systemctl status adnisd \u2013l <\/strong> nous indique \u00e0 la fin qu\u2019il n\u2019y aucune NIS map dans Active Directory, \u00e0 ce stade, c\u2019est tout \u00e0 fait normal.<\/p>\n

Dans le prochain et dernier article de cette s\u00e9rie consacr\u00e9e \u00e0 l\u2019utilisation d\u2019Active Directory pour le stockage des maps NIS \u00e0 destination des clients UNIX ou Linux, nous verrons comment publier quelques maps NIS dans Active Directory, comment param\u00e9trer des clients NIS (ypbind) pour interroger ces m\u00eame maps NIS et comment r\u00e9aliser quelques tests suppl\u00e9mentaires.<\/p>\n","protected":false},"excerpt":{"rendered":"

  Lors de notre post pr\u00e9c\u00e9dent nous avons vu comment installer l\u2019agent Centrify (adclient) et le package de la Centrify NIS Gateway (adnisd) sur le serveur qui publiera les maps NIS stock\u00e9es dans Active Directory. Nous allons maintenant voir comment activer l\u2019agent Centrify sur la NIS Gateway, comment r\u00e9aliser quelques GPOs depuis Active Directory pour param\u00e9trer la NIS Gateway et finir par des v\u00e9rifications locales \u00e0 faire sur la NIS Gateway. Tout d\u2019abord nous allons int\u00e9grer le futur serveur NIS dans Active Directory et le faire rejoindre une zone Centrify. Nous consid\u00e9rerons ici que la partie basique d\u2019une installation Centrify a d\u00e9j\u00e0 \u00e9t\u00e9 r\u00e9alis\u00e9e, et que des zones ont \u00e9t\u00e9 cr\u00e9\u00e9es. Je vous laisse jeter un \u0153il sur la documentation (notamment le Quick Start Guide) sur ces \u00e9tapes extr\u00eamement basiques. Dans notre exemple, la zone que nous allons rejoindre se nomme arizona. Tout d\u2019abord, se connecter en root sur le syst\u00e8mes (sur le futur serveur NIS donc) et ex\u00e9cuter cette commande pour rejoindre Active Directory et la zone nomm\u00e9e arizona: dans notre exemple: le domaine AD se nomme demo.local, la zone Centrify \u00e0 rejoindre se nomme arizona et le compte de service (Active Directory) ayant le droit de joindre une machine au domaine se nomme centrify \u2013 ensuite, le mot de passe AD pour le compte utilisateur\/administrateur centrify sera demand\u00e9: Apr\u00e8s quelques secondes, la fen\u00eatre suivante apparaitra, vous confirmant que l\u2019op\u00e9ration s\u2019est bien d\u00e9roul\u00e9e: Nous pourrions nous amuser \u00e0 ne red\u00e9marrer que certains services, mais allons red\u00e9marrer le serveur NIS, ce sera plus simple: Maintenant, laissons le syst\u00e8me Linux de c\u00f4t\u00e9 quelques instant et utilisons quelques outils de gestion propos\u00e9s par Centrify pour affiner notre configuration. Lancer l\u2019outil Centrify Access Manager, nous constatons qu\u2019une nouvelle machine a rejoint la zone arizona, il s\u2019agit de nisserver01, notre futur serveur NIS: Une autre vue, avec la liste des machines qui sont dans la zone Centrify, pour information, la machine fedora17 nous servira de client NIS (ypbind) pour les tests, pour que cela fonctionne il faut bien sur que la NIS Gateway et le client NIS soient dans la m\u00eame zone Centrify: Comme nous n\u2019avons pas sp\u00e9cifier de conteneur Active Directory sp\u00e9cifique lors de la jointure au domaine de la machine Linux (notre futur serveur NIS), l\u2019objet Computer le repr\u00e9sentant dans Active Directory s\u2019est cr\u00e9\u00e9 dans le conteneur par d\u00e9faut, si vous n\u2019avez pas fait de modification au niveau d\u2019Active Directory, vous retrouverez alors l\u2019objet Computer dans le conteneur nomm\u00e9 Computers: Pour la suite des tests, et notamment pour l\u2019application de certaines GPOs sur le serveur NIS lui-m\u00eame, nous allons cr\u00e9er une Unit\u00e9 d\u2019Organisation (UO) dans laquelle nous allons d\u00e9placer l\u2019objet AD repr\u00e9sentant le compte ordinateur du serveur NIS, dans notre exemple, l\u2019UO se nomme NIS_Gateway: Nous allons maintenant d\u00e9marrer notre serveur NIS. Une fois d\u00e9marr\u00e9 nous pourrions maintenant utiliser n\u2019importe quel compte AD ayant un profil UNIX dans la zone et ayant les droits de login pour nous authentifier sur le syst\u00e8me \u2013 pour plus de souplesse, nous continuerons d\u2019utiliser le compte root pour les diff\u00e9rentes manipulations. Si nous nous connectons sur le syst\u00e8me, et que nous tapons la commande adinfo, nous devons obtenir des informations sur l\u2019\u00e9tat du service adclient qui repr\u00e9sente le client AD du syst\u00e8me Linux: Le plus important est que l\u2019attribut \u2018CentrifyDC mode\u2019 est bien la valeur \u2018connected\u2019, cela signifie que le syst\u00e8me est bien connect\u00e9 \u00e0 Active Directory. A ce stade nous avons un serveur Linux int\u00e9gr\u00e9 dans Active Directory, dans une zone Centrify et qui est fonctionnel d\u2019un point de vue syst\u00e8me et totalement s\u00e9curis\u00e9 par l\u2019agent Centrify. Nous allons maintenant voir certains \u00e9l\u00e9ments sp\u00e9cifiques \u00e0 la partie NIS Gateway (adnisd). Tout d\u2019abord nous allons utiliser l\u2019outil d\u2019administration Centrify pour cr\u00e9er des GPOs sp\u00e9cifiques aux serveurs NIS qui s\u2019appliqueront \u00e0 notre serveur nisserver01. Centrify propose soit d\u2019int\u00e9grer directement des fichiers ADMX au niveau de la GPMC soit d\u2019installer un snap-in pr\u00e9sentant les GPOs sp\u00e9cifiques aux environnements Unix\/Linux et MacOS toujours au niveau de cette m\u00eame GPMC. Il faut bien sur au pr\u00e9alable avoir fait une de ces deux manipulations. Ouvrir la GPMC, se rendre sur le noeud Configuration ordinateur \/ Strat\u00e9gies \/ Mod\u00e8les d\u2019administration \/ Centrify Settings \/ DirectControl Settings \/ NIS Daemon Settings: Editer la propri\u00e9t\u00e9 \u2018Specify allowed client machines for NIS daemon\u2019 et renseigner la valeur 0\/0: En effet, par d\u00e9faut, le d\u00e9mon adnisd n\u2019accepte que les requ\u00eates locales, c\u2019est \u00e0 dire, les requ\u00eates NIS \u00e9mises depuis le serveur NIS lui-m\u00eame (je ne rentrerai pas dans les d\u00e9tails, mais cette configuration est utilis\u00e9e dans des cadres pr\u00e9cis de s\u00e9curit\u00e9), il faut donc sp\u00e9cifier les adresses IP qui auront le droit de lancer des requ\u00eates NIS vers notre NIS Gateway, si l\u2019on renseigne la valeur 0\/0, toutes les requ\u00eates NIS seront accept\u00e9es. Editer \u00e9galement la propri\u00e9t\u00e9s \u2018Specify NIS daemon update interval\u2019 et renseigner la valeur 60: Cette valeur (par d\u00e9faut sur 30 minutes) permet de sp\u00e9cifier l\u2019intervalle de rafraichissement des donn\u00e9es entre Active Directory et le cache local de la NIS Gateway. En effet, pour des raisons de performance, les informations des maps NIS stock\u00e9es dans Active Directory sont mises en cache au niveau de la NIS Gateway (comportement par d\u00e9faut), nous mettons ici la valeur sur 60 secondes afin de ne pas trop attendre entre les modifications faites dans Active Directory et leur synchronisation sur la NIS Gateway. En production, une valeur entre 15 et 30 minutes est tout \u00e0 fait acceptable. Valider la GPO, et refermer la console de gestion des GPOs Centrify. Pour mettre \u00e0 jour notre futur serveur NIS avec ces nouvelles valeurs de configuration (celles de la GPO), il faut se connecter sur le serveur NIS et ex\u00e9cuter la commande adgpupdate afin de forcer le rafraichissement de la GPO sur le syst\u00e8me Linux, sinon attendre la prochaine application des GPOs: Pour visualiser les GPOs qui sont bien appliqu\u00e9es sur le syst\u00e8me, ex\u00e9cuter la commande adgpresult, nous retrouvons bien les param\u00e8tres appliqu\u00e9s de notre GPO cr\u00e9\u00e9e pr\u00e9c\u00e9demment: Nous allons maintenant v\u00e9rifier quelques \u00e9l\u00e9ments au niveau de notre serveur NIS Gateway. Tout d\u2019abord pour qu\u2019un service NIS s\u2019ex\u00e9cute convenablement sur un syst\u00e8me, il faut que les services RPC soient op\u00e9rationnels. je ne rentrerais pas les d\u00e9tails, mais globalement le service RPC du serveur va recevoir la requ\u00eate, d\u00e9cider d\u2019un num\u00e9ro de port RPC pour la connexion cliente du client NIS et donc permettre la communication entre le client et le serveur. Il faut donc que RPC fonctionne correctement sur le serveur NIS, pour v\u00e9rifier cela, ex\u00e9cuter la commande  rpcinfo \u2013p localhost Nous voyons ici 6 portmapper en attente de demande d\u2019\u00e9change RPC, tout va bien. Nous allons maintenant ex\u00e9cuter la commande systemctl status adnisd \u2013l afin de v\u00e9rifier que le service adnisd est bien d\u00e9marr\u00e9 et fonctionnel: Si jamais le service n\u2019est pas d\u00e9marr\u00e9, ex\u00e9cuter la commande systemctl start adnisd \u2013l pour le d\u00e9marrer. Le r\u00e9sultat de la commande systemctl status adnisd \u2013l nous indique \u00e0 la fin qu\u2019il n\u2019y aucune NIS map dans Active Directory, \u00e0 ce stade, c\u2019est tout \u00e0 fait normal. Dans le prochain et dernier article de cette s\u00e9rie consacr\u00e9e \u00e0 l\u2019utilisation d\u2019Active Directory pour le stockage des maps NIS \u00e0 destination des clients UNIX ou Linux, nous verrons comment publier quelques maps NIS dans Active Directory, comment param\u00e9trer des clients NIS (ypbind) pour interroger ces m\u00eame maps NIS et comment r\u00e9aliser quelques tests suppl\u00e9mentaires.<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,7],"tags":[14,62,135,138,160,239],"class_list":["post-1390","post","type-post","status-publish","format-standard","hentry","category-centrify","category-technique","tag-active-directory","tag-centrify","tag-ldap","tag-linux","tag-nis","tag-unix"],"_links":{"self":[{"href":"https:\/\/identitycosmos.com\/index.php\/wp-json\/wp\/v2\/posts\/1390","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/identitycosmos.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/identitycosmos.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/identitycosmos.com\/index.php\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/identitycosmos.com\/index.php\/wp-json\/wp\/v2\/comments?post=1390"}],"version-history":[{"count":0,"href":"https:\/\/identitycosmos.com\/index.php\/wp-json\/wp\/v2\/posts\/1390\/revisions"}],"wp:attachment":[{"href":"https:\/\/identitycosmos.com\/index.php\/wp-json\/wp\/v2\/media?parent=1390"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/identitycosmos.com\/index.php\/wp-json\/wp\/v2\/categories?post=1390"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/identitycosmos.com\/index.php\/wp-json\/wp\/v2\/tags?post=1390"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}