Identity Cosmos

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

3 janvier 2016SylvainLeave a comment

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 :

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 :

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

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:

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:

Puis cliquer sur le bouton bleu AD Check

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:

Ç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:

Choisir "Continue":

Puis à nouveau sur "Continue":

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

Puis sur "Agree":

Puis sur "Install":

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

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

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

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

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

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

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":

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"

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

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

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

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

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

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

Un nouveau bureau pour Luc apparait :

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 :

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

Ç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

2 janvier 20164 janvier 2016SylvainLeave a comment

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 :

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 :

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 »

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 :

Puis choisir Network/Réseau :

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.

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:

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

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

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 »:

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

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

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 !

16 octobre 201527 janvier 2016SylvainLeave a comment

Ç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 ]

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

17 mai 2015SylvainLeave a comment

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

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:

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.

Script to create a Kerberos Token Size Report

24 octobre 2014SylvainLeave a comment

Un excellent article reprenant les différentes sources liées à la problématique du Kerberos Token Size, à lire par tous les architectes Active Directory: http://www.jhouseconsulting.com/2013/12/20/script-to-create-a-kerberos-token-size-report-1041

European AFS & Kerberos Conference 2014

17 décembre 201319 décembre 2013SylvainLeave a comment

Les inscriptions pour la « European AFS & Kerberos Conference 2014 » sont ouvertes – Vous pouvez vous rendre [ ici ] pour plus de détails.

Cette année, les conférences feront un focus sur l’intégration Web, la correspondance avec les PKI ou encore les différentes méthodes de SSO héritées du protocole Kerberos.

Kerberos V5: comment cela fonctionne t-il ?

31 janvier 201331 janvier 2013SylvainLeave a comment

C’est tout bête, mais je relie cet article de Microsoft traitant du protocole kerberos au moins une fois par an… Il y a tout dedans, le protocole lui-même, les protocoles de chiffrement utilisés, la gestion des tickets, le contenu des tickets, l’interaction avec le LSA Windows, les relations inter-royaumes, etc… bref tout ce qu’il faut savoir quand on travaille avec kerberos dans l’environnement Active Directory.

C’est fou ce que l’on oublie rapidement 😉

Je vous conseil de le mettre en favoris, et de revenir sur cette page régulièrement, refaire une lecture, vous verrez c’est extrêmement bénéfique !

Un autre lien indispensable, le « Kerberos Survival Guide« , provenant du Technet Wiki de Microsoft – cette page est le point de départ de nombreuses réponses et de nombreuses questions…

Authentification Kerberos sur MySQL & MariaDB

30 janvier 2013SylvainLeave a comment

Le protocole Kerberos est certainement le protocole le plus adapté pour gérer l’authentification des utilisateurs sur un réseau d’entreprise. Il est relativement simple d’insérer les systèmes (au sens OS du terme) au sein de royaumes Kerberos (MIT, HEIMDAL ou Active Directory) grâce notamment à des suites logicielles gratuites comme Centrify Express.

Concernant les applications Web, idem, la méthode est relativement standardisée, notamment grâce à l’interface normalisée GSSAPI, qui permet de définir une méthode d’authentification basée sur Kerberos au niveau du module d’authentification de l’application Web elle-même. La méthode GSSAPI a notamment été normalisée pour JAVA, ce qui rend l’authentification utilisateur des applications JAVA relativement simple à implémenter et à gérer avec Kerberos.

Concernant les applications « lourdes », cela se complique un peu… Les applications propriétaires, type SAP, nécessitent généralement des modules commerciaux complémentaires, les applications « Open Source » ne sont pas toujours compatibles, néanmoins les bases de données MySQL et MariaDB sont pleinement compatibles avec une authentification Kerberos intégrée.

Le paramétrage se réalise alors au niveau des modules PAM, vous trouverez [ ici ] les explications pour MySQL, et [ ici ] les explications pour MariaDB: bonne lecture et bons tests !

Etude comparative des solutions d’intégration gratuites à Active Directory pour les systèmes Unix et Linux

16 juillet 201116 juillet 2011SylvainLeave a comment

Une étude extrêmement intéressante a été réalisée par Rodney Ruddock, consultant au sein de la société Interop Systems, qui est un cabinet d’expertise Américain spécialisé dans les études de marché techniques en ce concerne les problématiques d’interopérabilité.

Cette excellente étude compare les différentes solutions logicielles gratuites permettant d’intégrer les systèmes Unix, Linux et Mac dans Active Directory, et qui permettent aux organisations d’utiliser Active Directory comme annuaire centralisant pour les authentifications des utilisateurs quel que soit le système utilisé. cette approche apportant de nombreux avantages tels que: unicité du nom utilisateur et du mot passe utilisateur sur l’ensemble des systèmes, centralisation des logs d’authentification sur les contrôleurs de domaine AD, stratégie de politique et de complexité de mot de passe unifiée sur l’ensemble des systèmes, etc.

En substance, voila les conclusions de Rodney Ruddock dans le tableau suivant, les cases en jaune indiquant les éléments significatifs et importants selon Rodney Ruddock:

Rodney Ruddock préconisant donc Centrify Express comme la solution idéale pour l’intégration gratuite des environnements hétérogènes dans Active Directory.

L’étude complète est accessible [ ICI ]

Centrify DirectExpress: Intégrer gratuitement les machines Mac, Linux et Unix dans Active Directory !!!

31 mai 20116 juin 2011Sylvain3 Comments

Centrify propose maintenant une version gratuite permettant de déployer et gérer l’intégration des environnement Mac, Linux et Unix dans Active Directory.

Bien sur, certaines fonctions ne sont pas présentes, donc pas de possibilité ici de gérer plusieurs UIDs/GIDs, de supporter les SmartCard ou de faire des GPOs sur les systèmes (fonctions intégrées dans la version payante) – néanmoins, il est possible ici de gratuitement intégrer les systèmes hétérogènes dans Active Directory.

Il donc possible de réaliser une intégration transparente dans l’annuaire Microsoft et donc de permettre aux utilisateur d’utiliser le même mot de passe sur tous les systèmes et de profiter d’un SSO utilisateur basé sur kerberos. Cela est déjà génial !

Centrify DirectExpress est téléchargeable [ ICI ]

Si vous voulez en savoir plus sur Centrify DirectExpress avant le déploiement, vous pouvez regarder la vidéo suivante: