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 [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.

Microsoft Identity Manager 2016 SP1 – MIM 2016 SP1

mim2016_features

 

Microsoft vient d’annoncer la mise à disposition du SP1 pour MIM 2016.

Outre des correctifs de “problèmes” inhérents à la notion de service pack, le SP1 de MIM complète la solution de gestion des identités de Microsoft avec les éléments suivants:

  • Support de Windows 2016 Server, SharePoint 2016 et SQL Server 2016 (ce n’est pas encore mis à jour dans la page de support de configuration accessible ici https://docs.microsoft.com/en-us/microsoft-identity-manager/plan-design/microsoft-identity-manager-2016-supported-platforms mais c’est bien le cas pourtant)
  • Compatibilité étendue à d’autres navigateurs web pour le portail MIM 2016: Edge, Chrome, Safari et Firefox sont maintenant rajoutés à la liste de compatibilité officielle qui contenait uniquement Internet Explorer (ok, oui ca marchait, mais c’est une question de support officiel, maintenant les tests ont été réalisés chez Microsoft)
  • Le service de notification et de workflow de MIM 2016 supporte maintenant Office 365 et plus seulement Exchange Server (ok, je sais on pouvait bricolé un serveur SMTP local pour contourner certaines limitations, mais maintenant on peut directement utiliser Office 365)
  • La fonction PAM (gestion des privilèges sous la forme d’une forêt dédiée à un bastion) supporte maintenant Windows Server 2016 et le niveau fonctionnel de forêt Windows 2016
  • Fourniture de script pour automatiser le déploiement de MIM 2016 PAM dans une forêt bastion – A tester, pour vérifier jusqu’où il est possible d’aller en terme d’automatisation

Le CD de MIM 2016 SP1 est disponible en download depuis MSDN, il n’y a pas pour l’instant la possibilité de télécharger uniquement le SP1, mais cela va venir, c’est encore frais.

 

 

Directory as a Service, c’est parti !

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

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

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

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

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

Faire des tests !

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

En bref.

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

CADIM: Communauté Active Directory et Identity Management – www.cadim.org

Logo

Je suis très heureux d’annoncer une très belle initiative pour la nouvelle année 2014 !

La communauté CADIM (Communauté Active Directory et Identity Management) vient de lancer sa nouvelle plateforme web communautaire: www.cadim.org

Cette communauté regroupe les professionnels et utilisateurs francophones d’Active Directory, de WA AD et des technologies de gestion des identités de façon plus globale [ description de la cadim ]

La communauté est ouverte à toutes et tous, n’hésitez à vous inscrire et à vous abonnez aux news ou même à participer en tant qu’auteur !

389 Directory Server 1.3.1.10

389Directoryserver

 

Le projet Fedora vient de mettre en ligne la version 1.3.1.10 de 389 Directory Server. Cette nouvelle version est téléchargeable [ ici ] – vous y trouverez aussi les notes d’information sur les nouveautés.

Pour moi, le plus “gros bug” corrigé est celui-ci: ” Ticket #47492 – PassSync removes User must change password flag on the Windows side  “

En effet, lors de la synchronisation vers Active Directory (module encore largement perfectible !) , un bug éliminait le besoin pour un utilisateur de changer son mot de passe au niveau d’Active Directory, plutôt ennuyeux…

Globalement, je suis assez déçu par ce produit, plein de promesses au départ, les trop nombreux bugs au niveau des modules de synchronisation ont eut raison de ma patience… FIM est peut être payant, mais cela fonctionne et il y a du support…

 

Active Directory dans le nuage, est ce bien raisonnable ?

Le service d’authentification rattaché à l’offre de Cloud Public de Microsoft, dont Office365, vient de changer de nom: il s’appelle dorénavant Windows Azure Active Directory (WAAD), et oui, carrément !

Attention, pas de confusion, pour l’instant il s’agit toujours d’un annuaire différent de l’annuaire “On premise” – En clair, il faut implémenter le service de synchronisation fournit par Microsoft afin de faire du push des comptes Utilisateurs et Groupes depuis l’Active Directory On Premise vers “l’annuaire” WAAD dans le nuage de Microsoft, et les fonctions ne sont pas les même.

Vous trouvez cela nuageux ? vous n’avez encore rien vu !

pour le push des objets, vous utiliserez le composant DirSync V2, qui est en fait un packaging spécifique du moteur de synchronisation d’ILM (oui, j’ai bien dit ILM, pas FIM, donc 32bits only) réalisé par l’équipe Cloud de Microsoft US. Cette synchronisation vous permettra alors de provisionner “automatiquement” une partie de vos objets dans l’annuaire en ligne utilisé par vos applications hébergées sur le service en ligne de Microsoft (ah, oui, j’oubliai, on ne dit plus ASP ou service en ligne, on dit Cloud…)

Pour un certain nombre de raisons techniques, cette synchronisation est actuellement obligatoire pour faire ensuite de la fédération d’identité et donc du SSO basé sur un scénario de fédération entre l’annuaire Active Directory local et le service d’annuaire dans le “cloud” de Microsoft.

Depuis quelques mois, une nouvelle brique à fait son apparition, il s’agit de ACS 2.0, pour être tout à fait honnête, je n’ai pas encore totalement intégré les subtilités fonctionnelles additionnelles de ce composant (d’ailleurs si certains veulent laisser des commentaires sur ce post…) à part le fait que je devrais être en théorie capable de fédérer des fournisseurs des services tel que Google ou Facebook, ce que je n’ai pas réussi à faire… et on ne peut pas dire que la documentation sur ce sujet me brule les yeux…

Bref, cela avance à petit pas, mais cela avance.

Le changement de nom du service d’authentification en Windows Azure Active Directory semble vouloir démontrer un futur “véritable” Active Directory dans le cloud de Microsoft. Pourquoi ne pas imaginer avoir des contrôleurs de domaine répliquant directement les informations “On premise” vers le cloud de Microsoft, au delà de la Fédération qui reste compliqué à implémenter pour beaucoup d’entreprises; pourquoi ne pas imaginer une abolition des frontières classique en terme de couverture d’annuaire ?

Pourquoi ne pas l’imaginer, oui, mais… est ce souhaitable ? c’est là pour moi la vraie question… j’avoue être assez émerveillé (ou horrifié, cela dépend…) par le peu de précaution que prennent les organisations avec ce type de sujet. Je vous laisse seul juge, mais voulez vous vraiment mettre votre Active Directory dans le nuage ???

Présentation FIM 2010 des Techdays 2011

fred_esnouf Frédéric Esnouf, Tech Specialist IAM chez Microsoft France a réussi la performance de présenter FIM 2010 en 1 heure condensée. Si vous vous posez des questions sur FIM 2010 et sur les scénarios d’utilisation, je vous invite a regarder ce webcast enregistré directement pendant les Techdays 2011.


Get Microsoft Silverlight


A regarder et à diffuser sans limitation 😉