Identity Cosmos

Utilisation d’Active Directory pour le stockage des maps NIS UNIX/Linux via la Centrify NIS Gateway [3/3]

6 avril 20165 avril 2017SylvainLeave a comment

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 !

Utilisation d’Active Directory pour le stockage des maps NIS UNIX/Linux via la Centrify NIS Gateway [2/3]

5 avril 2016SylvainLeave a comment

Lors de notre post précédent nous avons vu comment installer l’agent Centrify (adclient) et le package de la Centrify NIS Gateway (adnisd) sur le serveur qui publiera les maps NIS stockées dans Active Directory.

Nous allons maintenant voir comment activer l’agent Centrify sur la NIS Gateway, comment réaliser quelques GPOs depuis Active Directory pour paramétrer la NIS Gateway et finir par des vérifications locales à faire sur la NIS Gateway.

Tout d’abord nous allons intégrer le futur serveur NIS dans Active Directory et le faire rejoindre une zone Centrify. Nous considérerons ici que la partie basique d’une installation Centrify a déjà été réalisée, et que des zones ont été créées. Je vous laisse jeter un œil sur la documentation (notamment le Quick Start Guide) sur ces étapes extrêmement basiques. Dans notre exemple, la zone que nous allons rejoindre se nomme arizona.

Tout d’abord, se connecter en root sur le systèmes (sur le futur serveur NIS donc) et exécuter cette commande pour rejoindre Active Directory et la zone nommée arizona:

dans notre exemple: le domaine AD se nomme demo.local, la zone Centrify à rejoindre se nomme arizona et le compte de service (Active Directory) ayant le droit de joindre une machine au domaine se nomme centrify – ensuite, le mot de passe AD pour le compte utilisateur/administrateur centrify sera demandé:

Après quelques secondes, la fenêtre suivante apparaitra, vous confirmant que l’opération s’est bien déroulée:

Nous pourrions nous amuser à ne redémarrer que certains services, mais allons redémarrer le serveur NIS, ce sera plus simple:

Maintenant, laissons le système Linux de côté quelques instant et utilisons quelques outils de gestion proposés par Centrify pour affiner notre configuration.

Lancer l’outil Centrify Access Manager, nous constatons qu’une nouvelle machine a rejoint la zone arizona, il s’agit 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ême zone Centrify:

Comme nous n’avons pas spécifier de conteneur Active Directory spécifique lors de la jointure au domaine de la machine Linux (notre futur serveur NIS), l’objet Computer le représentant dans Active Directory s’est créé dans le conteneur par défaut, si vous n’avez pas fait de modification au niveau d’Active Directory, vous retrouverez alors l’objet Computer dans le conteneur nommé Computers:

Pour la suite des tests, et notamment pour l’application de certaines GPOs sur le serveur NIS lui-même, nous allons créer une Unité d’Organisation (UO) dans laquelle nous allons déplacer l’objet AD représentant le compte ordinateur du serveur NIS, dans notre exemple, l’UO se nomme NIS_Gateway:

Nous allons maintenant démarrer notre serveur NIS. Une fois démarré nous pourrions maintenant utiliser n’importe quel compte AD ayant un profil UNIX dans la zone et ayant les droits de login pour nous authentifier sur le système – pour plus de souplesse, nous continuerons d’utiliser le compte root pour les différentes manipulations.

Si nous nous connectons sur le système, et que nous tapons la commande adinfo, nous devons obtenir des informations sur l’état du service adclient qui représente le client AD du système Linux:

Le plus important est que l’attribut ‘CentrifyDC mode’ est bien la valeur ‘connected’, cela signifie que le système est bien connecté à Active Directory. A ce stade nous avons un serveur Linux intégré dans Active Directory, dans une zone Centrify et qui est fonctionnel d’un point de vue système et totalement sécurisé par l’agent Centrify.

Nous allons maintenant voir certains éléments spécifiques à la partie NIS Gateway (adnisd).

Tout d’abord nous allons utiliser l’outil d’administration Centrify pour créer des GPOs spécifiques aux serveurs NIS qui s’appliqueront à notre serveur nisserver01. Centrify propose soit d’intégrer directement des fichiers ADMX au niveau de la GPMC soit d’installer un snap-in présentant les GPOs spécifiques aux environnements Unix/Linux et MacOS toujours au niveau de cette même GPMC. Il faut bien sur au préalable avoir fait une de ces deux manipulations.

Ouvrir la GPMC, se rendre sur le noeud Configuration ordinateur / Stratégies / Modèles d’administration / Centrify Settings / DirectControl Settings / NIS Daemon Settings:

Editer la propriété ‘Specify allowed client machines for NIS daemon’ et renseigner la valeur 0/0:

En effet, par défaut, le démon adnisd n’accepte que les requêtes locales, c’est à dire, les requêtes NIS émises depuis le serveur NIS lui-même (je ne rentrerai pas dans les détails, mais cette configuration est utilisée dans des cadres précis de sécurité), il faut donc spécifier les adresses IP qui auront le droit de lancer des requêtes NIS vers notre NIS Gateway, si l’on renseigne la valeur 0/0, toutes les requêtes NIS seront acceptées.

