Arnaud Jumelet

Techdays 2012–Qu’est-ce qu’un poste de travail sécurisé ?

2012-02-09T18:39:39Z

Merci pour votre présence lors de la session “Qu’est-ce qu’un poste de travail sécurisé ?”
Le support de présentation est disponible ici :

http://www.box.com/s/dn7akqykczu0eyjtspxl

Techdays 2011 : Support de présentation “SEC2301 Déploiement automatique de BitLocker et BitLocker To Go!”

2011-02-10T09:39:22Z

La session que j’ai animé aux Techdays 2011, sera bientôt disponible sous la forme d’un Webcast.

En attendant, le support de présentation PowerPoint est téléchargeable ici : http://www.box.net/shared/g1mzbraurq

[03/06/2011] : Le webcast est disponible ici :
http://www.microsoft.com/france/mstechdays/showcase/player.aspx?uuid=191512a4-c210-461b-bfae-1f7292b0d426&parcours=TD11_ENJEUX_SECURITE

Cryptographie, Autorité de Certification, PKI… Explication !

2010-12-19T15:35:25Z

A quoi sert la cryptographie asymétrique ?

La cryptographie asymétrique offre trois services de sécurité :

Authentification
Non-répudiation
Confidentialité

La cryptographie asymétrique manipule des bi-clefs (clef privée/clef publique).

On chiffre les données avec la clef publique ; on déchiffre les données avec la clef privée associée.
On signe un message avec sa clef privée ; on vérifie la signature avec la clef publique associée.

Néanmoins, un problème reste à régler comment s’assurer qu’un clef publique appartient bien à un utilisateur ?
Il faut passer par un acteur intermédiaire qui va certifier la clef publique.

A quoi sert une autorité de certification ?

Une autorité de certification (AC) lie une clef publique à un sujet durant une période de validité.
(Le sujet est un utilisateur, un processus ou un ordinateur).

L’assertion « ce sujet détient bien cette clef publique » se traduit par la génération d’un certificat de clef publique.
En résumé, une autorité de certification offre un niveau d’assurance sur le certificat de clef publique que l’on utilise.

Dans le monde numérique, la confiance à un prix : voir les certificats SSL de type EV.
(La fameuse barre verte qui apparait dans le navigateur)

Qu’est-ce qu’une PKI ?

Une infrastructure de gestion de clefs publiques (Public Key Infrastructure) désigne une hiérarchie d’autorité de certification.

Protecteurs BitLocker

2010-12-19T15:21:15Z

Afin d’accéder à un lecteur, BitLocker propose de nombreuses méthodes qui sont exposées sous le terme de protecteur. Les protecteurs protègent l’accès à un lecteur, on dit qu’ils permettent de déverrouiller un lecteur.

Note : On distingue les protecteurs nécessitant une interaction utilisateur, de ceux qui déverrouillent automatiquement un lecteur.

BitLocker propose 10 protecteurs. Sauf exception, ils peuvent être combinés entre eux.

TPM : TPM seulement
Ce protecteur est automatiquement configuré par l'interface utilisateur par défaut lors de l’activation de BitLocker. Le mode TPM seul ne peut pas être configuré en combinaison avec d'autres protecteurs de type TPM. Il n’est pas possible de définir plusieurs protecteurs TPM.
TPMAndStartupKey : TPM + clef de démarrage
Une clef USB doit être présente dans l’ordinateur lors du démarrage pour déverrouiller le volume. Il n’est pas possible de définir plusieurs protecteurs TPM + clef de démarrage.
TPMAndPIN : TPM + PIN (Il s’agit du protecteur recommandé par Microsoft)
L’utilisateur doit saisir un code PIN composé de 4 à 20 chiffres. La longueur minimale peut être augmenté via GPO ou clef dans la base de registre. Il n’est pas possible de définir plusieurs protecteurs TPM + PIN.
TPMAndPINAndStartupKey : TPM + PIN + USB
Combine la saisie d’un code PIN au démarrage avec l'exigence d'une clef de démarrage. Cette combinaison offre un niveau de protection très avancée. Il n’est pas possible de définir plusieurs protecteurs de ce type.
StartupKey : Clef de démarrage
Ce protecteur n’est pas accessible avec l’interface graphique. Il doit être configuré avec l’outil en ligne de commande manage-bde ou via un appel WMI. Uniquement disponible lorsqu’une puce TPM est absente du système.
RecoveryKey : Clef de récupération
Une clef de récupération est similaire à une clef de démarrage, mais elle peut être sauvegardée dans Active Directory. De plus, une clef de démarrage et une clef de récupération sont listées sous la même dénomination comme clef externe (External Key) avec le même conteneur de fichier .BEK.
ExternalKey : Clef externe
Une clef externe est généralement utilisable dans le scénario de déverrouillages automatique de lecteur de données fixes ou amovibles. Dans ce cas, la clef externe est stockée dans la base de registre à cet emplacement : HKLM\SYSTEM\CurrentControlSet\Control\FVEAutoUnlock\{Volume ID}
(Cette clef est protégée lorsque le système est alimenté électriquement par une ACL qui ne permet qu'au compte SYSTEM d'y accéder). La base de registre étant stockée sur le volume du système d’exploitation qui est intégralement chiffré.
RecoveryPassword : Mot de passe de récupération
Le mot de passe de récupération peut être enregistré dans un dossier, imprimé ou sauvegardé dans Active Directory, le tout configurable par une stratégie de groupe. Avec l’outil manage-bde ou appel WMI, il est possible de spécifier un mot de passe de récupération.
Certificate : Agent de récupération
Ce protecteur n’est pas accessible avec l’interface graphique. Il doit être configuré avec une stratégie de groupe ou bien avec l’outil en ligne de commande manage-bde ou via un appel WMI. Le lecteur n’est accessible seulement si l’on possède la clef privée associée au certificat de clef publique.
ClearKey : Clef en clair
Ce protecteur n’est pas listé en tant que protecteur avec l’interface graphique ou l’outil en ligne de commande manage-bde. Néanmoins ce protecteur est ajouté lorsque l’on décide de suspendre temporairement le chiffrement BitLocker sur la partition du système d’exploitation.

How to schedule FEP 2010 to check new definition updates every 15 minutes ?

2010-11-27T18:51:52Z

Comment demander au moteur FEP 2010 (Malware Protection) de rechercher automatiquement de nouvelles mises à jour toutes les 15 minutes ?

Il suffit d’exécuter cette ligne de commande avec des privilèges administrateur :

schtasks /create /tn "Update FEP 2010" /tr "'C:\Program Files\Microsoft Security Client\Antimalware\MpCmdRun.exe' -SignatureUpdate" /sc minute /mo 15 /rl Highest /F

How to regenerate the BitLocker Numerical Recovery Password

2010-11-12T22:42:06Z

From time to time it may be necessary to create a new set of recovery information for an encrypted volume, for example, the information may have been passed to a support engineer or user to recover a laptop that had entered recovery mode. There will be no guarantee that this information hasn’t been written down and left with the computer, so to ensure the security of data on the computer a new recovery password can be generated and any previous ones deleted.

1. Suspend BitLocker Protection :

manage-bde -protectors -disable %systemdrive%

2. Delete Recovery Password :

manage-bde -protectors -delete %systemdrive% -type RecoveryPassword

3. Add a new Recovery Password :

manage-bde -protectors -add %systemdrive% -RecoveryPassword

4. Backup the new Recovery Password :

manage-bde -protectors -adbackup %systemdrive% -ID KeyProtectorID

5. Enable BitLocker Protection :

manage-bde -protectors -enable %systemdrive%

Note :
When generating a new recovery password and storing the new one in AD DS; AD DS will not overwrite the old recovery password. This is by design. BitLocker recovery password entries do not get deleted from AD DS; therefore, you might see multiple passwords for each drive. To identify the latest password, check the date on the object.

Le contrôle d’accès logique : Gestion des autorisations

2010-11-12T22:31:00Z

En guise d’introduction : de l’authentification à l’autorisation !

Il est nécessaire de bien faire la distinction entre l’autorisation et l’authentification. L’authentification est le processus par lequel on s’assure qu’un sujet est bien celui qu’il prétend être. Le processus d’authentification peut mettre en jeu un ou plusieurs facteurs authentifiant. Lorsque l’on combine plusieurs facteurs on parle d’authentification forte. Les facteurs sont classés en trois catégories :

Ce que l’on connait. (mots de passe)
Ce que l’on possède. (cartes, tokens)
Ce que l’on est. (méthodes biométriques)

L’authentification permet de s’assurer de l’identité d’un sujet, avec un degré de certitude très variable. Par exemple, une authentification reposant uniquement sur la connaissance d’un mot de passe est jugée moins sûr qu’une authentification par le biais de la prise d’empreinte de la rétine. De plus, on admettra qu’il est plus facile de voler un mot de passe qu’une caractéristique biométrique.

Le processus d’authentification est nécessaire dans la sécurité d’un système mais ne permet aucunement de restreindre ni de définir le périmètre d’action d’un sujet. L’authentification s’attache à contrôler l’accès au système et non pas l’accès aux éléments du système (logiciels et matériels). La notion d’autorisation commence à se dessiner.

Quelles sont les opérations qu’un utilisateur peut effectuer sur le système informatique ?
Comment restreindre l’accès à des données confidentielles ?

Pour répondre à ces questions, il faut avoir défini au préalable des autorisations. Les mécanismes de contrôle d’accès permettent de faire respecter la politique de sécurité mise en place. Nous allons définir le contrôle d’accès comme un mécanisme visant à protéger les ressources du système contre un accès inapproprié ou non désiré.

Les systèmes d’exploitation utilisent le contrôle d’accès afin de protéger des ressources comme les fichiers, les processus, la mémoire...

Nous allons expliquer les trois niveaux d’abstraction régissant le contrôle d’accès :

La politique de contrôle d’accès.
Le modèle de contrôle d’accès.
Le mécanisme de contrôle d’accès.

La politique de contrôle d’accès

Une politique de contrôle d’accès définit les droits, les interdictions, les informations auditées ainsi que les personnes habilitées à modifier la politique de contrôle d’accès. Au sein d’une entreprise, une politique peut permettre à des partenaires d’accéder au système d’information : une politique peut s’appliquer de manière globale et être distribuée sur différents serveurs. On peut noter que chaque entreprise, chaque organisation possède sa propre politique de contrôle d’accès, ceci est dû à de nombreux facteurs comme la culture d’entreprise, la volonté d’ouverture, l’analyse de risque, la criticité du secteur, les lois en vigueur. Certaines politique d’accès seront plutôt axées sur le niveau de confidentialité des données comme pour le secteur militaire. Dans le secteur commercial, on privilégiera en premier l’intégrité des ressources. De plus, les politiques de contrôle d’accès sont par définition dynamiques. Elles s’adaptent au fil du temps en fonction des lois du marché, des normes de régulations ou bien de la stratégie de l’entreprise.

Modèle de contrôle d’accès

La politique de contrôle d’accès est une vue haute et abstraite du contrôle d’accès. Un niveau intermédiaire permettant de faire le pont entre la politique et son implémentation est le modèle de contrôle d’accès. Le modèle va permettre de supporter la politique définit. En ayant formalisé un modèle, on va pouvoir décrire les différentes propriétés de sécurité du modèle. Par exemple le modèle RBAC (Role Based Access Control) donne la possibilité de séparer les rôles qu’une personne peut endosser à un instant t. Le modèle DAC (Discretionnary Access Control) donne la possibilité au propriétaire de la ressource de gérer lui-même les autorisations. Le modèle MAC (Mandatory Access Control) quant à lui permet de garantir la confidentialité des données. Il existe ainsi différents modèles qui sont plus ou moins adaptés à la politique de sécurité de l’entreprise.

Depuis 50 ans, plusieurs modèles de contrôle d’accès ont été successivement proposés. On peut citer DAC, MAC, RBAC, TBAC, TMAC ou encore ORBAC. A chaque fois, un nouveau modèle est apparu pour répondre soit à des problématiques d’ordre militaire, soit à des problématiques du monde civil. On considère souvent que le domaine militaire nécessite un fort degré de confidentialité, tandis que les systèmes civils recherchent à garantir un niveau d’intégrité.

Le mécanisme de contrôle d’accès

Le modèle de contrôle d’accès ne définit pas de quelle manière il va être implémenté. Le modèle reste indépendant des différentes implémentations possibles. Par contre, le mécanisme de contrôle d’accès permet de réaliser la politique définit au préalable. A ce niveau, le niveau d’abstraction est faible ; la technicité est forte. Les mécanismes de contrôle d’accès peuvent être classés de nombreuses façons et ont un support réduit des politiques. En général, des attributs de sécurité sur les utilisateurs et les ressources sont conservés dans le système. Les attributs de sécurité sur les ressources peuvent être des étiquettes de sécurité ou bien des listes de contrôles d’accès. Pour déterminer si un utilisateur à la permission de faire une opération sur une ressource, le mécanisme peut par exemple vérifier que le couple identité utilisateur-opération est inclus dans la liste de contrôle d’accès de la ressource. Les mécanismes de contrôle d’accès différent selon leur habilité à fournir des rapports et à administrer les droits d’accès.

Microsoft Malware Protection

2010-11-12T11:37:34Z

Comme vous l'avez surement remarqué, il existe plusieurs gamme de produits anti-malware chez Microsoft :

Forefront Endpoint Protection 2010 (FEP 2010) : Gamme Entreprise
Windows Intune Malware Protection : Gamme TPE et PME
Microsoft Security Essentials (MSE 2.0) : Gratuit, pour les TPE et les particuliers

Néanmoins, techniquement, ces trois produits partagent le même moteur anti-malware “Microsoft Malware Protection”.
Ainsi, il est intéressant de savoir que le moteur “Microsoft Malware Protection” est administrable en ligne de commande à l’aide de “MpCmdRun.exe”.

Usage:
MpCmdRun.exe [command] [-options]

-RemoveDefinitions [-All] :
Restores the installed signature definitions to a previous backup copy or to the original default set of signatures.

-RestoreDefaults :
Resets the registry values for Microsoft Antimalware Service settings to known good defaults

-SignatureUpdate [-UNC] :
Checks for new definition updates

   -Scan [-ScanType] :
    Scans for malicious software
         0 Default, according to your configuration
         1 Quick scan
         2 Full system scan

-Restore -Name <name> [-All] :
Restore the most recently or all quarantined item(s) based on name

-GetFiles :
Collects support information and gathers log files and packages them together in a compressed file in the support directory

-RemoveDefinitions [-All] :
Restores the last set of signature definitions or removes any installed signature and engine files

-SignatureUpdate [-UNC] :
Check for signatures update

-Restore -Name <name> :
Restores the most recently quarantined item based on name or Restores all the quarantined items

-AddDynamicSignature -Path <path> :
Adds a Dynamic Signature specified by <path>

-RemoveDynamicSignature -SignatureSetID <SignatureSetID> :
Removes a Dynamic Signature

   -ListAllDynamicSignatures :
    Lists SignatureSet ID's of all Dynamic Signatures added to the client via SpyNet and
    MPCMDRUN -AddDynamicSignature

Administration à l’aide de Windows Remote Shell : WinRS

2010-10-24T17:08:42Z

Pour administrer à distance, en ligne de commande, un serveur Windows 2003 R2 et supérieur, il est possible d’utiliser Windows Remote Shell (WRS).

Windows Remote Shell utilise Windows Remote Management (WinRM) qui est l’implémentation de WS-Management.
Les services WS-Management (Web Services for Management) permettent l'exécution de commandes et de scripts à distance. Les communications sont chiffrées et authentifiées, limitant ainsi les risques en matière de sécurité.

Les administrateurs peuvent utiliser l'outil de ligne de commande Windows Remote Shell pour obtenir des données de gestion (des informations, par exemple, sur des objets tels que les disques, les adaptateurs réseau, les services ou les processus) auprès d'ordinateurs locaux et distants.
Si l'ordinateur exécute une version du système d'exploitation Windows qui inclut Windows Remote Management, les données de gestion sont fournies par Windows Management Instrumentation (WMI).

L’administrateur à l’aide de Windows Remote Shell ouvre un interpréteur en ligne de commandes, puis exécute des requêtes WMI à l’aide de l’outil wmic.exe.

Afin d’utiliser Windows Remote Shell à distance, il est nécessaire de créer un « écouteur » sur l’ordinateur à administrer à l’aide de la commande suivante :

winrm quickconfig

2. Le texte suivant s’affiche :

WinRM n'est pas configuré pour la gestion à distance de cet ordinateur.

Les modifications suivantes doivent être effectuées :

Créez un écouteur WinRM sur HTTP://* pour accepter les demandes de la gestion des services Web sur toutes les adresses IP de cet ordinateur.

Activez l'exception de pare-feu WinRM.

Effectuer ces modifications [o/n] ?

3. Taper la lettre o, pour terminer, le texte suivant s’affiche:

WinRM a été mis à jour pour la gestion à distance.

Écouteur WinRM créé sur HTTP://* pour accepter les demandes de la gestion des services Web sur toutes les adresses IP de cet ordinateur.

Exception de pare-feu WinRM activée.

4. WinRM est correctement configuré et en attente de connexion distante.

5. Sur un poste Windows 7, par exemple, il faut ajouter l’adresse IP de l’ordinateur à administrer en tant qu’hôte de confiance :

winrm set winrm/config/client @{TrustedHosts="10.0.0.2"}

6. Il est alors de se connecter à l’ordinateur distant et de lancer un interpréteur de commandes :

winrs -r:http://<FQDN Serveur CORE> cmd

Note : dans cet exemple, les commandes ainsi que les résultats sont transmis en clair sur le réseau.

Lorsque WinRS est utilisé pour administrer un serveur distant, les limitations suivantes doivent être prises en compte :

Les commandes WinRS ne peuvent être exécutées qu’à partir d’un ordinateur sous Windows Vista ou supérieur.
Les commandes produisant des messages comme « Press any key to continue » ne sont pas supportés.
Pour des raisons de sécurité, veillez à utiliser uniquement WinRM avec un écouteur HTTPS.

FEP 2010 et moteur Anti-malware de Microsoft “Malware Protection”

2010-10-21T09:58:54Z

La solution FEP 2010 est une solution de protection contre les logiciels malveillants, dont la console de gestion s’intègre nativement dans une infrastructure SCCM 2007 existante. En effet, FEP 2010 ne nécessite pas de déployer des serveurs supplémentaires, mais s’intègre nativement dans la solution de gestion des postes de travail SCCM 2007.

Le moteur anti-malware, dont le nom est Malware Protection, couvre à la fois les virus, chevaux de Troie, spywares ainsi que les rootkits.
Les technologies de protection sont multiples : Analyse à base de signature, détection comportementale et protection contre les exploits réseaux.

Lorsqu’un malware est détecté, plusieurs actions sont disponibles (conformément à la politique définie par l’administrateur FEP 2010) : nettoyage du système (avec ou sans redémarrage nécessaire), mise en quarantaine, suppression du fichier.

A noter que le laboratoire Microsoft MMPC (Microsoft Malware Protection Center) publie en moyenne une mise à jour des signatures trois fois par jour. Le moteur reçoit une mise à jour mensuelle applicable sans avoir à redémarrer l’ordinateur.

Le document « Understanding Anti-Malware Research and Response at Microsoft » est une introduction à la technologie anti-malware et l’organisation du laboratoire MMPC :
http://download.microsoft.com/download/0/c/0/0c040c8f-2109-4760-a750-96443fd14ef2/Understanding%20Malware%20Research%20and%20Response%20at%20Microsoft.pdf

Analyse de forme statique et émulation

D’après Éric Filiol : L’analyse de forme consiste à analyser un code hors de tout contexte d’exécution. Il s’agit de rechercher des structures d’octets correspondant à une signature de code malveillant connu ou générique (famille de code malveillant).

Généralement, les créateurs de virus cherchent à échapper à l’analyse de forme et de ce fait ajoute une couche de protection (obfuscation, chiffrement, compression) qui disparait à l’exécution.
C’est pourquoi, le moteur Malware Protection dispose d’une fine machine virtuelle (Dynamic Translation) émulant l’API Win32. Ainsi, le binaire à analyser est exécuté dans une machine virtuelle afin de supprimer les éventuelles couches de protection, rendant ainsi de nouveau opérationnelle l’analyse de forme. De plus, et de façon plus traditionnelle, le moteur Malware Protection prend en charge de nombreux formats de compression ainsi qu’un large éventail de « packers ».

Enfin, lors des analyses du système, le moteur prend en charge l’analyse directe du système de fichiers permettant l'identification et la suppression des programmes malveillants qui seraient autrement cachés par un rootkit qui détournerait le fonctionnement de certaines API liés au système de fichiers.

Détection comportementale (Protection dynamique)

D’après Éric Filiol : La détection comportementale consiste à déterminer, au moment où le code est exécuté – par émulation de code ou à l’accès – si certains comportements s’apparentent à du logiciel malveillant ou non.

Pour cela, le moteur Malware Protection utilise des signatures heuristiques pour rechercher les signes d'un comportement suspect, matérialisés par un ensemble de caractéristiques imputables à des logiciels malveillants connus. Ces signatures heuristiques sont utilisées avant que le binaire ne s’exécute sur le système lors de la phase d’émulation de code qui s'appuie sur la technologie de traduction dynamique de Microsoft.

Le moteur Malware Protection définit un point d’ancrage sur le navigateur Internet Explorer afin d’être à même d’analyser et de bloquer l’exécution de script malveillant. Pour ce faire, le contenu de la mémoire est analysé avant qu’un traitement soit effectué par le navigateur Internet Explorer.

Après le démarrage d'un processus, le moteur anti-malware surveille les appels système portant sur les fichiers, base de registre, réseau et le noyau afin d’identifier un comportement suspect. Un comportement douteux déclenche alors une requête vers le service de signature dynamique pour savoir si le programme doit être bloqué ou soumis pour analyse. Cette protection porte également sur les fichiers de contenu (pdf,docx..)

Concernant le système d’exploitation, le comportement du noyau est supervisé en temps-réel. La technologie acquise en 2008 à la société Komoku Inc. (http://www.microsoft.com/security/portal/komoku/) a été complètement intégrée au moteur Malware Protection qui surveille maintenant l'intégrité des structures du noyau. Cette brique technologique est fondamentalement un KIDS (Kernel Intrusion Detection System) Si le noyau semble avoir été compromis alors des demandes de télémétrie et de mise à jour sont envoyées au service signature dynamique.

HIPS (Host-Based Intrusion Prevention System)

D’après Thierry Evangelista : Un HIPS est un agent logiciel que l’on installe sur l’hôte à protéger et qui analyse en temps réel les flux relatifs à cette machine.

Microsoft Research a développé la technologie NIS (Network Inspection System - http://research.microsoft.com/apps/pubs/default.aspx?id=70223) qui est intégrée dans FEP 2010.

Un HIDS possède un avantage considérable sur un pare-feu de segment réseau, en ce qui concerne les flux chiffrés. En effet, l’agent NIS étant installé à l’extrémité de la chaine de communication, il est alors possible d’analyser le flux en clair.

NIS est un HIPS basé sur la détection de formes, disposant d’un moteur et de signatures régulièrement mises à jour. NIS permet de se protéger contre les flux réseaux cherchant à exploiter les vulnérabilités des produits Microsoft dont les correctifs ne seraient pas déployés. Lorsque le correctif est appliqué, alors les signatures sont déchargées du moteur NIS. Si le correctif est désinstallé, alors les signatures en relation sont de nouveaux actives. La protection de NIS porte sur les flux entrants et sortants.

Ensemble de ressources sur la technologie de chiffrement EFS

2010-07-20T11:26:00Z

Dans le graphique ci-dessous, j’ai consolidé l’ensemble des fiches de référence sur EFS disponible sur le site de microsoft.com
Chaque graphique est cliquable.

SharePoint 2010 : Une application claim-aware avec son propre STS

2010-07-14T10:25:05Z

SharePoint 2010 propose un mode d’authentification, appelé authentification par revendication (Claim Based Authentication).

L’authentification par revendication de SharePoint 2010 s’appuie sur un STS local développé à l’aide de WIF (Windows Identity Foundation).
WIF est un ensemble de classes .NET Framework qui permettent de créer des applications prenant en charge les revendications.
Pour rappel, une application prenant en charge les revendications créée avec WIF peut traiter des demandes d’authentification basées sur les protocoles WS-Federation et WS-Trust. Il faut savoir que WS-Federation prend en charge différent type de jeton de sécurité, dont les jetons SAML 1.1

Le STS local (SP-STS) est développé à l’aide du framework WIF et de ce fait supporte uniquement les protocoles de fédération suivants :
WS-Federation, WS-TRUST
Le SP-STS ne consomme, en entrée, que des jetons de sécurité SAML au format SAML 1.1

Il est légitime de se demander, s’il est possible de fédérer SharePoint 2010 avec un serveur d’identité ne prenant en charge que le protocole SAMLv2.
La réponse est oui : il est possible de fédérer (indirectement) SharePoint 2010 avec un serveur d’identité compatible uniquement avec le protocole SAMLv2. L’implémentation passe par un serveur de fédération disposant d’une double pile protocolaire : WS-Federation et SAMLV2.
Le logiciel ADFS 2.0 répond parfaitement à cette exigence.

Domain Controller Locator : In depth

2010-07-11T19:56:09Z

When a client computer needs to contact a domain controller for a specific domain, NetLogon service running at the client computer tries to search the nearest Domain Controller by querying the local computer registry for DynamicSiteName.

Note
If the domain being located is the same as the domain to which the computer is joined and the computer has not physically moved to a different site since the last query, the dynamically determined site name in the registry is the actual site in which the computer is located.

On the other hand, if the site name in the registry is not the current site of the computer (for example, if the computer is portable), the domain controller location process serves to update the site information in the registry.

DC Locator Service uses this DynamicSiteName entry to query DNS Server to find the domain controllers in that site. It appends the site name to the DNS query (SRV Record) and sends it to the DNS Server which in turns sends a response.
DNS must return a list of IP addresses that are sorted by priority and weight.

Client inspects the SRV record and attempts to choose the domain controller with the lowest priority. If servers have the same priority, client randomly chooses SRV records with probability proportional to the weight. The algorithm is defined in RFC 2782.

The client (Netlogon service) sends a datagram to the domain controller chosen in the step before. The datagram is implemented as an LDAP User Datagram Protocol (UDP) search.

The domain controller receives the query, which contains the IP address of the client, and passes it to NetLogon on the domain controller. NetLogon looks up the client IP address in its subnet-to-site mapping table by finding the subnet object that most closely matches the client IP address and then returns the following information:

The name of the site in which the current domain controller is located.
The name of the site in which the client is located, or the site that most closely matches the client IP address.
A bit that indicates whether the found domain controller is located (bit is set) or not located (bit is not set) in the site closest to the client.
Other pieces of information that describe the domain controller.

Note
The site information for the forest is stored in the configuration directory partition in Active Directory, and this information is replicated to all domain controllers in the forest. Included with the configuration information is a list of IP subnets that are associated with a particular site.

The domain controller returns the information to the client.
The client inspects the information to determine whether to try to find a beter domain controller. The decision is made as follows:

If the returned domain controller is in the closest site (the returned bit is set), the client uses that domain controller.
If the client has already tried to find a domain controller in the site in which the domain controller claims the client is located, the client uses that domain controller.
If the domain controller is not in the closest site, the client updates its site information and sends a new DNS query to find a new domain controller in the site. If the second query is successful, the client uses the new domain controller. If the second query fails, the client uses the original domain controller.
If the domain that is being queried by a computer is the same as the domain to which the computer is joined, the site in which the computer resides (as reported by a domain controller) is stored in the computer registry. The client stores this site name in the DynamicSiteName registry entry in HKLM\SYSTEM\CurrentControlSet\Services\ Netlogon\Parameters. Therefore, the DsGetSiteName API returns the site in which the computer is located.

To override the dynamic site name value returned, you can fix the SiteName entry.
When a value is present for the SiteName entry, the DynamicSiteName entry is ignored.

REG_SZ

HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters\SiteName

Range :
String

Searching a domain controller at a specific site

If no other site is specified, a locator searches for a domain controller in the Active Directory site at which the client is located, or was last found. If the Active Directory site of the client is not known to the locator when the search begins, it asks a DNS server for the general entries of the domain controllers in the specified domain. It then turns to one of the domain controllers found to determine the Active Directory site which the client belongs to. If the addressed domain controller is not in the same Active Directory site, the locator repeats the DNS request specifying the Active Directory site of the client in order to find a domain controller in its Active Directory site.

If the client does not receive a response from the domain controller of its Active Directory site, or if no domain controller is available at this site, the client returns again to the general list of domain controllers. In this case, the client receives a pseudorandom domain controller in return to its general request.

Client with no apparent site

If the client pings a domain controller 2000/2003 and the client IP address cannot be found in the subnet-to-site mapping table, then in this case, the domain controller returns a NULL site name, and the client uses the returned domain controller.

Important
The behavior on Windows Server 2008 domain is not the same.
If a domain member has an IP address that is not linked to a specific site, that computer will be placed in the Default-First-Site-Name site. Every computer that is part of a Windows Server 2008 domain must belong to a site.

Domain Controller Locator : an overview

2010-07-05T19:05:40Z

When an application requests access to Active Directory, a domain controller is located by a mechanism called the Domain Controller Locator.
The process of location is to use DNS to identify a set of candidate domain controllers from a list, based on SRV records.
Then, the servers on the list are queried to test if they are alive.

The client is initialized with DomainName.FQDN being set to the Domain Name System (DNS) name of the domain to locate, for example mockup1.contoso.com

The general process is shown in the following diagram:

The first step is to perform the DNS discovery.
The client issues a DNS request for _ldap._tcp.dc._msdcs.mockup1.contoso. com
The DNS server returns a list of SRV records that match this request. If no records are available, then the domain location fails.
The DNS exchange is done as specified in the DNS protocols (RFC 1769 and related RFCs).
If target hosts have the same priority, the client select a return SRV record according to weighted pseudorandom order (see RFC2052).

The client then resolves the SRV record to an address, again as specified in the DNS protocols.

Once the address is known, the client sends an LDAP “Ping,” as a way of detecting that the domain controller is in fact handling requests and determining the characteristics of this domain controller. The LDAP “Ping” also known as connectionless LDAP is sent over UDP

After each packet is sent, the client waits for a response, and if no response is received, it sends a packet to the next domain controller. The client continues this process until it receives a valid response that specifies the requested services or has tried all of the domain controllers.

When a client tries to locate a domain controller after it has received the IP address from DNS, it varies the time it waits for a response based on the number of domain controllers it has already pinged. For the first five domain controllers, it waits for 0.4 seconds, and for next five domain controllers, it waits for 0.2 seconds. After 10 domain controllers have been pinged, the client uses a 0.1 second wait for the remaining requests.

The LDAP “Ping” is an LDAP rootDSE search to the domain controller, looking for an attribute called “NetLogon.”

The domain controller server inspects the query and returns the NetLogon result.
The response is typically returned in a NETLOGON_SAM_LOGON_RESPONSE_EX.

Upon receipt of the LDAP SearchResultEntry, the client validates the capabilities returned by the domain controller.

If the capabilities returned by the domain controller are incompatible with the requirements specified by the invoker of the locator algorithm on entry, the client must select another candidate domain controller from the list of domain controller SRV records returned above.

Incompatibility in this case can arise because the client requested a Kerberos KDC, but the domain controller did not indicate that a KDC was present, or the client requested a domain controller that could accept writes, but this domain controller is read-only.

These sorts of negative results are cached by the client; however, they are purged promptly (on the order of minutes).

Because the LDAP “Ping” returns a snapshot of the current state of the domain controller at the moment of the query, services such as a time server, may not be running at the moment, but may be available once the server has completely started.

If all the responses in the SRV records have been checked, and each SRV record points to a server that is either not available or does not match the requirements, then the location operation has failed.

Upon successful response from the domain controller, the location portion completes.
The DomainController element is set to the name and address of the domain controller that was selected.

BitLocker : Registres PCR d’une puce TPM

2010-07-05T18:47:21Z

La mesure de l’intégrité de la séquence de démarrage s’appuie sur les registres de configuration de la plateforme (Platform Configuration Registers ou PCR) qui sont des portions de mémoire volatiles de 160 bits (pour stocker des condensats SHA-1) permettant de stocker l'état d'une plateforme. La spécification impose que les PCRs soient, au minimum, au nombre de 16 (numérotés de 0 à 15). Les registres 0 à 7 sont utilisés par la puce TPM et le BIOS TCG, ceux de 8 à 15 peuvent être utilisés par une application pour y placer des mesures d’intégrité portant sur des composants spécifiques.

Sur le schéma ci-dessous, est représenté en bleu, les mesures d’intégrité prises en compte par la solution de chiffrement BitLocker sous Windows 7. Le comportement est configurable par stratégie de groupe. A noter que la table des partitions est prise en compte lors de la mesure d’intégrité de la séquence de démarrage.

BitLocker : Etats d’une puce TPM

2010-07-05T18:43:01Z

Il existe 8 modes opérationnels pour une puce TPM, définis à travers trois variables : enabled, activated et owned. Ces booléens représentent respectivement le fait que la puce est inactive et sans possibilité d’en devenir propriétaire, le fait que la puce est inactive mais que l’on peut effectuer l’opération de prise de possession (TakeOwnership) et enfin le fait que la puce ait été initialisée par un propriétaire via l’opération takeownership.

L’outil tpm.msc (inclus dans Windows 7) permet d’effectuer des actions sur la puce TPM afin de modifier son état. Ainsi, il est possible d’arriver à l’état 0, 6 ou 7 comme illustré sur le schéma précédent et la capture d’écran ci-dessous :

Le changement d'état de la puce TPM nécessite l'autorisation du propriétaire de la puce (via l'utilisation du mot de passe de propriétaire) ou bien un consentement via une démonstration de la présence physique. Ainsi, le fait de modifier l’état d’une puce TPM n’ayant encore aucun propriétaire définit impose de redémarrer l’ordinateur et d’appuyer physiquement sur une touche pour valider le changement de configuration.

Par défaut, la prise de possession de la puce TPM s’effectue en trois étapes, nécessite deux redémarrages et impose la présence physique d’un opérateur. Lors de la prise de possession de la puce TPM, le mot de passe du propriétaire est définit et la puce va créer la clef SRK (Storage Root Key).

Pour automatiser la prise de possession de la puce TPM, il faut que la puce se trouve dans état correct pour la prise de possession, c'est-à-dire dans l’état enabled et activated. Il est dans ce cas nécessaire de flasher le BIOS et la mémoire CMOS contenant la configuration du BIOS.

Note : Le fait de réinitialiser (Clear TPM) une puce TPM efface la SRK et toutes les clefs cryptographiques dérivées. Si BitLocker est activé avec un protecteur de type TPM, alors au prochain démarrage BitLocker entre alors en mode de récupération.

Intégration AD RMS avec Exchange 2010

2010-07-05T18:19:58Z

Au menu des nouveautés d’Exchange 2010, ce qui m’intéresse plus particulièrement est le lot de fonctionnalités autour de l’intégration très poussée d’AD RMS. Il devient possible de définir des règles obligatoires chiffrant à la volée le contenu des messages et appliquant des droits d’usages.

Grâce à Exchange 2010, la protection des messages peut être appliquée :

Automatiquement au niveau du serveur Exchange 2010 (règles de transport) ou bien au niveau du client de messagerie (règles de protection Outlook 2010).

o Automatiquement sur les serveurs de transport Hub Exchange 2010
Vous pouvez créer des règles de protection du transport pour activer une protection RMS automatique des messages sur les serveurs de transport Hub d’Exchange 2010.

o Automatiquement dans Outlook 2010
Outlook 2010 permet de créer des règles de protection Outlook pour activer une protection RMS automatique des messages. Les règles de protection Outlook sont déployées automatiquement chez les clients Outlook 2010 et la protection RMS est appliquée par Outlook 2010 lorsque l’utilisateur compose un message.

Manuellement au niveau du serveur Exchange 2010 (rôle CAS, si l’utilisateur envoie son message à partir du site Outlook Web App) ou bien au niveau du client de messagerie (Outlook 2003/2007/2010).

o Manuellement par les utilisateurs Outlook 2003/2007/2010
Les utilisateurs Outlook peuvent protéger leurs messages par RMS en appliquant les modèles de stratégie de droits d’accès AD RMS mis à leur disposition. Ce processus utilise la fonctionnalité RMS dans Outlook, pas dans Exchange. Il reste toutefois possible d’utiliser Exchange pour accéder aux messages et prendre des mesures (telles que l’application des règles de transport) pour faire appliquer la stratégie de messagerie de votre organisation.

o Manuellement par les utilisateurs Outlook Web App
Lorsque vous activez RMS dans Outlook Web App, les utilisateurs peuvent activer une protection RMS pour les messages qu’ils envoient et afficher les messages protégés par RMS qu’ils reçoivent.

DirectAccess : Afficher en permanence le dernier utilisateur actuellement connecté

2010-05-25T13:36:53Z

Comment afficher, en permanence, le dernier utilisateur connecté à travers Direct Access ?
Avec PowerShell, bien sûr !!!

Do{

Write-Host "DERNIER UTILISATEUR CONNECTE" -ForeGroundColor "Green"

Get-EventLog -LogName Security -Source Microsoft-Windows-Security-Auditing -InstanceId 4981 | Select-Object -index 0 | format-list

Start-Sleep -s 5

clear-Host

}

while(1)

Forefront UAG / DirectAccess : Supervision des utilisateurs et ordinateurs connectés

2010-04-27T20:01:14Z

Avec Forefront UAG et la fonctionnalité DirectAccess, il arrive de vouloir afficher en “temps réel” la liste des machines et utilisateurs qui sont connectés.

Pour cela, il suffit de suivre les étapes suivantes :

1. Autoriser l’exécution de script PowerShell non signé.

En tant qu’administrateur, ouvrir une invite PowerShell et taper la commande :
Set-executionPolicy –ExecutionPolicy Unrestricted

2. Enregistrer le snap-in PowerShell.
Pour ce faire, créer un fichier texte "Profile.ps1" dans "c:\Windows\System32\WindowsPowerShell\V1.0".

Dans ce fichier, taper la ligne suivante :
Add-PSSnapin UAGDAUserMonitoring

3. Créer un script PowerShell qui contiendra les lignes suivantes :

Do{
Write-Host "Clients Connectés" – ForeGroundColor "Green"

Get-DirectAccessUsers –LogName Security –Outputverbosity Rawdata –verbose | select-object Username –unique

Start-Sleep –s 5
Clear-Host

}
While(1)

Note : le cmdlet Get-DirectAccessUsers est apporté sur le système lors de l’installation de Forefront UAG.

Forefront UAG : Synthèse des accès distants

2010-04-05T10:09:29Z

Je viens de réaliser une matrice de compatibilité entre les technologies de tunneling UAG et les systèmes d’exploitation. Les informations contenues dans ce tableau proviennent de la page “System requirements for Forefront UAG endpoints” : http://technet.microsoft.com/en-us/library/dd920232.aspx

	Windows XP	Windows Vista	Windows 7	Mac OS X	Linux
Application Tunneling (ActiveX ou Java JRE 1.5)	(32 bits uniquement)	(32 bits uniquement)		(10.4 et supérieur)	(32 bits uniquement)
Socket Forwarding (Winsock 2 LSP)	(32 bits uniquement)		(32 bits uniquement)
SSL Network Tunneling (Network Connector)	(32 bits uniquement)
SSTP		(à partir du SP1)
DirectAccess

Note : Pour avoir plus de détails, sur la technologie de “Socket Forwarding”, vous pouvez utiliser l’outil Sporder.exe (disponible dans le SDK Windows).
Sur la capture ci-dessous, on peut voir que le client ISA est installé sur le système. Il en serait de même pour le client UAG.

Protection des données : Comment tirer bénéfice de la solution de chiffrement intégrée EFS ?

2010-02-04T20:10:29Z

Ce mercredi 10 Février 2010, lors des TechDays, j’anime une session de type retour d’expérience sur chiffrement des données.

Le constat est simple, chaque semaine, 833 ordinateurs portables sont déclarés perdus à l’aéroport Roissy Charles De Gaulles.
Face à cela, seulement 27% des entreprises déclarent chiffrer les données des disques durs.

Et Vous ? Il est temps d’adopter une stratégie afin de réduire le risque de fuite de données.

EFS est aujourd’hui une technologie de 4ième génération, sans surcoût additionnel, permettant de protéger efficacement les ordinateurs portables sous Windows XP, Vista et Windows 7.

L’agenda de la session est le suivant :

Panorama des solutions de chiffrement
Technique de chiffrement EFS
Intégration avec une PKI et ADCS
Performance
Protection des dossiers locaux avec EFS Assistant.
Stratégie de récupération des données (KRA vs DRA)
Etapes de mise en œuvre

[Update 05/04/2010]
Je viens de poster la présentation PowerPoint.
Le fichier est disponible téléchargeable à partir du lien suivant :
http://www.box.net/shared/1e4lgytf3g

[Update 27/04/2010]
La session est disponible sous forme de Webcast à la demande :
http://www.microsoft.com/france/vision/mstechdays10/Webcast.aspx?EID=52eb1f7e-bb1c-41f7-85cd-2a951d7604c3

Certificate Services : Certutil.exe

2009-12-10T11:24:17Z

L’outil certutil est l’interface en ligne de commande, par excellence, pour tout ce qui concerne la gestion des certificats sur la plateforme Windows.
C’est également l’outil idéal pour administrer et configurer le service de certificats de Windows Server.

Autoriser à ce qu’une requête de certificat contienne une date d’expiration différente de celle spécifiée dans le modèle. Indispensable pour NAP et la génération de certificat de santé !	certutil -setreg policy\EditFlags +EDITF_ATTRIBUTEENDDATE
Désactiver la génération d’un certificat cross-certifié.	certutil -setreg ca\CRLFlags +CRLF_DISABLE_ROOT_CROSS_CERTS
Forcer la génération d’un certificat cross-certifié en se basant sur le template “CROSS_CERT_TEMPLATE”	certutil -setreg ca\CRLFlags +CRLF_USE_CROSS_CERT_TEMPLATE
Forcer la génération d’un certificat d’échange basé sur le template “XCHG_CERT_TEMPLATE”. Si, ce template n’est pas disponible, l’archivage d’une clef privée lors d’un enrôlement automatique échouera.	certutil -setreg ca\CRLFlags +CRLF_USE_XCHG_CERT_TEMPLATE
Empêcher la modification du champ “subject” transmis dans une requête de certification.	certutil -setreg ca\CRLFlags +CRLF_REBUILD_MODIFIED_SUBJECT_ONLY
Supprimer une CRL lorsque la clef privée d’une CA expire.	certutil -setreg ca\CRLFlags +CRLF_DELETE_EXPIRED_CRLS
Forcer la publication des certificats expirés dans la CRL.	certutil -setreg ca\CRLFlags +CRLF_PUBLISH_EXPIRED_CERT_CRLS
Ignorer les erreurs liées à la révocation.	certutil -setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE

Afficher le CSP stockant une clef privée

2009-12-10T10:09:46Z

Une commande permettant d’afficher le CSP (Cryptographic Service Provider) utilisé par une bi-clef :

certutil /user /store my

Il suffit ensuite de lire la ligne contenant “Provider =”.

Dans cet exemple, mon certificat est stocké sur une carte à puce.

Anti-spam Exchange 2007

2009-10-03T13:11:56Z

Ce billet est l’occasion de présenter le fonctionnement de la protection Anti-spam incluse dans Exchange 2007.
Ainsi ce billet se veut être le plus synthétique possible afin de bien faire comprendre les différents niveaux de filtrage.

Le premier niveau de protection « Filtrage de connexion » est un filtrage basé sur l’adresse IP de l’émetteur. Microsoft dispose d’une base de données actualisée en permanence, contenant la liste des spammeurs à travers le monde « Block List».
Cette liste alimente la fonctionnalité « Réputation de l’expéditeur » qui en fonction des réglages ajoute ou non temporairement l’expéditeur dans la « liste rouge IP ».
La connexion est alors coupée et le message rejeté.
Remarque : Il est possible de définir manuellement des adresses IP supplémentaires dans la liste « Liste Rouge IP ou bien d’ajouter des exceptions en spécifiant l’adresse IP de l’émetteur dans la « Liste Verte IP ».

Le deuxième niveau de protection « Filtrage des destinataires » est basé sur l’adresse e-mail du destinataire. Si le destinataire n’appartient pas à liste des utilisateurs de l’entreprise (liste d’adresses globale), la connexion est alors coupée et le message rejeté. Il est possible de proscrire manuellement des destinataires dans l’onglet « Filtrage des destinataires ».
La connexion est alors coupée et le message rejeté.

Le troisième niveau « Filtrage des expéditeurs» est basé sur l’adresse e-mail de l’expéditeur.
La liste des expéditeurs proscrits se renseigne en ajoutant manuellement des adresses e-mail ou bien des domaines de messagerie. De plus, il est possible de rejeter les messages sans expéditeur. La connexion est alors coupée et le message rejeté.

Le quatrième niveau « Sender ID » (RFC 4407) permet de détecter l’usurpation d’adresse e-mail. La vérification s’effectue en comparant l’entrée DNS SPF (Sender Policy Framework) au sein des DNS publiques avec l'adresse IP du serveur SMTP émetteur. Cette entrée définie les adresses IP autorisées à envoyé des messages pour le domaine en question. En cas d'échec de vérification, il est possible de « Rejeter le message », « Supprimer le message » ou bien « Continuer le traitement en augmentant la note SCL »

Le cinquième et dernier niveau « Filtrage de contenu » est une analyse à base de signatures anti-spam complétée par une analyse heuristique (moteur de règles).

o Si un courrier correspond à un spam connu, celui-ci se voit attribuer la note SCL (Spam Confidence Level) maximum 9.

o Sinon, le message est confronté au moteur de règles SmartScreen/IMF (filtre de contenu) qui attribue une note SCL comprise entre 0 et 9.

1. Si le score SCL dépasse le seuil maximum toléré, le message est automatiquement rejeté/supprimé.

2. Si le score est borné entre le seuil minimum et maximum, le message est considéré étant probablement un courrier indésirable.
Il peut être alors redirigé dans un BAL administrateur, délivré en changeant le sujet, délivré en ajoutant un X-Header, ou bien redirigé dans le dossier « Courrier Indésirable » de la BAL utilisateur.

3. Si le score est inférieur à un seuil minimum, le message est considéré comme légitime et délivré dans la boite de réception utilisateur.

Forefront Online Protection for Exchange – FOPE/FOSE/EHS

2009-09-27T11:57:46Z

Le diagramme suivant présente les fonctionnalités anti-spam de Forefront Online Protection for Exchange (FOPE) anciennement connu sous le nom de FOSE et EHS .

Le premier niveau de protection « Directory-Based Edge Blocking» est basé sur l’adresse e-mail du destinataire. Si le destinataire n’appartient pas à liste des utilisateurs de l’entreprise, la connexion est alors coupée et le message rejeté.
Le deuxième niveau « Reputation Database » est un blocage basé sur l’adresse IP de l’émetteur. FOPE dispose d’une base de données actualisée en permanence, contenant la liste des spammeurs à travers le monde. La connexion est alors coupée et le message rejeté.
Il est possible de mettre des exceptions en spécifiant dans une Policy Rule, l’adresse IP de l’émetteur.
Le troisième niveau « Fingerprint Engine » est une analyse à base de signatures.
Si un courrier correspond à un spam connu, celui-ci est rejeté.
Le quatrième niveau « Rules-Based Scoring » est une analyse comportementale/heuristique attribuant un score à chaque e-mail selon plus de 20.000 règles, dont Sender Policy Framework (SPF).
Il est possible d’activer des règles supplémentaires connues sous le nom de «Custom Spam Filter Management ».

1. Si le score dépasse le seuil maximum toléré, le message est automatiquement rejeté.

2. Si le score est borné entre le seuil minimum et maximum, le message est considéré comme un spam.
Il peut être alors redirigé, mis en quarantaine Web, délivré en changeant le sujet ou délivré en ajoutant un X-Header personnalisé.

3. Si le score est inférieur à un seuil minimum, le message est considéré comme légitime.