LEX, the definitive LDAP Explorer ! [1/4]

Je viens de commencer une série d’articles sur un outil tout à fait extraordinaire découvert il y a peu, au hasard d’échanges informels avec quelques spécialistes LDAP, j’ai nommé LDAP Explorer, ou LEX de son petit nom. Non, il ne s’agit pas d’une option permettant de jouer Lex Luthor dans un jeu en ligne pour mettre sa raclée à Superman, mais bel et bien du meilleur explorateur LDAP du marché !

C’est quoi LEX ?

Comme de nombreux consultants IAM, j’ai forcement dans ma boite à outils un explorateur LDAP. Comme je suis très feignant (oui, je suis feignant), je faisais comme tout le monde, c’est-à-dire :

  • ADSIEDIT fourni par Microsoft et gratuit lorsque j’ai besoin d’un browser LDAP coté Active Directory. Outil développé à la « va vite » et extrêmement basic mais accessible depuis la MMC.
  • LDAP Administrator de la société Softerra et payant lorsque j’ai besoin d’un browser LDAP à utiliser avec un autre service LDAP qu’Active Directory. Outil très puissant, la référence sur le marché depuis de nombreuses années.

Oui bien sûr, il est tout à fait possible d’utiliser LDAP Administrator pour administrer Active Directory, mais il manque quelques fonctions, disons spécifiques à Active Directory et qui rendent cet outil intéressant mais pas un must to have pour l’administration Active Directory (nous reviendrons sur ce point un peu plus loin).

Oui, il est aussi possible d’utiliser des alternatives « gratuites » à LDAP Administrator, mais là on rentre dans un monde rempli de projet SourceForge plus ou moins aboutis, avec des trucs sous JAVA, ce qui me donne des boutons très très rapidement. De plus, lorsque je travaille avec un outil, je veux dire vraiment « travailler », je ne veux pas dépendre d’un bout de code développé par un stagiaire un soir de pleine lune, mes outils professionnels, je préfère les payer et être tranquille. Chacun sa méthode, mais j’ai tendance à me méfier des produits « gratuits ».

C’est là où LEX intervient et m’apporte le meilleur des deux mondes !

En effet, LEX est un explorateur LDAP, tout ce qu’il y a de plus classique, mais il possède la caractéristique de contenir des fonctions très avancées en ce qui concerne l’utilisation et la gestion d’Active Directory. Et bientôt (nous y reviendrons) l’outil pourra également gérer un annuaire Azure Active Directory. Cela m’intéresse fortement…

Premiers pas avec l’outil LEX

Vous pouvez télécharger l’outil ici : http://ldapexplorer.com/en/download.htm

Vous pouvez trouver une description des fonctions principales ici : http://ldapexplorer.com/en/features.htm

Et consulter la documentation ici : http://ldapexplorer.com/en/manual.htm

Installation de LEX et première connexion LDAP

Cet article est basé sur la version 1.5 Build 003 de LEX.

Commençons donc l’installation,à cette étape, rien de bien compliqué, on est sur du bon vieux next / next / next…

Au premier lancement, vous êtes invité à renseigner la clé du logiciel ou à utiliser LEX en mode évaluation :

La différence principale qui existe entre le mode « trial version » et le mode « sous licence » est que seule une version sous licence peut modifier l’annuaire LDAP, en version d’évaluation, vous ne pouvez réaliser que des visualisations. La suite de cet article est réalisée avec la version sous licence, permettant d’exploiter pleinement l’ensemble des fonctionnalités.

Une fois lancé, sur le premier écran, il est alors possible de se connecter à des services LDAP sur le réseau public ou de paramétrer une connexion à un LDAP en interne, dans notre exemple nous allons nous connecter à un contrôleur de domaine Active Directory :

Il est alors possible de définir soi-même le serveur sur lequel se connecter :

Ou d’utiliser le bouton « Detect » qui va rechercher des serveurs LDAP ou des Contrôleurs de domaine AD sur votre réseau :

Ici, on détecte immédiatement les avantages de LEX lorsque l’on veut manipuler AD, il va pouvoir s’adapter à un contexte AD, proposer des informations puis des fonctions spécifiques à Active Directory :

Les autres onglets de la mire de connexion sont assez classiques, il s’agit de pouvoir par exemple filtrer les classes d’objet que l’on veut voir afficher dans l’explorateur LDAP.

Usage de LEX et options spécifiques à Active Directory

Rentrons maintenant dans le vif du sujet, ce qui saute immédiatement aux yeux, c’est que le produit est très « moche » !

Pour information (nous reviendrons plus loin sur cet aspect) une nouvelle version de LEX est en cours de préparation avec notamment une IHM totalement revisitée, avec encore plus de fonctions spécifiques à Active Directory :

Mais pour l’instant, continuons avec la version actuelle.

La sélection d’un objet permet d’afficher les attributs de cet objet dans la zone à droite, ici, nous voyons que les attributs sont typés via des icônes différentes, ce qui fait une première différence à comparaison des éditeurs LDAP classiques, avec l’habitude, si l’on recherche par exemple l’attribut « objetSID », on visualise immédiatement l’icône qui correspond à cet attribut :

Les options d’affichage sont complètes, avec :

Un affichage classique :

Un affichage sur le DN :

On remarque des petits détails, mais qui facilitent la vie de l’administrateur ou de l’architecte AD, ici pas besoin de vérifier un attributs LDAP pour vérifier si le compte est activé ou non, un compte désactivé affichera une icône spécifique, c’est vraiment sur ce type de fonction que LEX se distingue de la concurrence, il apporte une « intelligence » d’affichage Active Directory au lieu de se contenter d’afficher des objets au format LDAP :

Il est également possible de filtrer les objets affichés sans passer par la case requête LDAP, directement via un menu déroulant, typiquement, la liste des objets utilisateurs désactivés est très simple à afficher :

Avec la barre de filtre des attributs, on peut spécifier les attributs affichés : uniquement les attributs avec des valeurs, les attributs multi-value ou non – il existe aussi un système de filtre avancé sur les attributs affichés :

Bien évidemment, les attributs modifiables sont éditables depuis l’explorateur LDAP :

Un bon exemple des particularités de LEX par rapport à un éditeur LDAP classique est la gestion de l’attribut « nTSecurityDescriptor ». Cet attribut contient la liste des ACE (AccessControlEntry) posés sur l’objet, pour faire simple, c’est ce que vous voyez dans l’onglet sécurité de l’objet. Cet attribut n’est pas affiché dans ADSIEDIT, car Microsoft considère que l’onglet Sécurité suffit au bonheur des administrateurs :

Peu de personnes le savent, mais ces informations sur les ACEs sont stockées au sein de l’objet lui-même, dans cet attribut. Si l’on requête cet attribut depuis un explorateur LDAP classique, on reçoit une valeur en binaire ; inexploitable. LEX a donc intégré un convertisseur hexadécimal et un parseur afin de présenter l’attribut et le rendre éditable :

C’est tout bonnement génial.

Un autre très bon exemple des caractéristiques avancées de LEX est l’attribut « userAccountControl ». Quand on requête cet attribut via un explorateur LDAP classique, voilà ce que l’on peut trouver :

L’attribut userAccountControl est en fait construit avec une somme de valeurs qui décrivent certaines options sur le compte utilisateur, par exemple le fait qu’un utilisateur doit changer son mot de passe à la prochaine ouverture de session est contrôlé par cet attribut.

Pour comprendre comment cet attribut est construit et à quoi il peut bien servir, je vous conseille la lecture de ces articles :

https://blogs.technet.microsoft.com/askpfeplat/2014/01/15/understanding-the-useraccountcontrol-attribute-in-active-directory/

https://msdn.microsoft.com/fr-fr/library/ms680832(v=vs.85).aspx

https://support.microsoft.com/fr-fr/help/305144/how-to-use-the-useraccountcontrol-flags-to-manipulate-user-account-pro

A nouveau LEX se démarque en présentant non pas la valeur brute de l’attribut mais une interface permettant de paramétrer individuellement les différents paramètres de comptes, le calcul de la valeur finale (=la valeur de l’attribut via LDAP) sera fait automatiquement par LEX avant enregistrement des choix de l’administrateur au niveau de l’attribut :

Comme nous venons de le voir, LEX est bien plus qu’un explorateur LDAP, il intègre des fonctions qui lui permette quasiment de se substituer à la console ADUC !

Dans la suite de cette série d’articles, nous irons encore plus loin dans la découverte de LEX, croyez-moi, vous n’êtes pas au bout de vos surprises…

Retrouvez mes présentations lors de l’évènement aOS Grenoble !

Le 22 mai 2017, de nombreux experts IT se sont réunis sur Grenoble afin de présenter différents concepts autour des nouvelles technologies et des tendances informatiques actuelles. Cet évènement était organisé par la communauté aOS. Les sessions couvraient des sujets aussi variés que le développement dans Azure, la téléphonie sur IP ou les infrastructures Cloud. Pour ma part, j’ai réalisé une première présentation sur la Digitalisation des environnements de travail (Workplace Digitalization) et une deuxième sur la gestion des identités dans le cloud.

Vous pouvez retrouvez ces deux présentations sur ce lien docs.com:

 

Quel intérêt à utiliser Ping Identity avec Azure AD Premium ?

 

Il y a quelques mois, Microsoft annonçait son partenariat avec Ping Identity pour renforcer son offre Azure AD Premium:

Mais cette annonce coïncidait avec l’annonce quelques semaines auparavant de la mise en preview d’une fonction de App Gateway au niveau d’Azure AD Connect (fonctionnel mais toujours en preview à ce jour). Ainsi, beaucoup de mes clients et contacts me demandaient au fil des semaines quel pouvait être l’intérêt pour eux d’utiliser Ping Identity alors que Microsoft fournissait maintenant une App Gateway permettant non seulement de publier des applications on-prem au niveau du portail Azure AD Premium sans l’obligation d’ouvrir des ports au niveau des firewall mais également de jouer des authentification sur l’annuaire Active Directory local sans déployer ADFS. Nous allons essayer de répondre à cette question dans cette article.

Déjà, revenons quelques instant sur l’offre Ping Identity. Ping Identity est l’entreprise leader dans le domaine des solutions de fédération d’identité pour les entreprises. Cette entreprise américaine a vraiment été un des pionniers en la matière, principalement pour les organisations avec des besoins complexes ne pouvant pas être couverts avec ADFS et Shibboleth. Mais depuis environ 18 mois, les offres Ping Identity ont été progressivement dépassées par les solutions de IDentity as a Service, qui rappelons le, propose notamment un système de fédération multi-tiers en mode SaaS. Ping Identity a essayé de réagir sur le segment IDaaS, mais leur architecture produit n’a pas convaincu, laissant le champs libre à Microsot, Centrify et Okta sur le marché IDaaS. Il fallait donc régir pour ce leader établi  de la fédération d’identité.

En septembre dernier, Microsoft annonçait donc son partenariat avec Ping Identity:

En parallèle, Microsoft proposa en private preview puis en public review la fonction App Gateway intégrée à Azure AD Connect avec notamment les possibilités suivantes:

  • Fournir un accès aux applications internes sans modification des firewall, des routeurs ou des reverse proxy
  • Sécurisation de l’accès aux applications internes via un mécanisme de « reverse VPN » basé sur la fonction bus d’Azure
  • Publication d’applications web internes utilisant IWA (Integrated Windows Authentication)
  • Publication d’applications Web utilisant « form-based access »
  • Publication d’applications publliées via la fonction Remote Desktop Gateway

Ces avancées notoires permettant nottamment à Microsoft de rattraper son retard sur la fonction Cloud Gateway proposé par Centrify via son offre IDaaS.

Que peut donc me fournir Ping Identity en plus de ces fonctions déjà très intéressantes ?

La raison principale de ce partenariat est de pouvoir traiter des applications web internes utilisant l’authentification de type headers HTTP.

Pour ce, il sera nécessaire d’installer un composant supplémentaire PingAccess au niveau du réseau local, ce composant communiquant avec Azure AD Premium et le connecteur Azure AD Connect:

Pour ce, il est possible directement au niveau de la console Azure AD Premium de publier de telles applications en indiquant quelles seront accédées en passant par le composant PingAccess:

Un des intérêts de cette combinaison est de « contourner » les options de sécurité assez faibles d’une authentification par headers Http en utilisant des APIs Azure spécifiquement développées pour faire communiquer Azure AD Premium et PingAccess: ainsi, il sera possible de définir des règles d’accès et de rôles qui seront transposées et traduites par le composant PingAccess depuis le RBAC Azure:

Quel avenir pour ce partenariat ?

Euhm… bonne question ! Pour ma part je ne suis pas convaincu par le fait que cette fonction sera suffisante a faire décoller le partenariat technologique et commercial, surtout que pour l’instant le modèle de pricing de PingAccess pour Azure AD est assez obscure, Ping Identity n’étant pas spécialement connu pour le côté bon marché de ses produits… (bon, après ce sont de très bons produits, tout se paye). De plus, au travers de mes différentes missions de consulting sur la partie IDaaS, ce type d’authentification (Headers Http) n’étaient pas la priorité des clients…

Un point stratégique important est de comprendre que les offres de IDaaS vont petit à petit éliminer le besoin de solution de fédération d’identité installées localement (ADFS, Shibboleth, Ping, ForgeRock, etc.) et vont remplacer sous forme de service SaaS l’ensemble des composants de fédération. Bien sur, pour des besoins très spécifiques, notamment en ce qui concerne des scénarios complexes dans des grandes entreprises, les passerelles de fédération d’identité installées localement ont encore de beaux jours devant elles, mais dans 5 ou 6 ans ? Pas certain !

Bon, à la fin, cela serait peut-être plus simple si Microsoft rachetait Ping Identity, non ? 😉

40 minutes pour tout comprendre de Microsoft EMS

Microsoft Cloud Platform vient de poster une vidéo de présentation de Microsoft EMS (Enterprise Mobility & Security) extrêmement bien réalisée. La vidéo mêle la présentation globale de chaque module EMS et les enjeux rattachés en termes de productivité ou de sécurité ainsi que des démonstrations techniques extrêmement bien ciblées.

En 40 minutes, cette vidéo permet à chacun de comprendre le positionnement d’EMS et les fonctionnalités principales des différents modules. cette vidéo est tellement simple qu’elle peut même être envoyée à un manager, c’est dire !  😉

L’ensemble des modules est passé en revue, Azure AD Premium, AIP, Conditional Access, etc.

La vidéo est accessible ici:

 

 

Azure AD Pass-Through Authentication et Seamless SSO par Maxime Rastello

Maxime Rastello est consultant & MVP, il s’est fait une spécialité de la partie Azure et notamment des processus et des fonctions liées à l’IAM ou à la sécurité dans Azure. Depuis peu, il a commencé une série de vidéos, dites « Deep-Dive ». C’est vraiment très bien fait et didactique, le format entre 15 et 30 minutes est parfait pour approfondir le sujet mais sans que cela devienne assommant. La dernière vidéo en date porte sur deux nouvelles fonctions en preview, qui de mon point de vue, vont révolutionner l’usage d’Azure Active Directory dans le monde des entreprises et notamment dans les PME ou ETI: Azure AD Pass-Through Authentication et Seamless SSO.

Pour suivre sa chaîne YouTube: https://www.youtube.com/channel/UCL9JIy1auTKjwESwa3XCJ7g/videos

Pour le suivre sur Twitter: @MaximeRastello

