Si vous vous intéressez aux principes d’attaques et d’exploit, vous trouverez dans cette vidéo des informations importantes vous permettant de mieux comprendre comment les groupes cyber-criminels utilisent Active Directory pour se répandre dans les organisations, et bien sur quelques trucs …
Le NIST vient de mettre en ligne un document (en Draft) proposant une description des concepts de gestion de identités par la BlockChain. Au delà du document, les nombreuses références citées (que l’on retrouve à la fin du document) sont …
Chaque semaine, je discute avec des dizaines d’organisations, des très grandes, des moyennes, des gigantesques… c’est assez varié. Le point commun de l’ensemble de ces organisations, c’est leur certitude d’avoir un environnement Active Directory extrêmement sécurisé, c’est assez amusant.
J’insiste, mes contacts ne veulent pas « m’abuser » ou me « faire croire »… ils sont vraiment persuadés de maintenir un environnement Active Directory sécurisé… Quand je leur demande de fournir une note entre 1 et 10 sur l’estimation du niveau de sécurité de leur Active Directory, la plupart des réponses sont positionnées entre 7 et 9 – ils sont malheureusement très loin de la réalité…plus précisément de leur réalité…
…
La solution de Google, Google G-Suite est une solution très utilisée aux USA, notamment pour son coût extrêmement faible à destination des petites organisations par rapport à la concurrence. Ensuite, c’est une affaire de goût et d’habitude, personnellement, j’ai toujours eu des « difficultés » avec les interfaces proposées par Google, mais c’est un autre débat !
…
Une annonce majeure de la part de Microsoft, attendue depuis longtemps !
Microsoft va proposer une interface de gestion commune des fonctions de protections (ex Azure RMS) et des fonctions de Labeling (ex Secure Island) ainsi qu’un client unifié pour les postes et périphériques mobiles.
…
Le National Institute of Standards and Technology (NIST) est un institut américain délivrant régulièrement des documents de spécifications et des recommandations à l’attention de l’ensemble des autres organisations gouvernementales américaines. Même si les documents publiés ne sont pas exclusivement orientés sur les aspects sécurité (comme par l’exemple l’ANSSI en France) de nombreuses recommandations traitent de ces sujets, et de nombreux documents sont publiés pour aider les organismes américains à l’implémentation de solutions fiables et standardisées.
Le NIST a récemment publié un brouillon (Draft) de trois documents importants traitant de Digital Identity:
…
I received a lot, I mean a lot, of requests after I had published my 3 last posts about the storage of NIS maps in Active Directory [http://bit.ly/1S4gKUG – http://bit.ly/1qvvyzr – http://bit.ly/1q8iAHi ] – The main problem was my posts are in French 😉 and a lot of people tried to use Google Translate to get it, but it wasn’t perfect. So, from the popular demand, I decided to translate it in English. English is not my native language, so sorry in advance if you will find some ‘bugs’ in the text.
As I explained in one of my last post (sorry again in French !), Microsoft announced it will not implement some Unix Services in Windows 2016 and Active Directory 2016 anymore, including NIS Services.
…
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.
…
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.…
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 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.…