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 ? 😉

Quel avenir pour One Identity ? (ex Quest)

 

Les plus vieux d’entre vous connaissent vraisemblablement l’historique truculent et les tribulations sans fin des actifs de la société Quest Software.

A l’origine cette société a racheté et vendu le produit Toad pour les DBA Oracle dans le monde entier. Toad, véritable vache à lait de la société, a permis à Quest Software de constituer un véritable trésor de guerre, très conséquent (voir très très très conséquent…), permettant à Quest Software de réaliser massivement des acquisitions de sociétés IT et de produits tiers sur le marché des startup américaines, constituant au fil du temps un portfolio impressionnant de produits technologiques destinés aux entreprises. Cette démarche d’acquisition fut à la fois la force et la faiblesse de Quest Software car il n’y avait aucun ciment technologique commun entre les différentes acquisitions aboutissant à un éventail de produits totalement désynchronisés d’un point de vue stratégique et technique.

La solution ActiveRoles a fait partie de ces acquisitions, permettant ainsi à la société de rentrer dans le domaine de la gestion des identités et des accès, notamment en environnement Microsoft. Ensuite, Quest Software a essayé de rationaliser sa stratégie liée à la gestion de l’identité en constituant une « marque » One Identity sensée représenter l’ensemble de la gamme gestion des identités au sein de Quest Software.

S’en est suivi le rachat de Quest Software par DELL, et là, franchement, cela a été un jeu de massacre, les produits non rentables commercialement ont plus ou moins été abandonnés, de nombreuses ressources tant techniques que commerciales sont aller voir ailleurs, et l’activité de la division DELL Software a petit à petit périclité… L’exemple typique est l’abandon d’investissement dans la gamme ex-Vintela, laissant à Centrify le champs libre sur le marché du bridge AD et de la gestion des privilèges sur Unix et Linux. Le nombre de migration ex-Vintela vers Centrify a alors été impressionnant…

DELL a ensuite décidé de rendre sa « liberté » à Quest afin de reprendre du poil de la bête. Désirant certainement modifier sa stratégie, la nouvelle société Quest a ensuite  décidé de se séparer de la division Gestion des Identités, appelée One Identity, afin de constituer une structure juridique indépendante de Quest. Tout ceci est assez surprenant, mais je ne connais pas tous les détails de la « transaction » ni les objectifs cachés de cette décision.

Un nouveau site est en ligne afin de présenter cette nouvelle entité juridique et les activité de One Identity: https://www.oneidentity.com/

 

Ce site web présente les produits historiques de la gamme de Quest Software en ce qui concerne la gestion des identités:

J’avoue que je ne sais plus trop quoi penser de ces produits…ni de leur avenir à moyen terme. De sources sures, les développeurs originels de ces différentes solutions se sont majoritairement fait la malle… Donc…

Quelle est la stratégie globale à moyen et long terme de cette nouvelle entité ?

Quel support technique pour les clients ?

Quel support commercial & technique pour les partenaires ? (abominable à l’époque de Quest Software)

Tout ceci est encore un peu nébuleux pour moi… et je n’ose imaginé ce qu’il en est pour les clients…

Pourtant certains produits, si ils sont véritablement repris en main, modifiés et adaptés aux nouvelles contraintes en terme d’IAM, possèdent un énorme potentiel, je pense notamment au couple Identity Manager +  Active Roles qui pourraient devenir une alternative crédible à MIM dans des grosses PME ou des ETI.

Si cette nouvelle entité possède les moyens de ses ambitions, cela mérite véritablement de garder un œil sur les futures mises à jour de ces produits et de suivre l’évolution de tout ceci dans les prochains mois.

A suivre donc, pour le meilleur ou pour le pire, nous verrons bien  😉

 

Comment Microsoft peut il vous accompagner dans votre démarche de certification ou conformité ?

Travaillant actuellement pour une grande organisation internationale désireuse de différentes certifications afin d’atteindre certains principes de conformité, je me suis trouvé pris à parti lors du dernier comité de pilotage. Lors d’une réunion garnie de chefs à plumes, le CISO du client, du haut de son piédestal, de ses certitudes et de son Anglais parfait d’Oxford m’a demandé comment les technologies Microsoft pouvaient aider son organisation dans cette démarche… La question ne m’avait jamais été posée sous cette angle… Bon il faut dire que le personnage n’avait pas l’air super fan des technologies Microsoft, cela sentait le piège… son œil malicieux était vif et brillant…

J’ai travaillé sur de nombreux projets PCI-DSS, des projets ISO, etc… souvent les solutions implémentées en réponse à ces demandes étaient réalisées via un ensemble de technologies différentes: Active Directory, Centrify, principes de moindre privilège, FreeBSD, système d’audit et de tableaux de bord, FIM/MIM, méthodologie BPM, scripts, utilisation de cartes à puce, etc. Jamais un RSSI ne m’avait « attaqué » sous l’angle « moqueur » du tout Microsoft…

Suite à sa demande et à quelques recherches, je suis tombé sur un site web de Microsoft vraiment intéressant proposant une source d’information quasi exhaustive sur le « comment Microsoft me permet d’avancer dans mon projet de Compliance »: https://www.microsoft.com/en-us/trustcenter/compliance/complianceofferings

Tout n’est pas parfait, mais ce site a le mérite d’exister. Il permet en effet de sélectionner les différents type de certification par type ou par région du monde:

Après une brève description de la certification, exemple ici avec ISO27001:

Le site permet d’obtenir tout d’abord des informations concernant les certifications obtenues par les produits ou services Microsoft dans le domaine considéré:

Puis de consulter de nombreuses sources additionnelles:

Bien évidement, en fonction de la certification, les données proposées et la structure de présentations diffèrent quelque peu.

Pour ceux qui recherchent sur la certification PCI-DSS, notamment dans le cadre de l’utilisation des services Azure, Microsoft met à disposition un fichier Excel vous permettant de définir, en fonction des objectifs PCI-DSS, quels sont les éléments sous la responsabilité de Microsoft et quels sont les éléments sous votre responsabilité. Très utile pour structurer son approche conjointe Cloud + PCI-DSS:

Je vous rappelle également l’existence d’un outil souvent méconnu de Microsoft, Security Compliance Manager (SCM), qui est une boite à outils extraordinaire pour ce type de projet – de plus l’outil est totalement gratuit et peut fournir des modèles prêts à l’emploi à utiliser via les GPOs, DSC ou SCCM afin d’appliquer des modèles de « compliance » sur les workstations ou les serveurs. Une nouvelle version de SCM prend d’ailleurs en compte Windows Server 2016 et Windows 10: https://technet.microsoft.com/fr-fr/solutionaccelerators/cc835245.aspx

Bref, une mine d’or pour ceux qui travaillent sur des projet de certification et de conformité.

Et bien oui, Microsoft pouvait bel et bien aider mon RSSI imbus de lui même…

En pièce jointe de cet article, en bonus, je vous ai rajouté un document réalisé par McAfee sur la liste des événements à auditer au sein d’Active Directory dans le cadre d’un projet PCI-DSS. Néanmoins ce document peut s’utiliser dans d’autres projets de conformité ou même dans une démarche toute simple de sécurisation ou de réduction de la surface d’attaque Active Directory: wp-pci-guidance-microsoft-windows-logging

Pour rappel: https://www.microsoft.com/en-us/trustcenter/compliance/complianceofferings

Bonne recherche et bonne lecture !

RegTechLab délivre un panorama des startups qui comptent dans l’IAM

Le cabinet RegTechLab a réalisé une étude très intéressante, en identifiant 187 startups qui comptent dans le domaine de la gestion des Identités et des Accès sur la scène internationale.

Ils ont catégorisé ces 187 startups en 7 segments:

  • Gestion des attributs

  • Authentification/Autorisation

  • Identity Access Management (IAM)

  • Identité Digitale

  • Identité pour l’Internet des Objets
  • Solution de monitoring
  • Technology Providers

Honnêtement, je trouve la segmentation pas très bien choisie, mais bon, c’est une erreur de jeunesse.

Au final, c’est un travail assez minutieux, il faudrait maintenant que RegTechLab puisse réaliser une étude plus en profondeur de chaque segment, puis de chaque startup.

Vous retrouverez l’intégralité de l’article sur ce lien: https://www.regtechlab.io/the-identity-startup-landscape

 

Directory as a Service (DIRaaS) : Découverte de JumpCloud [4/4]

Directory as a Service (DIRaaS) : Découverte de JumpCloud [4/4]

Au travers de ce quatrième et dernier article, nous allons découvrir comment utiliser l’annuaire JumpCLoud comme un LDAP as a Service.

Activation et paramétrages de base du service « LDAP service »

Tout d’abord, il faut activer la fonction, pour ce, il faut se rendre dans la section SETTINGS et activer la fonction via le bouton ON/OFF :

Une fois que la fonction est activée, cela génère un « Organization ID », cet ID est utilisé pour identifier l’instance LDAP de l’organisation au niveau du service JumpCloud, une connexion vers cet ID sera renvoyé au niveau de la branche de notre organisation. En effet, chaque entité cliente de JumpCloud utilise le même annuaire LDAP mais avec des branches complètement indépendantes. Dans notre exemple, notre branche sera :

o=585322a6bc0b5b5c277062ee,dc=jumpcloud,dc=com

Il faut ensuite créer un compte LDAP qui servira de compte de service pour la connexion sur l’annuaire LDAP :

Et lui donner un mot de passe :

Bien sûr, il est possible d’activer la fonction « LDAP BINDING USER SERVICE ACCOUNT » pour n’importe lequel des utilisateurs, disons que dans notre exemple, nous considérons que la connexion doit être réalisée par un compte de service, comme le ferait une application cherchant des attributs dans le LDAP par exemple.

Test du service LDAP

Pour tester la connexion, nous allons utiliser une browser LDAP, il en existe de nombreux, mais nous utiliserons le freeware LDAP Browser 4.5 téléchargeable ici : http://www.ldapadministrator.com/download.htm

Il suffit d’installer le client LDAP sur une machine Windows et de lancer l’utilitaire puis de créer une nouvelle connexion :

La connexion doit avoir les caractéristiques suivantes :

Host (serveur LDAP) : ldap.jumpcloud.com

Port : 389

Base DN : ou=Users,o=585322a6bc0b5b5c277062ee,dc=jumpcloud,dc=com

Ici, 585322a6bc0b5b5c277062ee est notre organisation ID que l’on peut récupérer depuis la section SETTINGS de l’interface web de JumpCloud :

Il faut ensuite indiquer le compte de service avec lequel nous allons nous connecter sur l’annuaire LDAP et son mot de passe :

Dans notre exemple, le principal utilisé pour la connexion est:

uid=ldapservive,ou=Users,o=585322a6bc0b5b5c277062ee,dc=jumpcloud,dc=com

Nous avons ensuite accès à l’annuaire LDAP:

Avec par exemple, l’objet Sylvain Cortes :

Rajouter des groupes LDAP

Il est possible de rajouter des groupes LDAP dans l’annuaire en utilisant la fonction TAGS.

Définir un nom pour le TAG, qui sera aussi le nom du groupe LDAP et activer la fonction « Create LDAP groups for this tag » :

Puis rajouter des membres au groupe :

Il est alors possible de vérifier la présence du groupe et de ses membres depuis le browser LDAP :

Ce groupe LDAP pourra alors être utilisé depuis une application se basant sur des groupes LDAP pour fournir l’accès à certaines partie de l’application par exemple.

Les attributs utilisateurs : attention, rien à voir avec LDAP !

Dans l’interface de modification des comptes utilisateurs, il est possible de rajouter des attributs :

Attention, pour l’instant, ces attributs sont uniquement exploitables via l’API JumpCLoud et ne sont pas rajoutés dans le schéma LDAP. Il est prévu dans la roadmap de pouvoir rajouter des attributs LDAP et donc de rendre le schéma extensible, ce qui serait une fonction bien utile !

Voilà, cette série d’articles destinés à la découverte de l’offre JumpCloud est terminée. Je réaliserai vraisemblablement deux autres articles sur les fonctions avancées : les TAGS et la fonction de SSO via Fédération. En sachant que cette dernière fonction, pour moi, s’éloigne quelque peu de la fonction mise en avant qui est du DIRaaS et se rapproche plutôt des fonctions de IDaaS que l’on retrouve chez Microsoft, Okta et Centrify.

Si vous avez des questions sur le sujet ou si vous avez un projet allant dans ce sens, n’hésitez pas à me contacter par email ou via mon compte twitter : https://www.identitycosmos.com/sylvain-cortes_mvp

Directory as a Service (DIRaaS) : Découverte de JumpCloud [3/4]

Directory as a Service (DIRaaS) : Découverte de JumpCloud [3/4]

Dans la deuxième partie de cet article, nous avons évoqué l’intégration des systèmes Windows et Linux dans l’annuaire JumpCloud. Nous allons maintenant explorer une autre fonction intéressante de cet annuaire : la fonction Serveur RADIUS as a Service.

Paramétrage du service RADIUS

Dans une première étape, nous allons activer le RADIUS as a Service dans l’interface JumpCloud :

Il faut fournir un nom à notre service RADIUS, ici : jumpcloud_radius1

Il faut indiquer l’adresse IP publique du réseau qui va interagir avec le serveur RADIUS, il s’agit de l’adresse IP publique utilisée au niveau de votre routeur ou firewall pour la connexion à votre fournisseur de services Internet – vous pouvez traditionnellement trouver cette adresse IP dans l’interface de configuration de votre routeur/firewall.

Un « SHARED SECRET » est généré pour vous, mais vous pouvez tout à fait définir le vôtre, il est possible de visualiser le secret en cliquant sur le bouton représentant un œil afin de faire un copier/coller.

L’onglet TAGS permettrait d’associer des groupes d’utilisateurs avec ce serveur RADIUS afin de restreindre l’utilisation de ce service à des utilisateurs en particulier – ici nous ne paramétrons aucun TAGS, donc tous les utilisateurs de l’annuaire peuvent utiliser le service RADIUS.

Test du service RADIUS

Pour tester l’authentification sur le service RADIUS, il est possible de réaliser le test avec un client RADIUS de test. L’un de mes favoris est le client qui a été réalisé par la défunte société MasterSoft : NTRadPing test Utility. L’outil est encore téléchargeable sur le site de Novell, ici : http://www.novell.com/coolsolutions/tools/downloads/ntradping.zip

Dans l’interface, il suffira d’indiquer les informations suivantes :

Radius Server : 104.154.91.253 ou 104.196.54.120

Port Radius : 1812

Radius Secret Key : il faut ici copier/coller le « SHARED SECRET » que l’on a configuré dans l’étape précédente dans l’interface JumpCloud

Il faudra ensuite renseigner le login et mot de passe d’un utilisateur présent dans l’annuaire JumpCloud et qui a le droit d’utiliser le service Radius configuré.

Il ne reste plus qu’à appuyer sur le bouton « Send » pour tester la connexion et la réponse du serveur. Si la réponse est « response : Access-Accept » c’est que tout va bien et fonctionne correctement.

Si le mot de passe renseigné n’est pas correct, le message serait le suivant :

La plupart des articles pouvant guider sur le paramétrage du service Radius se trouvent sur ce lien : https://support.jumpcloud.com/customer/portal/topics/926833-radius-as-a-service/articles

Bien évidement l’usage classique d’un service Radius serait de permettre à des utilisateurs de s’authentifier auprès un point d’accès wifi avec leur login et mot de passe provenant de l’annuaire Cloud.

Directory as a Service (DIRaaS) : Découverte de JumpCloud [2/4]

Directory as a Service (DIRaaS) : Découverte de JumpCloud [2/4]

Dans la première partie de cet article, nous avons évoqué la prise en main de la solution ainsi que la création des comptes utilisateurs, nous allons maintenant explorer l’intégration des systèmes Windows et Linux dans l’annuaire JumpCloud.

Référencement de systèmes (OS) dans l’annuaire JumpCloud

Il est possible de renseigner des systèmes, c’est-à-dire des OS dans l’annuaire JumpCloud. JumpCloiud est compatibles avec des clients Windows, MacOS et Linux. Il faut alors installer un agent JumpCloud sur le système qui fera office de client pour l’annuaire, un peu comme un client Active Directory pour un système Windows ou un client Active Directory sur un système Linux ou MacOS grâce à la technologie Centrify.

Le client jumpCloud communique avec une session sur le port 443 avec l’annuaire JumpCloud, la communication depuis l’annuaire JumpCloud vers l’OS se fera via cette connection sécurisée, il n’y a donc pas besoin d’ouvrir de port entre l’extérieur et l’intérieur de l’entreprise car cette session sur port 443 est initiée depuis le client JumpCloud :

Vous trouverez ici la liste des systèmes supportés par le client JumpCloud : https://support.jumpcloud.com/customer/portal/articles/2390451-jumpcloud-agent-compatibility-and-system-impacts

Vous trouverez ici la liste des ports TCP/IP nécessaire pour la communication entre le client JumpCloud et l’annuaire JumpCloud : https://support.jumpcloud.com/customer/portal/articles/2390681

Pour rajouter un système depuis l’interface d’administration :

Référencement d’un système Windows

Choisir l’onglet Windows, télécharger le client JumpCloud :

Le lien de téléchargement direct est : https://s3.amazonaws.com/jumpcloud-windows-agent/production/JumpCloudInstaller.exe

Bien évidemment, nous prendrons ici comme exemple un PC sous Windows 10 qui est en Workgroup et qui n’est donc pas intégré dans un domaine. Nous explorerons au travers de prochains articles la liaison possible entre une infrastructure Active Directory existante et JumpCloud, mais dans tous les cas, il n’est pas possible d’installer l’agent JumpCloud sur une machine Windows liée à un domaine Active Directory (c’est-à-dire qui possède un compte machine dans un annuaire Active Directory).

Installation de l’agent :

Copier/Coller la clé disponible depuis l’interface web JumpCloud :

Réaliser un redémarrage du système après la fin de l’installation. Après le premier redémarrage, le système Windows apparait dans l’interface :

En cliquant sur le bouton détails, il est possible de visualiser les attributs principaux de la machine :

Par défaut, les utilisateurs présents dans l’annuaire sont vus dans l’interface mais ils n’ont pas le droit de se connecter sur le système, il faut donc sélectionner explicitement les utilisateurs que l’on autorise sur ce système en les sélectionnant et en cliquant sur le bouton « save system » :

Le système des TAGS nous permettrait d’automatiser cette sélection explicité, mais nous découvrirons cela dans un prochain article.

L’utilisateur provenant de l’annuaire JumpCloud est alors créé dans la base SAM locale de la machine :

Comme il a été décidé que cet utilisateur possède des droits d’administration sur les machines de l’annuaire JumpCloud, il est aussi rajouté automatiquement dans le groupe des Administrateurs locaux de la base SAM :

Le compte utilisateur créé possède les propriétés suivantes :

Il est maintenant possible de s’authentifier avec le compte utilisateur JumpCloud sur la machine Windows en utilisant le mot de passe du directory JumpCloud :

Un nouveau profil utilisateur est créé sur la machine lors de la première authentification :

Changement du mot de passe de l’utilisateur et impact sur le système Windows

Via l’interface en ligne, l’utilisateur final peut changer son mot de passe depuis son portail utilisateur :

L’administrateur peut lui aussi réinitialiser le mot de passe d’un utilisateur de l’annuaire :

Le nouveau mot de passe devra être conforme aux exigences liées à la politique de mot de passe définies dans le portail administrateur :

Le nouveau mot de passe sera alors automatiquement poussé sur le système lors de la prochaine connexion avec l’agent du système.

Référencement d’un système Linux

Ici les tests seront réalisés avec une CentOS 7.

Lors de la première étape, nous allons indiquer que pour un même utilisateur, nous souhaitons avoir le même UID sur les différents systèmes Linux sur-lesquels nous allons provisionner ce compte – de cette façon, quand un compte utilisateur sera provisionné sur des systèmes Linux différents, l’UID associé sera toujours le même. Voir cet article : https://support.jumpcloud.com/customer/en/portal/articles/2439908-manually-assigning-uid-gid-to-users

Pour cela il faut se rendre dans la partie SETTINGS :

Puis désigner l’UID et GID pour les utilisateurs qui vont se connecter sur les différents systèmes Linux :