Editer également la propriétés ‘Specify NIS daemon update interval’ et renseigner la valeur 60:

Cette valeur (par défaut sur 30 minutes) permet de spécifier l’intervalle de rafraichissement des données entre Active Directory et le cache local de la NIS Gateway. En effet, pour des raisons de performance, les informations des maps NIS stockées dans Active Directory sont mises en cache au niveau de la NIS Gateway (comportement par défaut), 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 à fait acceptable.

Valider la GPO, et refermer la console de gestion des GPOs Centrify.

Pour mettre à 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écuter la commande adgpupdate afin de forcer le rafraichissement de la GPO sur le système Linux, sinon attendre la prochaine application des GPOs:

Pour visualiser les GPOs qui sont bien appliquées sur le système, exécuter la commande adgpresult, nous retrouvons bien les paramètres appliqués de notre GPO créée précédemment:

Nous allons maintenant vérifier quelques éléments au niveau de notre serveur NIS Gateway.

Tout d’abord pour qu’un service NIS s’exécute convenablement sur un système, il faut que les services RPC soient opérationnels. je ne rentrerais pas les détails, mais globalement le service RPC du serveur va recevoir la requête, décider d’un numéro 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érifier cela, exécuter la commande rpcinfo –p localhost

Nous voyons ici 6 portmapper en attente de demande d’échange RPC, tout va bien.

Nous allons maintenant exécuter la commande systemctl status adnisd –l afin de vérifier que le service adnisd est bien démarré et fonctionnel:

Si jamais le service n’est pas démarré, exécuter la commande systemctl start adnisd –l pour le démarrer.

Le résultat de la commande systemctl status adnisd –l nous indique à la fin qu’il n’y aucune NIS map dans Active Directory, à ce stade, c’est tout à fait normal.

Dans le prochain et dernier article de cette série consacrée à l’utilisation d’Active Directory pour le stockage des maps NIS à destination des clients UNIX ou Linux, nous verrons comment publier quelques maps NIS dans Active Directory, comment paramétrer des clients NIS (ypbind) pour interroger ces même maps NIS et comment réaliser quelques tests supplémentaires.

Utilisation d’Active Directory pour le stockage des maps NIS UNIX/Linux via la Centrify NIS Gateway [1/3]

4 avril 2016SylvainLeave a comment

Comme indiqué dans un de mes derniers posts, Microsoft a annoncé la suppression de certains services Unix majeurs au sein de Windows 2016 et donc d’Active Directory 2016.

Au travers de mes projets, je rencontre de nombreuses sociétés qui utilisent des environnements mixtes Microsoft/Unix, et il est clair que les services NIS ont la vue dure… Bien sur, il ne faut pas gérer les authentifications et les autorisations via NIS, au profit d’utiliser Kerberos et LDAP. Je ne vais pas rentrer dans les détails ici, mais c’est comme dans Ghosbusters, utiliser les services NIS, c’est “mal”… Néanmoins, pour de nombreuses organisations, l’élimination totale des services NIS est un véritable challenge, car ces même organisations gère depuis des dizaines d’années des informations très importantes pour leur production dans ces fameuses map NIS (automount ou autre).

L’idée est donc généralement d’utiliser Kerberos/LDAP pour utiliser les services d’authentification et d’autorisation d’Active Directory et un service NIS “gateway” qui permettra d’accéder à Active Directory de façon sécurisée pour proposer le service NIS server depuis cette gateway. De cette façon, on obtient le meilleur des deux: on sécurise les services d’authentification par Kerberos et on permet à l’organisation de continuer à utiliser NIS pour exposer des maps “legacy”.

Nous allons donc utiliser les services de NIS gateway proposés par la solution Centrify pour réaliser cette prouesse technologique et fonctionnelle Smile

Pour ce, nous allons paramétrer une workstation Fedora 23 en tant que passerelle NIS vers Active Directory.

Tout d’abord, il faut bien paramétrer votre Fedora pour vous assurer de lui donner un nom hostname qui corresponde à votre besoin et lui donner un paramétrage IP qui permette à cette passerelle NIS de communiquer avec Active Directory. Nous considérons ici, que les paramétrage basiques d’installation et de paramétrage de Zones Centrify ont déjà été effectués.

1/ Paramétrage du hostname

Dans notre exemple, le hostname du futur serveur NIS sera: nisserver01.demo.local

2/ Vérification du service SSH

Nous allons vérifier que le service SSH Server est présent sur la machine, ceci afin de nous permettre de transférer les package de l’agent Centrify et de la NIS Gateway sur le futur serveur NIS

Si le serveur SSH n’est pas installé, renseigner la commande suivante pour installer les packages:

Une fois que les packages SSH sont installés, démarrer le service SSH serveur

3/ Transfert des packages sur la machine

Via WinSCP, nous allons transférer l’agent Centrify de la version Centrify Server Suite 2016 sur la machine (dans le répertoire/tmp) pour une fedora 23, le nom du package est centrify-suite-2016-rhel4-i386.tgz

