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 !

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 ]

 

 

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…

 

 

 

 

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.

 

 

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:

 

 

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.

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 ]

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:

Est ce que freeIPA est l’Active Directory de RedHat ?

redhat_freeIPA Apparu il y a quelques mois en version 1.0, la suite freeIPA est passée totalement inaperçue dans le monde de la gestion des identités et des accès. Et pourtant, la version 2.0 (pour l’instant en beta) propose une liste de fonctions qui rappelle fortement ce que propose Microsoft au travers d’Active Directory:

  • Service LDAP (anciennement Fedora Directory Server)
  • Service MIT Kerberos
  • Service NTP
  • Service DNS
  • Service d’autorité de certification
  • Interface d’administration en mode web ou en ligne de commandes
  • Gestion des comptes utilisateurs et des groupes

HighLevelArchV2

Avouez que la ressemblance est troublante…

J’ai pour habitude de dire qu’Active Directory, c’est trois éléments: [1] Un service LDAP [2] Un service Kerberos [3] Un ensemble d’autres choses…  Le tout proposé avec des outils d’administration et de gestion intégrés.

freeIPA 2.0 proposera en Mars 2011 des outils de synchronisation avec Active Directory, à voir la comparaison avec un méta-annuaire.

Mais, le véritable chalenge sera comme souvent l’intégration des clients… Active Directory possède pour l’instant la plus grande couverture fonctionnelle de clients qui puisse exister: Windows, Mac, Unix, Linux, tout est possible ! Il sera donc très important de tester l’intégration des clients lors du test éventuel de freeIPA en version 2.0.

Sortie de la version 2.1 pendant l’été 2011.

Appel à participation pour la conférence Européenne sur AFS & Kerberos

ensemble Les 13, 14 et 15 Septembre 2010, l’Université de West Bohemia, en République Czech hébergera la conférence Européenne sur AFS et Kerberos.

L’université réalise un appel à participation pour d’éventuels orateurs et un appel à participation pour des sponsors. Il est possible d’obtenir des informations complémentaires en envoyant un email à afs2010@civ.zcu.cz

Des informations sur AFS peuvent notamment être trouvées sur le site d’Open AFS.

Réunion de la CADIM (Communauté Active Directory & Identity Management) le 17 mars 2010 dans les locaux de Microsoft France

cadim_logo

La prochaine réunion de la CADIM aura lieu le 17 Mars 2010  dans les nouveaux locaux de Microsoft France, à Issy-les-Moulineaux – Cette prochaine réunion sera l’occasion d’évoquer les nouveautés produit de chez Microsoft sur les annuaires et la gestion des identités:

  • FIM 2010  – les nouveautés sur le portail utilisateurs et le système de Workflow
  • Utilisation de Kerberos en tant que système de Single Sign On (SSP) à l’ensemble des systèmes et des applications
  • Couplage de la gestion des accès physique (accès aux bâtiments) et logique (gestion de l’ouverture de session Windows) via la solution HID on the Desktop

Comme d’habitude, les démonstrations et l’interaction entre les personnes présentes seront privilégiées. Venez découvrir des éléments techniques que vous ne verrez QUE dans le cadre de la communauté  CADIM !

***   DEBUT DE LA REUNION A 14H – VOUS POUVEZ VOUS INSCRIRE A CETTE REUNION DU 17 MARS 2010   ***

[ INSCRIPTION ICI ]

Vulnérabilité de Kerberos sous Windows: Bulletin de sécurité Microsoft MS10-014

skullAttention !!! Une vulnérabilité dans Kerberos due à un traitement incorrect de certaines requêtes permet à une personne mal intentionnée de provoquer un déni de service sur un contrôleur de domaine Windows. Il s’agit bien évidemment d’une faille majeure qu’il faut absolument corriger.

La faille impacte les systèmes d’exploitation suivants:

– Windows 2000 Server Service Pack 4

– Windows Server 2003 Service Pack 2

– Windows Server 2003 Édition x64 Service Pack 2

– Windows Server 2003 avec SP2 pour systèmes Itanium

– Windows Server 2008 pour systèmes 32 bits etWindows Server 2008 pour systèmes 32 bits Service Pack 2

– Windows Server 2008 pour systèmes x64 et Windows Server 2008 pour systèmes x64 Service Pack 2

Microsoft délivre le correctif de sécurité MS10-014 pour corriger le problème, à appliquer de toute urgence.

Sortie de FreeBSD 8.0 – c’est du tout bon !

FreeBSD_LOGOSortie officielle de FreeBSD 8.0.

Avec l’arrivée de Windows 7 et de FreeBSD 8.0, l’année est plutôt exceptionnelle en ce qui concerne les mises à jour des systèmes d’exploitation !!! Franchement, de la même façon que je suis vraiment épaté par Windows 7, j’avoue être super fan de FreeBSD 8.0; comme quoi, avec un peu d’ouverture d’esprit, on trouve des choses intéressante de part et d ‘autre…

Au rayon des nouveautés:

  • Support des processeurs x86, 64bits, Itanium, PowerPC et SPARC
  • Jails V2, un outil de gestion des processus en environnement multiprocesseurs
  • Système de fichiers ZFS 13
  • ULE 3.0 comme nouvelle version de l’ordonnanceur système
  • Support amélioré de NFS en ce qui concerne Kerberos

Pour télécharger cette nouvelle mouture direction le site FTP de FreeBSD.org

Les présentations de la conférence Kerberos 2009 sont disponibles

logo_kerberos_consortium Comme chaque année, le « Consortium Kerberos », géré en grande partie par le MIT, a organisé une grande conférence sur le protocole kerberos et ses évolutions. Des pointures mondiales telles que Kim Cameron étaient présentes et ont réalisé des démonstrations de grande qualité. Ce fut également l’occasion de révéler les nouveauté de la version 1.8 de la libraire Kerberos.  La présentation sur la cohabitation OpenLDAP/royaume Kerberos est particulièrement intérressante car elle démontre bien à quel point il est complexe d’allier les deux systèmes.

Pour visualiser ou télécharger les présentations: http://www.kerberos.org/events/2009conf/ – les nouveautés de la version 1.8 de la libraire kerberos sont présentées sur le WiKi du Kerberos consortium: http://k5wiki.kerberos.org/wiki/Release_1.8

Sortie de la Release 1.7 de la librairie Kerberos 5

kerberos-prot-logoL’équipe du MIT Kerberos a annoncé la disponibilité de la version 5 1.7 de la librairie Kerberos. Cette nouvelle version corrige un certain nombre de bugs, notamment pour les plate-formes Windows.

Pour les environnements Windows, voici la liste des modifications tel que présenté sur le site du MIT [ http://web.mit.edu/kerberos/krb5-1.7/ ]:

Compatibility with Microsoft Windows:

  • Follow client principal referrals in the client library when obtaining initial tickets.
  • KDC can issue realm referrals for service principals based on domain names.
  • Extensions supporting DCE RPC, including three-leg GSS context setup and unencapsulated GSS tokens inside SPNEGO.
  • Microsoft GSS_WrapEX, implemented using the gss_iov API, which is similar to the equivalent SSPI functionality. This is needed to support some instances of DCE RPC.
  • NTLM recognition support in GSS-API, to facilitate dropping in an NTLM implementation for improved compatibility with older releases of Microsoft Windows.
  • KDC support for principal aliases, if the back end supports them. Currently, only the LDAP back end supports aliases.
  • Support Microsoft set/change password (RFC 3244) protocol in kadmind.
  • Implement client and KDC support for GSS_C_DELEG_POLICY_FLAG, which allows a GSS application to request credential delegation only if permitted by KDC policy.

Les packages de la version 5 1.7 sont téléchargeables ici: http://web.mit.edu/kerberos/dist/index.html