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:

 

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.

Azure AD Application Gallery

Azure AD Application Gallery
Azure AD Application Gallery

Comme vous le savez déjà si vous travaillez avec les concepts de fédération d’identité et d’IDentity as a Service (IDaaS), notamment via Azure AD Premium, il est parfois difficile de connaître la liste des applications supportées ainsi que le mode de fédération ou de SSO que ces applications SaaS acceptent. Microsoft publie un site web « Azure AD Application Gallery » permettant de consulter la liste des applications supportées et de déterminer quel type de SSO elles sont capables de « comprendre ».

Pour faire simple, il existe 4 types d’applications SaaS selon la terminologie utilisée par Microsoft – notons toutefois, que les protocoles acceptés par l’application ne dépendent pas directement de Microsoft mais de l’application elle même, il y a toutes les chances pour que les « capacités » de l’application en termes de SSO ou de Fédération soient exactement les même quelques soit la solution d’IDaaS employée:

# Application de type « federated SSO only »: ces applications supportent la fédération et le SSO via la fédération de façon basique, généralement elles requièrent de mettre en œuvre un système de provisioning des comptes coté applicatif,  rappelez vous que la fédération d’identité ne vous élimine pas le fait de devoir créer les comptes côté applicatif de façon à lister les personnes acceptées et pouvoir définir le profiling applicatif (en gros qui a droit à quoi dans l’application)

# Application de type « federated SSO and provisioning »: ces applications supportent la fédération et le SSO via la fédération, et permettent aussi de gérer le provisioning des comptes via la solution d’IDaaS elle-même. Ici, on définie des règles, et la création des comptes, voir l’appartenance aux bons groupes côté applicatif, se fait via la solution IDaaS, plus besoin de penser un système de provisioning en parallèle.

# Application de type « federated SSO and consent »: ces applications supportent la fédération et le SSO via la fédération, et supportent la fonction « consent » – pour faire simple, cela permet à un utilisateur lorsqu’il utilise la passerelle de fédération d’accepter que ces identités soient utilisées et passées à l’applications SaaS pour valider son identité. Ce mécanisme est assez peu utilisé, permet sous certaines législation de demander la permission à l’utilisateur de transmettre son identité à l’application demandée. Qq explications sur le « consent » dans cet article: https://identitynetworks.wordpress.com/2009/03/09/ready-able-and-willing-federated-consent/

# Application de type « password SSO only »: ces applications ne supportent pas la fédération, et ne sont capable de faire du SSO que sur la transmission d’un couple username+password. Il y a un effet de bord principal à ce type d’authentification, c’est lorsque l’on veut utiliser le service d’IDaaS depuis un périphérique de type smartphone ou tablette, mais ceci est un autre débat, je ferais un article prochainement sur ce sujet. Ici, il faudra alors mémoriser le couple username+password ou éventuellement se baser sur l’authentification AD, mais il faudra alors aligner ce couple avec le compte dans l’application SaaS.

Sur l’interface « Azure AD Application Gallery », il suffit de choisir le type d’applications que l’on veut lister, et le site vous propose la liste des applications supportées par Azure AD Premium dans ce cadre. Par exemple:

consent_federation_applications