4/ Installation de l’agent Centrify

Vérifier que l’agent est bien dans le répertoire /tmp:

Décompresser le package de l’agent:

Lancer l’installation de l’agent:

Le script d’installation va lancer une vérification pour voir si la plateforme sera compatible avec l’installation de l’agent – si aucun test ne sort en “failed”, l’installation sera possible, les “warning” ne sont pas rédhibitoires pour l’installation:

Choisir d’installer la version Enterprise ou Standard, en ce qui nous concerne pour le service NIS, cela n’a aucune importance – dans notre exemple, nous choisissons Enterprise [E]:

Choisir de lancer adcheck à nouveau (pour être sur…) et renseigner les informations liées à Active Directory que demandera le processus d’installation – dans notre exemple, nous allons rejoindre une zone Centrify nommée arizona, notre futur serveur NIS fournira donc des services NIS pour cette zone Centrify – choisir de ne pas redémarrer à la fin de l’installation:

Une fois les informations fournies, le processus d’installation vous demande de valider une dernière fois les informations fournies avant installation et paramétrage de l’agent:

Le processus d’installation commence – après le processus adcheck, valider l’installation de l’agent:

L’installation se termine avec l’installation des agents Centrify:

Nous allons maintenant installer le package permettant de mettre à jour le serveur SSH livré avec l’OS par la version serveur SSH Centrify qui permet une meilleure intégration au niveau de l’authentification Kerberos intégrée:

Nous allons maintenant installer le package du serveur Centrify NIS Gateway:

Nous allons maintenant pouvoir redémarrer le système !

Lors du prochain article, nous verrons ensemble le paramétrage de l’agent Centrify, le paramétrage du service NIS Gateway et nous publierons quelques maps NIS dans Active Directory afin de les rendre accessibles pour des clients NIS Unix/Linux sur notre réseau.

Webinaire sur l’intégration des MacOS X dans Active Directory

21 janvier 201621 janvier 2016SylvainLeave a comment

J’ai dernièrement réalisé un webinaire sur la thématique de l’intégration des machines MacOS X dans Active Directory pour le compte de la société Cerberis. Nous avons pris en exemple l’intégration via les technologies Centrify avec le mode AutoZone de manière à simplifier l’intégration et l’accès des utilisateurs sur les systèmes. La fin du Webinaire comporte une démonstration avec des GPOs appliquées sur les MacOS, la relation entre les comptes AD et l’authentification sur les postes MacOS X et encore la migration des comptes locaux vers des comptes Active Directory afin de conserver l’environnement utilisateur d’un compte local après migration vers un compte AD.

Voici le webinaire:

Intégration Unix & Linux dans Active Directory: Quelle type de zone Centrify utiliser ?

9 janvier 201613 janvier 2017SylvainLeave a comment

Dernièrement un client m’a demandé quel était le meilleur choix en termes de zones Centrify – quel type de zone doit on privilégier ?

La question est intéressante, car la “zone Centrify” est un élément important d’un design d’intégration UNIX/Linux dans Active Directory.

Comme d’habitude, il n’y a pas de réponse absolue, s’il existe plusieurs types de zones, c’est que certaines situations impliquent un type de zone et d’autres un autre type… évidement…

Rappel sur la notion de zone

Une zone Centrify représente ce que j’appelle personnellement un “ilot identitaire” – les zones servent globalement aux situations suivantes:

– Résultat de migration depuis différents ilots identitaires existants (plusieurs serveurs NIS, des serveurs LDAP, voir des fichiers passwd locaux depuis chaque système) – Ceci permettant notamment de gérer la problématique de collision d’UIDs/GIDs qui est LE gros problème rencontré par des entreprises voulant migrer vers un annuaire unique

– Règles de gouvernance: les zones permettent de ségréguer la gouvernance de différents ensembles de serveurs Unix, Linux ou Windows ou des Workstations Linux ou MacOS: si des équipes d’administrateurs IT différentes gèrent différents périmètres, les zones peuvent aider à encadrer tout cela

– Règles d’accès: même si il est possible de gérer les règles d’accès des utilisateurs aux différents systèmes, c’est à dire, « qui a le droit de se connecter sur tel système » de plusieurs manières différentes (GPOs, Rôles, pam.deny, pam.allow, etc.) les zones Centrify permettent rapidement et facilement de définir le « qui a a accès à quoi »

– Le reporting: il est extrêmement facile de générer des reports par zone, indiquant facilement le “qui a accès à quoi” en termes de systèmes – extrêmement efficace pour des audits

Pour une zone donnée, il est très simple de définir des attributs POSIX pour un utilisateur Active Directory, et bien sur il est possible de définir des jeux d’attributs POSIC différents par zone pour un même individu:

Les différents types de zones

Il existe 7 types de zones Centrify:

(0) AutoZone (nous ne le traiterons pas dans cet article, dans la vraie vie, ceci ne concerne que les workstations sous MacOS)

(1) SFU-compatible zones, version 3.5
(2) SFU-compatible zones, version 4.0
(3) Classic Centrify zones, 2.x, 3.x, and 4.x
(4) Classic RFC 2307-compatible zones
(5) Hierarchical Centrify zones, 5.x
(6) Hierarchical RFC 2307-compatible zones

Les zones dites “SFU-compatible” (1)(2) permettaient la compatibilité avec le schéma SFU exploité par Microsoft dans Active Directory à une certaine époque, autant dire que vu le “bazard” que constitue SFU en terme de compatibilité et de standard, peu de clients se sont aventuré dans cette voie…

Les zones “Classic” (3)(4) représentent l’ancienne famille de zone Centrify, à cette époque, les zones étaient “à plat”, c’est à dire non-hiérarchiques – c’était déjà très bien, mais cela obligeait à reproduire toutes les configurations communes aux différentes zones dans chacune des zones, de façon individuel et donc sans gestion centralisée – beaucoup de clients utilisent encore ce modèle car ils n’ont pas migré vers le modèle hiérarchique.

Les zones “Hierarchical” permettent d’avoir une arborescence de zones, avec un héritage descendant au niveau des profils POSIX. Cela permet notamment de définir une zone dite Parent avec l’ensemble des UIDs Corporate voulus et de définir des zones enfants avec uniquement les exceptions/différences par rapport aux profils POSIX définis dans la zone Parent. C’est donc bien évidement le meilleur choix, même dans le cas d’une architecture simpliste (dans ce cas on ne créera qu’une seule zone parent).

La zone “Hierarchical RFC 2307-compatible”

Avec la nouvelle version de Centrify Server Suite, le format de zone par défaut lorsque l’on créé une zone est le format: Hierarchical RFC 2307-compatible – l’avantage de ce format est que les attributs POSIX rattachés au ServiceConnectionPoint représentant le profil Unix de l’utilisateur dans la zone est “proprement” renseigné dans des attributs particuliers, permettant des requêtes LDAP facilitées et surtout une gestion par un outil IAM externe extrêmement simplifié.

On voit ici par exemple que l’attribut POSIX uidNumber est un attribut à part entière dans l’annuaire Active Directory.

Cette approche simplifie la manipulation des profils Unix depuis un browser LDAP:

Merci pour ce client, je n’avais jamais pensé faire un article sur ce sujet ! N’hésitez pas à me contacter pour plus précision.

Installation de Centrify Workstation for Mac 2016 sur EL CAPITAN (OSX 10.11) [Part 3/4] – Quelques manipulations après l’installation de l’agent Centrify

4 janvier 2016SylvainLeave a comment

Installation de Centrify Workstation for Mac 2016 sur EL CAPITAN (OSX 10.11) [Part 3/4] – Quelques manipulations après l’installation de l’agent Centrify.

Lors de l’article précédent, nous avons installé l’agent Centrify sur une machine MacOS X afin que celle-ci bénéficie d’une véritable intégration à Active DIrectory – cad une intégration basée sur Kerberos et LDAP permettant également l’application de GPOs sur les systèmes MacOS, et non pas une intégration basée sur Samba.

Nous allons maintenant faire quelques paramétrages supplémentaires dans la première partie de cet article, puis nous traiterons la gestion des comptes locaux existants avant la migration dans la deuxième partie de cet article.

# Nous allons maintenant faire quelques vérifications et manipulations afin de parfaire cette installation

[1] Déplacement du compte machine de la machine MacOS X

Comme nous n’avons spécifié dans quelle UO créer le compte machine, celui-ci s’est créé dans le conteneur par défaut, à savoir « computers »:

Pour information, il est possible que votre administrateur Active Directory est défini un autre conteneur par défaut, mais dans la plupart des cas, il s’agit du conteneur « computers ».

Nous allons maintenant déplacer le compte ordinateur « ELCAPITAN » dans l’UO que nous avons prévue à cet effet au tout début, l’UO CENTRIFY/WORKSTATIONS:

[2] Vérification des informations dans l’annuaire

Réaliser un clic-droit sur le compte machine et choisir « Propriétés »

Vous pouvez parcourir les différents onglets afin d’avoir des informations sur le compte machine, la version de l’OS, la version de l’agent Centrify installée, etc.

Il est également possible de vérifier le type de zone Centrify rejointe, dans notre exemple, nous avons choisi le mode AutoZone qui permet de s’affranchir de la gestion des UIDs et du contrôle d’accès. Dans ce mode, les UIDs sont générés automatiquement par un dérivé du SID utilisateur, les UIDs sont gérés localement par l’agent, il n’y a pas d’UIDs stockés coté Active Directory – ce mode est tout à fait particulier et convient uniquement aux workstations, et je dirais même uniquement aux workstations MacOS.

En utilisant ce mode, tous les utilisateurs Active Directory peuvent ouvrir une session sur le poste MacOS (à moins que localement sur le MacOS on est spécifié le contraire dans le gestionnaire de login des Paramètres Systèmes – ou encore – il est possible d’utiliser le fichier de configuration centrifydc.conf en jouant sur les attributs pam.allow.users et pam.allow.groups ), il n’y a pas besoin de de donner le droit de ‘login » sur la machine, ceci est automatique pour tous les comptes utilisateurs présents dans Active Directory.

Il est également possible de constater via l’éditeur d’attributs, certaines propriétés avancées du compte machine, comme par exemple les différents servicePrincipalName qui seront utiles au protocole kerberos:

[3] Vérification des informations via l’outil Centrify DirectManage AccessManager

Lancer l’outil de gestion Centrify:

Il est facile de constater l’existence d’une nouvelle zone « Auto Zone » et de voir qu’elle contient un compte machine. Il est aussi possible de constater qu’il n’y a aucun moyen de gestion directe sur les droits d’accès ou sur la gestion des UIDs / GIDs comme il est possible via une zone Standard:

Comparaison avec une zone standard:

Pour bien comprendre les différences entre une Auto Zone et une Zone Standard, je vous conseille de consulter cette vidéo :

# Utilisation de comptes utilisateurs au niveau de machine MacOS X : Nous allons maintenant explorer les différentes possibilités pour utiliser les comptes utilisateurs sur la machine MacOS X

[1] Utilisation d’un compte local existant avant l’installation de l’agent

Il est bien sur possible de continuer à utiliser des comptes locaux, par exemple, nous avions un compte local « florent » qui est présent sur le MacOS X dans la base de comptes locale :

Par exemple, nous avons sur le bureau de cet utilisateur local quelques fichiers :

Si nous vérifions l’UID utilisé par le compte, nous constatons un UID local, qui est dans exemple 502:

[2] Utilisation d’un compte Active Directory sans lien avec la base de compte locale

Dans notre annuaire, nous avons par exemple un utilisateur « luc » qui n’existe pas dans la base de comptes locale :

il est possible d’utiliser ce compte et le mot de passe Active Directory pour se connecter sur la machine MacOS X:

Il est facile de constater que l’UID utilisé est un dérivé du SID du compte Active Directory généré par l’agent Centrify lui-même :

On peut constater la même chose au niveau de l’utilitaire « Users & Groups » dans les Préférences Système:

[3] Alignement d’un compte local existant avec un compte Active Directory : l’idée est ici de mapper un compte local existant avant la migration vers Centrify et l’installation de l’agent pour utiliser un compte utilisateur Active Directory le remplaçant tout en conservant le profil (/home/) de l’utilisateur local existant – cette manipulation est une opération très courante si vos machines MacOS X étaient déjà utilisées

Dans notre exemple, nous avons un compte local « dark »:

Personnalisons le bureau de cet utilisateur pour bien le repérer par la suite :

Cet utilisateur a un UID local, ici 502 :

Maintenant il faut créer un utilisateur avec le même login au niveau d’Active Directory :

Maintenant, reconnectons-nous sur le poste MacOS avec le compte local « dark », à ce stade l’agent Centrify vérifie s’il y a un compte équivalent côté Active Directory, ce qui est le cas et affiche le message suivant :

Cliquer simplement sur OK

Nous allons maintenant aligner les deux comptes en mappant le compte local avec le compte Active Directory et ce sans perdre les propriétés locales du compte existant.

Tout d’abord il faut s’authentifier sur la machine MacOS X avec un autre compte que le compte à aligner, par exemple le compte Florent puis il faut se rendre dans les Préférences Systèmes, puis dans les propriétés de l’agent Centrify :

Débloquer la configuration en cliquant sur le cadenas en bas à gauche et renseigner un compte avec des pouvoirs sur cette machine :

Puis sélectionner l’onglet « Account Migration » – ensuite sélectionner le compte à aligner avec le compte Active Directory, dans notre exemple il s’agit du compte « dark » et cliquer sur « Link »:

Un message d’avertissement apparait alors, cliquer sur OK :

Ce message est normal, il indique simplement que l’agent va supprimer le compte local (en fait il supprime l’entrée de ce compte dans l’index provenant de la liste du pointeur des comptes locaux OS X), pas de panique, cette manipulation ne supprime le profil local de l’utilisateur situé dans /users/ – cela va seulement supprimer l’existence du compte utilisateur local tout en conservant les données inhérentes au profil qui est conservé.

Automatiquement le mappage sur le compte Active Directory se réalise (basé sur le username), il faut alors cliquer sur « Apply »:

A la fin du processus, les deux comptes sont maintenant liés :

Fermer la session administrateur.

Maintenant, la mire de login ne propose plus le compte local « dark »:

Nous allons utiliser le login réseau et nous utiliserons le compte Active Directory « dark » pour se connecter sur la machine MacOS X:

Un message peut apparaitre vous demandant de mettre à jour la « keychain » du mot de passe – il faut alors choisir « update keychain » et renseigner votre ancien mot de passe ou tout simplement recréer une « keychain » pour le nouveau mot de passe si vous ne vous souvenez plus de votre ancien mot de passe local.

Comme convenu, nous avons conservé le profil utilisateur du compte local (/users/dark) mais il s’agit bien de l’utilisateur Active Directory avec un UID différent provenant du dérivé du SID compte utilisateur Active Directory :

A ce stade, l’utilisateur « dark » est maintenant capable d’utiliser sa machine MacOS X exactement comme avant, avec son bureau, ses raccourcis, etc. mais en bénéficiant de son compte Active Directory.

Dans le prochain et dernier article de cette série consacrée à MacOS X et Centrify, nous explorerons quelques possibilités en termes de GPOs Active Directory appliquées à MacOS X grâce aux technologies Centrify.

Installation de Centrify Workstation for Mac 2016 sur EL CAPITAN (MacOS X 10.11) [Part 2/4] – Installation de l’agent Centrify

3 janvier 2016SylvainLeave a comment

Installation de Centrify Workstation for Mac 2016 sur EL CAPITAN (MacOS X 10.11) [Part 2/4] – Installation de l’agent Centrify.

Lors de l’article précédent, nous avons préparé l’environnement, maintenant tout est prêt et le package DMG est sur le bureau d’un compte local MacOS X avec des pouvoirs d’administrateur :

La dernière des choses à vérifier est que le MacOS X n’est pas relié à Active Directory avec le plug-in Active Directory natif de MacOS X, ceci est très important. Pour vérifier, choisir l’option Utilisateurs & Groupes / Users & Groups dans les préférences systèmes :

Ici, il n’y pas de domaine joint, c’est donc parfait :

Passons maintenant au choses sérieuses…

[1] Vérification de l’environnement grâce à ADCheck

Le package DMG contient un outil de vérification de l’environnement avant installation de l’agent, il faut donc ouvrir l’image DMG:

Et choisir l’icône AD Check au lancement d’AD Check, l’assistant vous demande le nom de domaine du domaine que vous souhaitez rejoindre afin de faire les vérification, dans mon exemple, le nom de domaine est demo.local:

Puis cliquer sur le bouton bleu AD Check

Pour que la future installation se déroule sans encombre, il faut que vous n’ayez aucun "Failed" dans la liste des résultats aux tests – par exemple, ici, l’assistant AD Check m’indique que un des serveurs DNS que j’utilise sur ma machine ne gère pas le nom de domaine demo.local – nous allons donc l’enlever de la configuration DNS et refaire les test AD Check:

Ça y est, tout va bien !

[2] – Installation de l’agent et rejoindre le domaine AD

Lancer le package pour l’installation de l’agent Centrify:

Choisir "Continue":

Puis à nouveau sur "Continue":

Puis, après avoir lu le Software License Agreement, à nouveau sur "Continue":

Puis sur "Agree":

Puis sur "Install":

Indiquer le mot de passe de l’administrateur local (ici, le mot de passe pour Florent) et appuyer sur "Install Software":

Le processus d’installation de l’agent se poursuit alors :

A la fin du processus, choisir l’option "Launch centrify Join Assistant" (sélectionnée par défaut) et choisir "Continue":

La fenêtre de l’installateur indique que tout s’est bien déroulé :

Et une nouvelle fenêtre apparait pour lancer l’assistant AD JOIN, cliquer sur "Continue":

Indiquer le mot de passe de l’administrateur local (ici, l’administrateur local est Florent) et cliquer sur OK:

Indiquer alors le nom de domaine du domaine AD à rejoindre (ici demo.local), un compte administrateur AD qui a le droit d’écrire dans AD (à minima dans les UOs que vous avez créé dans l’article précèdent) ainsi que le mot de passe de ce compte d’administration AD, puis cliquer sur "Continue":

Indiquer les options pour rejoindre le domaine, vous pouvez garder toutes les options par défaut – pour des machines MacOS, je vous conseille de garder "Auto" pour le "Licensed Mode", cela vous permet de ne pas avoir à gérer les UIDs pour les comptes utilisateurs, par défaut dans ce mode, les UIDs générés dans la Zone Centrify seront un dérivé du SID utilisateur AD – vous pourrez ensuite aligner les UIDs générés dans cette zone avec les comptes utilisateurs existants au niveau de l’OS MacOS X via un outil fourni par centrify.

A noter que le premier ordinateur MacOS qui sera joint à AD avec le mode "Auto" va automatiquement créer la zone "Auto" au niveau de l’AD lui-même, contrairement aux systèmes Unix et Linux qui sont généralement joints dans des zones « standards », il n’y a pas besoin ici de créer la zone en amont de la première jointure au domaine.

Puis cliquer sur "Join"

Indiquer le mot de passe de l’administrateur local (ici, l’administrateur local est Florent) et cliquer sur OK:

L’assistant indique que la machine est en train de rejoindre le domaine AD:

Tout s’est bien déroulé, cliquer sur "Done":

Redémarrer le poste MacOS.

[3] – Première connexion avec un compte utilisateur AD

Sur la fenêtre de login du MacOS X, vosu trouverez par défaut les comptes locaux existants (ici Florent) – mais maintenant que vous avez joint la machine à AD, vous pourrez accéder à une liste d’utilisateurs provenant d’AD en cliquant sur "Other…"

Par exemple, nous avons un compte utilisateur existant dans AD qui est Luc:

Nous allons utiliser ce compte et son mot de passe AD pour nous connecter sur la machine MacOS X:

Un nouveau bureau pour Luc apparait :

Si nous utilisons une fenêtre de Terminal, et que l’on taper la commande ‘id’ on obtient les informations suivantes, l’UID a été automatiquement généré pour l’utilisateur :

Toujours dans le terminal, la commande ‘adinfo’ nous permet d’obtenir des informations sur la connectivité à AD:

Ça y est, c’est officiel, notre machine MacOS X EL CAPITAN a rejoint AD et peut utiliser tous les services AD.

Dans les prochains articles, nous allons explorer quelques pistes d’améliorations du paramétrage de base, utiliser quelques outils d’administration et nous allons explorer les GPOs applicables aux systèmes MacOS X.

Installation de Centrify Workstation for Mac 2016 sur EL CAPITAN (MacOS X 10.11) [Part 1/4] – Préparation de l’environnement pour installation de l’agent Centrify

2 janvier 20164 janvier 2016SylvainLeave a comment

Installation de Centrify Workstation for Mac 2016 sur EL CAPITAN (MacOS X 10.11) [Part 1/4] – Préparation de l’environnement pour installation de l’agent Centrify.

La version 2016 de la Centrify Workstation for Mac est sortie courant Décembre 2015. L’agent livré avec cette version (CentrifyDC-5.3.0-mac10.9.dmg) est directement compatible avec la version OSX 10.11 (EL CAPITAN).

A noter, cette version de l’agent n’est plus compatible avec les versions 10.8.x d’OSX, pour supporter ces anciennes versions, il faut utiliser les agents fournis avec les anciennes versions de la Centrify Workstation for Mac (version 2015.1 ou version 2015 par exemple).

A savoir, le CD Centrify 2016 qui contient les agents ne contient que la version TGZ du paquet de l’agent Centrify. Une fois le paquet TGZ extrait, celui-ci contient un paquet TAR qui contient les éléments suivants :

Le fichier CentrifyDC-5.3.0-mac10.9.dmg est un disque image pour Mac OS X et contenant les éléments suivants :

• AD Check.app: une application graphique pour réaliser une vérification de l’environnement avant de lancer l’installation réelle de l’agent (ADCHECK)

• Un Guide d’utilisation pour les Administrateurs Mac OS X (Admin Guide for Mac OS X.pdf)

• Un installeur graphique de l’agent (CentrifyDC-5.3.0-x86_64.pkg) valide pour Mac OS 10.0.x, 10.10.x et 10.11

• Un Guide de prise en main rapide (Quick Start Guide for Mac OS X.pdf)

• Le document de « Release Notes » pour cette version de l’agent (Release Notes for Mac OS X.pdf)

Afin de bien préparer votre environnement, vous pouvez réaliser les actions suivantes :

[1] – Créer des UOs pour ranger vos objets dans AD

Je vous conseille de créer une arborescence comme celle-ci par exemple :

Dans notre exemple, nous mettrons plus tard les objets des comptes machines MacOS X dans l’UO « WORKSTATIONS »

Bien évidemment, sur ces UOs, il faudra que l’administrateur MacOS X est des droits d’administration suffisant, mais cela, c’est du design AD pur et dur.

[2] – Installer les outils d’administration sur une machine Windows

Vous devez installer mes outils d’administration (suivre le guide d’installation) afin d’avoir au moins deux outils d’installés :

Centrify DirectManage – Access Manager

Centrify DirectManage – Deployment Manager

[3] Renseigner les licences

Ouvrir l’outil « DirectManage Access Manager » et rajouter les licences pour la partie Mac OS en réalisant un clic droit sur le nœud supérieur et choisir « Manage Licenses »

Puis renseigner la clé de licences dans l’onglet « Update » – Il faut bien saisir la clé avec les tirets. Une fois les licences validées vous devez avoir une entrée telle que : « Unix Workstation Licenses ».

[4] – Vérifier la configuration de la machine MacOS X:

Aller dans les préférences systèmes :

Puis choisir Network/Réseau :

Renseigner les éléments réseau de manière à ce que le MacOS X soit compatible avec votre plan d’adressage IP réseau, renseigner les serveurs DNS qui adressent votre nom de domaine Active Directory.

Vous pouvez aussi modifier le nom hôte de votre système MacOS, car par défaut c’est le nom qui sera utiliser pour créer l’objet ordinateur représentant votre systèmes dans Active Directory – Pour cela, aller dans Préférences systèmes, puis choisir Partage/Sharing:

Votre changement doit être reflété si vous tapez la commande hostname dans un terminal:

Ensuite, nous allons activer la fonction de « Remote Login » dans Partage/Sharing (Préférences Systèmes):

A ce stade, un membre des administrateurs du MacOS pourra se connecter en SSH pour notamment transférer l’agent sur la machine avant installation.

[5] – Transfert de l’agent sur la machine

Il existe de nombreux moyens de transférer le fichier dmg de l’agent, mais comme nous sommes censés être en réseau nous allons utiliser l’outil WinSCP que vous pouvez télécharger ici: http://winscp.net/eng/download.php