Maintenant, tout est prêt pour rajouter un système Linux :

Sur le système Linux, passer en root (su) pour vérifier que vous êtes bien en root, taper la commande « id », l’id retourné doit être «zéro»:

Ouvrir un terminal sur le système Linux, puis Copier/Coller la commande qui se trouve dans l’interface JumpCloud dans la fenêtre de terminal sur le système Linux :

L’installation de l’agent se déroule, le système doit avoir accès à Internet pour télécharger le package de l’agent.

Il est possible de redémarrer le système Linux pour s’assurer que tout fonctionne bien au démarrage, mais le système doit apparaitre sur l’interface de JumpCloud sans redémarrage :

Ensuite, il faut rajouter l’utilisateur que l’on souhaite provisionner sur le système (sans passer par le système des TAGS que nous verrons dans un prochain article) :

Après un redémarrage de l’agent JumpCloud :

service jcagent stop

service jcagent start

Le nouvel utilisateur est créé avec le bon UID/GID dans le fichier /etc/passwd :

Après avoir ouvert une session sur le système avec le nouveau compte, il est possible de vérifier son ID :

Pour avoir un statut de l’agent depuis le système Linux :

service jcagent status

Pour des détails sur le fonctionnement de l’agent sous Linux, voir l’article suivant : https://jumpcloud.desk.com/customer/portal/articles/2399128

Dans notre prochain article, nous allons explorer les fonctions liées à RADIUS et l’annuaire JumpCloud.

Directory as a Service (DIRaaS) : Découverte de JumpCloud [1/4]

Directory as a Service (DIRaaS) : Découverte de JumpCloud [1/4]

Les différents fournisseurs de services d’identités hébergés dans le cloud se sont concentrés soit sur les fonctions de Identity as a Servive (IDaaS) ou de Cloud Access Security Broker (CASB), mais très peu ont tenté de proposer une véritable offre d’annuaire (DIRaaS) sous forme de SaaS.

Les seuls qui ont tenté la chose sont pour moi Microsoft (avec l’offre Azure Directory Services, nécessitant Azure Active Directory comme back-end), Amazon (AWS Directory Service, mais avec de nombreuses limitations techniques) et la société JumpCloud.

L’approche de JumpCloud est tout à fait innovante, car ils se positionnent comme des « pure player » fournisseur de DIRaaS et non pas comme fournisseur de IDaaS (bon, dans les faits, ils n’ont pas pu s’empêcher de mettre une brique de SSO basée sur SAML…). En effet l’idée est ici de fournir un « véritable » annuaire, dans le cloud qui est compatible par exemple avec LDAP ou RADIUS et demain pourquoi pas avec Kerberos.

L’idée de JumpCloud est donc de fournir un annuaire sous la forme d’un service. La difficulté de cet exercice réside dans le fait que les annuaires modernes ne sont pas simplement des annuaires LDAP – si l’on prend Active Directory par exemple, l’intégration avec Kerberos, la gestion des certificats ou dans une moindre mesure le lien Radius sont tout à fait remarquables. De plus, les annuaires modernes doivent pouvoir servir d’IdP pour les applications désirant consommer un service de fédération pour l’authentification des utilisateurs.

L’exercice de style n’est donc pas simple pour JumpCloud, voyons donc comment ils s’en sortent dans une série de quatre articles traitant de la découverte de cette offre en ligne. Si j’ai des retours positifs, j’aborderais ensuite dans une courte série de deux articles les fonctions avancées.

Pour se créer un compte d’évaluation, il faut se rendre sur cette page : https://jumpcloud.com/signup – une fois le formulaire rempli et le traditionnel lien de confirmation par email cliqué, le compte d’administration est prêt et l’on peut se connecter sur l’interface de gestion.

JumpCloud laisse à disposition une liste de « QuickStart Guide » pour bien prendre les choses en main – la liste de ces guides est accessible ici : https://support.jumpcloud.com/customer/portal/topics/947955-getting-started/articles

Le premier login administrateur sur le service JumpCloud

Voici le lien pour se connecter sur l’interface de gestion : https://console.jumpcloud.com/login

