Dans le premier article de notre série consacrée à ATA nous avons évoqué les fonctions globales du produit, maintenant voyons comment réaliser une installation et comment réaliser une mise à jour avec des patchs ATA sur une version existante.
Installation de Microsoft ATA
Cet article est réalisé avec la version 1.8.6645 de Microsoft ATA disponible en téléchargement sur Microsoft MSDN. Nous réaliserons ensuite une mise à jour de la version disponible sur Microsoft MSDN.
Installation du centre ATA
La première étape consiste à installer l’ATA Center sur un serveur Windows Server dédié.
Copier le contenu de l’ISO dans un répertoire sur le disque dur local et ne pas exécuter l’installation directement depuis l’ISO monté dans le système.
Lancer l’installation en lançant l’application « Microsoft ATA Center Setup ».
Je vous conseille de réaliser l’installation en langue Anglaise et de réaliser une installation sur un OS en Anglais – Microsoft ATA est supporté sur les OS Français et propose une interface applicative en Français, mais comme d’habitude, il est au final plus simple de consulter les différentes documentation en langue Anglaise :
Je commence ici une série d’articles sur Microsoft ATA. Nous allons découvrir ensemble rapidement quels sont les objectifs de Microsoft ATA, décrire l’installation et le paramétrage de base. Nous verrons ensuite comment paramétrer certaines fonctions plus avancées puis nous réaliserons des attaques de tests pour vérifier le bon fonctionnement.
Présentation de Microsoft Advanced Threat Analytics (ATA)
Microsoft Advanced Threat Analytics (ATA) est une plateforme locale qui aide à protéger votre entreprise contre plusieurs types d’attaques informatiques ciblées et de menaces internes avancées.
Microsoft ATA fournit des fonctionnalités de détection pour les différentes phases d’une attaque avancée : reconnaissance, compromission des informations d’authentification, mouvement latéral, élévation des privilèges, contrôle du domaine, etc. Les attaques avancées et les menaces internes peuvent ainsi être détectées avant de pouvoir causer des dommages dans l’organisation. Chaque type de détection correspond à un ensemble d’activités suspectes liées à la phase en question, chacune de ces activités correspondant elle-même à différents types d’attaques possibles. Les phases de la « kill-chain » où ATA fournit une détection sont mises en surbrillance dans l’image suivante :
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.
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:
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 !
Travaillant 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:
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:
# 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.
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.
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 ]
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
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…
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…
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
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.
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:
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”.
Nous allons donc utiliser les services de NIS gateway proposés par la solution Centrify pour réaliser cette prouesse technologique et fonctionnelle
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
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
Si le serveur SSH n’est pas installé, renseigner la commande suivante pour installer les packages:
Une fois que les packages SSH sont installés, démarrer le service SSH serveur
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
4/ Installation de l’agent Centrify
Vérifier que l’agent est bien dans le répertoire /tmp:
Décompresser le package de l’agent:
Lancer l’installation de l’agent:
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:
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]:
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:
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:
Le processus d’installation commence – après le processus adcheck, valider l’installation de l’agent:
L’installation se termine avec l’installation des agents Centrify:
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:
Nous allons maintenant installer le package du serveur Centrify NIS Gateway:
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.
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 »:
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:
[2] Vérification des informations dans l’annuaire
Réaliser un clic-droit sur le compte machine et choisir « Propriétés »
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.
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.
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:
[3] Vérification des informations via l’outil Centrify DirectManage AccessManager
Lancer l’outil de gestion Centrify:
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:
Comparaison avec une zone standard:
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 :
Par exemple, nous avons sur le bureau de cet utilisateur local quelques fichiers :
Si nous vérifions l’UID utilisé par le compte, nous constatons un UID local, qui est dans exemple 502:
[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 :
il est possible d’utiliser ce compte et le mot de passe Active Directory pour se connecter sur la machine MacOS X:
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 :
On peut constater la même chose au niveau de l’utilitaire « Users & Groups » dans les Préférences Système:
[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 »:
Personnalisons le bureau de cet utilisateur pour bien le repérer par la suite :
Cet utilisateur a un UID local, ici 502 :
Maintenant il faut créer un utilisateur avec le même login au niveau d’Active Directory :
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 :
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 :
Débloquer la configuration en cliquant sur le cadenas en bas à gauche et renseigner un compte avec des pouvoirs sur cette machine :
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 »:
Un message d’avertissement apparait alors, cliquer sur OK :
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 »:
A la fin du processus, les deux comptes sont maintenant liés :
Fermer la session administrateur.
Maintenant, la mire de login ne propose plus le compte local « dark »:
Nous allons utiliser le login réseau et nous utiliserons le compte Active Directory « dark » pour se connecter sur la machine MacOS X:
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 :
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.