Pour retrouver sa dernière vidéo sur Azure AD Pass-Through Authentication et Seamless SSO:

 

Quel futur pour Active Directory et Azure Active Directory ?

eic_kimcameron

La 10ème conférence European Identity & Cloud (eic) est terminée. Elle a été très riche en sessions techniques ou stratégiques. Un des points culminants de cet événement a été la présentation de Kim Cameron sur le futur des technologies Active Directory (en local donc) et Azure Active Directory (dans le cloud donc).

Pour ceux qui ne connaissent pas Kim Cameron, il s’agit de « monsieur identité » chez Microsoft, il est Chief Architect of Identity et donne la mesure et bâtie la stratégie de Microsoft en ce qui concerne la gestion des identités. Son blog est une référence sur ce sujet dans le monde anglophone: http://www.identityblog.com/

Dans cette session, Kim Cameron a tenté de présenté des pistes pour les décideurs IT, leur donnant sa vision du futur et de la cohabitation des technologies Active Directory et Azure Active Directory, en faisant notamment un focus sur le service Azure AD Directory Services permettant d’exposer Azure Active Directory au travers de services généralement utilisés localement sur un Active Directory local (kerberos, LDAP, etc.).

Pour ma part, je pense que dans 2 ou 3 ans, le couple Azure Active Directory + Azure AD Domain Services permettra de fournir un ensemble de services équivalents à ce que nous connaissons actuellement avec un Active Directory local, il s’agit vraisemblablement du futur des annuaires dans le cloud, avec une multitude d’applications ou de systèmes qui pourront se connecter et utiliser ce service global. Sans vouloir faire le « Microsoft Fan Boy » de base, il n’y a aucun équivalent à cette offre chez les autres fournisseurs cloud, Microsoft est en train de créer une offre de services IAM dans le cloud sans aucun concurrent valable ou valide. Cela est même assez étonnant de voir la pauvreté de l’offre Amazon et Google dans ce domaine…

Vous pouvez consulter la présentation de Kim Cameron ici:

 

Bien commencer avec Azure Active Directory: Azure Active Directory Proof Of Concept Playbook

azure_ad_poc

Beaucoup de mes partenaires et clients me demandent: « comment tester, évaluer et comprendre en quelques jours se qu’est et comment fonctionne Azure Active Directory ? » – en qq mots, comment faciliter la mise en oeuvre d’un POC sur la solution. Microsoft a conçu et met régulièrement un jour un document de référence qui permet « assez facilement » de réaliser ce test: « Azure Active Directory Proof of Concept Playbook.pdf »

Ce document a un grand intérêt car il contient l’ensemble des informations importantes pour la réalisation d’un POC Azure AD et surtout il contient la liste des autres documents ou articles de référence permettant facilement de comprendre les concepts périphériques pour aller un peu plus loin dans la compréhension si c’est la volonté de la cellule IT réalisant cette évaluation.

Le document possède la structure suivante:

azure_ad_poc_doc_contenu

 

Par exemple, comme indiqué, le document contient toutes les références « externes » nécessaires aux différentes étapes, par exemple ici, la liste des prérequis pour la réalisation du POC avec les liens externes nécessaires:

azure_ad_poc_doc_contenu_a

Bref, un très bon point de départ pour ceux qui veulent explorer et comprendre Azure Active Directory.

Rappel du lien pour le document: [ ICI ]

 

 

 

Comparatif DirSync vs Azure AD Sync vs Azure AD Connect

windows_azure_smallDeuxième article remarquable sur le blog de Maxime: un article de synthèse réalisant un comparatif des trois solutions de « synchronisation » ou de « mise à jour des informations » entre les données locales et le service Azure AD (service nécessaire notamment à l’utilisation d’Office365)

Le problème de ce type d’article est le côté « périssable » de l’image instantanée des fonctions décrites, donc peu de personnes font l’effort de les écrire, encore merci à Maxime pour son travail de synthèse.

L’article est accessible [ ici ]