Il faut bien comprendre qu’il y a deux parties dans la mire de login, la partie « user » à gauche et la partie « administrator » à droite, il faut faire le bon choix car l’interface qui sera proposée derrière est différente en fonction de ce choix :

Une fois connecté à l’interface d’administration, un menu apparait sur la gauche permettant de sélectionner la zone d’administration, la partie de droite changera en fonction de ce choix.

  • USERS : Gestion des comptes utilisateurs, qu’ils soient créés directement dans l’annuaire manuellement ou qu’ils proviennent d’une synchronisation (depuis Active Directory par exemple)
  • SYSTEMS : Gestion des OS qui seront connectés à l’annuaire (Windows, Linux et MacOS) et qui pourront recevoir des règles de gestion depuis l’annuaire JumpCloud
  • TAGS : La gestion des TAGs permet de multiples choses, mais notamment l’association d’utilisateurs à des ressources ou à des objets (groupes)
  • APPLICATIONS : C’est la partie SSO vers des applications compatibles avec SAML (fédération d’identité)
  • COMMAND : Permet de programmer l’exécution de commandes sur les systèmes (OS) gérés dans l’annuaire
  • RADIUS : Utilisation d’un service serveur RADIUS as a Service

Création du premier utilisateur dans l’annuaire JumpCloud

La première connexion à l’interface d’administration permet de créer immédiatement des utilisateurs depuis la section USERS :

Ici nous allons choisir de créer un utilisateur qui aura des droits d’administration, il sera donc « Global Administrator », il pourra invoquer sudo sur les systèmes Linux et mais devra s’authentifier. De plus, l’utilisateur aura le droit de faire un Bind LDAP et de réaliser des recherches sur l’annuaire via LDAP. Enfin, nous lui définissons son mot de passe.

Un point important, ici, « Global Administrator » ne signifie pas que ce compte a des droits d’administration sur le service JumpCLoud en tant que tel, mais uniquement qu’il a des droits avancés sur les systèmes sur lesquels il pourra s’authentifier.

Après avoir cliqué sur le bouton « save user », nous avons notre premier utilisateur dans l’annuaire JumpCloud :

Quand on regarde les détails de sa fiche utilisateur, il est possible de constater que l’utilisateur à bien un « LDAP DISTINGUISHED NAME »:

Il est tout à fait possible de modifier ses attributs existants, par exemple son email :

Premier login utilisateur

Si maintenant on utilise cet utilisateur pour se connecter à l’annuaire JumpCloud en précisant qu’il s’agit d’un login utilisateur via l’URL suivante : https://console.jumpcloud.com/login

Nous constatons que l’utilisateur peut de lui-même éditer un certain nombre d’attributs ou de champs dans l’annuaire (attributs qui lui sont liés bien sur) :

Et qu’il a accès à des applications, la possibilité de rajouter des clés ainsi que la possibilité d’activer le MFA via Google Authenticator :

Distinction entre les comptes utilisateurs et les comptes administrateurs JumpCLoud

Attention, il faut bien comprendre qu’il y a trois types de comptes :

Type de compte Stockage Etendue d’administration
Administrateurs de l’instance JumpCloud Dans une base des administrateurs séparées de la base de l’annuaire en tant que tel Administrators

Administrators with Billing

Command runner

Command runner with Billing

Utilisateurs de l’entreprise Dans l’annuaire JumpCloud Aucune
Utilisateurs de l’entreprise avec des droits d’administration sur les systèmes Dans l’annuaire JumpCloud Certaines droits d’administration sur les systèmes eux-même

Base de comptes des Administrateurs JumpCloud:

La base de comptes des utilisateurs dans l’annuaire JumpCloud (représente les utilisateurs « end users » de l’entreprise :

Il est donc tout à fait possible d’avoir deux comptes avec le même login, un qui est administrateur JumpCloud et l’autre qui représente l’utilisateur au sens « end-user » avec deux mots de passe différents, lors de l’authentification en ligne, il faudra choisir sur quelle base de comptes (users ou administrators) se connecter :

Voilà ce premier article nous a permis de prendre en main la solution JumpCloud et de comprendre les bases de comptes utilisées. Dans le prochain article nous explorerons l’intégration des OS Windows et Linux au sein de cet annuaire.

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: