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

Active Directory Replication Status Tool: Back to the Future !

A l’heure d’AWS, d’Azure AD, de l’IDaaS & autre joyeuseté « Cloudifiante », il est totalement incongru de voir à quel point l’IT interne des entreprises est pauvrement géré, c’est même terrifiant… Surtout quand nous parlons d’Active Directory !

Je viens de finir une mission chez un grand compte (bien sur je garderais pour moi le nom du coupable par charité intellectuelle et conscience professionnelle…) sur la gouvernance et la sécurisation de leur annuaire Active Directory: et oui ! je fais encore de l’Active Directory ! J’en fais même encore beaucoup, mais disons que je sélectionne les missions.

Le pauvre responsable Active Directory n’en peut plus, je dois dire qu’il a fort à faire… vous vous voyez jongler avec 3 parpaings en équilibre sur un château de cartes avec un bandeau sur les yeux ? vous voyez l’idée ? c’est son pain quotidien… Je ne suis pas sur que la direction générale est bien conscience du danger, mais bon c’est un autre problème, moi perso, j’ai présenté mes recommandations au CTO, il en fera bien ce qu’il veut.

Pendant cette mission, il a fallut comprendre pourquoi la réplication AD ne fonctionnait pas, ou peu… Alors oui, on peut faire du « repadmin /showrepl * /csv > replsd.csv » à tour de bras et s’amuser avec Excel pour filtrer tout cela; oui, il y a plein de moyens de superviser la chose; oui. Mais le pauvre responsable Active Directory voulait juste un tool tout simple qui le sauve de la bankrupt les soirs de pleine lune…

C’est alors que je me suis rappelé d’un tool Microsoft, et il se trouve que ce software a été mis à jour il y a quelques mois: Active Directory Replication Status Tool (ADREPLSTATUS) – téléchargeable [ ICI ]