Installer WinSCP sur la machine qui sert à l’administration Centrify (par exemple), puis lancer WinSCP et paramétrer une session SFTP pour transférer le package Centrify – choisir un nom utilisateur qui fait partie des Administrateurs locaux du MacOS (dans notre exemple, l’utilisateur a un login « florent »:

Transférer ensuite le package DMG sur le bureau de florent (répertoire Desktop):

Le package doit alors apparaitre sur le bureau de l’utilisateur :

Une fois ces éléments préparés, nous allons maintenant passer à l’installation de l’agent côté Mac OS X dans le prochain article.

Directory as a Service, c’est parti !

16 octobre 201527 janvier 2016SylvainLeave a comment

Ça y est ! Microsoft rend public Azure AD Domain Services (à ne pas confondre avec Azure AD ou avec le fait d’installer un DC sur la plateforme IAAS d’Azure… Bon, je sais, ca devient un peu compliqué) qui est la première brique d’une approche qui fait fantasmer énormément de monde: le Directory As A Service ou DaaS. Alors oui, vous allez me dire le DaaS c’est aussi le « Data as a Service », le « Desktop as a service », etc… bon d’accord, alors écrivons le comme cela: DIRaaS, cela sera plus clair…

Donc pour faire simple, Microsoft rend public un nouveau service Azure permettant de créer un service online « simulant » un Active Directory dans Azure (côté SaaS, pas côté IaaS): Azure AD Domain Services. Les objectifs de ce service sont multiples:

(1) Permettre aux entreprise qui possèdent des applications AD dépendantes dans l’IaaS d’Azure (donc des applications hébergées sur des machines virtuelles Azure pour faire simple) de consommer un service Active Directory standard (enfin presque…) sans être obligé d’installer et de maintenir des DCs sur des machines virtuelles Azure uniquement pour des besoins applicatifs

(2) Permettre à des petites entreprises de pouvoir TOUT consommer sous la forme de service d’infrastructure depuis la plateforme Azure – Mais attention, à ce stade il n’est possible que de joindre des machines qui sont des VMs dans Azure, donc ici, pas possible de joindre un domaine Azure AD Domain Services depuis par exemple une machine Windows 10 qui est « on premises » (alors que cette fonction existe avec AD Azure, oui je sais c’est un peu compliqué…)

(3) A terme, fournir un véritable DIRaaS pour les grandes entreprises. Sur ce point, oui, je sais, j’extrapole, mais je sens bien les choses comme cela, et franchement c’est assez intéressant. Bien sur il y a encore pas mal de dev à faire, mais cela va venir, j’en suis persuadé…

Faire des tests !

En effet, dans le cadre de la gestion de VMs qui sont dans Azure et qui possèdent des applications dépendantes à AD, il faut voir globalement le service Azure AD Domain Services comme un service qui expose les protocoles Kerberos, NTLM, LDAP et GPOs – les VMs Azure peuvent donc joindre ce domaine. Mais attention, on est pas ici exactement comme un domaine AD, donc il est important de faire des tests pour valider que vos applications sont fonctionelles dans ce contexte technique et être certain qu’elles fonctionnent avec ce service – à ce jour, je ne suis pas sur qu’il existe un catalogue officiel d’applications certifiées pour le service, cela viendra certainement.

En bref.

Super intéressant, à tester. Plus d’informations [ ici ]

Microsoft prépare un outil de gestion des privilèges basé sur MIM, MFA et Kerberos

17 mai 2015SylvainLeave a comment

Comme vous le savez, la prochaine version de Forefront Identity Manager (FIM) s’appellera Microsoft Identity Manager (MIM) et sortira vraisemblablement courant 2015 (voir les annonces de roadmap ici) . Cette nouvelle version apportera une nouveauté extrêmement intéressante pour les grandes organisations: un bastion pour la gestion des privilèges.

Pour faire simple, le principe est la création d’une forêt bastion (avec des DC Windows 2012R2 ou vNext), la création d’un trust (la forêt de production approuve la forêt bastion), la création des groupes AD d’administration (ceux dont l’appartenance permet l’exécution de commande à privilège) dans la forêt bastion (avec le même SID que les groupes qui sont dans la forêt de production), et le « vidage » des groupes d’administration dans la forêt de production.

Ensuite, un administrateur peut faire une demande via MIM ou via un service web utilisant les APIs de MIM afin de « devenir » administrateur d’une partie du SI pendant un temps donné. La solution est capable de gérer l’appartenance temporaire à ce groupe, fournie du reporting (bon, ok, c’est un peu de la bricole pour l’instant le côté reporting…), l’intégration avec MFA pour l’authentification à deux facteurs lors d’une demande particulière et le pilotage du TGT du ticket kerberos pour être certain que l’administrateur ne pourra pas bénéficié de l’appartenance au groupe plus longtemps que prévu.

Voici un schéma résumant la fonction:

Il reste à vérifier avec le temps comment les entreprises vont appréhender cette nouvelle fonction et comment elles vont accepter le fait d’avoir à rajouter une forêt bastion pour gérer les comptes à privilège.