François Tran
Mon blog Nelite
Pour nos amis belges ne ratez pas la session Dynamic Access Control dans Windows 8 présenté par John Craddock alias Monsieur “XT Seminars” le 14 février de 17:45 à 19:00. Le modèle d’identité par revendications arrive enfin au cœur de la stratégie sécurité de la plate-forme Windows pour sa version 8 !
http://www.microsoft.com/belux/techdays/2012/SessionDetail.aspx?sessionId=202
Sinon pour les gens qui veulent voir tout de suite de quoi il en retourne, je vous conseille également de visionner cette petite vidéo de présentation de DAC via Channel9 du site MSDN (Vous pourrez également télécharger les slides correspondant à la présentation) :
http://channel9.msdn.com/events/BUILD/BUILD2011/SAC-422T
Plop,
Pour les personnes intéressées par les questions autour de la fédération d'identité, je vous conseille vivement la lecture de l'excellent guide sur l'identité basée sur les revendications dans sa seconde édition :
http://www.microsoft.com/download/en/details.aspx?id=28362 ou ici via le site MSDN : http://msdn.microsoft.com/en-us/library/ff423674.aspx
Ce guide très complet explique de façon très ludique les questions d'identité au travers de technologies à base de revendications, les mécanismes de fédération, les standards avec des scénarios à l’appui.
A noter que dans cette seconde édition, ce qui est à noter sont les chapitres supplémentaires dédiés à Sharepoint 2010 et Windows Azure ACS... Et pour ceux qui veulent mettre en application sans plus attendre c’est par ici que ça se passe : http://claimsid.codeplex.com/
Enjoy ! François. @++
Chez les clients ayant de nombreux groupes de sécurité et utilisant beaucoup l’appartenance de groupe afin de donner des droits accès, que ce soit pour des applications ou à des données partagées, vous serez certainement confrontés aux limites de taille de jeton.
Comment déceler les utilisateurs à risque ? Facilement grâce à Powershell, en utilisant tout simplement un attribut disponible sur les Global Catalog qui est “tokengroups” contenant la liste des SID des groupes, que ce soit de premier niveau ou ‘n’ niveau (groupe dans le groupe).
tokengroups sur MSDN –> http://msdn.microsoft.com/en-us/library/windows/desktop/ms680275(v=vs.85).aspx
Cela nous permet donc de retrouver le nombre groupes dans lequel l’utilisateur est embarqué.
(Get-QADUser <MyUser>).tokengroups.count
Pour aller au but de ce topic, je vous invite surtout à regarder ce post de M. Ali sur les archives du blog AD Powershell et de récupérer le script proposé :
http://blogs.msdn.com/b/adpowershell/archive/2009/09/05/token-bloat-troubleshooting-by-analyzing-group-nesting-in-ad.aspx
Ce script est bien fait et le gros bonus de ce script est le paramètre –TreeView qui permet d’avoir une représentation arborescence des groupes embarqués mais également de donner la valeur “maxnestinglevel” qui représente le nombre de niveau d’imbrication de groupes de l’utilisateurs, information pertinente.
Evidemment PS 2.0 et module AD requis pour avoir les cmdlets AD.
François. @+
Plop tout le monde,
Ci-dessous une “petite astuce” histoire de gagner des précieuses minutes quand vous travaillez à la volée sur votre active Directory, surtout quand vous n’avez pas la possibilité d’importer le module Active Directory.
Dans votre profil Powershell ($profile), il peut être sympathique de pré-charger comme variable certaines informations de votre Active Directory afin de pouvoir l’interroger plus facilement à la volée.
# Retrieve Forest Informations $Forest = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()
# retrieve Domain Informations $domainList = $forest.domains
foreach ($Domain in $domainList) { # create variable which name is current domain $ShortDomainName = ($Domain.Name).split(".")[0] New-Variable -name "$ShortDomainName" -value $Domain
# Group Policies from Current Domain $gpm = New-Object -ComObject GPMgmt.GPM $gpmConstants = $gpm.GetConstants() $gpmDomain = $gpm.GetDomain($Domain,'',$gpmConstants.UseAnyDC) $gpmSearchCriteria = $gpm.CreateSearchCriteria() $gpmAllGpos = $gpmDomain.SearchGPOs($gpmSearchCriteria)
# create variable which name is current GPO_domain New-Variable -name "GPO_$ShortDomainName" -value $gpmAllGpos }
Une fois ce bout de code chargé, vous avez la possibilité maintenant directement d’interroger votre AD via les variables :
$Forest : pour retrouver les informations relatives à votre forêt.
Par exemple si vous souhaitez retrouver certaines informations sur les subnets de vos sites AD : $forest.sites | select name,subnets,Location
$<Domain> : où <Domain> est le nom court du domaine root ou enfant cible à interroger. Chaque domaine de la forêt a une variable chargée à son nom ($domain1, $domain2, etc…)
Par exemple si vous souhaiter, retrouver les noms,IP version d'OS et site AD relatif à vos DCs: $MonDomaine.DomainControllers | select name,Ipaddress,OSVersion,SiteName
Il est intéressant également de pouvoir charger les informations GPOs de tous les domaines :
$GPO_<Domain> : où <Domain> est le nom court du domaine enfant cible à interroger
Vous n’avez plus qu’à choisir le ou les informations de votre choix.
Bonjour à tou(te)s
Comme la plupart du commun des mortels, nous sommes des utilisateurs invétérés du moteur de recherche Google pour rechercher sur la toile les informations tant désirés.
Parfois les informations se cachent dans un petit coin de page de site parmi des milliards d’autres... et trouver les critères de recherches efficaces pour caractériser votre recherche est un exercice parfois pas si facile qu’il n’y parait.
Pour les utilisateurs plus aguerris, la recherche avancée est un bon moyen de préparer votre recherche aux petits oignions:
Ce qui est intéressant de connaitre est que chacun des champ de la recherche avancée correspond à une syntaxe de recherche précise. Google nous souffle quelques un en tant qu’astuce . C’est un peu maigre, mais découvrons les ensemble !
Réjouissez vous ! Vous en avez bien plus encore mais certains sont méconnus dont voici quelques exemples :
Si vous voulez en avoir une liste plus étendue, je vous conseille le site de Google, même si ce n’est pas mis en avant, allez au chapitre 2.2 sur les “query terms”
Sinon sur le site de dumblitttleman qui synthétise très bien les syntaxes de recherche :
Sinon histoire de mentionner BING le moteur de recherche de Microsoft , voici le lien vers la référence des opérateurs avancés du MSDN
Bonne recherche !
C’est par ici pour le lien MS !! –> Bulletin
Des corrections de bugs sont inclus dans ce lot :
Mais aussi des apports de fonctionnalités intéressantes tels que :
Description
Min Value = 1000 Max Value=60000 Default value = 2000
Min Value = 1 Max Value = 10000 Default value = 16
Et également par l’ajout de compteurs de performances additionnels pour AD FS 2.0.
Enjoy !
Le billet précédent était dédiée à la compréhension générale de la fédération d’identité et l’introduction de la plate-forme GENEVA, réponse de Microsoft aux problématiques de l’identité. Celui-ci sera consacré au composant AD FS (Active Directory Federation Service) dans sa version 2.0, son architecture, sa gestion des accès par revendications et ses modèles de déploiement type.
Pour commencer, on va remonter dans l’histoire dans les années 2002 et citer quelques grandes initiatives de Microsoft dans la réflexion sur l’identité. Microsoft a depuis longtemps investi le terrain de l’identité, que ce soit par la participation à l’élaboration de standards :
Mais également par la création d’un des plus large service d’authentification au monde et à l’échelle d’Internet (.NET Passport l’ancêtre de Windows Live ID : plus de 250 millions de “Passport actifs” et plus d’1 milliards d’authentification par jour effectuées), leur permettant ainsi de développer une approche de l’identité numérique. Ces efforts et investissements importants leur ont rapportés un retour d’expérience indéniable en la matière, menant ainsi au développement des « Lois de l’identité » (disponible ici –> "Laws of Identity"), des fondements d’une notion de méta-Système d’identité et de produits Microsoft associés.
Entrons dans le vif du sujet et abordons les pré-requis du produit AD FS 2.0 :
Hardware requirement
Minimum requirement
Recommended requirement
CPU speed
Quad-core, 2 GHz
x
Au delà de ces pré-requis, plusieurs conditions sont à réunir pour obtenir une solution AD FS 2.0 qui fonctionne :
Les 4 composants constituant AD FS 2.0 :
“Federation Service” :
“Federation Service Proxy” :
“Web agents for Claim-Aware Applications” :
“Web agents for Windows NT Token-Based Applications” :
L’installation du composant AD FS 2.0 :
Attention, une erreur à ne pas commettre lors de l’installation du composant est d’utiliser l’interface de gestion du serveur d’ajout de rôle !! En effet, si vous utilisez la fonction ajout de rôle et installez AD FS via cette méthode, vous n’obtiendrez QUE la version 1.0 d’AD FS… et ce, même si vous l’effectuez depuis un serveur 2008 R2… Cela peut paraître étrange mais vous n’avez pas d’autres choix que de télécharger le composant pour l’installer.
Je vous conseille également de prévoir déjà à l’avance vos certificats SSL afin de pouvoir terminer d’une traite la configuration de votre Service de fédération AD FS 2.0 dans le chapitre suivant.
La configuration du composant AD FS 2.0 :
L’assistant de configuration du composant AD FS 2.0 vous propose soit de :
L’assistant de configuration du composant AD FS 2.0 vous propose soit de créer :
Choisissez votre cas de figure et cliquez sur “Next” afin de passer à l’étape suivante de la configuration.
--> « Add-pssnapin microsoft.adfs.powershell »
Dans le cas d’utilisation d’AD FS 2.0 en ferme de serveur, il est recommandé d’utiliser une base SQL et non WID.
L’utilisation de WID entraîne en effet, systématiquement un mode Primaire/secondaires avec réplication toutes les 5 minutes entre les partenaires qui ne permet pas un mode de propagation fiable.
Ajout d’une relation de confiance, de partenariat :
Afin d’initier un partenariat entre 2 organisations, il est nécessaire d’établir en tout premier lieu une relation de confiance ou Trust entre les 2 parties. Dans ce partenariat, la configuration de ce trust est nécessaire pour définir le processus de gestion de jetons et revendications entrantes/sortantes selon que l’on soit positionné en tant que “Claim Provider” ou “Relying Party”.
Les “Claims rules” d’une relation de confiance :
Les règles de gestion et le process des revendications doivent être définies dans le TRUST afin de prendre en charge les revendications entrantes et sortantes par le moteur de gestion des revendications.
Processus “Claims pipeline”
Il est constitué de 3 phases, chacune ayant son lot de règles procédant à l’analyse de tous les revendications qui leur sont soumises.
Phase d’acceptation de la revendication entrante :
Phase d’autorisation :
Phase de délivrance des revendications sortantes :
Chaque phase comporte une liste d’actions disponible :
Issuance Transform Rules (Règles spécifiant les revendications qui seront envoyés à la partie tierce de confiance)
Issuance Authorization Rules (Règles spécifiant les utilisateurs autorisés à accéder à la partie tierce de confiance)
Delegation Authorization Rules (Règles spécifiant les utilisateurs autorisés à agir en tant que d’autres utilisateurs de la partie tierce de confiance)
Du côté du navigateur notons l’existence de notions de cookies facilitant les connexions au sites et applications fédérées.
Authentification Cookie
Account Partner Cookie
Sign-Out Cookie
Avant de vous lancer dans un projet de fédération d’identité, posez vous les bonnes questions et surtout “identifiez les objectifs de votre architecture” ?
En fonction des mappages de vos objectifs d’architecture, 3 scénarios de base sont à retenir :
Conception SSO de Web pour prendre en charge l’accès client à des applications dans des scénarios entreprise-client (B2C)
Conception SSO de Web fédéré pour prendre en charge les scénarios interentreprises (B2B) et la collaboration entre divisions avec des forêts indépendantes.
Conception SSO de Web fédéré avec approbation de forêt pour prendre en charge les scénarios intra-entreprise (B2E).
Afin de clôre ce billet, nous allons finir sur les bonnes pratiques sécurité pour la planification et le déploiement sécurisé d’AD FS 2.0.
scwcmd register /kbname:ADFS2Standalone /kbfile:"%programfiles%\Active Directory Federation Services 2.0\scw\StandAlone.xml" etc…)
Mon premier billet sur ce blog ! Et je commence sur un sujet des plus intéressant et très à la mode : La fédération d’identité et le produit Microsoft ADFS 2.0. Vu que les notions de fédération d’identité sont complexes et assez vastes, pour se faire, nous allons dans ce premier billet, introduire la notion d’identité numérique et clarifier les bases de la fédération d’identité. Nous nous focaliserons ensuite plus précisément sur ADFS 2.0 dans un second billet.
Pour commencer, qu’est ce que l’identité numérique ? C’est la représentation numérique d’une personne physique se déclinant en un “identifiant” et “d’un ensemble d’attributs qui lui sont liés (nom, prénom, adresse, téléphone, fax, bureau…)”.
Quels sont les type identités les plus courantes nous définissant numériquement ?
Du point de vue des entreprises, des solutions de Gestion des Identités et des Accès existent déjà, et apportent des éléments de réponses à ces problématiques :
Mais ces solutions ont leur limite : la complexité de mise en œuvre de ces architectures et de toutes les questions relatives à la sécurité du SI restant à la charge de l’entreprise sans compter le coût de gestion de ces infrastructures multiples.
D’un point de vue grand public, la multiplication des identités numériques nous contraint à une gestion des identités fastidieuse et couteuse en temps. Combien de fois avons nous perdu de temps à nous ré-inscrire sur un service X en rentrant inlassablement nos données personnelles maintes et maintes fois ?… Ce qui nous amène à introduire la notion de fédération d'identité.
L’externalisation des processus métiers, et à présent, les offres Cloud ont posés la problématique de la gestion des identités multiples hors du royaume de sécurité de l‘entreprise, repoussant encore plus loin les frontières du SI. La fédération d'identités offre donc une valeur ajoutée particulière :
D’un point de vue grand public, la fédération d’identité permet à chacun de :
Par exemple : Réseau social : Facebook et LinkedIn / Services Web : Yahoo ID, Microsoft Windows Live ID, etc… )
D’un point de vue de l’entreprise, avec l’avènement des services Web, l’arrivée des architectures fédérées est inévitable, car celle-ci est une composante importante des architectures SOA (Services Oriented Architecture). Celles-ci proposent d’établir des liens de confiance de manière distribuée, basée sur des standards, ouvrant ainsi la voie à des scénarios de B2B, de collaboration et de partage de données. Elle permet :
Quel est donc la réponse de Microsoft par rapport à la fédération d’identité et quel rôle ADFS 2.0 joue t’il donc dans la fédération d’identité ?
La réponse de Microsoft à cette problématique est GENEVA. C’est une plate-forme ouverte permettant l’accès simplifiée pour les utilisateurs, basée sur les notions de « fédération » de « revendications ». Dans sa version actuelle, la solution GENEVA est constitué de 3 composants :
Cette plate-forme :
Les notions en jeu quand on parle de fédération d’identité :
Les normes, spécifications et standards qu’il faut connaître quand on parle de fédération d’identité.
Ces protocoles permettent de normaliser et standardiser les échanges d’identité entre les référentiels d’utilisateurs et les applications indépendamment de leur localisation.
Les termes à connaître quand on parle de fédération d’identité :
Jeton de sécurité de type SAML contenant des assertions : Company=Nelite Email=francois.tran@ MyCompany.com Role=Consultant Groupe=CoreIdentityCollaborationConsultant
Jeton de sécurité de type SAML contenant des assertions :
Afin d’illustrer efficacement l’application directe de la fédération d’identité et pour que vous puissiez comprendre son mécanisme, je vous propose 2 schémas simplifiés :
Dans le cas d’une utilisation la plus simple de la fédération d’identité : Accès à un service Web.
Imaginez maintenant ce même schéma avec un service Mana hébergé dans le cloud, ou bien même que celui-ci ne soit un serveur Web NON-Microsoft. Tout cela est donc possible grâce aux standards utilisés qui offre une interopérabilité multi-fournisseurs.
Dans le cas d’une utilisation plus courante de la fédération d’identité : Accès à une application Web externalisée et hébergée chez un partenaire.
Ce type d’architecture autorise des périmètres homogènes et hétérogènes et n’impose pas un modèle propriétaire aux tierces-parties ou à ses fournisseurs car la fédération est basée sur la relation de confiance et l’échange entre 2 partenaires basés sur des standards reconnus et constitués par une grande majorité des acteurs majeurs du marché.
Ce billet, je l’espère, vous aura permis d’avoir une compréhension globale des termes et mécanismes de fédération d’identité et une bonne introduction en la matière pour aborder dans un prochain billet, la solution AD FS 2.0 de Microsoft.