Il s’agit d’un outil vraiment sympa, avec une interface graphique remaniée qui permet d’analyser de façon très précise les réplications AD – les options de filtre sont vraiment très nombreuses et les résultats exportables dans un fichier CSV (pour les fans d’Excel 😉

La barre de menu est très claire:

Les options permettent de lancer un scan ciblé:

et de visualiser très simplement les résultats afin de permettre un diagnostic:

Bref, un outil vraiment sympa, mis à jour pour Windows Server 2016, et bien sur, plus le modèle de réplication est complexe, plus il est utile !

Bons tests de votre côté !

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.

Azure Information Protection: ce n’est pas encore très clair pour tout le monde !

En début de semaine, j’ai longuement échangé avec un client à propos des solution de chiffrement de documents disponibles sur le marché. Il m’est apparu que les choses étaient très confuses dans son esprit (désolé Olivier 😉 ).

Il y a beaucoup de confusion entre les différentes possibilités offertes par les multiples fournisseurs qui se sont positionnés sur ce marché. Bien évidemment, l’utilisation de plus en plus massive des solutions Cloud, que ce soit au niveau de l’email, des intranets ou du stockage de documents rend cette approche quasi obligatoire, car la sécurité périmétrique ne sert plus à rien en terme de protection de la donnée ou de protection de la propriété intellectuelle.

Dans l’ancien monde, le monde « on-premises », Microsoft fournissait déjà une solution nommée « Active Directory RMS », permettant de protéger (chiffrer) les documents Office et les emails Outlook produits par l’entreprise. Cette solution était assez efficace techniquement mais rendait les échanges inter-entreprises (avec un partenaire commercial par exemple) assez complexes à réaliser.

L’arrivée de Azure Information Protection (ex Azure RMS) a ouvert de nouveaux horizons en termes de protection des données et de l’information, mais il s’avère que nombre de clients ne comprennent pas bien certains aspects. L’objectif de ce post est de rapidement fournir quelques pistes afin de mieux comprendre les aspects AIP côté client (=device).

Petit rappel, la fonction AIP peut s’acquérir via les plans EMS 3 & 5 de Microsoft:

Le plan EMS E3 propose globalement (je fais simple…) les fonctions qui étaient anciennement portées par Azure RMS, à savoir la technologie de chiffrement elle-même – le plan EMS E5 rajoute globalement (je fais simple à nouveau…) les fonctions de classification – Ici, le challenge de Microsoft sera de lier au maximum ces deux technologies, permettant à l’utilisateur de choisir une classification, qui protégera automatiquement (en fonction de cette classification) les documents ou emails.

Rappelons également que la technologies AIP/RMS permet de protéger du contenu produit dans des technologies Microsoft (docx, pptx, email, etc.) mais aussi de protéger des documents qui ne sont pas produits avec des outils Microsoft (txt, PDF ou Autocad par exemple). Ce lien très utile décrit les différents formats pris en compte par AIP, que ce soit au niveau du module de protection ou au niveau du module de classification.

Lorsque d’un destinataire va recevoir un contenu protégé par AIP, il devra utiliser un « client » AIP/RMS lui permettant de faire le lien entre une authentification (=son identité) et l’application des règles d’accès au contenu décidées par le créateur du contenu (accès en lecture, en écriture, possibilité de copier/coller ou pas, etc.).

La technologie AIP/RMS nécessite donc un « client » côté device afin de déchiffrer un contenu. A ce niveau il y a globalement deux cas possibles pour déchiffrer et accéder au contenu selon les règles d’accès décidées par l’auteur du contenu:

Ce lien décrit les différentes possibilités en croisant les différents formats de fichiers avec la plateforme du device (=son OS) – ici par exemple, les différents clients AIP/RMS utilisables sur sur plateforme Windows en fonction des formats de fichiers:

De plus, vous retrouverez sur ce lien, la possibilité de télécharger Microsoft Azure Information Protection Viewer ( AZInfoProtectionViewer.exe ) pour Windows qui permettra a un client de consommer (=ouvrir) un contenu protégé par AIP/RMS même si il ne possède pas lui même une application intégrant un client AIP/RMS natif:

En conclusion, il faut bien assimiler plusieurs éléments:

  • AIP permet de protéger du contenu « Microsoft » mais aussi des documents hors format Microsoft (PDF, txt, etc.)
  • AIP fonctionne sur Windows, Mac, Android & iOS (avec quelque différences subtiles entre ces différents OS) – à noter aucun fournisseur tiers ne s’est lancé dans une aventure AIP sur Blackberry, mais il exite des possibilité pour supporter des clients AD RMS sur Blackberry
  • AIP intègre des fonctions de chiffrement & classification mais aussi d’autres fonctions extrêmement intéressantes comme le tracking des documents protégés par exemple
  • AIP permet d’échanger assez simplement du contenu protégé avec des personnes en dehors de l’organisation (au contraire de AD RMS)
  • La personne qui consomme le contenu, c’est à dire la personne qui accède au document/email protégé n’a pas besoin de licence AIP ni besoin d’avoir une application native AIP/RMS, elle peut télécharger le client AIP Viewer pour accéder au contenu protégé

Enfin, cette technologie évolue très très rapidement côté Microsoft, en effet, il s’agit d’une technologie clé pour permettre l’adoption des solutions Cloud tout en protégeant l’accès à l’information de l’organisation.

Si vous avez des questions ou des besoins sur AIP, n’hésitez pas à me contacter. J’ai créé dernièrement un nouveau Workshop d’une demi-journée ou une journée dédié à AIP et qui permet de comprendre comment fonctionne cette technologie et les différentes possibilités offertes pour une organisation.

Annonce de la fusion des portails d’administration pour les fonctions AIP (Azure RMS & Labeling)

Une annonce majeure de la part de Microsoft, attendue depuis longtemps !

Microsoft va proposer une interface de gestion commune des fonctions de protections (ex Azure RMS) et des fonctions de Labeling (ex Secure Island) ainsi qu’un client unifié pour les postes et périphériques mobiles.

Bien sur, cette nouvelle interface de gestion sera disponible depuis la version V2 du portail d’administration Azure: https://portal.azure.com

La stratégie est maintenant de considérer la protection comme une option de la fonction de classification. Je milite pour cette approche depuis longtemps, car c’est la seule possible d’un point de vue structurel & organisationnel – il faut comprendre que la protection RMS n’a pas de sens sans la fonction de classification, car l’utilisateur créateur de contenu est le seul chaînon capable de « définir » la protection via le choix d’une classification (classification au sens large du terme).

Les fonctions de classification et de protection des données non structurées sont absolument essentielles dans le cadre de l’adoption des technologies de Cloud Public. Il s’agit donc de se préparer au déploiement de ce type de fonction, c’est absolument essentiel.

Plus d’information sur le blog EMS: https://blogs.technet.microsoft.com/enterprisemobility/2017/04/26/azure-information-protection-unified-administration-now-in-preview/

Et sur ce lien: https://aka.ms/DanPlastina

 

Le National Institute of Standards and Technology (NIST) met à jour ses recommandations sur « Digital Identity Guidelines »

Le National Institute of Standards and Technology (NIST) est un institut américain délivrant régulièrement des documents de spécifications et des recommandations à l’attention de l’ensemble des autres organisations gouvernementales américaines. Même si les documents publiés ne sont pas exclusivement orientés sur les aspects sécurité (comme par l’exemple l’ANSSI en France) de nombreuses recommandations traitent de ces sujets, et de nombreux documents sont publiés pour aider les organismes américains à l’implémentation de solutions fiables et standardisées.

Le NIST a récemment publié un brouillon (Draft) de trois documents importants traitant de Digital Identity:

Document SP 800-63A: Digital Identity Guidelines – Enrollment and Identity Proofing Requirements

 

 

Document SP 800-63B: Digital Identity Guidelines – Authentication and Lifecycle Management

 

 

Document SP 800-63C: Digital Identity Guidelines – Federation and Assertions

 

 

Ces trois documents, même à l’état de brouillon, sont une véritable mine d’or (et je pèse mes mots…) pour toute personne travaillant dans la sécurité informatique et dans le domaine de la gestion des identités. Le premier document donne par exemple les grandes lignes en ce qui concerne la gestion des identités de façon globale, le deuxième réalise un focus sur les méthodologies d’authentification et fournit des conseils sur les règles de sécurité liées aux mots de passe alors que le troisième traite particulièrement des technologies de Fédération d’Identité.

Ce que j’apprécie particulièrement dans ces documents, c’est qu’ils ne sont pas uniquement un recueil bête et méchant de bonnes pratiques mais liste de façon exhaustives les technologies associées et les standards du moment – par exemple le document traitant de la fédération d’identité ne se contente pas de recenser les bonnes pratiques à suivre autour de la fédération mais liste l’intégralité des termes à connaître et à utiliser – le grand intérêt est que du coup on peut choisir de considérer le document du NIST comme document de référence sur les termes à employer, et dans un monde aussi confus que la Fédération d’Identité par exemple, cela ne fait pas de mal de s’appuyer sur un lexique de référence…

Bref, c’est un peu long, mais c’est à lire absolument…

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

 

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

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

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

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

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

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

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

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

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

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

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

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

Quel avenir pour ce partenariat ?

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

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

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

40 minutes pour tout comprendre de Microsoft EMS

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

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

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

La vidéo est accessible ici:

 

 

Activer une fonction MFA telle que Google Authenticator sur un système Linux ou MacOS

 

L’authentification forte à deux facteurs (MFA) est une solution commune pour sécuriser l’accès aux applications SaaS. Mais il est aussi parfois nécessaire de sécuriser via MFA l’accès aux systèmes qu’ils soient exécutés sur le LAN ou sur une plateforme IaaS telle que Azure ou AWS.

L’idée est ici par exemple de sécuriser via un facteur d’authentification supplémentaire (en plus d’un password) l’exécution d’une sessions SSH sur un système Linux. JumpCloud nous permet de faire cela sur les systèmes Linux et MacOS en utilisant un MFA totalement gratuit et très répendu, Google Authenticator. Je ferais prochainement un tutoriel pour implémenter cette fonction car pour moi ceci est une demande courante de nombreux clients que je rencontre.

En attendant, voici deux vidéos présentant cette fonction sur un système Linux et un système MacOS:

Vidéo sur Linux:

Vidéo sur MacOS:

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…