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 ]

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.

 

 

European AFS & Kerberos Conference 2014

afs-kerb-2014

 

 

 

 

 

 

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 ?

kerberos_noir

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

mysql_mariadbLe 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

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 !!!

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: