Comment gérer l’authentification sur Samba ou des NAS depuis un annuaire LDAP Cloud

 Une très bonne vidéo et article expliquant comment gérer les authentifications sur Samba ou plus généralement sur un NAS (Synology ou QNAP par exemple) depuis un annuaire LDAP hébergé dans le Cloud public. En effet, l’accès aux fichiers on-prem pour les utilisateurs restent un des problèmes majeurs pour la migration vers des architectures DIRaaS ou LDAP Cloud.

La vidéo:

Le lien vers l’article: [ ICI ]

Active Directory : rajouter une fonction de création de containeur (container) dans l’interface graphique de la MMC

De base, lorsque l’on veut créer une arborescence depuis le snap-in « Utilisateur et ordinateurs Active Directory », il n’est possible que de créer des Unités d’Organisation (Organization Unit) :

Or, dans certains cas, il est souhaitable de pouvoir créer un objet de type containeur (container), notamment s’il n’est pas nécessaire d’avoir d’application de GPOs sur les objets contenus dans ce répertoire ou pour stocker des objets de types SCP par exemple.

Bien entendu, il est possible de passer par PowerShell pour créer un objet containeur, mais il est également possible d’activer une fonction graphique directement dans les consoles MMC.

Pour la manipulation, il faut utiliser un compte qui appartient au groupe « schema admins » – ouvrir ADSIEDIT et se connecter sur la partition du schéma : Lire la suite

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 ». Lire la suite

Conférence LDAP à Bruxelles les 19 et 20 Octobre 2017

Une conférence exceptionnelle aura lieu à Bruxelles les 19 et 20 Octobre prochains. Il s’agit d’une conférence dédiée à LDAP, et je dirais même à Open LDAP et tous ses dérivés. Le panel de speakers est très impressionnant et le programme me semble de qualité.

Les anciennes conférences étant de qualité, il n’y a pas de raison que cela change cette année 😉

Pour vous inscrire, c’est [ ICI ]

Fournir un véritable service d’annuaire pour les organisations utilisant Google G Suite

La solution de Google, Google G-Suite est une solution très utilisée aux USA, notamment pour son coût extrêmement faible à destination des petites organisations par rapport à la concurrence. Ensuite, c’est une affaire de goût et d’habitude, personnellement, j’ai toujours eu des “difficultés” avec les interfaces proposées par Google, mais c’est un autre débat !

Un des problèmes majeurs que rencontrent les clients Google G-Suite provient du manque de fonctionnalités autour de la gestion des identités, en effet, Google ne propose pas un véritable service d’annuaire en mode SaaS, on sent bien que les fonctions sont uniquement là pour supporter l’usage de G-Suite et point. Il est donc très compliqué pour une organisation de se passer d’un Active Directory local, et généralement les organisations synchronisent leurs informations provenant de l’annuaire Active Directory vers le Google Directory via les outils Google Cloud Directory Sync et G Suite Password Sync. Cette approche ne convient pas aux organisations désirant justement éliminer l’usage d’Active Directory et s’affranchir des frais de gestion et d’administration des serveurs locaux.

Spécialement conçu pour les organisation ayant besoin de beaucoup d’agilité au niveau de la gestion de leur annuaire, JumpCloud propose via un partenariat avec Google de fournir un véritable service d’annuaire pour les client Google G-Suite et propose donc la brique manquante aux clients Google. Lire la suite

Une nouvelle vidéo expliquant les protocoles utilisables dans le Cloud dans un contexte DIRaaS

JumpCloud vient de mettre en ligne une vidéo très intéressante exposant les différents services et fonction que doit proposer un annuaire Cloud de type DIRaaS, en listant les différents protocoles utiles dans ce type de mécanismes.

L’idée est de bien comprendre comment migrer l’ensemble des services ou interactions de services habituellement portés par un annuaire local (LDAP, Radius, etc…) vers un annuaire de type Cloud et d’assimiler la liste des protocoles utiliser.

A la vue de cette vidéo, on se rend bien compte de la puissance du système, obtenir l’ensemble des services habituelles d’un Active Directory ou d’un OpenLDAP sous forme de service SaaS.

Okta rachète Stormpath

La nouvelle est tombée hier, la société Okta a réalisé l’acquisition de la société Stormpath. Pour ceux qui ne connaissent pas Strompath, la société propose une solution d’AUTHentification as a Service à destination des développeurs Web.

Attention, on ne parle pas ici d’une solution complète IDaaS comme  le propose déjà Microsoft, Centrify ou Okta, mais d’une brique à destination des développeurs permettant d’intégrer dans des services ou des applications web n’importe quel type d’authentification directement au niveau du code de l’application. Typiquement la solution Stormpath ne propose pas son propre annuaire Cloud (du moins pas du même niveau fonctionnel que Microsoft/Centrify/Okta) mais va permettre d’utiliser de nombreuses sources d’authentification différentes en intégrant au passage des mécanismes d’authentification forte ou de SSO:

Je m’étais intéressé à cette société quand elle avait fournie une Gateway permettant d’utiliser directement dans les applications SaaS un modèle d’authentification basé sur Active Directory ou LDAP:

Un modèle technique extrêmement intéressant axé sur les développeurs mais vraisemblablement un modèle trop réducteur pour résister aux points lourds de l’IDaaS qui commencent à proposer ce type d’API en standard dans leurs propres solutions. Voir par exemple chez Centrify:

Centrify Cloud API Guide: http://developer.centrify.com/site/global/documentation/api_guide/index.gsp
Centrify Cloud API Reference: http://developer.centrify.com/site/global/documentation/api_reference/index.gsp

Reste à savoir la raison de ce rachat de la part d’Okta. Pour moi la raison majeure n’est pas au niveau des APIs d’intégration (Okta a commencé à travailler sur ses propres APIs depuis quelques mois) mais au niveau de la technologie de gateway avec les éléments on-premises tels qu’un annuaire LDAP, Active Directory ou même un ADFS. En effet, sur cette brique majeure pour une entreprise d’une certaine taille, Okta était bien mal équipé… voulant imposer une vision à l’Américaine basée sur une approche pure Cloud Public à ses clients.

A noter, que la plupart des analystes ne sont pas d’accord avec moi et mettent en avant la partie API – voir par exemple: https://techcrunch.com/2017/03/06/okta-stormpath/ – ceci est normal puisque Stormpath est majoritairement connu pour cela… Mais pour moi ce n’est pas la raison principale, à moins que les équipes interne d’Okta aient vraiment fait du mauvais travail depuis quelques mois..

Il sera intéressant de suivre et comprendre comment les technologies Stormpath vont être intégrées à l’environnement Okta… Quelles briques technologiques vont être abandonnées… A suivre…

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

Ubuntu: Mise à jour de la documentation intégration Kerberos/LDAP

ubuntu_kerberos_ldap

Comme vous le savez certainement, il est possible d’utiliser un annuaire LDAP comme conteneur des utilisateurs utilisés dans un royaume Kerberos. Sous Active Directory, cette “association” se fait naturellement, Active Directory proposant cette fonction de native et transparente pour les administrateurs.

Dans le monde Linux/Unix, cela est très différent, il faut expressément paramétrer le royaume Kerberos pour que celui-ci utilise un back-end LDAP pour stocker les informations utilisateurs, ensuite, en terme de protocole, on est sur du connu, Kerberos pour la partie authentification, LDAP pour la partie autorisations.

Franchement, quand on a compris le concept, ce n’est pas très compliqué, je dois avoué que l’avantage sur Unix/Linux, est une plus grande séparation des fonctions, donc une meilleure compréhension globale de l’architecture: Comme les choses ne sont pas faite automatiquement, et bien du coup, on comprend précisément les différences entre Kerberos et LDAP, cela rend vraisemblablement les choses plus simple à conceptualiser pour les débutants même si bien sur cela occasionne un paramétrage supplémentaire non nécessaire sous Active Directory.

Les concepts sont identiques sur l’ensemble des plateformes Linux mais chaque distribution a bien sur ses petites particularités. Ubuntu a mis jour dernièrement la documentation présentant cette intégration: dans ce scénario, les comptes utilisateurs sont donc créés dans LDAP, si la réplication LDAP est paramétrée, on a donc “l’équivalent” d’une réplication multi-maitres comme des contrôleurs de domaine Active Directory (enfin presque…) et un royaume Kerberos qui peut s’appuyer sur l’annuaire LDAP au lieu de s’appuyer sur une base de données Berkeley (ce qui est la configuration native d’un royaume Kerberos) pour stocker les objets utilisateurs.

La documentation pour Ubuntu, en Français est accessible [ ICI ]

Pour une référence plus générique et globale, vous pouvez aussi consulter la documentation MIT Kerberos [ ICI ]