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 pas 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…

Une vidéo pour rappeler les fondamentaux des différentes sources d’identités utilisables avec Office 365

Cette vidéo ne contient pas une révolution en termes d’informations, mais peut-être utile afin de montrer à un quelqu’un qui débute sur Office 365 les différentes options pour s’authentifier sur ce service en ligne. L’approche très didactique peut aussi être utilisée pour réaliser qq slides de présentation présentant les grandes lignes de la gestion des identités sur Office 365.

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 : http://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.

Azure AD Pass-Through Authentication et Seamless SSO par Maxime Rastello

Maxime Rastello est consultant & MVP, il s’est fait une spécialité de la partie Azure et notamment des processus et des fonctions liées à l’IAM ou à la sécurité dans Azure. Depuis peu, il a commencé une série de vidéos, dites « Deep-Dive ». C’est vraiment très bien fait et didactique, le format entre 15 et 30 minutes est parfait pour approfondir le sujet mais sans que cela devienne assommant. La dernière vidéo en date porte sur deux nouvelles fonctions en preview, qui de mon point de vue, vont révolutionner l’usage d’Azure Active Directory dans le monde des entreprises et notamment dans les PME ou ETI: Azure AD Pass-Through Authentication et Seamless SSO.

Pour suivre sa chaîne YouTube: https://www.youtube.com/channel/UCL9JIy1auTKjwESwa3XCJ7g/videos

Pour le suivre sur Twitter: @MaximeRastello

Pour retrouver sa dernière vidéo sur Azure AD Pass-Through Authentication et Seamless SSO:

 

Le MIT lance un projet pour la documentation de Kerberos: MIT Kerberos Documentation

kerb_doc

La documentation, c’est toujours un problème ! Toutes les organisations ont du mal à gérer la documentation technique, cela prend du temps, ce n’est jamais à jour, il faut corriger, etc.

Le MIT (inventeur du protocole Kerberos) a décidé de créer un projet pour mieux gérer la documentation de son serveur Kerberos et des éléments périphériques à Kerberos.

Rappelons seulement que le MIT est « l’inventeur » de la première mouture de Kerberos qui existe maintenant selon différentes déclinaisons (Heimdal, Shishi, Microsoft) mais qui reste la référence en la matière, avec un système extrêmement stable et modulaire. Nous en sommes maintenant à la version 5 du protocole Kerberos.

Le MIT a mis en ligne un nouveau format pour la documentation accessible ici: http://web.mit.edu/kerberos/krb5-latest/doc/index.html – c’est plus aéré, plus clair, mieux découpé par section:

kerb_doc_a

De plus, le MIT a lancé un projet afin que chacun puisse éditer, corriger ou faire évoluer la documentation: http://k5wiki.kerberos.org/wiki/Projects/Kerberos_Documentation – Pour ma part, j’aurais préféré un projet sur Github, comme Microsoft le fait avec la documentation Azure, car le système d’édition et de mise à jour basé sur Doxygen n’est pas tout simple à implémenter…

Pour rappel, de nombreuses ressources existent côté MIT, n’hésitez pas à les consulter si vous utilisez Kerberos dans votre organisation, que ce soit avec MIT Keberos ou Microsoft Kerberos:

kerb_docb

 

Si qq est  intéressé par un projet de traduction en Français de la documentation, ne pas hésiter à me contacter sur mon compte Twitter, ce serait un beau projet communautaire à réaliser !

Module PowerShell V2 pour Azure Active Directory disponible en GA

aad_v2_powershell

Comme vous le savez certainement, il est tout à fait possible de manipuler les objets Azure Active Directory via PowerShell. Jusqu’à maintenant, la version V2 (au sens PowerShell) n’était disponible qu’en preview. Depuis quelques jours, le module powershell AAA V2 est disponible en ‘GA’.

Pour info, certaines commande disponible dans la version Preview, n’ont pas encore été intégrées dans la version publique délivrée (ce n’est qu’une question de temps, mais il est toujours possible d’installer le module Peview pour bénéficier de ces commandes en attendant leur intégration définitive).

Pour l’instant, voici la liste des commandes disponibles:

Get-AzureADAdministrativeUnit
New-AzureADAdministrativeUnit
Remove-AzureADAdministrativeUnitSet-AzureADAdministrativeUnit
Add-AzureADAdministrativeUnitMember
Get-AzureADAdministrativeUnitMember
Remove-AzureADAdministrativeUnitMember
Add-AzureADApplicationPolicy
Add-AzureADScopedRoleMembership
Get-AzureADScopedRoleMembership
Remove-AzureADScopedRoleMembership
Confirm-AzureADDomain
New-AzureADDomain
Remove-AzureADDomain
Set-AzureADDomain
Get-AzureADVerificationDnsRecord
Get-AzureADApplicationPolicy
Remove-AzureADApplicationPolicy
Get-AzureADPolicy
New-AzureADPolicy
Remove-AzureADPolicy
Set-AzureADPolicy
Get-AzureADPolicyAppliedObject
Add-AzureADServicePrincipalPolicy
Get-AzureADServicePrincipalPolicy
Remove-AzureADServicePrincipalPolicy
Get-AzureADServiceConfigurationRecord
New-AzureADDirectorySetting
Remove-AzureADDirectorySetting
Set-AzureADDirectorySetting
Get-AzureADObjectSetting
New-AzureADObjectSetting
Remove-AzureADObjectSetting
Set-AzureADObjectSetting

Informations sur le module PowerShell AAD V2 [ ICI ]

 

 

Série d’articles interressants sur Azure AD par un MVP Français

mvp Seyfallah Tagrerout, MVP Français travaillant à la base sur les technologies de virtualisation, commence une série d’articles sur Azure Active Directory.

C’est accessible aux débutants, bien documenté et surtout c’est en Français !

Vous pouvez consulter les deux premiers articles ici:

https://seyfallah-it.blogspot.fr/2016/06/azure-ad-part-1.html

https://seyfallah-it.blogspot.fr/2016/06/azure-ad-part-2-letude-qui-prepare.html?m=1

La page d’accueil de son blog: https://seyfallah-it.blogspot.fr/ – focus sur les technologies de virtualisation, mais pas que.

MIM 2016 & SAP

mim_sapTravaillant actuellement sur un projet implémentant la gestion du cycle de vie des utilisateurs SAP et des rôles SAP depuis MIM, il me semblait intéressant de créer un article court pour rappeler les possibilités de gestion des objets SAP via MIM.

Pour appel, SAP possède sa propre base de compte utilisateurs, lorsque un utilisateur final utilise l’interface web ou le GUI lourd SAP pour se connecter à l’instance SAP, il doit utiliser un compte étant dans cette base. Cette base permet aussi de gérer la partie SoD et la partie RBAC au niveau de SAP lui-même.

Même si cela ne rentre pas dans le cadre de cet article, rappelons que MIM ne permet pas de faire du SSO, mais éventuellement du CSO au niveau de l’authentification SAP, et à minima de gérer le cycle de vie des comptes, voir de créer les « triggers » qui vont bien au niveau de la base SAP pour assurer les mécanismes SoD & RBAC propres à SAP. En effet, le « connecteur » MIM pour SAP intègre maintenant la gestion des rôles au sens SAP du terme.

Si vous recherchez à faire du SSO sur SAP, je ne saurais que trop vous conseiller de réaliser cela en utilisant le protocole Kerberos, de cette façon vous aurez un système fiable, intégré à Active Directory et générique à l’échelle de votre SI. Juste une information importante, utiliser Kerberos pour gérer l’authentification sur la base SAP ne vous épargne pas de devoir créer les comptes utilisateurs dans la base propriétaire SAP, donc SSO ou pas SSO, MIM vous sera utile.

Si vous utilisez SAP sur un serveur Windows et que vous désirez faire du SSO, je vous conseille cette vidéo:

Si vous utilisez SAP sur un serveur Unix/Linux et que vous désirez faire du SSO, je vous conseille cette vidéo:

Mais revenons à nos moutons, le gestion de cycle de vie des utilisateurs dans la base SAP.

Depuis FIM 2010, et donc pour MIM 2016, le connecteur pour SAP est un connecteur générique utilisant des Web Service. Le connecteur SAP pour MIM 2016 est compatible avec les versions SAP ECC 5 & ECC 6.

Tout d’abord il faut télécharger le connecteur web services pour MIM 2016, il est accessible [ ICI ]

La documentation pour le connecteur Web Service est accessible [ ICI ] – A vérifier, mais il ne me semble pas avoir vu une documentation mise à jour spécifiquement pour MIM 2016

De plus, dans le package des connecteurs web services, Microsoft fournit un outil supplémentaire, le « Web Service Configuration Tool » permettant de créer un projet .wsconfig qui pourra être publié directement dans le répertoire \Synchronization Service\Extensions\

Exemple de configuration d’un projet sur un web service intégrant un WorkFLow via le Web Service Configuration Tool:

mim_web_service_configuration_tool

La documentation décrit les différents templates utilisables au travers des web services, pour SAP, il s’agit notamment des objet User SAP, Group SAP et Role SAP. La documentation Microsoft aborde les aspects FIM/MIM mais très peu les prérequis ou la configuration côté SAP, quand on est pas un spécialiste SAP, et je suis très loin d’être un spécialiste SAP, la documentation est un peu juste sur ce point – mieux vaut être accompagné par un « vrai » architecte SAP sur le projet afin de bien comprendre le modèle de données et les particularités des services web sur cette plateforme.

Pour compléter la documentation Microsoft, je vous conseille fortement de lire les articles suivants:

Integrate SAP HR and Active Directory using Forefront Identity Manager (FIM) SAP Connector for WS – article écrit par Salvatore Pellitteri, MVP Microsoft lui aussi, et qui a l’avantage de réaliser un step by step très complet.

#  Integrating SAP Web Services with MIM – (part 1) – article écrit par Ingólfur Arnar Stangeland, consultant travaillant sur les technologies de sécurité proposées par Microsoft, cet article est le premier d’une série et possède l’avantage d’être récent et focus sur la version MIM 2016.

How to Create a Web Service Connector for SAP in FIM/MIM – (part 1) – et How to Create a Web Service Connector for SAP in FIM/MIM – (part 2)  – série de deux articles écrite par Tracy Yu, employé de Microsoft – ces articles font le focus sur la version MIM 2016.

Il ne me souhaite plus qu’à vous souhaiter bonne lecture – je devrais poster dans les mois qui viennent un complément à cet article avec un step by step en Fr sur la partie MIM/SAP.

 

 

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 ]

 

 

Bien commencer avec Azure Active Directory: Azure Active Directory Proof Of Concept Playbook

azure_ad_poc

Beaucoup de mes partenaires et clients me demandent: « comment tester, évaluer et comprendre en quelques jours se qu’est et comment fonctionne Azure Active Directory ? » – en qq mots, comment faciliter la mise en oeuvre d’un POC sur la solution. Microsoft a conçu et met régulièrement un jour un document de référence qui permet « assez facilement » de réaliser ce test: « Azure Active Directory Proof of Concept Playbook.pdf »

Ce document a un grand intérêt car il contient l’ensemble des informations importantes pour la réalisation d’un POC Azure AD et surtout il contient la liste des autres documents ou articles de référence permettant facilement de comprendre les concepts périphériques pour aller un peu plus loin dans la compréhension si c’est la volonté de la cellule IT réalisant cette évaluation.

Le document possède la structure suivante:

azure_ad_poc_doc_contenu

 

Par exemple, comme indiqué, le document contient toutes les références « externes » nécessaires aux différentes étapes, par exemple ici, la liste des prérequis pour la réalisation du POC avec les liens externes nécessaires:

azure_ad_poc_doc_contenu_a

Bref, un très bon point de départ pour ceux qui veulent explorer et comprendre Azure Active Directory.

Rappel du lien pour le document: [ ICI ]

 

 

 

Les différents scénarios possibles selon la topologie d’entreprise avec Azure AD Connect

adconnect je suis tombé qq peu par hasard sur un article (US) qui me semble intéressant pour un architecte débutant dans les problématiques de synchronisation liées à Azure AD Connect. Cet article liste les différentes topologies d’entreprise existantes possibles, et les scénarios d’implémentation Azure AD Connect pour chaque situation. Quand un scénario n’est pas supporté officiellement par Microsoft, cela est notifié dans l’article, ce qui est important et parfois qq peu obscure à décrypter (supporté ou pas supporté…) pour les débutant.

Bref, l’article n’est pas révolutionnaire en soi, mais constitue un bon point de départ pour un consultant déchiffrant ce nouveau monde. L’article est disponible ici: https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-topologies/

Bonne lecture 😉

Comprendre les fonctions PAM de MIM et les nouveautés sur PAM apportées par MIM SP1

privilaged-access

 

La gestion des privilèges et des accès à des comptes d’administration est une problématique récurrente chez les clients d’une certaine taille. Plus l’infrastructure grossie, plus les applications sont nombreuses, plus les services IT sont découpés (merci ITIL…) plus les comptes dits « à pouvoir » se multiplient dans l’écosystème IT des entreprises.

Ici, point de salut avec le Cloud, IT locale ou délocalisée, le nombre de comptes à privilèges ne réduit pas dans le nuage, parfois, il augmente, car la situation actuelle est hybride, de l’IT locale et de l’IT dans le nuage, donc multiplication des comptes à privilège, représentant  des populations d’administrateurs ou de responsables IT parfois différentes.

De nombreuses solutions sur le marché existent pour gérer ces comptes, j’ai commencé un article qui parcourra les différents modèles, mais je voulais mettre en avant la solution proposée notamment par Microsoft car elle a un caractère innovant.

De prime abord, la fonction PAM proposée par MIM semble lourde, elle l’est. En effet, le principe est globalement (je fais simple) de créer une forêt dédiée à la gestion des comptes ou des groupes qui contiennent des comptes à privilèges. On parle ici d’un forêt « bastion », oui vous avez bien lu, il faut une nouvelle forêt, et cela peut rebuter les comptes de tailles moyennes, car cela signifie, de nouvelles procédures, des outils de backup, de supervision, etc…

Mais, pour les comptes d’une certaine taille, je dirais au delà de 10 000 comptes, cette approche d’architecture peut apporter des avantages:

1/ on utilise ici des technologies connues & fiables: Active Directory

2/ la solution sera de facto compatible avec tous les systèmes acceptant  Active Directory comme référentiel de comptes et de groupes, les technologies Microsoft bien sur, mais aussi, Linux, Unix, MacOS, etc… ca commence donc à devenir intéressant

3/ la solution se base sur des protocoles reconnus, tel que Kerberos par exemple

Je vous conseille cette page sur le site de documentation de Microsoft: https://docs.microsoft.com/en-us/microsoft-identity-manager/pam/privileged-identity-management-for-active-directory-domain-services qui décrit les fonctionnalités dans les grandes lignes et l’infrastructure afférente.

Les nouveautés du SP1 de MIM 2016.

Bon, le SP1 de MIM 2016 apporte des choses intéressantes à la solution, comme par exemple le support officiel des différentes browsers web du marché, mais concernant le module PAM, ce qui me semble le plus intéressant, c’est la possibilité de scripter l’intégralité de l’installation du module PAM via PowerShell. Cela ouvre de nouveaux horizons car les scripts de configurations ne s’arrêtent pas uniquement à la partie PAM de MIM mais prennent aussi en compte les paramètres nécessaires comme la partie Active Directory, le SID filtering, la partie Silo Active Directory, etc…

mimsp1_pam_powershell

Il est donc imaginable, soyons fous, de déployer des instances dédiées pour des environnements différents au sein d’une même entreprise; pourquoi pas modéliser la chose sous forme d’appliance prête à l’installation et dont le setup final se ferait via une interface web pilotant le PowerShell ?

Si la gestion des privilèges est dans votre périmètre, et que vous travaillez dans une entreprise de plus de 10 000 employés, regardez la solution PAM de MIM, elle peut être une voie parmi d’autres…

 

 

 

 

Gestion des clés SSH via Key Manager Plus

key_manager_plus
key_manager_plus

ManageEngine est plus connu pour ses solutions autours de l’infrastructure Microsoft dans le monde des PME/PMI et depuis quelques année pour ses solutions MSPs et réseau. Je ne connaissais pas le produit « Key Manager Plus » qui est un outil de gestion des clés SSH, qui comme chacun le sait est une des plaies de l’administration courante dans les entreprises utilisant SSH.

Les fonctions du produits sont globalement présentées sur cette page: https://www.manageengine.com/key-manager/features.html. Au delà du marketing, le produit à l’air très intéressant.

L’outil semble très graphique:

key_manager_plus_demo

La gestion des clés SSH semble complète:

key_manager_plus_ssh

Une fonction audit retrace l’ensemble des usages:

key_manager_plus_audit

Bref, l’outil semble complet. Après il faut surtout vérifier si il correspond à des besoins de grands comptes, en effet, les différents produits ManageEngine que j’ai pu croisé sont très adaptés à la PME/PMI, pour un grand compte c’est généralement un peu léger… Hors la gestion des clés SSH est généralement une grande « douleur » chez les grands comptes. Il convient donc de tester la chose. Ca tombe bien, l’outil est téléchargeable pour évaluation, il est possible de récupérer une version d’évaluation [ ici ].

Enfin,une démo en ligne du produit est disponible [ ici ].

Dès que j’ai 2 heures à tuer, je teste la bête !

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

 

 

Contrer l’attaque pass-the-hash grâce à Windows 10 et Windows Server 2016: Credential Guard

hacker-1280x600

L’attaque « pass-the-hash » est un phénomène connu depuis quelques années, Microsoft a eu quelques difficultés à trouver des solutions efficaces et universelles pour contrer ce type d’attaque. Fort heureusement Microsoft a intégré dans le couple Windows 10 / Windows Server 2016 les outils pour permettre de gérer ce type d’attaque de façon efficace, et c’est plutôt du bon boulot !

Pour en savoir un peu plus sur pass-the-hash:

Une mini-site complet sur le site de Microsoft décrivant en détails pass-the-hass: https://technet.microsoft.com/en-us/dn785092.aspx

Pass-the-Hash attack : compromise whole corporate networks P1

Pass-the-Hash attack : compromise whole corporate networks P2

Pass-the-Hash attack : compromise whole corporate networks P3

 

Credential Guard de Microsoft, permettant notamment de contrer pass-the-hash:

https://technet.microsoft.com/en-us/itpro/windows/keep-secure/remote-credential-guard

https://technet.microsoft.com/en-us/itpro/windows/keep-secure/credential-guard

 

Si vous travaillez dans la sécurité ou si vous gérez un environnement Active Directory dans un contexte de sécurité avancé, je vous conseille de consulter et assimiler ces différents concepts.

 

 

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.

 

 

Migration de Samba vers un Proxy Active Directory

samba_logo

 

Les solutions de Active Directory Bridge proposent généralement une intégration avec Samba, permettant notamment une configuration automatisée des paramètres Winbind et des paramètres nsswitch.conf liés à Winbind. Ainsi le mapping des utilisateurs peut se faire avec des comptes utilisateurs Active Directory et non pas avec des comptes utilisateurs locaux au système UNIX/Linux. Certaines solutions, telle que Centrify, propose une intégration encore plus poussée avec Active Directory permettant en quelques clics un intégration de l’authentification kerberos sur Samba et en fournissant des GPOs pour paramétrer les détails de la configuration Samba sur les différents serveurs Samba – mais le revers de la médaille est qu’il faut alors utiliser les package Samba fournis par Centrify.

Depuis peu, Centrify propose de remplacer leur distribution Samba spécifique par une fonction « ADbindproxy ». ce nouveau service « centrifydc-samba » permet d’utiliser les packages standards fournis par le système d’exploitation (en version samba 4 néanmoins) et de relier le service Samba standard avec une zone d’utilisateurs créées dans Active Directory en gardant tous les avantages de ce type de configuration: intégration kerberos, mot de passe unique, etc…

Une vidéo de présentation courte (15 minutes) permet de mieux comprendre le fonctionnement de ce nouveau composant:

 

 

Format des URLs dans les forums Microsoft

URLBonjour à toutes et tous, c’est le retour de congés, beaucoup de choses à faire, mais il faut bien s’y remettre ! Je suis tombé un peu par hasard sur un article décrivant le format des URLs dans les forums Microsoft, et cela est très instructif. Comme vous le savez, les forums techniques en général et les forums Microsoft en particulier sont une mine d’information pour toute personne qui est à la recherche d’informations techniques, le partage de connaissance est une chose importante dans notre métier. Vous pourrez consulter cet article, qui décrit en détail les URLs des forums, je suis certain que cela pourra vous aider dans vos recherches !

Tutorial: how to store or migrate UNIX NIS maps in Active Directory using the Centrify NIS Gateway

I received a lot, I mean a lot, of requests after I had published my 3 last posts about the storage of NIS maps in Active Directory [http://bit.ly/1S4gKUGhttp://bit.ly/1qvvyzrhttp://bit.ly/1q8iAHi ] – The main problem was my posts are in French 😉 and a lot of people tried to use Google Translate to get it, but it wasn’t perfect. So, from the popular demand, I decided to translate it in English. English is not my native language, so sorry in advance if you will find some ‘bugs’ in the text.

As I explained in one of my last post (sorry again in French !), Microsoft announced it will not implement some Unix Services in Windows 2016 and Active Directory 2016 anymore, including NIS Services.

Through my different projects, I had meet a lot of organizations which are using mixt environment with Windows and Unix boxes and I can say the NIS usage is even nowadays very widespread. For sure, it is very bad to use NIS authentication and NIS authorizations, it is really better to use Kerberos ad LDAP instead. I will not go in the details now, but it is true that NIS is not something secured, however, the fact to totally eliminate the NIS Services is impossible for a lot of organizations. These organizations have a « IT history », from years, and a lot of very important information still remain in the NIS maps (automount, etc.)

So, the goal is to use Kerberos/LDAP for authentication/authorization services and a NIS Gateway service which expose to NIS client the maps NIS which are stored in Active Directory. Using this way, we get the best of the two worlds, we can secure the authentication with Kerberos and the organization is able to continue to use the NIS maps for the legacy needs.


In this tutorial, we will use the NIS Gateway provided by Centrify and get a magic trick to improve security without abandon the NIS history.

Inn this tutorial, we will use a Fedora 23 workstation as a NIS Gateway and Fedora 23 as a NIS client, in my example the Active Directory is a Windows 2012R2 one, but it will work with various flavors of Linux/Unix and with different versions of Active Directory.

A/ First step: Centrify packages installation on the future NIS Server (=NIS Gateway)

First, we need to set our NIS Gateway with a hostname and with a IP which permit to the NIS Gateway to communicate with the Active Directory world. Here, we consider that the basic settings regarding the Centrify Zones are already done (just refer to the Centrify Quick Start Guide to do it).

1/ Hostname settings


In our example, the hostname of the NIS Gateway will be: nisserver01.demo.local

2/ SSH checking

We will check that the SSH server service is present on the Linux box, we will need it to transfer the packages for the Centrify agent and the packages for the Centrify NIS Gateway on the NIS Server.


If the SSH server is not installed, type the following command to install the SSH server packages:


When the SSH packages are installed, you need to start the SSH service


3/ Centrify packages transfer to the machine

We will use WinSCP to transfer the Centrify agent (Centrify Server Suite 2016) on the NIS server (/tmp directory for example) – for a Fedora23 OS, the name of the package is centrify-suite-2016-rhel4-i386.tgz


4/ Centrify agent installation

Go the the /tmp directory and check you have the agent package.


Unzip the package:


Instal the agent, using the install.sh script:


The install.sh script will check everything to be sure your system is able to get it – if you don’t have any ‘failed » result, you will be able to install the agent – if you get some ‘warning’ result, it is not really important (we are doing a POC !)


Choose the Enterprise or the Standard version, it doesn’t matter for the NIS Gateway itself, so let’ choose Enterprise [E] in our example:


Choose the run adcheck again (just to be sure…) et provide the needed information linked to Active Directory during the installation process – In our example, we will join a zone named arizona, so our NIS server will provide « NIS service » for this zone – and choose to not reboot at the end of the installation:


As soon the information will be provided, the install process will start, but just before the installation process will ask you to verify your different values.


The installation process is starting – after the adcheck final check, just validate the agent installation process:



At the end of the process, the Centrify agent installation proceeds:


Now, we will install the package which will update the SSH Server packages with the Centrify packages – this is not 100% mandatory, but it will provide a better integration with Kerberos authentication, so let’s do it:


Now, we will install the Centrify NIS Gateway package:


At the end, just reboot the system, again this is not 100% mandatory, but let’s do it easier and reboot the system.

At this stage the first big step is over. Let’s see now how to set Centrify NIS Gateway.

B/ Second step: Centrify NIS Gateway settings

1/ Active Directory integration of the NIS Gateway Linux box

We will integrate the NIS Server in the zone named arizona. We consider here that you already performed the basic step of the Centrify installation procedure (refer to the Centrify Quick Start guide for details) and we consider you already created some Centrify zones in Active Directory.

First, let’s connect to the NIS Server and execute the following command to perform the Active Directory join to the arizona zone:


In our example, the domain is named demo.local, the Centrify zone is named arizona and the Active Directory service account used to perform the Active Directory join is named centrify. And the password for the service account is …no, for sure, just kidding ;-)) – but the join process will ask you the password for the Active Directory service account.


After few seconds, the following window will appear, saying everything is ok:


It is not mandatory to reboot the server itself, but to make it easier, let’s reboot the server:


2/ Let’s check some important things

Now let’s set some accurate parameters of the Centrify NIS Gateway. We will start to start the management tool Centrify Access Manager, we will find a new machine account in the zone names arizona, it is nisserver01:


This is another view with the list of the machines in the Centrify zone. We will use a other machine from this zone to be NIS client (ypbind) of our NIS Gateway. For sure, the NIS Gateway as a NIS server only for the machines which are in the same zone.


As we didn’t specify a specific container during the Active Directory join of the NIS Gateway, the computer object which represents the NIS server is stored by the containers Computers in Active Directory or any default container if you changed your Active Directory configuration:


Because we will apply some specific GPOs on the computer object which represents the NIS Gateway, we will create a new organization unit (OU) and we will move the computer object in it- in our example, the OU is named NIS_Gateway:


Now, we will start our NIS Gateway computer. When the computer will be started, it would be possible the use any AD account with a UNIX profile in the Centrify zone to log on it, but we will log as root to make it more convenient for the future manipulations.

As soon you are logged on the system, just type the adinfo command, you will obtain information about the state of the adclient daemon which represents more or less a Active Directory client for UNIX/Linux:


The most important thing is to have the value ‘connected’ for the attribute ‘CentrifyDC mode’, this means the system is truly connected to Active Directory and communicate with it. At this stage, our Linux server is integrated in Active Directory and it is totally secured, thanks to Centrify technology.

3/ Apply specific settings on the Centrify NIS Gateway

Let’s set some settings to set the correct behavior of Centrify NIS Gateway (adnisd).

First, we will use the Centrify extension for the GPMC to create some specific GPOs to set the NIS Gateway, nisserver01. Centrify provides some ADMX files if you just want to use the classic GPMC provided by Microsoft, so you can import the administration model in the GPMC. Or you can install some Centrify GPMC snap-in to create the UNIX/Linux GPOS. It is up to you, but you need to do one or the other.

Here we will use the ADMX files method, and e consider we already import the different ADMX files in the GPMC. Open the GPMC and go the node « computer configuration / Strategy / Administration model / Centrify Settings / DirectControl Settings / NIS Daemon Settings:


Edit the ‘Specify allowed client machines for NIS daemon‘ property and set the value to 0/0:


We need to do so, because by default, the NIS Gateway only accept NIS request from itself (I will not go in the details, but in some specific secured configurations where you need to deploy the NIS Gateway packages on all the UNIX systems, this « by default » behavior is useful). So we need to define the is of the IP addresses which are authorized to request the NIS service, if you set the value to 0/0, the NIS server will accept all the request from all the client.

Let’s edit also the ‘Specify NIS daemon update interval‘ property and set the value to 60.


This property will allow us to set the synchronization time between Active Directory and the NIS Gateway. Because of performance reasons, the NIS Gateway maintains a local cache of the values from Active Directory, so in our example, the values will be replicate every minute. In a production environment, a value between 16 and 30 minutes seems a good choice.

Just validate the GPO and close the GPMC. If you want to update the NIS Server with these new settings, it is just matter to execute the adgpupdate command on the NIS Server, this command will refresh the GPOs settings from Active Directory. You can also wait for the next GPO application process (the time period will depend of your Active Directory settings):


It is possible to check which GPO is applied or not by executing the adgpresult command on the system, here, we will see the settings we just created in the new GPO we created:


C/ Third step: Verify some elements on the Centrify NIS Gateway settings

As you may know, to have a consistent NIS Server on a system, we need to have RPC services up and running. If you don’t know so much about NIS, I recommend to read this book which is for me a sort of « NIS bible » [ special thanks to Randip M to let me know about this book. 😉 ]

I will not go in the very details, but globally the RPC server service will receive the requests from the NIS/RPC client from the network, so the RPC server service will decide to use a certain port number, using the port mapper, then the communication between the client and the server will use this specific RPC port for the rest of session. So to have a NIS server running in the right shape we need to have a RPC server running in the right shape.

To verify if everything is ok for the RPC server, execute the following command: rpcinfo –p localhost


Here we can see we have six port mappers waiting for a RPC connection, so everything is ok.

We will now check if the Centrify NIS Gateway service (adnisd) is up and running by executing the following command: systemctl status adnisd –l


If the adnisd service is not running, execute the following command to start it: systemctl start adnisd –l

When we execute the command systemctl status adnisd –l to check the status of the service, we have a message saying that we don’t have any NIS map stored in Active Directory, at this stage it is totally normal, we will publish NIS maps in Active Directory latter.

D/ Fourth step: Check the configuration of the NIS client

1/ some thoughts about what we are doing here…

At the Linux client level, it is very important to understand that we have two different components:

– The Centrify DirectControl agent which provides the ability of the system to be fully integrated in Active Directory and provides the Kerberos and LDAP layers for authentication and authorization against Active Directory – Even if we have a NIS client on system to use NIS maps, the authentication is not managed by NIS but by Kerberos

– The NIS client of the Linux system – this is not a component provided by Centrify agent installation, here we are using a generic client, which could be slightly different from different Linux/UNIX forks – never mind, the generic NIS client will use « classic » NIS exchange with the Centrify NIS Gateway, so it will work

The good thing with this scenario, is we will get all the advantage provided by the Centrify agent but we will be able to use legacy NIS maps. As the NIS gateway server itself is using a Centrify agent, all the communication between the NIS gateway and Active Directory is secured. Another big advantage is the fact that we will not have any more a dependency with one single NIS Master – in this scenario, the « NIS master role » is technically provided by the different AD domain controllers, as the AD domain controllers are using multi-master replication, we don’t have any single point of failure there – The NIS gateway will act as a NIS slave and will cache the information from AD on his own system, and we reply to the NIS requests from the network.

It is existing other scenarios, where the NIS authentication (ok, I don’t like to use the expression « NIS authentication » because NIS is NOT an authentication protocol, but I make the things simple here by comparing with Kerberos…) will be provided by NIS even if the NIS maps are stored in Active Directory – but in this scenario we will need to store in Active Directory a hashed version of the user passwords compatible with NIS, we will not review this particular scenario there because it is not really used anymore and above all because it is not really secured (I will even say it is not secured at all…).

2/ Apply some settings at the NIS client level

Perform a connection, using root, to the NIS client, in our example, the NIS client hostname is : fedora23.

We will first check if the ypbind service (the NIS client) is up and running, so let’s execute the following command: systemctl status ypbind –l

If you get something like this :


It means the service is not started, and it means the ypbind packages are even not installed at all.

To check is the package are installed or not, let’s try to start the service using this command: systemctl start ypbind –l

The following message will confirm that the ypbind packages are not installed at all:


To install the NIS client packages, execute the following command: dnf -y install ypbind rpcbind

If rpcbind was already installed, you will get this message, it is not a big deal, just ignore it :


In all the situations, you may obtain something like that at the end of the packages installation:


After packages installation, I advise you to restart the system, it is not purely technically a requirement, but I was used to be a Microsoft Guy 😉

Never mind if you just installed the NIS client packages or if you were using it during years before this tuto, we will now stop the ypbind service on the client to apply some settings at the NIS client level: systemctl status ypbind –l

To be sure we will not have bad behavior because of previous settings/usage, we will delete all the files which are in the var/yp/binding directory: rm -rf /var/yp/binding/*

Now, we will define the NIS domain name at the client level – remember, by default, the NIS domain name is equal to the Centrify zone name where our NIS Gateway is acting, in our example, the zone name is arizona. So let’s execute the command: domainname arizona


Then, we will edit the /etc/yp.conf file to set the NIS domain name and the NIS Gateway hostname – in our example, we need to add the value: domain arizona server nisserver01

Example, with the nano editor:


If you are using nano, after editing the value, let’s use Ctrl+O & Ctrl+X

Now, let’s start the ypbind service: systemctl start ypbind –l

You can check the service status using this command : systemctl status ypbind –l


Note: if the NIS client is not able to contact the NIS server, so the NIS client service will not start. If you get an error when you try to start the NIS client service, the first thing to do is to disable the firewall service on the NIS server (use the following command to stop the firewall on a fedora system: systemctl stop firewalld –l )

At this stage, we have a NIS server and a NIS client which are able to communicate each other, let’s publish some NIS maps in Active Directory now !

E/ Fifth step: Publish some NIS maps in Active DIrectory

In this tutorial, we will use the Centrify graphical tool « Centrify Access Manager » to publish some information in the NIS maps, but you can do it using different ways (LDP command for example).

Start the Centrify Access Manager tool, and go the Centrify zone (arizona in our example) – Then go to ‘Unix Data’, then ‘NIS maps’ node. Right-click on the node and choose ‘New / Generic Map’:


In our example, we will create a Generic Map, i.e. a map used to store text information with no direct relation with something used by the Linux system itself. For sure, you create some ‘classic’ NIS maps like Automount or Netgroup, but we will not cover the usage of these NIS maps in this article.

In this example, the NIS maps name is test and we have a key test01 with the value test0101:


From the NIS client, execute the following command: ypcat test – you may get the values from the NIS map test :


Here we go, it is working fine !

With the ypwhich command you will be able to confirm the NIS server name used by the NIS client (so in our example, it is the NIS Gateway hostname:


F/ One step beyond…

1/ Generated NIS maps

Let’s now explore, some advance details. To get the list of NIS maps from a NIS master server you need to execute the following command ypwhich –m


Here you can note two important things:

(1) from a NIS client, the NIS gateway is considered as NIS master server

(2) we created only one NIS map (test) in d’Active Directory but the NIS client is able the « see » four other NIS maps : passwd.byuid / passwd.byname / group.byname / group.bygid – These four maps are what we call ‘derived maps’, there are implicited generated from Active Directory data – In fact, at the system level (NIS client side), the NIS client needs to have a visibility of these four maps, so you don’t need to create it, the Centrify NIS gateway will create it and update it for you. So the passwd.byuid and passwd.byname maps will be automatically generated from the UNIX user profiles from the arizona zone, and the group.byname and group.bygid maps will be automatically generated from the UNIX group profiles from the arizona zone. Remember, behind the scene, the UNIX user profiles and the UNIX group profiles are linked with ‘real’ Active Directory user and group objects.

If you are using the command ypwhich –x you will be able to see the correspondence between NIS maps aliases and the real technical name of such NIS maps.


If you are using the command ypcat passwd you will be able to see the content of the generated map passwd.byname which is the list of the UNIX user profiles from the zone arizona :


To fully understand this feature, you can open the graphical tool Centrify Access Manager and check the list of UNIX user profiles from the arizona zone, you will exactly the same list :


2/ NIS maps objects in Active Directory

We can check how the NIS maps objects are stored in Active Directory – let’s use Microsoft Active Directory Users and Computers tool (ADUC) or a basic LDAP client to do so.

If you go to the zones containers, you will be able to see all the Centrify zones you created (not cover by this article) – select the arizona zone, and the NisMaps container, you will list the NIS map we created, means the test NIS map.

Under the test container (our NIS map), you will see the entry we create named test01:


If you do right-click on the test01 object and choose ‘Properties’ (with ADUC, Attribut Editor), you will see the different values from the different attributes used by Centrify to store the information:


If you look at three specific attributes, we will review the values we put in the system with the Centrify Access Manager tool for our test map – as a reminder:


These are the three attributes:

KEY: (description)


VALUE: (adminDescription)


COMMENTS: (wWWHomePage)


For sure, you will be able to use Active Directory ACLs Active Directory to provide access and delegation for such NIS map or even some specific rights on a specific value: this is very useful to define the NIS administrators AD group which will be able to create or update NIS map values in the future:


The main difference for the UNIX administrator will be the interface. As now the NIS maps are stored in Active Directory, they will use a LDAP Browser, the Centrify graphical tool or some LDAP script to maintain the NIS maps contain.

At the end, the ideal situation will be to use a IAM tool such MIM for example to manage the NIS maps lifecycle with delegation, workflow, approval and activity logs !

We did it !

Now, this tutorial is finished. Don’t hesitate to add some comments or contact me if you have any questions. Let’s discuss on twitter (@sylvaincortes) or by email if you have a NIS migration project, we can help you 😉

Utilisation d’Active Directory pour le stockage des maps NIS UNIX/Linux via la Centrify NIS Gateway [3/3]

 

Lors des deux premiers posts, nous avons vu les bases de l’intégration du système supportant la NIS Gateway au sein d’Active Directory puis l’installation et le paramétrage de la NIS Gateway elle-même. Dans ce dernier article consacré à la Centrify NIS Gateway, nous allons voir la configuration d’un client NIS et quelques options de publication des maps NIS.

Tout d’abord, il faut bien comprendre que dans notre cas d’utilisation, deux composants sont utilisés sur le client Linux/UNIX:

– L’agent DirectControl de Centrify qui permet l’intégration dans Active Directory du système ainsi que les mécanisme d’authentification par Kerberos et de gestion des autorisations via LDAP

– Un client NIS générique (celui du système)

Dans ce scénario, nous conservant tous les avantages de sécurité apportés par l’agent Centrify et nous permettons l’utilisation des NIS Maps de façon classique. La différence est que les NIS maps sont stockées dans Active Directory. Ceci amène plusieurs avantages dont celui-ci extrêmement important de ne plus dépendre du NIS master unique mais d’avoir en fait le rôle de NIS master porté par les contrôleurs de domaine Active Directory, cela tombe bien, ils sont multi-maitres et la NIS Gateway agit alors en tant que NIS Slave et répond donc aux requêtes des clients NIS.

Il existe d’autres scénarios, où l’authentification peut aussi être réalisé via NIS (bon je n’aime pas dire authentification via NIS, car NIS n’est en fait pas un protocole d’authentification, mais c’est pour rendre les choses simples via la comparaison avec Kerberos) avec des maps NIS et des hash de mots de passe compatibles NIS stockés dans Active Directory. Nous ne parlerons pas ici de ce scénario car il est de moins en moins utilisé par les entreprises et surtout parce que le niveau de sécurité global n’est pas très bon –ok, meilleur qu’avec uniquement NIS, mais c’est pas terrible quand même).

Paramétrage du client NIS

Réaliser une connexion via root sur le système client NIS, dans notre exemple la machine nommée fedora23.

Nous allons tout d’abord vérifier si le service ypbind (le client NIS) est démarré et fonctionnel sur le système en exécutant la commande: systemctl status ypbind –l

si vous obtenez quelque chose qui ressemble à cela:

capture20160406205428817

c’est que le service n’est pas démarré, et si il n’est pas démarré, il y a de fortes chances pour que ce soit tout simplement parce que les packages ne soient pas installés.

Un tentative de démarrage infructueuse via la commande systemctl start ypbind –l vous confirmera que les packages ne sont pas présents:

capture20160406205753580

Pour installer les packages nécessaires à l’exécution du client NIS, exécuter la commande suivante: dnf -y install ypbind rpcbind

Si rpcbind est déjà installé, vous obtiendrez le message suivant, ce n’est pas bien grave:

capture20160406210235398

Dans tous les cas, vous devriez obtenir quelque chose comme cela après l’installation des paquets:

capture20160406210435735

Après installation des paquets, je vous conseille un petit redémarrage du système. (pas purement techniquement obligatoire, mais bon…)

Que vous ayez déjà un client NIS fonctionnel sur la machine ou que vous veniez de l’installer, il faut maintenant arrêter le service ypbind sur le système via la commande: systemctl status ypbind –l

Ensuite, nous allons supprimer tous les fichiers qui peuvent se trouver dans le répertoire var/yp/binding via la commande: rm -rf /var/yp/binding/*

Il faut maintenant définir le nom de domaine NIS auquel le client devra se référer, par défaut le nom de domaine NIS est le nom de la zone Centrify dans laquelle le système et la NIS Gateway se trouvent, dans notre exemple il se nomme donc arizona. Pour ce, exécuter la commande suivante: domainname arizona

capture20160406211557943

Puis éditer le fichier /etc/yp.conf afin de renseigner le nom du domaine NIS ainsi que le nom de serveur de la NIS Gateway, dans notre exemple, il faut donc renseigner la ligne suivante: domain arizona server nisserver01

Exemple avec l’éditeur nano:

capture20160406211932335

avec nano, après édition du fichier, Ctrl+O & Ctrl+X

Ensuite, démarrer le service ypbind via la commande: systemctl start ypbind –l

Vous pouvez aussi vérifier le statut du service via la commande: systemctl status ypbind –l

capture20160406213506789

Note: si le client NIS ne peut pas atteindre le service NIS de la NIS Gateway, alors le service client ne démarre pas. Si vous avez une erreur au démarrage, la première chose à faire est de désactiver le firewall sur le serveur portant la NIS Gateway afin de vérifier si le problème vient du filtrage du firewall. (commande pour arrêter le firewall sur fedora: systemctl stop firewalld –l)

Donc jusque ici, tout va bien, nous avons un service NIS Gateway opérationnel et un client NIS qui est capable d’interroger le service NIS Gateway – reste maintenant à publier des maps NIS dans Active Directory afin de voir si nous sommes capables d’y accéder via la commande ypcat !

Pour publier des maps NIS dans Active Directory, nous allons simplement utiliser l’outil graphique Centrify Access Manager – Lancer l’outil, puis se rendre dans la zone (arizona, dans notre exemple) puis ‘Unix Data’, puis sélectionner le noeud ‘NIS maps’. Réaliser un clic-droit sur le noeud et choisir ‘Nouveau / Generic Map’:

capture20160406214146188

Dans notre exemple, nous allons simplement créer une map générique, c’est à dire une map pour stocker des informations texte sans relation directe avec des éléments utilisés par le système. Vous pouvez bien sur créer des maps plus ‘classiques’ telle que Automount ou Netgroup par exemple.

Exemple de notre map:

capture20160406214457532

Notre map se nomme donc test et contient une clé test01 de valeur test0101

Depuis le client NIS, exécuter la commande suivante: ypcat test – vous devez obtenir les valeurs de la map tel que:

capture20160406214750560

Ca y est, ca fonctionne !

La commande ypwhich vous confirmera le nom du serveur NIS (la NIS Gateway) que le client utilise:

capture20160407091449128

Pour aller un peu plus loin dans la compréhension, exécuter la commande ypwhich –m qui permet d’afficher la liste des maps et le serveur NIS Master pour chaque map:

capture20160407091953853

Nous pouvons constater deux éléments:

(1) d’un point de vue du client NIS, la NIS Gateway est vue comme le Master NIS

(2) alors que nous n’avons créée qu’une seule map NIS (test) au niveau d’Active Directory, le client NIS perçoit quatre autres maps NIS: passwd.byuid / passwd.byname / group.byname / group.bygid – ces quatre maps NIS sont les maps dites ‘implicites’, c’est à dire qu’elles sont générées automatiquement par la NIS Gateway pour des besoins systèmes en fonction des profils UNIX et des groupes UNIX qui sont présents et actifs dans la zone Centrify arizona (pour rappel, avec la technologie Centrify, nous utilisons directement des comptes utilisateurs et des groupes Active Directory au niveau des systèmes UNIX)

Grâce à la commande ypwhich –x nous pouvons visualiser les correspondances entre les alias de nom de maps NIS (accessibles via la commande ypwhich) et le nom réel technique de certaines maps NIS:

capture20160407092842774

Si maintenant nous exécutons la commande ypcat passwd nous afficherons alors le contenu de la map NIS implicite passwd.byname qui contient une représentation des profils UNIX présents dans la zone ‘arizona’:

capture20160407093232688

Effectivement, si nous utilisons l’outil graphique de gestion Centrify Access Manager et si nous regardons la liste des profils UNIX effectifs dans cette zone ‘arizona’, nous retrouvons bien la même liste de comptes:

capture20160407093603198

Regardons maintenant à quoi ressemble le stockage des maps NIS dans Active Directory. Pour cela, vous pouvez utiliser l’ADUC de Microsoft ou un client LDAP basique.

Si nous regardons dans le container des zones, nous retrouvons l’ensemble de nos zones Centrify. Il suffit de sélectionner la zone ‘arizona’, puis le container NisMaps. Nous retrouvons à l’intérieur de ce container la map NIS que nous avons créée, c’est à dire la map nommée  ‘test’.

Sous le container de la map ‘test’, nous retrouvons notre entrée nommée ‘test01’:

capture20160407084650968

Si nous regardons les propriétés de cette objet ‘test01’ (avec ADUC, réaliser un clic-droit puis choisir ‘Propriétés’), nous pouvons visualiser les différentes valeurs des différents attributs de cet objet (avec ADUC, via l’éditeur d’attributs):

capture20160407085502254

Si nous regardons spécifiquement trois attributs, nous retrouvons les valeurs que nous avons renseignées lorsque nous avons créé l’entrée dans la map NIS, pour rappel:

capture20160407085643363

Voici les trois attributs:

KEY: (description)

capture20160407085942866

VALUE: (adminDescription)

capture20160407085806729

COMMENTS: (wWWHomePage)

capture20160407090045656

Bien évidement, vous pouvez utiliser les ACLs Active Directory pour donner des accès à une map NIS ou à une autre, ou même des accès spécifique à une entrée en particulier. Cela est très utile pour définir les groupes d’administrateur qui auront le droit de mettre à jour les entrées dans la maps NIS:

capture20160407090422802

En effet, la différence pour les administrateur Unix sera l’interface qu’ils vont maintenant utiliser pour mettre à jours les entrées dans les maps NIS: ils pourront utiliser l’interface graphique Centrify, un browser LDAP ou des scripts LDAP. Nous pourrions même imaginer réaliser une interface dans un outil de gestion des identités comme MIM !

Ce tutoriel est terminé. N’hésitez pas à me contacter si vous avez des questions ou des interrogations existentielles sur ce type de solution !

Utilisation d’Active Directory pour le stockage des maps NIS UNIX/Linux via la Centrify NIS Gateway [2/3]

 

Lors de notre post précédent nous avons vu comment installer l’agent Centrify (adclient) et le package de la Centrify NIS Gateway (adnisd) sur le serveur qui publiera les maps NIS stockées dans Active Directory.

Nous allons maintenant voir comment activer l’agent Centrify sur la NIS Gateway, comment réaliser quelques GPOs depuis Active Directory pour paramétrer la NIS Gateway et finir par des vérifications locales à faire sur la NIS Gateway.

Tout d’abord nous allons intégrer le futur serveur NIS dans Active Directory et le faire rejoindre une zone Centrify. Nous considérerons ici que la partie basique d’une installation Centrify a déjà été réalisée, et que des zones ont été créées. Je vous laisse jeter un œil sur la documentation (notamment le Quick Start Guide) sur ces étapes extrêmement basiques. Dans notre exemple, la zone que nous allons rejoindre se nomme arizona.

Tout d’abord, se connecter en root sur le systèmes (sur le futur serveur NIS donc) et exécuter cette commande pour rejoindre Active Directory et la zone nommée arizona:

capture20160405142931118

dans notre exemple: le domaine AD se nomme demo.local, la zone Centrify à rejoindre se nomme arizona et le compte de service (Active Directory) ayant le droit de joindre une machine au domaine se nomme centrify – ensuite, le mot de passe AD pour le compte utilisateur/administrateur centrify sera demandé:

capture20160405142947712

Après quelques secondes, la fenêtre suivante apparaitra, vous confirmant que l’opération s’est bien déroulée:

capture20160405143023882

Nous pourrions nous amuser à ne redémarrer que certains services, mais allons redémarrer le serveur NIS, ce sera plus simple:

capture20160405143109675

Maintenant, laissons le système Linux de côté quelques instant et utilisons quelques outils de gestion proposés par Centrify pour affiner notre configuration.

Lancer l’outil Centrify Access Manager, nous constatons qu’une nouvelle machine a rejoint la zone arizona, il s’agit de nisserver01, notre futur serveur NIS:

capture20160405143154356

Une autre vue, avec la liste des machines qui sont dans la zone Centrify, pour information, la machine fedora17 nous servira de client NIS (ypbind) pour les tests, pour que cela fonctionne il faut bien sur que la NIS Gateway et le client NIS soient dans la même zone Centrify:

capture20160405143220837

Comme nous n’avons pas spécifier de conteneur Active Directory spécifique lors de la jointure au domaine de la machine Linux (notre futur serveur NIS), l’objet Computer le représentant dans Active Directory s’est créé dans le conteneur par défaut, si vous n’avez pas fait de modification au niveau d’Active Directory, vous retrouverez alors l’objet Computer dans le conteneur nommé Computers:

capture20160405143259227

Pour la suite des tests, et notamment pour l’application de certaines GPOs sur le serveur NIS lui-même, nous allons créer une Unité d’Organisation (UO) dans laquelle nous allons déplacer l’objet AD représentant le compte ordinateur du serveur NIS, dans notre exemple, l’UO se nomme NIS_Gateway:

capture20160405143414531

Nous allons maintenant démarrer notre serveur NIS. Une fois démarré nous pourrions maintenant utiliser n’importe quel compte AD ayant un profil UNIX dans la zone et ayant les droits de login pour nous authentifier sur le système – pour plus de souplesse, nous continuerons d’utiliser le compte root pour les différentes manipulations.

Si nous nous connectons sur le système, et que nous tapons la commande adinfo, nous devons obtenir des informations sur l’état du service adclient qui représente le client AD du système Linux:

capture20160405143515949

Le plus important est que l’attribut ‘CentrifyDC mode’ est bien la valeur ‘connected’, cela signifie que le système est bien connecté à Active Directory. A ce stade nous avons un serveur Linux intégré dans Active Directory, dans une zone Centrify et qui est fonctionnel d’un point de vue système et totalement sécurisé par l’agent Centrify.

Nous allons maintenant voir certains éléments spécifiques à la partie NIS Gateway (adnisd).

Tout d’abord nous allons utiliser l’outil d’administration Centrify pour créer des GPOs spécifiques aux serveurs NIS qui s’appliqueront à notre serveur nisserver01. Centrify propose soit d’intégrer directement des fichiers ADMX au niveau de la GPMC soit d’installer un snap-in présentant les GPOs spécifiques aux environnements Unix/Linux et MacOS toujours au niveau de cette même GPMC. Il faut bien sur au préalable avoir fait une de ces deux manipulations.

Ouvrir la GPMC, se rendre sur le noeud Configuration ordinateur / Stratégies / Modèles d’administration / Centrify Settings / DirectControl Settings / NIS Daemon Settings:

capture20160405143959120

Editer la propriété ‘Specify allowed client machines for NIS daemon’ et renseigner la valeur 0/0:

capture20160405144020742

En effet, par défaut, le démon adnisd n’accepte que les requêtes locales, c’est à dire, les requêtes NIS émises depuis le serveur NIS lui-même (je ne rentrerai pas dans les détails, mais cette configuration est utilisée dans des cadres précis de sécurité), il faut donc spécifier les adresses IP qui auront le droit de lancer des requêtes NIS vers notre NIS Gateway, si l’on renseigne la valeur 0/0, toutes les requêtes NIS seront acceptées.

Editer également la propriétés ‘Specify NIS daemon update interval’ et renseigner la valeur 60:

capture20160405144101425

Cette valeur (par défaut sur 30 minutes) permet de spécifier l’intervalle de rafraichissement des données entre Active Directory et le cache local de la NIS Gateway. En effet, pour des raisons de performance, les informations des maps NIS stockées dans Active Directory sont mises en cache au niveau de la NIS Gateway (comportement par défaut), nous mettons ici la valeur sur 60 secondes afin de ne pas trop attendre entre les modifications faites dans Active Directory et leur synchronisation sur la NIS Gateway. En production, une valeur entre 15 et 30 minutes est tout à fait acceptable.

Valider la GPO, et refermer la console de gestion des GPOs Centrify.

Pour mettre à jour notre futur serveur NIS avec ces nouvelles valeurs de configuration (celles de la GPO), il faut se connecter sur le serveur NIS et exécuter la commande adgpupdate afin de forcer le rafraichissement de la GPO sur le système Linux, sinon attendre la prochaine application des GPOs:

capture20160405200401273

Pour visualiser les GPOs qui sont bien appliquées sur le système, exécuter la commande adgpresult, nous retrouvons bien les paramètres appliqués de notre GPO créée précédemment:

capture20160405200555997

Nous allons maintenant vérifier quelques éléments au niveau de notre serveur NIS Gateway.

Tout d’abord pour qu’un service NIS s’exécute convenablement sur un système, il faut que les services RPC soient opérationnels. je ne rentrerais pas les détails, mais globalement le service RPC du serveur va recevoir la requête, décider d’un numéro de port RPC pour la connexion cliente du client NIS et donc permettre la communication entre le client et le serveur. Il faut donc que RPC fonctionne correctement sur le serveur NIS, pour vérifier cela, exécuter la commande  rpcinfo –p localhost

capture20160405144954620

Nous voyons ici 6 portmapper en attente de demande d’échange RPC, tout va bien.

Nous allons maintenant exécuter la commande systemctl status adnisd –l afin de vérifier que le service adnisd est bien démarré et fonctionnel:

capture20160405202502019

Si jamais le service n’est pas démarré, exécuter la commande systemctl start adnisd –l pour le démarrer.

Le résultat de la commande systemctl status adnisd –l nous indique à la fin qu’il n’y aucune NIS map dans Active Directory, à ce stade, c’est tout à fait normal.

Dans le prochain et dernier article de cette série consacrée à l’utilisation d’Active Directory pour le stockage des maps NIS à destination des clients UNIX ou Linux, nous verrons comment publier quelques maps NIS dans Active Directory, comment paramétrer des clients NIS (ypbind) pour interroger ces même maps NIS et comment réaliser quelques tests supplémentaires.

Utilisation d’Active Directory pour le stockage des maps NIS UNIX/Linux via la Centrify NIS Gateway [1/3]

 

Comme indiqué dans un de mes derniers posts, Microsoft a annoncé la suppression de certains services Unix majeurs au sein de Windows 2016 et donc d’Active Directory 2016.

Au travers de mes projets, je rencontre de nombreuses sociétés qui utilisent des environnements mixtes Microsoft/Unix, et il est clair que les services NIS ont la vue dure… Bien sur, il ne faut pas gérer les authentifications et les autorisations via NIS, au profit d’utiliser Kerberos et LDAP. Je ne vais pas rentrer dans les détails ici, mais c’est comme dans Ghosbusters, utiliser les services NIS, c’est “mal”… Néanmoins, pour de nombreuses organisations, l’élimination totale des services NIS est un véritable challenge, car ces même organisations gère depuis des dizaines d’années des informations très importantes pour leur production dans ces fameuses map NIS (automount ou autre).

L’idée est donc généralement d’utiliser Kerberos/LDAP pour utiliser les services d’authentification et d’autorisation d’Active Directory et un service NIS “gateway” qui permettra d’accéder à Active Directory de façon sécurisée pour proposer le service NIS server depuis cette gateway. De cette façon, on obtient le meilleur des deux: on sécurise les services d’authentification par Kerberos et on permet à l’organisation de continuer à utiliser NIS pour exposer des maps “legacy”.

capture20160403202213508

Nous allons donc utiliser les services de NIS gateway proposés par la solution Centrify pour réaliser cette prouesse technologique et fonctionnelle Smile

Pour ce, nous allons paramétrer une workstation Fedora 23 en tant que passerelle NIS vers Active Directory.

Tout d’abord, il faut bien paramétrer votre Fedora pour vous assurer de lui donner un nom hostname qui corresponde à votre besoin et lui donner un paramétrage IP qui permette à cette passerelle NIS de communiquer avec Active Directory. Nous considérons ici, que les paramétrage basiques d’installation et de paramétrage de Zones Centrify ont déjà été effectués.

1/ Paramétrage du hostname

capture20160403204153493

Dans notre exemple, le hostname du futur serveur NIS sera: nisserver01.demo.local

2/ Vérification du service SSH

Nous allons vérifier que le service SSH Server est présent sur la machine, ceci afin de nous permettre de transférer les package de l’agent Centrify et de la NIS Gateway sur le futur serveur NIS

capture20160403204414276

Si le serveur SSH n’est pas installé, renseigner la commande suivante pour installer les packages:

capture20160403204724703

Une fois que les packages SSH sont installés, démarrer le service SSH serveur

capture20160403204915783

3/ Transfert des packages sur la machine

Via WinSCP, nous allons transférer l’agent Centrify de la version Centrify Server Suite 2016 sur la machine (dans le répertoire/tmp) pour une fedora 23, le nom du package est centrify-suite-2016-rhel4-i386.tgz

capture20160403205117288

4/ Installation de l’agent Centrify

Vérifier que l’agent est bien dans le répertoire /tmp:

capture20160403210045886

Décompresser le package de l’agent:

capture20160403210228837

Lancer l’installation de l’agent:

capture20160403210414251

Le script d’installation va lancer une vérification pour voir si la plateforme sera compatible avec l’installation de l’agent – si aucun test ne sort en “failed”, l’installation sera possible, les “warning” ne sont pas rédhibitoires pour l’installation:

capture20160403210626167

Choisir d’installer la version Enterprise ou Standard, en ce qui nous concerne pour le service NIS, cela n’a aucune importance – dans notre exemple, nous choisissons Enterprise [E]:

capture20160403210930120

Choisir de lancer adcheck à nouveau (pour être sur…) et renseigner les informations liées à Active Directory que demandera le processus d’installation – dans notre exemple, nous allons rejoindre une zone Centrify nommée arizona, notre futur serveur NIS fournira donc des services NIS pour cette zone Centrify – choisir de ne pas redémarrer à la fin de l’installation:

capture20160403211412414

Une fois les informations fournies, le processus d’installation vous demande de valider une dernière fois les informations fournies avant installation et paramétrage de l’agent:

capture20160403211646995

Le processus d’installation commence – après le processus adcheck, valider l’installation de l’agent:

capture20160403211958028

capture20160403212104744

L’installation se termine avec l’installation des agents Centrify:

capture20160403212219329

Nous allons maintenant installer le package permettant de mettre à jour le serveur SSH livré avec l’OS par la version serveur SSH Centrify qui permet une meilleure intégration au niveau de l’authentification Kerberos intégrée:

capture20160403213437402

Nous allons maintenant installer le package du serveur Centrify NIS Gateway:

capture20160403213822508

Nous allons maintenant pouvoir redémarrer le système !

Lors du prochain article, nous verrons ensemble le paramétrage de l’agent Centrify, le paramétrage du service NIS Gateway et nous publierons quelques maps NIS dans Active Directory afin de les rendre accessibles pour des clients NIS Unix/Linux sur notre réseau.

Microsoft propose une mise à jour des fichiers ADMX pour Windows 10

 

La version RTM de Windows contient une version maintenant obsolète des fichiers ADMX dont on besoin les administrateurs pour gérer les stations Windows 10.

Sur ce lien, vous trouverez les nouvelles définition des fichiers ADMX pour Windows 10. Avec les éléments suivants:

  1. DeliveryOptimization.admx
  2. fileservervssagent.admx
  3. gamedvr.admx
  4. grouppolicypreferences.admx
  5. grouppolicy-server.admx
  6. mmcsnapins2.admx
  7. terminalserver-server.admx
  8. textinput.admx
  9. userdatabackup.admx
  10. windowsserver.admx

Sur ce lien, vous trouverez le fichier Excel décrivant les fonctions et paramètres (Group Policy Settings Reference for Windows and Windows Server)

Microsoft annonce la suppression du support de Identity Management for Unix (IDMU) & NIS Server Role dans Windows Server 2016 Technical Preview (et après)

 

Depuis plus de dix ans, Microsoft propose le support des services NIS au sein d’Active Directory. Bon, ok, NIS c’est complètement pourri et le stockage des mots de passe NIS et leur transport sur le réseau sont un gouffre béant de sécurité sur une infrastructure d’entreprise.

Neanmoins, certaines entreprises utilisent encore NIS (et oui !) et certaines entreprises utilisent les Services for Unix sous la forme ou NIS Server Role dans Active Directory (bon, ok, pas beaucoup, mais j’en connais…)

Sur ce post, Microsoft révèle l’abandon de deux composants liés aux services Unix depuis Active Directory à partir de Windows Server 2016:

  • – NIS Server Role (rôle Windows Server)
  • – Extension IDMU pour la MMC: cette extension à la MMC permet de visualiser les attribut Posix définis dans la RFC2307 directement depuis l’interface ADUC

Pour rappel, voici un exemple d’interface IDMU:

Unix_tab

Attention, cela ne veut pas dire que la RFC2307 n’est plus supportée dans l’annuaire Active Directory, bien au contraire, cela signifie que si l’on veut modifier ces attributs, il faudra utiliser l’onglet Attribute Editor, comme pour tous les autres attributs prévu dans le schéma ou utiliser ADSIEDIT ou encore un client LDAP en écriture.

Pour rappel, voici la listes des attributs RFC2307 utilisés dans Active Directory:

RC2307

Par contre, cela signifie qu’il ne sera plus possible d’utiliser un contrôleur de domaine en émulation d’un service NIS en utilisant uniquement les technologie Microsoft.

Cela va ouvrir la porte vers les ISVs spécialistes de l’intégration Unix/Linux dans Active Directory et surtout à Centrify et Dell qui sont les seuls à proposer une NIS Gateway digne de ce nom.

Si vous êtes utilisateur SFU ou NIS Server Role, n’hésitez pas à me contacter pour définir comment anticiper ce changement majeur au niveau de Windows Server.

Installation de Solus 1.1

 

Solus est un OS Linux destiné à un usage desktop uniquement. Il a été créé par une communauté désirant désigner un OS desktop devenant une véritable alternative à Windows ou MacOS

Pour ma part, je suis convaincu que le fait de faire un focus unique sur la partie desktop est une excellente idée. Ici pas d’OS serveur, pas d’optimisation pour la partie serveur mais au contraire une optimisation de l’OS et des applications disponibles pour un usage workstation – c’est à mon sens le seul moyen de bien faire les choses, faire un focus fonctionnel précis répondant à des usages précis

Vous trouverez un article à propose de Solus sur le site de Korben: https://korben.info/solus-linux-user-friendly-refuse-de-devenir-usine-a-gaz.html

Télécharger l’ISO en version 1.1 depuis: https://solus-project.com/download/

Transformer une clé USB en clé USB bootable depuis l’ISO téléchargé – par exemple, sous Windows avec l’outil Rufus disponible sur http://rufus.akeo.ie/?locale=fr_FR

Démarrer sur la clé USB, après quelques secondes, vous obtenez un écran d’accueil, choisir “Instal Solus”

capture20160305121638720

Cliquer sur “Find my location automatically”

capture20160305123306338

Choisir la langue désirée

capture20160305123508918

Garder les options de clavier par défault, à moins que vous ayez des besoins particuliers

capture20160305123610657

Sélectionner le disque sur lequel l’installation doit être effectuée

Cliquer ensuite sur le bouton “Launch Partition Editor”

capture20160305123733104

Nous considérons ici que le disque est vierge, sans partition existante et sans données

Cliquer sur le menu Device et choisir “Create Partition Table”

capture20160305124113354

Choisir le type de table de partition “gpt” et cliquer sur le bouton “Apply”

capture20160305124304198

Ensuite, réaliser un clic-droit sur la zone “unllocated” et choisir “New”

capture20160305124615569

Sélectionner le menu “File system” et choisir “linux-swap”

capture20160305124847712

capture20160305125024381

capture20160305125105895

Dans la zone “New size” entrer la valeur 2048 – Puis cliquer sur le bouton “Add” – Pour rappel, la partition de swap sert de zone tampon si votre espace en mémoire vive est saturé, pour un poste de travail une valeur à 2Go est largement suffisante

capture20160305130011535

Réaliser à nouveau un clic-droit sur la zone “Unallocated”, choisir New

capture20160305131520143

Laisser les valeurs par défaut: Pour “File system”, laisser “ext4” et laisser la taille maximum possible au niveau de l’attribut “New size” ; puis cliquer le bouton “Add” – La partition ext4 prendra donc l’intégralité du restant sur le disque. Pour rappel, la partition ext4 sert à stocker les fichiers ou les répertoires du systèmes et des applications

capture20160305131808047

Au final, vous devez obtenir quelque chose qui ressemble à ceci:

capture20160305135031526

Cliquer ensuite sur la coche verte à droite de la barre d’outils afin de formater les différentes partitions

capture20160305135142166

Cliquer sur le bouton “Apply”

capture20160305135251889

A la fin de l’opération de formatage, vous devez obtenir le message “All operations successfully completed”

capture20160305135348272

Cliquer sur le bouton “Close”

Aller dans le menu “GParted” de l’utilitaire de partition et choisir la fonction “Quit”

capture20160305135649348

Vous revenez alors à l’utilitaire d’installation. Sélectioner la partition “swap” puis cliquer sur le bouton “Assign as swap partition”

capture20160305135838294

Sélectionner la partition “ext4” puis cliquer sur le bouton “Assign as root partition ext4”

capture20160305140120348

Puis cliquer le bouton “Next”

capture20160305140350262

Choisir la TimeZone puis cliquer sur le bouton “Next”

capture20160305140448573

Rajouter au moins un utilisateur qui pourra se connecter au système une fois l’installation terminée – cliquer le bouton [+] et rajouter autant d’utilisateurs que désiré puis cliquer sur le bouton “Next”

capture20160305140812465

capture20160305141105156

capture20160305141148729

Fournir un nom (hostname) qui permettra d’identifier le système sur le réseau – Activer la fonction “Should we install a boot loader on ths computer ?” en cliquant sur la coche – Cliquer sur le bouton “Next”

capture20160305141427214

Vous arrivez ensuite à un écran présentant le récapitulatif de l’ensemble des paramètres que vous avez choisis. Vérifier les paramètres et cliquer sur le bouton “Next”

capture20160305141707741

L’installation de l’OS Solus 1.1 sur le système de fichiers commence

capture20160305141907985

A la fin du procesus d’installation, cliquer sur la croix rouge en haut à droite de la fenêtre – puis déclencher un redémarrage du système après installation

capture20160305142710594

Le système redémarre

capture20160305143248700

L’écran d’accueil avec la mire de login apparait – par défaut l’utilisateur créé pendant le processus d’installation est présent  il suffit alors de renseigner le mot de passe et de tester ce nouvel OS plein de promesses !

capture20160305143512570

capture20160305144316504

Webinaire sur l’intégration des MacOS X dans Active Directory

J’ai dernièrement réalisé un webinaire sur la thématique de l’intégration des machines MacOS X dans Active Directory pour le compte de la société Cerberis. Nous avons pris en exemple l’intégration via les technologies Centrify avec le mode AutoZone de manière à simplifier l’intégration et l’accès des utilisateurs sur les systèmes. La fin du Webinaire comporte une démonstration avec des GPOs appliquées sur les MacOS, la relation entre les comptes AD et l’authentification sur les postes MacOS X et encore la migration des comptes locaux vers des comptes Active Directory afin de conserver l’environnement utilisateur d’un compte local après migration vers un compte AD.

Voici le webinaire:

SCCM supporte maintenant El Capitan (Mac OS X 10.11)

os-x-el-capitan

 

En direct du blog de l’équipe produit System Center Configuration Manager, SCCM supporte maintenant El Capitan – voir ceci: http://blogs.technet.com/b/configmgrteam/archive/2016/01/13/support-for-mac-os-x-10-11-in-configuration-manager.aspx

Vous pouvez consulter la page des téléchargements pour les clients SCCM hors Microsoft (Mac, Unix et Linux) ici: Clients SCCM hors Microsoft

 

 

Intégration Unix & Linux dans Active Directory: Quelle type de zone Centrify utiliser ?

 

Dernièrement un client m’a demandé quel était le meilleur choix en termes de zones Centrify – quel type de zone doit on privilégier ?

La question est intéressante, car la “zone Centrify” est un élément important d’un design d’intégration UNIX/Linux dans Active Directory.

Comme d’habitude, il n’y a pas de réponse absolue, s’il existe plusieurs types de zones, c’est que certaines situations impliquent un type de zone et d’autres un autre type… évidement…

Rappel sur la notion de zone

Une zone Centrify représente ce que j’appelle personnellement un “ilot identitaire” – les zones servent globalement aux situations suivantes:

– Résultat de migration depuis différents ilots identitaires existants (plusieurs serveurs NIS, des serveurs LDAP, voir des fichiers passwd locaux depuis chaque système) – Ceci permettant notamment de gérer la problématique de collision d’UIDs/GIDs qui est LE gros problème rencontré par des entreprises voulant migrer vers un annuaire unique

– Règles de gouvernance: les zones permettent de ségréguer la gouvernance de différents ensembles de serveurs Unix, Linux ou Windows ou des Workstations Linux ou MacOS: si des équipes d’administrateurs IT différentes gèrent différents périmètres, les zones peuvent aider à encadrer tout cela

– Règles d’accès: même si il est possible de gérer les règles d’accès des utilisateurs aux différents systèmes, c’est à dire, « qui a le droit de se connecter sur tel système » de plusieurs manières différentes (GPOs, Rôles, pam.deny, pam.allow, etc.) les zones Centrify permettent rapidement et facilement de définir le « qui a a accès à quoi »

– Le reporting: il est extrêmement facile de générer des reports par zone, indiquant facilement le “qui a accès à quoi” en termes de systèmes – extrêmement efficace pour des audits

Pour une zone donnée, il est très simple de définir des attributs POSIX pour un utilisateur Active Directory, et bien sur il est possible de définir des jeux d’attributs POSIC différents par zone pour un même individu:

Centrify_zone

 

Les différents types de zones

Il existe 7 types de zones Centrify:

(0) AutoZone (nous ne le traiterons pas dans cet article, dans la vraie vie, ceci ne concerne que les workstations sous MacOS)

(1) SFU-compatible zones, version 3.5
(2) SFU-compatible zones, version 4.0
(3) Classic Centrify zones, 2.x, 3.x, and 4.x
(4) Classic RFC 2307-compatible zones
(5) Hierarchical Centrify zones, 5.x
(6) Hierarchical RFC 2307-compatible zones

 

Les zones dites “SFU-compatible” (1)(2) permettaient la compatibilité avec le schéma SFU exploité par Microsoft dans Active Directory à une certaine époque, autant dire que vu le “bazard” que constitue SFU en terme de compatibilité et de standard, peu de clients se sont aventuré dans cette voie…

Les zones “Classic” (3)(4) représentent l’ancienne famille de zone Centrify, à cette époque, les zones étaient “à plat”, c’est à dire non-hiérarchiques – c’était déjà très bien, mais cela obligeait à reproduire toutes les configurations communes aux différentes zones dans chacune des zones, de façon individuel et donc sans gestion centralisée – beaucoup de clients utilisent encore ce modèle car ils n’ont pas migré vers le modèle hiérarchique.

Les zones “Hierarchical” permettent d’avoir une arborescence de zones, avec un héritage descendant au niveau des profils POSIX. Cela permet notamment de définir une zone dite Parent avec l’ensemble des UIDs Corporate voulus et de définir des zones enfants avec uniquement les exceptions/différences par rapport aux profils POSIX définis dans la zone Parent. C’est donc bien évidement le meilleur choix, même dans le cas d’une architecture simpliste (dans ce cas on ne créera qu’une seule zone parent).

La zone “Hierarchical RFC 2307-compatible”

Avec la nouvelle version de Centrify Server Suite, le format de zone par défaut lorsque l’on créé une zone est le format: Hierarchical RFC 2307-compatible – l’avantage de ce format est que les attributs POSIX rattachés au ServiceConnectionPoint représentant le profil Unix de l’utilisateur dans la zone est “proprement” renseigné dans des attributs particuliers, permettant des requêtes LDAP facilitées et surtout une gestion par un outil IAM externe extrêmement simplifié.

RFC2307

On voit ici par exemple que l’attribut POSIX uidNumber est un attribut à part entière dans l’annuaire Active Directory.

Cette approche simplifie la manipulation des profils Unix depuis un browser LDAP:

LDAP_serviceconnectionpoint

serviceconnectionpôint

Merci pour ce client, je n’avais jamais pensé faire un article sur ce sujet ! N’hésitez pas à me contacter pour plus précision.

TOP 100 des blogs anglophones sur la cyber-sécurité

 

top-cyber-security-blogs

 

Un article intéressant avec un recensement des différents blogs anglophones dans le domaine de la cyber-sécurité.

Bien sûr, c’est un peu subjectif, mais c’est une liste intéressante pour quelqu’un voulant se documenter sur le sujet.

La liste est accessible [ ICI ]

Pour ma part, le top-five serait celui-ci:

http://www.darkreading.com/ – blog généraliste sur la cyber-sécurité

https://googleonlinesecurity.blogspot.fr/ – le blog de google, bien sur très orienté technologie Google, mais pas que – traite d’Internet en général

http://www.net-security.org/ – un blog historique, généraliste

https://blog.malwarebytes.org/ – le blog de malwarebytes, très orienté malware forcément, mais très bien documenté

https://blogs.technet.microsoft.com/mmpc/ – le blog de Microsoft sur les malwares, souvent très interressant et souvent mise à jour

Grosse faille de sécurité (grub2) sur les systèmes Linux actuellement en production !

 

Une très grosse faille de sécurité a été mise en evidence sur les systèmes Linux utilisant Grub.

Pour être plus précis il s’agit de la version Grub2 et les versions touchées sont comprises entre la version 1.98 et 2.02. Plus d’information sur Grub2 ici: http://www.linuxpedia.fr/doku.php/expert/grub2

Grub2 est un boot loader utilisé par la majorité des systèmes Linux, ce boot loader intègre un mode particulier, le mode “grub rescue” – Il s’avère que ce mode st accessible simplement en executant la marche suivante:

– démarrage de l’OS (pas en mode graphique, en mode tty1)

– vous arrivez à la mire de login

– vous appuyez 28 fois sur la touche “retour arrière”

– et c’est magique, vous vous retrouvez dans le mode “grab rescue shell” vous permettant d’avoir un accès sans autentification au système

hack-linux-grub-password

Les différentes distributions Linux ont publié un correctif pour cette faille. (voir aussi ici http://git.savannah.gnu.org/cgit/grub.git/commit/)

Pour vérifier la version de grub2 que vous utilisez, il suffit d’éxécuter (debian/ubuntu): ‘grub-install –version’

grub2_version

Cette “mésaventure” nous indique à quel point il est important de:

[1] – Protéger l’accès physique aux machines

[2] – D’avoir un système de protection au boot (BIOS password, loader sécurisé, etc.)

Plus d’information sur la faille sur ces articles:

http://www.securityweek.com/password-bypass-flaw-found-grub2-linux-bootloader

http://thehackernews.com/2015/12/hack-linux-grub-password.html

Installation de Centrify Workstation for Mac 2016 sur EL CAPITAN (OSX 10.11) [Part 3/4] – Quelques manipulations après l’installation de l’agent Centrify

Installation de Centrify Workstation for Mac 2016 sur EL CAPITAN (OSX 10.11) [Part 3/4] – Quelques manipulations après l’installation de l’agent Centrify.

Lors de l’article précédent, nous avons installé l’agent Centrify sur une machine MacOS X afin que celle-ci bénéficie d’une véritable intégration à Active DIrectory – cad une intégration basée sur Kerberos et LDAP permettant également l’application de GPOs sur les systèmes MacOS, et non pas une intégration basée sur Samba.

Nous allons maintenant faire quelques paramétrages supplémentaires dans la première partie de cet article, puis nous traiterons la gestion des comptes locaux existants avant la migration dans la deuxième partie de cet article.

# Nous allons maintenant faire quelques vérifications et manipulations afin de parfaire cette installation

[1] Déplacement du compte machine de la machine MacOS X

Comme nous n’avons spécifié dans quelle UO créer le compte machine, celui-ci s’est créé dans le conteneur par défaut, à savoir « computers »:

clip_image002

Pour information, il est possible que votre administrateur Active Directory est défini un autre conteneur par défaut, mais dans la plupart des cas, il s’agit du conteneur « computers ».

Nous allons maintenant déplacer le compte ordinateur « ELCAPITAN » dans l’UO que nous avons prévue à cet effet au tout début, l’UO CENTRIFY/WORKSTATIONS:

clip_image004

[2] Vérification des informations dans l’annuaire

Réaliser un clic-droit sur le compte machine et choisir « Propriétés »

clip_image006

Vous pouvez parcourir les différents onglets afin d’avoir des informations sur le compte machine, la version de l’OS, la version de l’agent Centrify installée, etc.

clip_image008

Il est également possible de vérifier le type de zone Centrify rejointe, dans notre exemple, nous avons choisi le mode AutoZone qui permet de s’affranchir de la gestion des UIDs et du contrôle d’accès. Dans ce mode, les UIDs sont générés automatiquement par un dérivé du SID utilisateur, les UIDs sont gérés localement par l’agent, il n’y a pas d’UIDs stockés coté Active Directory – ce mode est tout à fait particulier et convient uniquement aux workstations, et je dirais même uniquement aux workstations MacOS.

En utilisant ce mode, tous les utilisateurs Active Directory peuvent ouvrir une session sur le poste MacOS (à moins que localement sur le MacOS on est spécifié le contraire dans le gestionnaire de login des Paramètres Systèmes – ou encore – il est possible d’utiliser le fichier de configuration centrifydc.conf en jouant sur les attributs pam.allow.users et pam.allow.groups ), il n’y a pas besoin de de donner le droit de ‘login » sur la machine, ceci est automatique pour tous les comptes utilisateurs présents dans Active Directory.

clip_image010

Il est également possible de constater via l’éditeur d’attributs, certaines propriétés avancées du compte machine, comme par exemple les différents servicePrincipalName qui seront utiles au protocole kerberos:

clip_image012

[3] Vérification des informations via l’outil Centrify DirectManage AccessManager

Lancer l’outil de gestion Centrify:

clip_image014

Il est facile de constater l’existence d’une nouvelle zone « Auto Zone » et de voir qu’elle contient un compte machine. Il est aussi possible de constater qu’il n’y a aucun moyen de gestion directe sur les droits d’accès ou sur la gestion des UIDs / GIDs comme il est possible via une zone Standard:

clip_image016

Comparaison avec une zone standard:

clip_image018

Pour bien comprendre les différences entre une Auto Zone et une Zone Standard, je vous conseille de consulter cette vidéo :

 

# Utilisation de comptes utilisateurs au niveau de machine MacOS X : Nous allons maintenant explorer les différentes possibilités pour utiliser les comptes utilisateurs sur la machine MacOS X

[1] Utilisation d’un compte local existant avant l’installation de l’agent

Il est bien sur possible de continuer à utiliser des comptes locaux, par exemple, nous avions un compte local « florent » qui est présent sur le MacOS X dans la base de comptes locale :

clip_image020

Par exemple, nous avons sur le bureau de cet utilisateur local quelques fichiers :

clip_image022

Si nous vérifions l’UID utilisé par le compte, nous constatons un UID local, qui est dans exemple 502:

clip_image024

[2] Utilisation d’un compte Active Directory sans lien avec la base de compte locale

Dans notre annuaire, nous avons par exemple un utilisateur « luc » qui n’existe pas dans la base de comptes locale :

clip_image026

il est possible d’utiliser ce compte et le mot de passe Active Directory pour se connecter sur la machine MacOS X:

clip_image028

Il est facile de constater que l’UID utilisé est un dérivé du SID du compte Active Directory généré par l’agent Centrify lui-même :

clip_image030

On peut constater la même chose au niveau de l’utilitaire « Users & Groups » dans les Préférences Système:

clip_image032

[3] Alignement d’un compte local existant avec un compte Active Directory : l’idée est ici de mapper un compte local existant avant la migration vers Centrify et l’installation de l’agent pour utiliser un compte utilisateur Active Directory le remplaçant tout en conservant le profil (/home/) de l’utilisateur local existant – cette manipulation est une opération très courante si vos machines MacOS X étaient déjà utilisées

Dans notre exemple, nous avons un compte local « dark »:

clip_image034

Personnalisons le bureau de cet utilisateur pour bien le repérer par la suite :

clip_image036

Cet utilisateur a un UID local, ici 502 :

clip_image038

Maintenant il faut créer un utilisateur avec le même login au niveau d’Active Directory :

clip_image040

Maintenant, reconnectons-nous sur le poste MacOS avec le compte local « dark », à ce stade l’agent Centrify vérifie s’il y a un compte équivalent côté Active Directory, ce qui est le cas et affiche le message suivant :

clip_image042

Cliquer simplement sur OK

Nous allons maintenant aligner les deux comptes en mappant le compte local avec le compte Active Directory et ce sans perdre les propriétés locales du compte existant.

Tout d’abord il faut s’authentifier sur la machine MacOS X avec un autre compte que le compte à aligner, par exemple le compte Florent puis il faut se rendre dans les Préférences Systèmes, puis dans les propriétés de l’agent Centrify :

clip_image044

Débloquer la configuration en cliquant sur le cadenas en bas à gauche et renseigner un compte avec des pouvoirs sur cette machine :

clip_image046

Puis sélectionner l’onglet « Account Migration » – ensuite sélectionner le compte à aligner avec le compte Active Directory, dans notre exemple il s’agit du compte « dark » et cliquer sur « Link »:

clip_image048

Un message d’avertissement apparait alors, cliquer sur OK :

clip_image050

Ce message est normal, il indique simplement que l’agent va supprimer le compte local (en fait il supprime l’entrée de ce compte dans l’index provenant de la liste du pointeur des comptes locaux OS X), pas de panique, cette manipulation ne supprime le profil local de l’utilisateur situé dans /users/ – cela va seulement supprimer l’existence du compte utilisateur local tout en conservant les données inhérentes au profil qui est conservé.

Automatiquement le mappage sur le compte Active Directory se réalise (basé sur le username), il faut alors cliquer sur « Apply »:

clip_image052

A la fin du processus, les deux comptes sont maintenant liés :

clip_image054

Fermer la session administrateur.

Maintenant, la mire de login ne propose plus le compte local « dark »:

clip_image056

Nous allons utiliser le login réseau et nous utiliserons le compte Active Directory « dark » pour se connecter sur la machine MacOS X:

clip_image058

Un message peut apparaitre vous demandant de mettre à jour la « keychain » du mot de passe – il faut alors choisir « update keychain » et renseigner votre ancien mot de passe ou tout simplement recréer une « keychain » pour le nouveau mot de passe si vous ne vous souvenez plus de votre ancien mot de passe local.

Comme convenu, nous avons conservé le profil utilisateur du compte local (/users/dark) mais il s’agit bien de l’utilisateur Active Directory avec un UID différent provenant du dérivé du SID compte utilisateur Active Directory :

clip_image060

A ce stade, l’utilisateur « dark » est maintenant capable d’utiliser sa machine MacOS X exactement comme avant, avec son bureau, ses raccourcis, etc. mais en bénéficiant de son compte Active Directory.

Dans le prochain et dernier article de cette série consacrée à MacOS X et Centrify, nous explorerons quelques possibilités en termes de GPOs Active Directory appliquées à MacOS X grâce aux technologies Centrify.

Installation de Centrify Workstation for Mac 2016 sur EL CAPITAN (MacOS X 10.11) [Part 2/4] – Installation de l’agent Centrify

Installation de Centrify Workstation for Mac 2016 sur EL CAPITAN (MacOS X 10.11) [Part 2/4] – Installation de l’agent Centrify.

Lors de l’article précédent, nous avons préparé l’environnement, maintenant tout est prêt et le package DMG est sur le bureau d’un compte local MacOS X avec des pouvoirs d’administrateur :

clip_image002

La dernière des choses à vérifier est que le MacOS X n’est pas relié à Active Directory avec le plug-in Active Directory natif de MacOS X, ceci est très important. Pour vérifier, choisir l’option Utilisateurs & Groupes / Users & Groups dans les préférences systèmes :

clip_image004

Ici, il n’y pas de domaine joint, c’est donc parfait :

clip_image006

Passons maintenant au choses sérieuses…

[1] Vérification de l’environnement grâce à ADCheck

Le package DMG contient un outil de vérification de l’environnement avant installation de l’agent, il faut donc ouvrir l’image DMG:

clip_image008

Et choisir l’icône AD Check au lancement d’AD Check, l’assistant vous demande le nom de domaine du domaine que vous souhaitez rejoindre afin de faire les vérification, dans mon exemple, le nom de domaine est demo.local:

clip_image010

Puis cliquer sur le bouton bleu AD Check

clip_image012

clip_image014

Pour que la future installation se déroule sans encombre, il faut que vous n’ayez aucun "Failed" dans la liste des résultats aux tests – par exemple, ici, l’assistant AD Check m’indique que un des serveurs DNS que j’utilise sur ma machine ne gère pas le nom de domaine demo.local – nous allons donc l’enlever de la configuration DNS et refaire les test AD Check:

clip_image016

Ça y est, tout va bien !

[2] – Installation de l’agent et rejoindre le domaine AD

Lancer le package pour l’installation de l’agent Centrify:

clip_image018

Choisir "Continue":

clip_image020

Puis à nouveau sur "Continue":

clip_image022

Puis, après avoir lu le Software License Agreement, à nouveau sur "Continue":

clip_image024

Puis sur "Agree":

clip_image026

Puis sur "Install":

clip_image028

Indiquer le mot de passe de l’administrateur local (ici, le mot de passe pour Florent) et appuyer sur "Install Software":

clip_image030

Le processus d’installation de l’agent se poursuit alors :

clip_image032

A la fin du processus, choisir l’option "Launch centrify Join Assistant" (sélectionnée par défaut) et choisir "Continue":

clip_image034

La fenêtre de l’installateur indique que tout s’est bien déroulé :

clip_image036

Et une nouvelle fenêtre apparait pour lancer l’assistant AD JOIN, cliquer sur "Continue":

clip_image038

Indiquer le mot de passe de l’administrateur local (ici, l’administrateur local est Florent) et cliquer sur OK:

clip_image040

Indiquer alors le nom de domaine du domaine AD à rejoindre (ici demo.local), un compte administrateur AD qui a le droit d’écrire dans AD (à minima dans les UOs que vous avez créé dans l’article précèdent) ainsi que le mot de passe de ce compte d’administration AD, puis cliquer sur "Continue":

clip_image042

Indiquer les options pour rejoindre le domaine, vous pouvez garder toutes les options par défaut – pour des machines MacOS, je vous conseille de garder "Auto" pour le "Licensed Mode", cela vous permet de ne pas avoir à gérer les UIDs pour les comptes utilisateurs, par défaut dans ce mode, les UIDs générés dans la Zone Centrify seront un dérivé du SID utilisateur AD – vous pourrez ensuite aligner les UIDs générés dans cette zone avec les comptes utilisateurs existants au niveau de l’OS MacOS X via un outil fourni par centrify.

A noter que le premier ordinateur MacOS qui sera joint à AD avec le mode "Auto" va automatiquement créer la zone "Auto" au niveau de l’AD lui-même, contrairement aux systèmes Unix et Linux qui sont généralement joints dans des zones « standards », il n’y a pas besoin ici de créer la zone en amont de la première jointure au domaine.

Puis cliquer sur "Join"

clip_image044

Indiquer le mot de passe de l’administrateur local (ici, l’administrateur local est Florent) et cliquer sur OK:

clip_image045

L’assistant indique que la machine est en train de rejoindre le domaine AD:

clip_image047

Tout s’est bien déroulé, cliquer sur "Done":

clip_image049

Redémarrer le poste MacOS.

[3] – Première connexion avec un compte utilisateur AD

Sur la fenêtre de login du MacOS X, vosu trouverez par défaut les comptes locaux existants (ici Florent) – mais maintenant que vous avez joint la machine à AD, vous pourrez accéder à une liste d’utilisateurs provenant d’AD en cliquant sur "Other…"

clip_image051

Par exemple, nous avons un compte utilisateur existant dans AD qui est Luc:

clip_image053

Nous allons utiliser ce compte et son mot de passe AD pour nous connecter sur la machine MacOS X:

clip_image055

Un nouveau bureau pour Luc apparait :

clip_image057

Si nous utilisons une fenêtre de Terminal, et que l’on taper la commande ‘id’ on obtient les informations suivantes, l’UID a été automatiquement généré pour l’utilisateur :

clip_image059

Toujours dans le terminal, la commande ‘adinfo’ nous permet d’obtenir des informations sur la connectivité à AD:

clip_image061

Ça y est, c’est officiel, notre machine MacOS X EL CAPITAN a rejoint AD et peut utiliser tous les services AD.

Dans les prochains articles, nous allons explorer quelques pistes d’améliorations du paramétrage de base, utiliser quelques outils d’administration et nous allons explorer les GPOs applicables aux systèmes MacOS X.

Installation de Centrify Workstation for Mac 2016 sur EL CAPITAN (MacOS X 10.11) [Part 1/4] – Préparation de l’environnement pour installation de l’agent Centrify

 

Installation de Centrify Workstation for Mac 2016 sur EL CAPITAN (MacOS X 10.11) [Part 1/4] – Préparation de l’environnement pour installation de l’agent Centrify.

La version 2016 de la Centrify Workstation for Mac est sortie courant Décembre 2015. L’agent livré avec cette version (CentrifyDC-5.3.0-mac10.9.dmg) est directement compatible avec la version OSX 10.11 (EL CAPITAN).

A noter, cette version de l’agent n’est plus compatible avec les versions 10.8.x d’OSX, pour supporter ces anciennes versions, il faut utiliser les agents fournis avec les anciennes versions de la Centrify Workstation for Mac (version 2015.1 ou version 2015 par exemple).

A savoir, le CD Centrify 2016 qui contient les agents ne contient que la version TGZ du paquet de l’agent Centrify. Une fois le paquet TGZ extrait, celui-ci contient un paquet TAR qui contient les éléments suivants :

clip_image002

Le fichier CentrifyDC-5.3.0-mac10.9.dmg est un disque image pour Mac OS X et contenant les éléments suivants :

• AD Check.app: une application graphique pour réaliser une vérification de l’environnement avant de lancer l’installation réelle de l’agent (ADCHECK)

• Un Guide d’utilisation pour les Administrateurs Mac OS X (Admin Guide for Mac OS X.pdf)

• Un installeur graphique de l’agent (CentrifyDC-5.3.0-x86_64.pkg) valide pour Mac OS 10.0.x, 10.10.x et 10.11

• Un Guide de prise en main rapide (Quick Start Guide for Mac OS X.pdf)

• Le document de « Release Notes » pour cette version de l’agent (Release Notes for Mac OS X.pdf)

Afin de bien préparer votre environnement, vous pouvez réaliser les actions suivantes :

[1] – Créer des UOs pour ranger vos objets dans AD

Je vous conseille de créer une arborescence comme celle-ci par exemple :

clip_image004

Dans notre exemple, nous mettrons plus tard les objets des comptes machines MacOS X dans l’UO « WORKSTATIONS »

Bien évidemment, sur ces UOs, il faudra que l’administrateur MacOS X est des droits d’administration suffisant, mais cela, c’est du design AD pur et dur.

[2] – Installer les outils d’administration sur une machine Windows

Vous devez installer mes outils d’administration (suivre le guide d’installation) afin d’avoir au moins deux outils d’installés :

Centrify DirectManage – Access Manager

Centrify DirectManage – Deployment Manager

[3] Renseigner les licences

Ouvrir l’outil « DirectManage Access Manager » et rajouter les licences pour la partie Mac OS en réalisant un clic droit sur le nœud supérieur et choisir « Manage Licenses »

clip_image006

Puis renseigner la clé de licences dans l’onglet « Update » – Il faut bien saisir la clé avec les tirets. Une fois les licences validées vous devez avoir une entrée telle que : « Unix Workstation Licenses ».

[4] – Vérifier la configuration de la machine MacOS X:

Aller dans les préférences systèmes :

clip_image008

Puis choisir Network/Réseau :

clip_image010

Renseigner les éléments réseau de manière à ce que le MacOS X soit compatible avec votre plan d’adressage IP réseau, renseigner les serveurs DNS qui adressent votre nom de domaine Active Directory.

clip_image012

clip_image014

Vous pouvez aussi modifier le nom hôte de votre système MacOS, car par défaut c’est le nom qui sera utiliser pour créer l’objet ordinateur représentant votre systèmes dans Active Directory – Pour cela, aller dans Préférences systèmes, puis choisir Partage/Sharing:

clip_image016

clip_image018

Votre changement doit être reflété si vous tapez la commande hostname dans un terminal:

clip_image020

Ensuite, nous allons activer la fonction de « Remote Login » dans Partage/Sharing (Préférences Systèmes):

clip_image021

clip_image023

A ce stade, un membre des administrateurs du MacOS pourra se connecter en SSH pour notamment transférer l’agent sur la machine avant installation.

[5] – Transfert de l’agent sur la machine

Il existe de nombreux moyens de transférer le fichier dmg de l’agent, mais comme nous sommes censés être en réseau nous allons utiliser l’outil WinSCP que vous pouvez télécharger ici: http://winscp.net/eng/download.php

Installer WinSCP sur la machine qui sert à l’administration Centrify (par exemple), puis lancer WinSCP et paramétrer une session SFTP pour transférer le package Centrify – choisir un nom utilisateur qui fait partie des Administrateurs locaux du MacOS (dans notre exemple, l’utilisateur a un login « florent »:

clip_image025

Transférer ensuite le package DMG sur le bureau de florent (répertoire Desktop):

clip_image027

Le package doit alors apparaitre sur le bureau de l’utilisateur :

clip_image029

Une fois ces éléments préparés, nous allons maintenant passer à l’installation de l’agent côté Mac OS X dans le prochain article.

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 ]

Une bonne série d’articles sur la technologie de conteneurs

contenaireStanislas Quastana, architecte chez Microsoft France nous propose une série d’articles à venir sur Docker, Azure & Windows. Comme d’habitude avec Stanislas, c’est bien écrit, et surtout il a testé avant ! A lire pour tout ceux dont l’interopérabilité multiplateformes liée à la technologie Docker intéresse.

Le premier article est disponible [ICI]

Vidéo de présentation du nouvel outil de gestion des privilèges intégré à MIM

Dans un article précédent, j’ai décrit rapidement le nouvel outil de gestion des privilèges (PAM) qui sera intégré dans la nouvelle version de FIM, c’est à dire MIM (Microsoft Identity Manager). Vous trouverez ici une vidéo de présentation de ce nouvel outil avec un exemple sur une réinitialisation de mot de passe. L’action est réalisée depuis un compte à pouvoir, pourtant même ce compte nécessite de réaliser une demande via le portail de requête pour les élévation de privilèges. La demande pourrait très bien être aussi liée à un workflow pour une demande d’approbation. Plus de contenu à venir sur ces nouvelles fonctions, au fur et à mesure que les informations seront publique et que les MVPs FIM/MIM auront le droit de communiquer dessus 😉

 

Microsoft prépare un outil de gestion des privilèges basé sur MIM, MFA et Kerberos

skullComme vous le savez, la prochaine version de Forefront Identity Manager (FIM) s’appellera Microsoft Identity Manager (MIM) et sortira vraisemblablement courant 2015 (voir les annonces de roadmap ici) . Cette nouvelle version apportera une nouveauté extrêmement intéressante pour les grandes organisations: un bastion pour la gestion des privilèges.

Pour faire simple, le principe est la création d’une forêt bastion (avec des DC Windows 2012R2 ou vNext), la création d’un trust (la forêt de production approuve la forêt bastion), la création des groupes AD d’administration (ceux dont l’appartenance permet l’exécution de commande à privilège) dans la forêt bastion (avec le même SID que les groupes qui sont dans la forêt de production), et le « vidage » des groupes d’administration dans la forêt de production.

PAMFIM

Ensuite, un administrateur peut faire une demande via MIM ou via un service web utilisant les APIs de MIM afin de « devenir » administrateur d’une partie du SI pendant un temps donné. La solution est capable de gérer l’appartenance temporaire à ce groupe, fournie du reporting (bon, ok, c’est un peu de la bricole pour l’instant le côté reporting…), l’intégration avec MFA pour l’authentification à deux facteurs lors d’une demande particulière et le pilotage du TGT du ticket kerberos pour être certain que l’administrateur ne pourra pas bénéficié de l’appartenance au groupe plus longtemps que prévu.

Voici un schéma résumant la fonction:

MIM-PAM

Il reste à vérifier avec le temps comment les entreprises vont appréhender cette nouvelle fonction et comment elles vont accepter le fait d’avoir à rajouter une forêt bastion pour gérer les comptes à privilège.

 

 

Comparatif DirSync vs Azure AD Sync vs Azure AD Connect

windows_azure_smallDeuxième article remarquable sur le blog de Maxime: un article de synthèse réalisant un comparatif des trois solutions de « synchronisation » ou de « mise à jour des informations » entre les données locales et le service Azure AD (service nécessaire notamment à l’utilisation d’Office365)

Le problème de ce type d’article est le côté « périssable » de l’image instantanée des fonctions décrites, donc peu de personnes font l’effort de les écrire, encore merci à Maxime pour son travail de synthèse.

L’article est accessible [ ici ]