[Microsoft Channel 9] - The best way to watch and understand all Microsoft technologies!

Et oui! Microsoft a sa propre chaîne TV! Cette Web TV vous permet de visionner tous les webcasts Microsoft sur n'importe quelle technologie soit pour vous donner une vue d'ensemble de celle-ci comme les nouveautés dans Active Directory 2012 mais aussi sur une partie bien spécifique - Intégration d'Active Directory avec Office 365.

Tous les webcasts concernant le sujet Active Directory sont disponibles en se rendant à l'adresse - http://channel9.microsoft.com/search?term=active+directory

 

Voici l'ensemble des ressources disponibles sur cette chaîne :

Blogs - http://channel9.microsoft.com/Browse/Blogs

Series - http://channel9.microsoft.com/Browse/Series

Shows - http://channel9.microsoft.com/Browse/Shows

Events - http://channel9.microsoft.com/Browse/Events (dont les fameux Microsoft TechEd et Imagine Cup!)

 

Ressource :

MICROSOFT CHANNEL 9 - http://channel9.microsoft.com/

Posted by Jordan Laurent | with no comments
Filed under: ,

[Microsoft Events] - Keep in touch with Microsoft technologies in live!

 

Comme vous le savez, Microsoft organise beaucoup d'évènements de part le monde tout au long de l'année! Le plus connu d'entre eux (surtout en Europe) est sans aucun doute le fameux Microsoft TechDays, la session 2014 s'est déroulée les 12, 13 et 14 février dernier au Palais des Congrès de Paris et des informations seront fournies sur les TechDays en Suisse dès l'été 2014!

Comment s'inscrire ou suivre les autres évènements Microsoft? Suivez le file... ;)

 

Note : Vous pouvez revivre les sessions des TechDays 2013 et 2014 en Français en cliquant sur les liens ci-dessous :)

 

  1. Microsoft Events (ces évènements sont réparties en 4 catégories - In-person Events / Live webcasts / On-demand webcasts / Virtual Labs)
    1. Evénements en Anglais : https://msevents.microsoft.com/cui/default.aspx?culture=en-US
    2. Evénements en Français (France) : https://msevents.microsoft.com/cui/default.aspx?culture=fr-fr
    3. Evénements en Français (Suisse) :  https://msevents.microsoft.com/cui/default.aspx?culture=fr-ch

 

Vous l'aurez donc compris, ces liens sont tout simplement le planning annuel des différents événements Microsoft (salons, présentations, webcasts, démonstrations) sur leurs différentes technologies. Ceux-ci peuvent savérer très pratique suivant l'endroit ou vous vous trouvrerez à une date précise ou le suivre directement depuis votre bureau confortablement installé!


Note : Attention, certains évènements requièrent une inscription préalable.



Posted by Jordan Laurent | with no comments

[Lab Guides/Trainings] - Active Directory Lab Guides. Let's do It :)

Besoin de construire un POC (Proof of Concept) pour tester un nouvel applicatif Microsoft, démontrer une solution devant votre management ou encore rester à la pointe de la technologie Microsoft? Tout le monde aimerait pouvoir mais trouver un "step-by-step" clair et conséquent n'est pas souvent chose facile...Alors comment faire?

En utilisant deux programmes Microsoft dédié aux tests de leurs nouvelles technologies :

 

Vous trouverez ci-dessous la liste des TLGs et MVA disponibles chez Microsoft concernant - le sujet de ce blog - Active Directory!

 

Active Directory - Test Lab Guides (TLGs)

Introducing the first Windows Server 2012 Domain Controller (Part 1) - http://blogs.technet.com/b/askpfeplat/archive/2012/09/03/introducing-the-first-windows-server-2012-domain-controller.aspx

Introducing the first Windows Server 2012 Domain Controller (Part 2) - http://blogs.technet.com/b/askpfeplat/archive/2012/09/06/introducing-the-first-windows-server-2012-domain-controller-part-2-of-2.aspx

Deploy Windows Firewall with Advanced Security to Protect Network Communication to a Domain Controller - http://www.microsoft.com/en-us/download/details.aspx?id=20453

Creating a Windows Azure AD and Windows Server Environment using DirSync with Password Sync - http://www.microsoft.com/en-us/download/details.aspx?id=41637

Creating a Windows Azure AD and Windows Server Environment with Federation (SSO) - http://www.microsoft.com/en-us/download/details.aspx?id=41636

Deploying an AD CS Two-Tier PKI Hierarchy - http://technet.microsoft.com/en-us/library/hh831348.aspx

Deploying an AD RMS Cluster - http://technet.microsoft.com/en-us/library/adrms-test-lab-guide-base.aspx

Install AD FS 2.0 - Active Directory Federation Services - http://social.technet.microsoft.com/wiki/contents/articles/11846.test-lab-guide-mini-module-install-ad-fs-2-0.aspx

 

Active Directory - Microsoft Virtual Academy (MVA)

Understanding Active Directory - http://www.microsoftvirtualacademy.com/training-courses/understanding-active-directory#?fbid=QnujfJ354FS

Active Directory Deployment and Management Enhancements - http://go.microsoft.com/?linkid=9838440

Windows Server 2008 R2 - What's New in Active Directory - http://go.microsoft.com/?linkid=9701967

Windows Server 2008 R2 - Active Directory and Server Manager Remoting - http://go.microsoft.com/?linkid=9694256

Windows Server 2008 R2 - Active Directory Recycle Bin, PowerShell v2, and Remoting - http://go.microsoft.com/?linkid=9694257

Windows Server 2012 - New Domain Controller Deployment and Dynamic Access Control - http://go.microsoft.com/?linkid=9822813

Migrating Active Directory to Windows Server 2012 R2 - http://go.microsoft.com/?linkid=9842894

Office 365 - Installing and Configuring Active Directory Synchronization - http://go.microsoft.com/?linkid=9836753

Windows Server 2012 R2 - New Features in AD FS - http://go.microsoft.com/?linkid=9842896

Windows Server 2012 R2 - Implementing Claims-Aware Applications - http://go.microsoft.com/?linkid=9836552

Office 365 - Preparing your environment for Active Directory Federation Services - http://go.microsoft.com/?linkid=9836750

Office 365 - Installing and Configuring Active Directory Federation Services - http://go.microsoft.com/?linkid=9836751

Office 365 - Adding and Verifying Federated Domains - http://go.microsoft.com/?linkid=9836752

 

Ressources :

Virtual Labs System Requirements - http://technet.microsoft.com/en-us/virtuallabs/dn336436.aspx

TLGs - Base Configurations - http://blogs.technet.com/b/tlgs/archive/2014/02/04/three-types-of-base-configurations.aspx

Posted by Jordan Laurent | with no comments
Filed under: ,

[Security] - Protocoles et systèmes d'authentifications, partie 3.3.2 - Protocoles d'authentifications - Digest Authentication

[Security] - Protocoles et systèmes d'authentifications, partie 1 - Introduction aux systèmes d'authentifications - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/04/security-protocoles-et-syst-232-mes-d-authentifications-partie-1-introduction-aux-syst-232-mes-d-authentifications.aspx

[Security] - Protocoles et systèmes d'authentifications, partie 2 - Comprendre comment Windows stocke et gère votre identité au sein du réseau d'entreprise - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/07/security-protocoles-et-syst-232-mes-d-authentifications-partie-2-comprendre-comment-windows-stocke-et-g-232-re-votre-identit-233-au-sein-du-r-233-seau-d-entreprise.aspx

[Security] - Protocoles et systèmes d'authentifications, partie 3.1 - Protocoles d'authentifications - Local Authentication - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/09/security-protocoles-et-syst-232-mes-d-authentifications-partie-3-1-protocoles-d-authentification-local-authentication.aspx

[Security] - Protocoles et systèmes d'authentifications, partie 3.2 - Protocoles d'authentifications - Basic Authentication - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/20/security-protocoles-et-syst-232-mes-d-authentifications-partie-3-2-protocoles-d-authentification-basic-authentication.aspx


[Security] - Protocoles et systèmes d'authentifications, partie 3.3.1 - Protocoles d'authentification - Introduction aux Challenge-Response Protocols - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/23/security-protocoles-et-syst-232-mes-d-authentifications-partie-3-3-1-protocoles-d-authentifications-challenge-response-protocols-digest-authentication.aspx

 

Suite des explications sur les protocoles d'authentifications :)

 

  • A quoi sert le protocole d'authentification Digest?

L'authentification Digest n'est pas un protocole d'authentification natif dans Windows...Le protocole d'authentification Digest à été conçu pour remplacer l'authentification de base (Basic Authentication - partie 3.2 de cet article). Il est toutefois considéré comme relativement faible parce qu'il fait quelques compromis sur la sécurité avec le serveur d'authentification.

Il est principalement utilisé avec les services IIS (Internet Information Services) pour l'authentification web mais aussi le protocole d'annuaire LDAP (Lightweight Directory Access Protocol).

 

  • Quelle est la séquence brut d'une authentification Digest?
  1. Le serveur d'authentification génère un nombre aléatoire ("nonce") et l'envoit au client.
  2. Le client calcule un hash MD5 (Message Digest v5) du nom d'utilisateur, de son mot de passe et du domaine Windows.
  3. Le client calcule un hash MD5 de la méthode et l'URI Digest
  4. Le client calcule un hash MD5 du résultat de l'étape 2, le nonce du serveur , un compteur de requêtes, le nonce client, un code de protection qualité et le résultat de l'étape 3.
  5. Cette valeure finale sera la réponse fournie par le client au serveur d'authentification et le serveur calculera à son tour ces même valeurs pour comparaison.

 

  • Le protocole d'authentification Digest est-il sécurisé?

Dire que l'authentification Digest est plus sécurisé que l'authentification de base est correcte mais la principale préoccupation de l'authentification Digest survient lors de l'étape 2. En effet, la réponse du client est calculé avec le mot de passe réel de l'utilisateur (et non un hash de ce mot de passe). Cela signifie que pour valider la réponse du client, le serveur doit avoir accès au mot de passe en !!texte clair!! (plain text) à l'étape 5.

Si l'utilisation de l'authentification Digest est une nécessité (applicative par exemple), vous devriez configurer votre annuaire Active Directory afin de stocker les mots de passes avec l'option de cryptage réversible - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/07/security-protocoles-et-syst-232-mes-d-authentifications-partie-2-comprendre-comment-windows-stocke-et-g-232-re-votre-identit-233-au-sein-du-r-233-seau-d-entreprise.aspx

 

  • Cas réel : Demande d'accès à du contenu renvoyé par un serveur web IIS

  1. Le client effectue une demande d'accès à travers les services IIS à un fichier de l'entreprise.
  2. Le serveur exécutant IIS refuse cette demande et envoie au client les informations ci-dessous,
    1. L'authentification Digest est le protocole d'authentification utilisé
    2. Le nom de domaine de connexion (Active Directory dans notre exemple).
  3. Le navigateur invite alors le client à entrer son nom d'utilisateur et son mot de passe. Ce même navigateur combine ces 2 informations avec le nom de domaine afin de créer le hash MD5 et soumet de nouveau la demande pour le fichier à partir du serveur exécutant IIS avec ce fameux hash!
  4. Une fois ce hash MD5 client reçu, le serveur IIS envoie ce même hash vers un contrôleur de domaine pour vérification.
  5. Ce contrôleur de domaine informe le serveur IIS des résultats d'authentifications.
  6. Le client peut alors accéder au fichier demandé lors de l'étape 1 si la comparaison entre le hash généré par le client et celui stocké sur le contrôleur de domaine sont équivalents.

 

Sources :

DIGEST AUTHENTICATION - RFC 2617 - https://www.ietf.org/rfc/rfc2617.txt

MD5  - RFC 1321 - http://www.ietf.org/rfc/rfc1321.txt


Posted by Jordan Laurent | with no comments
Filed under: ,

[Security] - Protocoles et systèmes d'authentifications, partie 3.3.1 - Protocoles d'authentifications - Introduction aux Challenge-Response Protocols

[Security] - Protocoles et systèmes d'authentifications, partie 1 - Introduction aux systèmes d'authentifications - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/04/security-protocoles-et-syst-232-mes-d-authentifications-partie-1-introduction-aux-syst-232-mes-d-authentifications.aspx

[Security] - Protocoles et systèmes d'authentifications, partie 2 - Comprendre comment Windows stocke et gère votre identité au sein du réseau d'entreprise - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/07/security-protocoles-et-syst-232-mes-d-authentifications-partie-2-comprendre-comment-windows-stocke-et-g-232-re-votre-identit-233-au-sein-du-r-233-seau-d-entreprise.aspx

[Security] - Protocoles et systèmes d'authentifications, partie 3.1 - Protocoles d'authentifications - Local Authentication - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/09/security-protocoles-et-syst-232-mes-d-authentifications-partie-3-1-protocoles-d-authentification-local-authentication.aspx

[Security] - Protocoles et systèmes d'authentifications, partie 3.2 - Protocoles d'authentifications - Basic Authentication - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/20/security-protocoles-et-syst-232-mes-d-authentifications-partie-3-2-protocoles-d-authentification-basic-authentication.aspx

[Security] - Protocoles et systèmes d'authentifications, partie 3.3.2 - Protocoles d'authentification - Digest Authentication - http://danstoncloud.com/blogs/jordanlaurent/archive/2014/01/10/security-protocoles-et-syst-232-mes-d-authentifications-partie-3-3-2-protocoles-d-authentifications-digest-authentication.aspx

 

Les protocoles d'authentification de la "famille" Challenge-Response Protocols sont construits afin d'éviter de transmettre un mot de passe en clair sur le réseau.

Le modèle de base d'un protocole Challenge-Response ("Défi-Réponse") est le suivant,

  1. Un utilisateur lance une connexion (donc une demande d'accès à un serveur)
  2. Le serveur créé alors un "Challenge" - c'est-à-dire qu'il propose un "défi" à l'utilisateur pour prouver qu'il est bien celui qu'il prétend être - (qui est souvent une valeur aléatoire) et l'envoie à cet utilisateur.
  3. Le client (ordinateur) a collecté les informations d'identifications de l'utilisateur qui seront combinés avec le challenge d'une opération de chiffrement.
  4. Le résultat sera la réponse qui sera envoyé au serveur.

 

 

  • Quels sont les protocoles d'authentifications de la famille Challenge-Response Protocols supportés par Windows?

Ces protocoles d'authentifications prise en charge nativement par Windows sont les protocoles Digest, LM (Lan Manager), NTLM v1 & v2 (New Technology Lan Manager) et bien sûr...le protocole Kerberos.

Dans les parties suivantes, nous verrons en détail le fonctionnement de ces protocoles d'authentifications!

 

Rendez-vous en 2014...et joyeuses fêtes de fin d'année à tous :)

Posted by Jordan Laurent | with no comments
Filed under: ,

[Security] - Protocoles et systèmes d'authentifications, partie 3.2 - Protocoles d'authentification - Basic Authentication

[Security] - Protocoles et systèmes d'authentifications, partie 1 - Introduction aux systèmes d'authentifications - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/04/security-protocoles-et-syst-232-mes-d-authentifications-partie-1-introduction-aux-syst-232-mes-d-authentifications.aspx

[Security] - Protocoles et systèmes d'authentifications, partie 2 - Comprendre comment Windows stocke et gère votre identité au sein du réseau d'entreprise - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/07/security-protocoles-et-syst-232-mes-d-authentifications-partie-2-comprendre-comment-windows-stocke-et-g-232-re-votre-identit-233-au-sein-du-r-233-seau-d-entreprise.aspx

[Security] - Protocoles et systèmes d'authentifications, partie 3.1 - Protocoles d'authentifications - Local Authentication - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/09/security-protocoles-et-syst-232-mes-d-authentifications-partie-3-1-protocoles-d-authentification-local-authentication.aspx

[Security] - Protocoles et systèmes d'authentifications, partie 3.3.1 - Protocoles d'authentification - Introduction aux Challenge-Response Protocols - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/23/security-protocoles-et-syst-232-mes-d-authentifications-partie-3-3-1-protocoles-d-authentifications-challenge-response-protocols-digest-authentication.aspx

[Security] - Protocoles et systèmes d'authentifications, partie 3.3.2 - Protocoles d'authentification - Digest Authentication - http://danstoncloud.com/blogs/jordanlaurent/archive/2014/01/10/security-protocoles-et-syst-232-mes-d-authentifications-partie-3-3-2-protocoles-d-authentifications-digest-authentication.aspx

 

Suite des protocoles d'authentifications! A quoi peut bien servir le protocole Basic Authentication? Suivez le file...et bonne lecture :)

La méthode d'authentification basique est une méthode standard de l'industrie largement utilisé pour la collecte de nom d'utilisateur et de mot de passe. Lorsque vous utilisez l'authentification basique, le navigateur affiche une boîte de dialogue dans laquelle les utilisateurs doivent entrer un compte Windows - qui comporte également un nom de domaine, par exemple, LABENV\jordan.laurent - et son mot de passe.

 

L'authentification basique est donc la forme la plus simple de toutes les formes d'authentifications! L'inconvénient est que celle-ci transmet simplement les informations brutes de connexions à travers le réseau...En d'autres termes, le nom d'utilisateur et son mot de passe sont envoyés à travers le réseau en texte clair - le mot de passe en clair, sera, cependant, codé en Base64 avant d'être transmis sur le réseau.

 

  • Le codage Base64 encrypte t'il votre mot de passe?...

NON! Le codage Base64 n'encrypte en aucun cas votre mot de passe! Si un mot de passe encodé en Base64 est interceptée par un analyseur de réseau, les utilisateurs non autorisées pourront facilement le décoder et réutiliser celui-ci. C'est pourquoi l'authentification basique n'est pas recommandée.

 

  • Quels protocoles de connexions utilisent ce protocole d'authentification?

L'authentification basique est assez répandue dans les "anciens" protocoles de connexions réseaux. Telnet, FTP, POP, IMAP...et même HTTP l'utilise.

 

  • Comment sécuriser une authentification basique?

Si la connexion entre l'utilisateur et le serveur prenant en charge l'authentifictation basique a été sécurisé grâce à une connexion SSL (Secure Sockets Layer) ou encore une ligne de transmission dédiée, alors votre authentification type basique sera sécurisée. Préférez donc l'utilisation des protocoles de connexions ci-dessous si vous activez le protocole d'authentification Basic Authentication,

 - TELNETS - TErminaL NETwork over TLS/SSL - port 992

 - FTPS - File Transfer Protocol over TLS/SSL - port 989 (data) & 990 (control)

 - POP3S - Post Office Protocol v3 over TLS/SSL - port 995

 - IMAP4S - Internet Message Access Protocol v4 over TLS/SSL - port 993

 - HTTPS - HyperText Transfer Protocol over TLS/SSL - port 443

 

  • Cas spécifique : la mise en cache des identifiants lors d'une connexion à un serveur web Microsoft IIS (Internet Information Services)

Lorsque vous activez l'authentification basique, le jeton d'authentification de l'utisateur (user token) est mis en cache dans le cache de jeton (token cache). Par défaut, celui-ci restera dans ce cache pendant 15 minutes. Si vous vous connectez en utilisant l'authentification basique avec un compte qui a un niveau élevé d'autorisations (ex : administrateur), un attaquant pourrait utiliser ce compte pour accéder aux ressources de votre ordinateur...

Il existe donc plusieurs méthodes pour contourner ce problème de sécurité,

 * Ne pas autoriser les comptes qui ont un niveau élevé d'autorisations à se connecter à l'un de vos système en utilisant l'authentification basique.

 * Reconfigurer la valeur de l'entrée de registre "UserTokenTTL" à moins de 15 minutes.

 * Désactiver la mise en cache du jeton de l'utilisateur en définissant la valeur de l'entrée de registre "UserTokenTTL" à 0.

 

Beaucoup de services Microsoft implémentés en entreprise utilisent le serveur web IIS pour le rendu utilisateur ou administrateur,

 - Microsoft Exchange

 * Lors de l'accès au webmail à travers l'interface OWA (Outlook Web App) - répertoire virtuel OWA.

 * Lors de l'accès à la console d'administration EAC (Exchange Admin Center - depuis Exchange 2013 seulement) ou au "panneau de configuration utilisateur" ECP (Exchange Control Panel) - répertoire virtuel ECP.

 

 - Microsoft Lync

 Lors de l'accès à la console d'administration LCP (Lync Control Panel) - répertoire virtuel CSCP

 

 - Microsoft SharePoint

 * Tous les sites SharePoint créés au sein de votre entreprise fonctionnent au niveau utilisateur et administrateur à travers le service IIS.


Sources :

GLOBAL REGISTRY ENTRIES FOR IIS - http://technet.microsoft.com/en-us/library/cc782380(v=ws.10).aspx

HTTP AUTHENTICATION RFC 2617 - http://www.ietf.org/rfc/rfc2617.txt

Posted by Jordan Laurent | with no comments
Filed under: ,

[Microsoft Tools] - LogonSessions tool - Lister les sessions actives d'un ordinateur locale ou d'un contrôle de domaine

 

On se pose souvent la question en tant qu'administrateur...Comment lister toutes les sessions actives d'un ordinateur locale ou d'un contrôleur de domaine? Nous avons la possibilité en effet de passer par le gestionnaire des tâches et d'aller dans l'onglet "Utilisateurs". Malheureusement, vous ne trouverez dans cette liste que les utilisateurs qui ont ouvert une session interactive (physique) avec votre machine mais surtout vous n'aurez que très peu d'informations sur les caractéristiques de celles-ci...

Alors comment faire? La suite Sysinternals de Mark E. Russinovich racheté en 2006 par Microsoft contient une fabuleuse liste d'outils dont un, développé par Bryce Cogswell, qui porte le nom de "LogonSessions" - http://technet.microsoft.com/en-us/sysinternals/bb896769

Vous obtiendrez non seulement la liste des deux types de sessions ouvertes sur la machine (interactives et réseau) mais aussi de nombreuses informations :

 - Nom d'utilisateur / User name

 - Package d'authentification utilisé (Kerberos, NTLM, Negociate, etc.) / Auth package

 - Type de session (1 signifie session console / interactive. 0 signifie session à distance / réseau) / Logon type

 - SID de l'utilisateur connecté / Sid

 - La date et l'heure de connexion / Logon time

 - Le serveur qui à authentifié cette session / Logon server

 - Le domain DNS associé / DNS Domain

 - Le nom complet de l'utilisateur / UPN (User Principal Name) = User Logon Name (UN Prefix) @ Domain Name (UN Suffix)

 

Ressources :

MICROSOFT SYSINTERNALS SUITE - http://technet.microsoft.com/en-us/sysinternals/bb842062.aspx 

Posted by Jordan Laurent | with no comments

[Active Directory] - Acronymes Active Directory...avec leurs définitions!

 

En tant qu'informaticien, nous avons la joie de savoir qu'il existe plusieurs centaines (voir milliers mais je n'ai pas compté :) ) d'acronymes et d'abréviations quelque soit la technologie utilisée dans le monde des réseaux, des systèmes, des bases de données...et bien souvent même si on ne peut tous les apprendre, il est intéressant de connaître les acronymes des protocoles standard et ceux liés à la technologie dont nous avons fait notre expertise! Lors des phases de design, des diagrammes d'architectures, pendant les réunions de vos différents projets, il est essentiel de savoir ce dont vous parlez. Dans le cas d'Active Directory, vous avez dû remarquer qu'ils ne manquent pas!

Alors incollable sur les acronymes Active Directory? ACE(s), ACL(s), CN, DACL, DN, DSRM...

Pour tout savoir c'est par ici (avec une définition pour chacun d'entre eux)! - https://social.technet.microsoft.com/wiki/contents/articles/16757.active-directory-glossary.aspx

Posted by Jordan Laurent | with no comments
Filed under:

[Security] - Protocoles et systèmes d'authentifications, partie 3.1 - Protocoles d'authentification - Local Authentication

[Security] - Protocoles et systèmes d'authentifications, partie 1 - introduction aux systèmes d'authentifications  - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/04/security-protocoles-et-syst-232-mes-d-authentifications-partie-1-introduction-aux-syst-232-mes-d-authentifications.aspx

[Security] - Protocoles et systèmes d'authentifications, partie 2 - comprendre comment Windows stocke et gère votre identité au sein du réseau d'entreprise - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/07/security-protocoles-et-syst-232-mes-d-authentifications-partie-2-comprendre-comment-windows-stocke-et-g-232-re-votre-identit-233-au-sein-du-r-233-seau-d-entreprise.aspx

[Security] - Protocoles et systèmes d'authentifications, partie 3.2 - Protocoles d'authentification - Basic Authentication - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/20/security-protocoles-et-syst-232-mes-d-authentifications-partie-3-2-protocoles-d-authentification-basic-authentication.aspx

[Security] - Protocoles et systèmes d'authentifications, partie 3.3.1 - Protocoles d'authentification - Introduction aux Challenge-Response Protocols - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/23/security-protocoles-et-syst-232-mes-d-authentifications-partie-3-3-1-protocoles-d-authentifications-challenge-response-protocols-digest-authentication.aspx

[Security] - Protocoles et systèmes d'authentifications, partie 3.3.2 - Protocoles d'authentification - Digest Authentication - http://danstoncloud.com/blogs/jordanlaurent/archive/2014/01/10/security-protocoles-et-syst-232-mes-d-authentifications-partie-3-3-2-protocoles-d-authentifications-digest-authentication.aspx


Dans la 1ère et 2e partie de cet article, nous avons discuté de la façon dont les mots de passe sont stockés au sein de Windows. C'est une première étape...mais quels sont les mécanismes utilisés pour vous authentifier sur votre machine locale ou sur un réseau d'entreprise? C'est parti...!! Afin que cela soit plus clair pour tout le monde et afin d'éviter d'écrire plusieurs centaines de lignes au sein d'un même billet ;) cette 3e partie sera découpé en plusieurs sous-parties! Voici les points qui y seront abordés;

Partie 3.1 - Local Authentication

Partie 3.2 - Basic Authentication

Partie 3.3.1 - Introduction aux Challenge-Response Protocols

Partie 3.3.2 - Challenge-Response Protocols - Digest Authentication

Partie 3.3.3 - Challenge-Response Protocols - LM et NTLM v1

Partie 3.3.4 - Challenge-Response Protocols - NTLM v2 et NTLM ++

Partie 3.3.5 - Challenge-Response Protocols - Kerberos

 

  • Processus et sous-systèmes intervenants lors de l'authentification locale
  1. Windows Logon Application - Processus WINLOGON.EXE
  2. Local Security Authority SubSystem - LSASS
  3. Authentication Package - MSV1_0
  4. Graphical Identification and Authentication (GINA) dynamic link-library (DLL) - Windows NT 3.1 à Windows NT 5.1 (XP/2003) / Credential Providers - à partir de Windows NT 6.0 (Vista/2008)

  • Authentification locale ("version simplifiée")
  1. L'utilisateur tape la combinaison CTRL+ALT+SUPPR  (SAS - Secure Attention Sequences  ou encore SAK - Secure Attention Keys). Cela provoque le sous-système d'autorité de sécurité locale (LSASS - Local Security Authority Subsystem Service) pour faire appel à une nouvelle session et charger le processus WinLogon.exe (Windows Logon Application) dans cette session. Winlogon.exe charge à son tour le processus LogonUI.exe (Windows Logon User Interface).
  2. L'utilisateur rentre ses identifiants (nom d'utilisateur + mot de passe).
  3. Le processus Winlogon.exe récupère la valeur du mot de passe, le "hash" en un hash NT (souvenez-vous de la 2e partie de cet article!), recherche le nom d'utilisateur dans la base SAM (Security Accounts Manager) locale, et compare les valeurs du hash NT reçu de l'utilisateur à celui qui est stocké dans cette même base SAM. Si les deux correspondent, la connexion est réussie :) Sinon, try again :(
  4. Si certains packages de sous-authentification sont installés sur l'ordinateur (cela sera traité dans la 4e partie de cet article), les informations de logon sont transférés à celles-ci pour un traitement supplémentaire. Dans le cas contraire, Userinit.exe est appelé et l'environnement de l'utilisateur est chargé.

 Ce processus est assez simple car il y a une transmission sécurisée (secure channel) tout au long du chemin d'authentification géré par le processus LogonUI.exe, qui récupère les identifiants des utilisateurs afin de les comparer aux informations contenues dans la base SAM. Toutefois, lorsque l'authentification est non plus locale mais réseau, le processus devient un peu plus compliqué parce que vous devez vous soucier de la façon dont les informations d'authentification sont échangées entre le client et le serveur d'authentification (AS - Authentication Server) qui héberge la base de données des comptes Active Directory (NTDS.DIT - New Technology Domain Services . Directory Information Tree)...ce qui sera traité dans la suite de cette 3e partie!

 

  • Authentification locale (version détaillée)

Phase 1 - Initialisation du système

  1. Winlogon.exe crée et ouvre une session Windows interactive pour représenter les périphériques essentiels à l'ordinateur (Clavier, souris et moniteur) - \Sessions\1\Windows\WindowStations\WinSta0 dans le gestionnaire d'objet.
  2. Winlogon.exe crée ensuite un descripteur de sécurité unique de la station qui a une seule ACE (Access Control Entry) ne contenant que le SID (Security IDentifier) du système (Ce descripteur garantit qu'aucun autre processus ne peut accéder au poste de travail, sauf si Winlogon.exe l'y autorise)
  3. Winlogon.exe crée et ouvre deux bureaux : un bureau d'application (interactive desktop - \Sessions\1\Windows\WinSta0\Default) - Seul Winlogon.exe pourra accéder à celui-ci, et un bureau Winlogon (secure desktop - \Sessions\1\Windows\WinSta0\Winlogon) - Winlogon.exe et les utilisateurs pourront y accéder. Cela signifie qu'à chaque fois que le bureau Winlogon est actif, aucun autre processus aura accès à un code actif ou des données associées de votre poste de travail. Avant que l'utilisateur ne fasse la séquence de touches sécurisés (CTRL+ALT+SUPPR), seul ce bureau sécurisé sera actif.
  4. Dès lors que l'utilisateur se connecte et effectue cette séquence, Winlogon.exe passe le relais à Logon UI (Cela explique pourquoi toutes les fenêtres de votre bureau interactif semblent disparaître lorsque vous appuyez sur CTRL+ALT+SUPPR puis revenir quand vous fermez la boîte de dialogue de sécurité de Windows :) )
  5. Winlogon.exe établit ensuite une connexion avec une classe ALPC (Advanced Local Procedure Call)  et utilise la fonction LsaAuthenticationPort du sous-système de sécurité locale (LSASS) pour échanger les informations de connexions, de déconnexions et des opérations de mots de passe en appelant  cette fois-ci la fonction LsaRegisterLogonProcess.
  6. Winlogon.exe initialise et enregistre une structure de données de type fenêtre qui associe une procédure Winlogon avec la fenêtre créée ensuite.
  7. Winlogon.exe enregistre les notifications Winlogon RPC, qui écoute les notifications de la séquence de touches sécurisées de Win32k.sys . Cette mesure empêche les chevaux de Troie de prendre le contrôle de l'écran lorsque le SAS est entré.
  8. Winlogon.exe enregistre la fenêtre pour que la procédure associée à cette fenêtre soit appelée si un utilisateur se déconnecte ou si l'ordinateur se met en veille. Le sous-système Windows vérifie alors que le processus de demande de notification est bien le processus Winlogon.exe

Une fois que le bureau sécurisé Winlogon est créé durant l'initialisation, il devient le bureau actif. Lorsque le bureau Winlogon est actif, il est toujours verrouillée. Winlogon.exe déverrouille seulement son bureau pour basculer vers le "bureau d'application" (celui de l'utilisateur) ou le "bureau de l'économiseur de veille"  (screen-saver dekstop). Seul le processus Winlogon.exe peut verrouiller ou déverrouiller un bureau.

Phase 2 - Authentification de l'utilisateur

  1. L'étape d'authentification commence quand un utilisateur appuie sur CTRL + ALT + SUPPR. Après que la séquence de touches sécurisée (SAS) soit pressé, le processus Winlogon.exe démarre donc à son tour le processus LogonUI.exe, celui-ci appelle les fournisseurs d'informations d'identification pour obtenir un nom d'utilisateur et mot de passe. Winlogon.exe crée également un SID d'ouverture de session local unique pour cet utilisateur qu'il attribue à cette instance de l'ordinateur de bureau (clavier, écran, et souris). Cela signifie qu'à un utilisateur correspond un SID d'ouverture de session local unique (logique!). Winlogon.exe passe ce SID au sous-système de sécurité LSASS dans le cadre de l'appel LsaLogonUser. Si l'utilisateur est connecté avec succès, ce SID sera inclus dans le jeton (token) d'ouverture de session.
  2. Lorsque la combinaison "nom d'utilisateur + mot de passe" ont été entrés, le processus Winlogon.exe récupère une poignée pour un forfait en appelant la fonction LsaLookupAuthenticationPackage du sous-système de sécurité (LSASS). Les paquets d'authentification sont localisés dans le registre sous HKLM\SYSTEM\CurrentControlSet\Control\Lsa. Winlogon.exe transmet alors les informations de connexion au package d'authentification grâce à la fonction LsaLogonUser. Lorsque le package authentifie l'utilisateur, Winlogon.exe poursuit le processus d'ouverture de session pour celui-ci (si aucun paquets d'authentification indique une connexion réussie, le processus d'ouverture de session s'interrompt).
  3. Windows utilise deux paquets d'authentification standard pour les connexions interactives: Kerberos et MSV1_0.
    1. Le package d'authentification par défaut sur ​​un système Windows locale est MSV1_0 contenue dans le répertoire %SystemRoot%\System32\Msv1_0.dll. LSASS l'utilise également sur les ordinateurs qui ne peuvent pas localiser un contrôleur de domaine.
    2. Le package d'authentification Kerberos contenue dans le répertoire %SystemRoot%\System32\Kerberos.dll, est utilisé sur les ordinateurs qui sont membres de domaines Active Directory.
  4. Le package d'authentification MSV1_0 prend le nom d'utilisateur ainsi que le hash du mot de passe et envoie une requête à la SAM locale pour récupérer les informations de compte, ce qui inclut le mot de passe, les groupes auxquels l'utilisateur appartient, les restrictions de compte et l'identifiant unique local (LUID - Locally Unique IDentifier) qui formeront le jeton locale d'authentification, plus connu sous le nom de logonID!
    1. MSV1_0 vérifie d'abord les restrictions de compte, tels que les heures ou le type d'accès autorisé (si l'utilisateur ne peut pas se connecter en raison des restrictions dans la base de données SAM, l'appel de connexion échoue et MSV1_0 renvoie un état d'échec à la LSA).
    2. MSV1_0 compare ensuite le hash du mot de passe et le nom d'utilisateur fournis par l'utilisateur à ceux stockés dans la base SAM.

Phase 3 - Chargement de la session utilisateur

  1. Winlogon.exe regarde dans le registre l'entrée Userinit dans HKLM\SOFTWARE\Microsoft\Windows NT\Current Version\Winlogon\Userinit et crée un processus pour exécuter la valeur de cette chaîne. La valeur par défaut est Userinit.exe
  2. Userinit.exe charge le profil de l'utilisateur et crée un processus pour exécuter ce que vaut la valeur de HKCU\SOFTWARE\Microsoft\Windows NT\Current Version\ Winlogon\Shell. Cette valeur n'existe pas par défaut.
  3. Si elle n'existe pas, Userinit.exe exécute un second processus pour lire la valeur du Shell dans HKLM\SOFTWARE\Microsoft\Windows NT\Current Version\Winlogon\Shell, qui est par défaut Explorer.exe

 

  • A propos de la combinaison de touches "CTRL + ALT + SUPPR" et des rumeurs sur son utilité...

"Lorsque nous avons conçu NT 3.1, l'une des questions qui est venu était la séquence de touche sécurisée - nous avions besoin d'une séquence de touches qui ne pouvait être intercepté par n'importe quelle application. Il s'est avéré que seule combinaison de touches qui n'était déjà pas utilisée par un autre système d'exploitation était CTRL + ALT + SUPPR. Et ainsi est né cette combinaison de touches permettant de vous connecter..." Jim Kelly, Security Architect - Windows NT.

La SAS (Secure Attention Sequence) est sécurisée car aucune application ne peut intercepter la combinaison de touches CTRL + ALT + SUPPR. Comment? C'est le processus Win32k.sys qui réserve cette combinaison de touches afin que chaque fois que le système d'entrée de Windows intercepte celle-ci (mis en œuvre dans un thread d'entrée spécifique à l'intérieur de Win32k.sys), il envoie un message RPC (Remote Procedure Call)  vers le processus Winlogon.exe  (qui est à l'écoute de notifications d'authentification). Les touches frappés au clavier qui correspondent à une touche de raccourci enregistrée (donc connus par le système d'exploitation) ne sont jamais envoyés à un processus autre que celui qui l'a enregistrée, et seul le thread qui a enregistré cette touche de raccourci peut annuler son inscription, donc un cheval de Troie (Trojan horse) ne pourra pas prendre possession du processus Winlogon.exe.

Un hacker serait-il capable de prendre possession ce thread spécifique à Win32k.sys...?

Une fonction spécifique de Windows, SetWindowsHook, permet à une application d'installer une "procédure de crochet" qui est invoqué à chaque fois qu'une touche est enfoncée sur le clavier (avant même que les touches de raccourci soit traitées). Néanmoins,  le code du noyau de Windows contient un cas particulier pour la combinaison de touches CTRL + ALT + SUPPR qui désactive ces "crochets" de sorte que la séquence de touches ne soit pas intercepté . De plus, si votre session est verrouillé, seules les touches de raccourci appartenant à Winlogon.exe seront traitées!
 

 

  • Architecture de l'authentification locale avant Windows NT 6.0

 

  • Architecture de l'authentification locale à partir de Windows NT 6.0

 

 

 

Sources :

INITIALIZING WINLOGON - http://msdn.microsoft.com/en-us/library/windows/desktop/aa375994(v=vs.85).aspx

HOW INTERACTIVE LOGON WORKS? - http://technet.microsoft.com/en-us/library/cc780332(v=ws.10).aspx#w2k3tr_intlg_how_rmil

MSV1_0 AUTHENTICATION PACKAGE - http://msdn.microsoft.com/en-us/library/windows/desktop/aa378753(v=vs.85).aspx

WINDOWS INTERNALS - http://technet.microsoft.com/en-us/sysinternals/bb963901.aspx

ALPC CLASS - http://msdn.microsoft.com/en-us/library/windows/desktop/aa964738(v=vs.85).aspx

SETWINDOWSHOOK FUNCTION - http://msdn.microsoft.com/en-us/library/windows/desktop/ms644990(v=vs.85).aspx

Posted by Jordan Laurent | with no comments
Filed under: ,

[Security] - Protocoles et systèmes d'authentifications, partie 2 - Comprendre comment Windows stocke et gère votre identité au sein du réseau d'entreprise

[Security] - Protocoles et systèmes d'authentifications, partie 1 - introduction aux systèmes d'authentifications  - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/04/security-protocoles-et-syst-232-mes-d-authentifications-partie-1-introduction-aux-syst-232-mes-d-authentifications.aspx

[Security] - Protocoles et systèmes d'authentifications, partie 3.1 - Protocoles d'authentification - Local Authentication - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/09/security-protocoles-et-syst-232-mes-d-authentifications-partie-3-1-protocoles-d-authentification-local-authentication.aspx

[Security] - Protocoles et systèmes d'authentifications, partie 3.2 - Protocoles d'authentification - Basic Authentication - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/20/security-protocoles-et-syst-232-mes-d-authentifications-partie-3-2-protocoles-d-authentification-basic-authentication.aspx

[Security] - Protocoles et systèmes d'authentifications, partie 3.3.1 - Protocoles d'authentification - Introduction aux Challenge-Response Protocols - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/23/security-protocoles-et-syst-232-mes-d-authentifications-partie-3-3-1-protocoles-d-authentifications-challenge-response-protocols-digest-authentication.aspx

[Security] - Protocoles et systèmes d'authentifications, partie 3.3.2 - Protocoles d'authentification - Digest Authentication - http://danstoncloud.com/blogs/jordanlaurent/archive/2014/01/10/security-protocoles-et-syst-232-mes-d-authentifications-partie-3-3-2-protocoles-d-authentifications-digest-authentication.aspx

 

Lorsque vous gérez un système d'authentification, vous devez stocker plusieurs informations sur vos utilisateurs de sorte qu'elles puissent être comparées au moment de l'exécution de ce qu'ils rentreront sur leurs systèmes pour obtenir l'accès à votre réseau d'entreprise. Ce procédé d'authentification varie en fonction à la fois du type du système d'authentification et comment le concepteur a construit le système.

Dans cette partie, nous allons discuter des authentificateurs stockés dans Windows, en particulier en mettant l'accent sur ​​les mots de passe, car ils sont plus communément utilisés et soumis à beaucoup plus de variations que les cartes à puce.

Les cartes à puce reposent sur des certificats, dont la gestion sera confiée à une autorité de certification. Brièvement, la carte à puce détient la partie secrète du certificat, le système d'authentification, dans ce cas un domaine Active Directory (AD DS - Active Directory Domain Services), détient la partie publique. Lorsque vous utilisez des cartes à puce pour authentifier vos utilisateurs, aucuns "secrets" liés à la carte à puce nécessitent d'être stockées sur les contrôleurs de domaine (DC - Domain Controller), mais comme dit plus haut, seront stockées au sein d'une autorité de certification (CA - Certification Authority) elle même faisant partie intégrante de l'infrastructure à clés publiques (PKI - Public Key Infrastructure) de votre entreprise. Dans le monde Microsoft, c'est le service AD CS - Active Directory Certificate Services qui joue ce rôle.

Les mots de passe, dans pratiquement toutes leurs formes d'implémentations disponibles aujourd'hui, sont dit "à secret partagé". C'est-à-dire? Bien entendu, nous aborderons l'authentification d'un client Windows sur un réseau d'entreprise en détail, mais simplement, gardez en tête que votre serveur d'authentification contient au sein de sa base de données toutes les informations de vos utilisateurs, cela signifie que ce serveur "connaît" à l'avance quels informations (couple nom d'utilisateur + mot de passe) il devrait recevoir de la part de vos clients Windows afin que ceux-ci puissent se connecter... Les mots de passe sont donc sensibles et doivent être protégés (pour l'instant rien de nouveau :) )

Note : Dans les systèmes du début de l'ère informatique, les mots de passe étaient simplement stockés en clair dans un fichier texte... Ceux-ci n'ont jamais été vraiment destiné à empêcher les gens d'accéder à une ressource parce que seul un petit groupe de personnes y avait accès. Ils ont été principalement utilisés pour contrôler l'environnement. Aujourd'hui, la base de données contenant vos mots de passe ont été chiffrés (encryptées diront certains même si ce terme provient de nos amis anglais). 

 

  • Chiffrement(s) et Hash(s)

"Chiffrement" provient du terme cryptographie, qui littéralement signifie "écriture cachée". Le cryptage est le processus utilisé par la cryptographie pour cacher l'écriture, ou convertir un texte clair (plaintext) en texte chiffré (ciphertext). Le "décryptage" (decryption) est le processus inverse, convertir un texte chiffré en texte clair.

Le cryptage utilise la cryptographie pour convertir quelque chose dans un format illisible mais réversible, le hash est une fonction qui convertit quelque chose en format illisible et irréversible. Un hash peut, par exemple, être utilisé comme une somme de contrôle (checksum) pour comparer les deux textes en clair. Si les deux génèrent le même hash (c'est-à-dire la même valeur numérique), vous serez sûrs que les textes en clair sont identiques. Les hash(s) sont aussi beaucoup plus petit qu'un texte chiffré et sont très bien adaptés à des usages comme le stockage de mot de passe. Nous pouvons donc maintenant revenir sur façon dont la base Active Directory stocke les mots de passe de vos utilisateurs! Lorsqu'il s'authentifie, celui-ci n'envoi donc pas son mot de passe en clair mais la valeur du couple "nom d'utilisateur + mot de passe"  (à travers une fonction de hash); une fois que le serveur d'authentification la reçoit il compare cette valeur avec celle contenue dans sa base (Somme de contrôle - checksum). Si les valeurs de hash correspondent, votre session Windows se chargera! Si ces valeurs ne correspondent pas vous n'aurez pas accès à votre session et aux ressources de votre entreprise :)

 

  • Comparaison avec les systèmes UNIX

La plupart des systèmes Unix utilisent encore cette forme exacte de stockage de mot de passe, avec deux légères modifications. Tout d'abord, le fichier de mot de passe, généralement stocké dans /etc /passwd, ne contient désormais plus les hash(s) des mots de passe, mais seulement les noms d'utilisateur et les ID. Les hach(s) sont stockés dans le fichier de mot de passe caché (/etc /passwd.shadow). Bien que le fichier de mot de passe soit lisible par tous, le fichier shadow est lisible uniquement par le compte root (ou droits équivalents).

Etant donné que les mots de passe étaient à l'origine lisible dans le fichier /etc /passwd, ils devaient être protégés contre les attaques. Imaginez une situation dans laquelle vous et moi avez des comptes utilisateurs sur le même ordinateur. Mon mot de passe est "P@ssw0rd" et, par pure coïncidence, vous choisissez le même mot de passe... avec une comparaison des hash(s), nous aurions le même hash stocké dans ce fameux fichier. Je pourrais donc chercher le fichier pour mon hash puis recherchez d'autres comptes avec le même hash. Je saurai alors qui a le même mot de passe que le mien... vous serez d'accord pour dire que c'est une situation inacceptable... La solution est d'ajouter une valeur aléatoire au mot de passe (technique du "grain de sel") avant que la fonction de hash "intervienne" (principe de MD4 et MD5). De cette façon, même si les deux mots de passe sont identiques, leurs hash(s) respectifs seront différents! (Si vous souhaitez en savoir un peu plus sur la technique du grain de sel, je vous conseille de lire l'article de Guillaume Affringue - http://guillaume-affringue.developpez.com/securite/chiffrement/?page=3#LIII-B).

Windows utilise des variantes sur toutes ces techniques pour stocker les mots de passe. Rentrons maintenant dans le cœur du sujet! Quels sont les fonctions de hash(s) utilisés dans le monde Microsoft...

 

  • LM Hash

La fonction de hash LM a été d'abord utilisé par Microsoft dans son système d'exploitation réseau LAN Manager (dernière version publiée au début des années 90). LAN Manager faisait également partie intégrante du système d'exploitation OS/2 de IBM. Lorsque Windows NT a été publié en 1993, il était impératif que le nouveau système d'exploitation inter opère avec LAN Manager afin que les organisations qui avaient investi dans LAN Manager ne se retrouvent pas dans une impasse. LAN Manager à continuer d'être activé par défaut dans les différents noyaux de Windows NT pour des raisons de rétrocompatibilité pendant 13 ans, avant que Microsoft ne décide de déprécier LM à partie de la version 6.0 (Vista / Server 2008 - tout récent donc). Il peut être activé si certains systèmes de votre entreprise utilisent encore la fonction de hash LM.

Techniquement, cette fonction n'est pas réellement un hash, même si elle en utilise quelques propriétés -  il s'agit d'une fonction à sens unique - et est désigné techniquement LMOWF (LanManager One-Way Function). Le hachage LM est créé en utilisant un grand nombre d'étapes relativement compliquées...  

  1. L'utilisateur crée un nouveau mot de passe
  2. Le mot de passe est immédiatement converti en majuscules (les mots de passe stockés en utilisant la fonction de hash LM sont insensibles à la casse!).
  3. Une fois que le mot de passe soit converti en majuscules il est complété jusqu'à obtenir 14 caractères. Si le mot de passe fait déjà plus de 14 caractères (théoriquement il pourrait être tronqué), le processus échoue et le hash LM ne sera pas généré (c'est pourquoi vous obtenez un avertissement sur ​​la compatibilité avec les systèmes d'exploitation plus anciens lorsque vous définissez un mot de passe de plus de 14 caractères).
  4. Ensuite, le mot de passe est divisé en deux parties de 7 caractères chacune. La première raison est que celles-ci vont à présent être utilisées en tant que clés de cryptage (comme dans DES - Data Encryption Standard), et la seconde est que l'algorithme de cryptage de données DEA (Data Envcryption Algorithm - utilisé dans DES) opère par tranche de 56 bits (et comme vous le savez, 1 octet = 8 bits donc 7 octets = 8 bits * 7 = 56 bits! CQFD :) )
  5. Enfin, les résultats des deux opérations de DES sont concaténées et les résultats sont stockés sous le hachage LM. Le hachage est stocké soit dans la base de données SAM - Security Accounts Manager si le mot de passe est associé à un compte local ou dans l'attribut dBCSPwd de l'objet utilisateur dans Active Directory.

Cela explique pourquoi un attaquant est capable de déduire la longueur du mot de passe d'une personne juste en regardant la table de hash(s). Si la seconde moitié du hash LM est AAD3B435B51404EE, la seconde moitié du mot de passe est vide, et il ne fera pas plus de sept caractères. Si les deux moitiés sont AAD3B435B51404EE, le mot de passe est entièrement vide...

  • NT Hash

Lorsque la première version de Windows NT est sorti en 1993, une nouvelle méthode de stockage de mot de passe a été introduit. Ce mécanisme est bien plus simple que le hash LM. Le hash NT (techniquement NTOWF - New System One-Way Function) est stocké soit dans la SAM ou dans l'attribut unicodePwd de l'objet utilisateur dans Active Directory.

A noter que ni la fonction NTOWF ni LMOWF n'utilisent la technique de "grain de sel" comme dans le monde UNIX. Pourquoi c'est à noter? Tout simplement, parce que la fonction de hash NT  est finalement un dérivé de la fonction de hash bien connu - MD4 (Message Digest version 4). Microsoft n'a jamais utilisé ce procédé pour la simple et bonne raison que les bases de données de mots de passe ne sont jamais lisibles par les comptes (excepté administrateur), de telle sorte que la  recherche ne soit pas utilisé en tant que vecteur d'attaque!

NoteL'authentification NTLM se sert encore de MD4 et RC4 (méthode d'encryption) pour effectuer les comparaisons de mots de passe des noyaux Windows NT 5.1 (XP / 2003), NT 6.0 (Vista / 2008), NT 6.1 (7 / 2008 R2), NT 6.2 (8 / 2012) et NT 6.3 (8.1 / 2012 R2) lors de l'ouverture de session en locale (base SAM) - http://msdn.microsoft.com/en-us/library/cc236715.aspx. Kerberos et la méthode d'encryption AES (Advanced Encryption Standard) seront utilisés à partir de NT 6.0, si et seulement si, les ordinateurs se connectent à un domaine Active Directory (ou un annuaire informatique prenant en charge le protocole Kerberos)!

 

  • Système de vérification du mot de passe

Si vous travaillé déjà dans un environnement Active Directory, vous avez probablement remarqué que vous pouvez transporter un ordinateur portable joint au domaine avec vous et vous authentifier à l'aide d'un compte de domaine, même si vous n'êtes pas connecté à celui-ci. Ce cas particulier est opéré grâce à ce qu'on appelle le vérificateur de mot de passe (Password Verifier). Le vérificateur de mot de passe, souvent appelé en dehors de Microsoft comme "la mise en cache des identifiants" (Cached credentials) - http://technet.microsoft.com/en-us/magazine/2009.07.windowsconfidential.aspx, est une copie locale de votre "hash de domaine" que vous pouvez utiliser pour ouvrir une session. Dans les versions du système d'exploitation antérieures à NT 6.0, le calcul du vérificateur de mot de passe était "simplement" le hash d'un hash.

Au cours des dernières années, les assaillants ont mis l'accent sur ce vérificateur de mot de passe et ont commencé à créer des outils pour le "casser". Même si le hash (+ la technique du grain de sel) d'un hash est très difficile à casser, le craquer est possible si le mot de passe n'est pas très complexe. A partir de NT 6.0, le calcul du vérificateur de mot de passe a été modifié en exécutant l'ancien vérificateur à travers un grand nombre d'opérations PKCS # 5 - Password-based Cryptography Specifications - http://www.ietf.org/rfc/rfc2898.txt. Ceci permet d'obtenir une protection adéquate contre tous même sur les mots de passe faibles. 

"The purpose of PKCS #5 is to solve the "dictionary passwords" attack. There are two approaches to solve this problem. One approach is to combine a password with a salt to produce the key. This generates a long key which makes it is difficult to be guessed. The other approach is to provide a complicate KDF, for example, include the iteration count. therby increasing the cost of exhaustive search." - Qing-Ming Jeff Cai, 2008.

Cas particuliers d'authentifications :

 - Lorsqu'un utilisateur se connecte en utilisant les services Terminal Server de Windows, le système d'exploitation met en cache le hash NT de l'utilisateur (et le hash LM si l'ordinateur est configuré pour le stocker). Le hash est maintenue dans un emplacement de mémoire disponible uniquement pour le système d'exploitation (ouf!), et tout processus qui peut faire office de système d'exploitation.

 - Lorsqu'un utilisateur tente d'accéder à une ressource réseau qui requiert une authentification, le système d'exploitation utilise ce hash en cache pour l'authentifier (c'est ce qui permet l'authentification transparente aux ressources du réseau). Dès que l'utilisateur se déconnecte, l'emplacement de mémoire est automatiquement purgée.

 

Ces méthodes de hash ont fait l'objet de pas mal de critiques, il a été démontré que si un administrateur de domaine est connecté, tout autre utilisateur qui est  administrateur pourra lire le hash de cet administrateur de domaine et l'utiliser pour s'authentifier auprès d'un DC...en tant qu'administrateur du domaine!. Ces méthodes sont pris en charge pour permettre la transmission transparente (SSO - Single Sign-On) à des périphériques réseau Windows (ou non-Windows). Bien qu'il soit possible de supprimer la mise en cache des hash(s) des mots de passe, la plupart des utilisateurs se révolterait à avoir à taper son mot de passe à chaque fois qu'ils accèdent à une ressource réseau... Quel serait donc le bon compromis? En fait, le problème n'est pas vraiment de la façon dont Windows met en cache le hash NT mais plutôt à veiller à respecter les bonnes pratiques d'authentification! Un administrateur de domaine ne doit jamais se connecter de manière interactive à un poste de travail utilisé par un utilisateur avec des privilèges d'administrateur local (à moins que l'utilisateur soit également un administrateur de domaine). En suivant ce principe simple, vous pourrez garder cette fonctionnalité tout en évitant d'en faire un vecteur d'attaque :)

 

  • Cryptage réversible...

Windows propose une option pour stocker les mots de passe à cryptage réversible. C'est à dire? Lorsqu'un mot de passe est stocké avec l'option de cryptage réversible, il peut être inversée en texte clair. L'option "cryptage réversible" est désactivée par défaut, et est généralement nécessaires que dans deux cas suivants :

 - Nécessaire si vous avez besoin d'utiliser d'anciens protocoles d'authentifications pour l'accès à distance comme les protocoles CHAP - Challenge-Handshake Authentication Protocol (http://technet.microsoft.com/en-us/library/cc775567(v=ws.10).aspx) ou Digest (http://technet.microsoft.com/en-us/library/cc778868(v=ws.10).aspx).

 - Nécessaire si vous souhaitez effectuer une analyse avancée de vos mots de passe (Par exemple, certaines organisations souhaitent analyser si les mots de passe contiennent certains mots spécifiques).

Note : Pour activer le chiffrement réversible d'une manière globale, utiliser l'éditeur de stratégie de groupe (GPMC - Group Policy Management Console).

Après avoir traité des fonctions de hash(s) utilisées par Windows (NT et LM), la 3e partie de cet article sur la sécurité Microsoft portera sur les protocoles d'authentifications!

Sources :

PASSWORDS TECHNICAL OVERVIEW - http://technet.microsoft.com/en-us/library/hh994558(v=ws.10).aspx

MICROSOFT SECURITY INTELLIGENCE REPORT - DEFENDING AGAINST PASS-THE-HASH ATTACKS - http://www.microsoft.com/security/sir/strategy/default.aspx#!password_hashes

Posted by Jordan Laurent | with no comments
Filed under: ,

[Security] - Protocoles et systèmes d'authentifications, partie 1 - Introduction aux systèmes d'authentifications

[Security] - Protocoles et systèmes d'authentifications, partie 2 - comprendre comment Windows stocke et gère votre identité au sein du réseau d'entreprise - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/07/security-protocoles-et-syst-232-mes-d-authentifications-partie-2-comprendre-comment-windows-stocke-et-g-232-re-votre-identit-233-au-sein-du-r-233-seau-d-entreprise.aspx

[Security] - Protocoles et systèmes d'authentifications, partie 3.1 - Protocoles d'authentification - Local Authentication - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/09/security-protocoles-et-syst-232-mes-d-authentifications-partie-3-1-protocoles-d-authentification-local-authentication.aspx

[Security] - Protocoles et systèmes d'authentifications, partie 3.2 - Protocoles d'authentification - Basic Authentication - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/20/security-protocoles-et-syst-232-mes-d-authentifications-partie-3-2-protocoles-d-authentification-basic-authentication.aspx

[Security] - Protocoles et systèmes d'authentifications, partie 3.3.1 - Protocoles d'authentification - Introduction aux Challenge-Response Protocols - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/12/23/security-protocoles-et-syst-232-mes-d-authentifications-partie-3-3-1-protocoles-d-authentifications-challenge-response-protocols-digest-authentication.aspx

[Security] - Protocoles et systèmes d'authentifications, partie 3.3.2 - Protocoles d'authentification - Digest Authentication - http://danstoncloud.com/blogs/jordanlaurent/archive/2014/01/10/security-protocoles-et-syst-232-mes-d-authentifications-partie-3-3-2-protocoles-d-authentifications-digest-authentication.aspx


Cet article sur la sécurité des objets et des protocoles d'authentifications prise en charge par Microsoft sera écrit en plusieurs parties étant donné la densité du sujet et celui-ci couvrira la première partie "introduction aux systèmes d'authentifications". 

Dans un précédent article, nous avions expliqué que les ordinateurs ou utilisateurs peuvent être appelés dans le langage courant des "sujets" et dans la terminologie Microsoft des "entités principales de sécurité" (Security Principals).

Si cette notion fondamentale ne vous paraît pas claire, je vous conseille de lire cet article avant de commencer celui-ci :) - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/11/29/active-directory-concepts-des-annuaires-informatiques-sujet-objet-et-quot-action-tuple-quot.aspx

Une fois que vous avez compris ce concept, vous serez donc d'accord pour dire que cet entité principal de sécurité a besoin de prouver qu'il est vraiment celui qu'il prétend être pour accéder à des ressources de votre réseau. Prenons un cas très classique dans le monde réel dans lequel vous souhaitez acheter quelque chose avec une carte de crédit dans un magasin...


Vous avez votre identité: vous. Toutefois, le personnel du magasin ne sait pas qui vous êtes et votre achat pourrait nécessiter une preuve d'authentification supplémentaire. Pour apporter la preuve que la carte de crédit vous appartient, vous utilisez un authentificateur (comme une carte d'identité ou un passeport) et vous le présentez alors à l'employé du magasin. Nous pourrions donc dire que votre carte d'identité ou votre passeport sert dans ce cas de protocole d'authentification.

Le monde virtuel (informatique) n'est pas différent, à l'exception que l'entité à laquelle vous faites appel pour vous authentifier comprend dans notre exemple qu'une signature (sur le dos de votre carte de crédit) et n'est pas un authentificateur "fiable", elle ne fournit absolument aucune preuve d'identité, ce que signifie que vous avez besoin d'une forme d'authentification plus forte!

 

  • Les 3 types d'authentificateurs standards

De manière générale, vous pouvez prouver votre identité au sein d'un système informatique (ou de la vie quotidienne!) en utilisant un des trois systèmes ci-dessous.

 - Fournir quelque chose que vous connaissez - Un secret que vous connaissez (partagé avec le système auquel vous accédez) est la manière la plus simple (et la plus répandue) de prouver votre identité. Le mot de passe en est un parfait exemple!

 - Fournir quelque chose que vous avez - Un jeton (token) que vous avez en votre possession est un système différent d'authentificateur. Vous vous authentifiez vous-même  en prouvant que vous êtes en possession de ce jeton. Un bon exemple de ce système est la carte à puce (smart card) ou un dispositif de mot de passe unique lié à votre appareil comme un jeton RSA (http://www.rsa.com/node.aspx?id=1156). Ces types de jetons sont presque toujours associées à quelque chose que vous savez, et améliorent la sécurité des demandes d'authentification. On parle alors d'authentification forte.

 - Fournir quelque chose qui vous caractérise - Le dernier authentificateur utilisé / définit est celui qui utilise quelque chose qui vous caractérise pour prouver votre identité. Nous rentrons alors dans la catégorie des authentificateurs biométriques...Les exemples de cette catégorie sont nombreux (Analyse de la rétine, empreintes digitales, échantillons de sang, reconnaissance vocale). Certains systèmes peuvent même prendre en compte la cadence de frappe d'un mot de passe avec un clavier d'ordinateur. Vous me direz que cela est discutable et que même dans le monde de la biométrie, certains systèmes permettent de s'assurer que la donnée envoyée qui vous caractérise est plus unique qu'une autre (un échantillon de votre sang le sera - l'ADN est unique - mais difficile à utiliser dans l'informatique!!)...par exemple, Windows 8 prend en charge l'authentification en analysant votre visage (via WBF - Windows Biometric Framework - http://danstoncloud.com/blogs/jordanlaurent/archive/2012/01/02/les-quot-pictures-passwords-quot-dans-windows-8-windows-8-developer-preview.aspx). Sommes-nous sûr que chaque forme de visage est unique? Et au délà de cette simple question, encore faut-il connaître les caractéristiques prise en charge par l'authentificateur (ici Windows 8), prend t'il en charge chaque infime partie de la forme du visage ou une forme beaucoup plus globale? Cela pourrait poser un problème d'authentification si une personne vous ressemble fortement (il suffit de regarder une série TV ou un bon vieux film d'espionnage pour observer que cette méthode est souvent utilisé). Un système externe pourrait également "facilement" capturer et rejouer la séquence d'authentification sans nuire ou gêner le sujet initial...

Comment dit plus haut, les systèmes biométriques sont malheureusement souvent imprécis quand à l'exactitudes des informations envoyées. Alors que l'ADN fournit une correspondance exacte, la plupart des gens seraient réticents à donner un échantillon de sang pour utiliser un ordinateur. La plupart des facteurs biométriques ne sont pas aussi précis que l'analyse d'un échantillon sanguin. Par exemple, les empreintes digitales sont considérés comme étant unique...cependant, il n'est pas certain que l'enregistrer de multiples fois donnent des résultats exactes. Par conséquent, les systèmes d'authentification biométriques fonctionnent généralement sur ​​une plage de valeurs acceptables. Sur cette base, le système développe la gamme acceptable pour votre authentificateur.

 

  • Les lacunes dont souffrent les systèmes biométriques

Premièrement, ils nécessitent des dispositifs matériels à usage spécifique à chaque client.

Deuxièmement, les méthodes biométriques sont imprécises. Avec certaines méthodes, cela peut être fatal. Si pour une raison quelconque, votre authentificateur biométrique a changé, votre authentification échouera (Par exemple, si vous utilisez la reconnaissance vocale et que vous êtes malade ou fatigué, cela affectera votre voix...).

Troisièmement, beaucoup de personnes considèrent l'authentification biométrique très intrusive. En effet, avoir des détails extrêmement personnelles telles que les empreintes digitales stockées sur un système informatique n'est pas du goût de tout le monde!

Quatrièmement, de nombreux experts en sécurité estiment les dispositifs biométriques survendus. Les entreprises dans le secteur de la vente de systèmes biométriques font souvent des revendications impossibles ou de la mauvaise information (parfois trop marketing... - lors de l'achat pré-intrégré d'un dispositif d'empreintes digitales chez un constructeur, vous trouverez généralement deux gammes différentes...un authentificateur biométrique à quelques dizaines d'euros...et un autre coûtant plus de cent euros mais certifié FIPS - Federal Information Processing Standards - en d'autres mots réputé inviolable)  Par exemple, une entreprise qui fabrique une solution logicielle qui mesure la frappe de cadence prétend protéger les clients contre les enregistreurs de frappe (keystroke logging). C'est impossible... En effet, l'utilisateur doit toujours taper le mot de passe sur un client, et un enregistreur de frappe sur le client pourrait être facilement "amélioré" ou détourné pour capturer tous les informations que le logiciel biométrique capture. Le dispositif pourrait également comporter un "backdoor" et cette information pourrait être facilement rejoué pour s'authentifier avec succès. Nous pourrions également soutenir le même argument au niveau des navigateurs web qui stockent vos mots de passe à la demande de l'utilisateur (Webmail, portail d'authentification, etc.) et les nombreux sites web qui utilisent le système de "cookies" qui seront stockés sur votre ordinateur pour améliorer votre "confort" de navigation sur Internet...

Cinquièmement, il y a une idée fausse que les systèmes biométriques sont sûrs parce qu'ils sont intrinsèquement une part de l'utilisateur et ne peuvent pas être laissées à la traînela façon dont les mots de passe écrits sur un post-it caché en dessous un clavier...nous avons tous connus ça de la part de nos chers utilisateur :) ). De plus, cela n'est pas seulement lié au fait que les séquences d'authentification biométriques peuvent être capturés, comme les empreintes digitales sur un verre, mais les jetons eux-mêmes sont aussi amovibles (l'exportation de la clé est techniquement possible!).

Pour finir, il y a relativement peu de choix pour les authentificateurs biométriques. Dans un système utilisant les empreintes digitales, vous n'avez qu'une dizaine de choix différents auprès des constructeurs d'ordinateurs professionnels... Si l'un d'eux est compromis ou perdue il vous en restera neuf. La capture et la relecture d'informations d'identification est un risque réel, le manque de choix d'authentificateurs est une menace à ne pas prendre à la légère.

Choisir une solution de sécurité fiable, autant pour la communication serveur-serveur ou client-serveur, n'est pas une chose simple. C'est pour cela que le système de certificat (catégorie 2 - "fournir quelque chose que vous avez") géré par une infrastructure à clés publiques (PKI - Public Key Infrastructure) est devenu aujourd'hui chose courante pour effectuer une authentification forte. La sécurité au sein de votre système informatique est un gros projet mais est heureusement pris en compte par de plus en plus entreprises pour cacher les informations que celles-ci transmettent (Intranet ou Internet). Cela sera traité dans une partie spécifique de cet article sur la sécurité dans le monde Microsoft...mais procédons par étape, pour être tous sur la même longueur d'onde :) à la lecture de ces parties complexes.

La 2e partie de cet article portera sur "comprendre comment Windows stocke et gère votre identité au sein du réseau d'entreprise".

Ressources :

PASSWORD SAFE - DESIGNED BY THE RENOWNED CRYPTOGRAPHER : Bruce Schneier - http://passwordsafe.sourceforge.net/

VALIDATED FIPS 140-1 AND FIPS 140-2 CRYPTOGRAPHIC MODULES - http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2013.htm

WINDOWS BIOMETRIC FRAMEWORK OVERVIEW - http://technet.microsoft.com/en-us/library/hh831396.aspx

WHAT'S NEW IN BIOMETRICS IN WINDOWS 8.1 - http://technet.microsoft.com/en-us/library/dn344916.aspx

INTRODUCTION TO THE WINDOWS BIOMETRIC FRAMEWORK - http://msdn.microsoft.com/en-us/library/windows/hardware/gg463089.aspx

Posted by Jordan Laurent | with no comments
Filed under: ,

[Windows 8] - What's new in Windows 8.1?

Update - Information importante : Le cycle de vie produit de Windows 8.1 suivra le même que Windows 8 (date de fin de support principal fixé au 09/01/2018 / date de fin de support étendue fixé au 10/01/2023). Cependant, suite à un communiqué officiel de Microsoft, il est à noter que vous devez effectuer la mise à jour de Windows 8 RTM vers Windows 8.1 sous 24 mois (mandatory!) Si vous ne faites pas celle-ci, vous ne recevrez plus les mises à jours sur votre système d'exploitation Windows 8 RTM!

http://support.microsoft.com/gp/msl-Windows-81

 

Je sais que j'ai un peu de retard sur la communication de Windows 8.1 (version du build 9600.16384.130821-1623) mais je voulais quand même écrire un petit article sur la dernière version du système d'exploitation de Microsoft disponible depuis le 26 octobre 2013 pour le grand public (publiée sur le Windows Store le 17 octobre) et depuis le 26 août pour les fabricants de PC.


La mise à jour majeure pour Windows 8 sort pratiquement un an après le lancement de cette version de l’OS. Au programme, des correctifs et des optimisations de performances, mais également plusieurs nouvelles fonctionnalités qui pourront ravir les utilisateurs.

  • Possibilité de personnaliser l'écran de verrouillage

 

  • Nouveau navigateur web : Internet Explorer 11 (par défaut dans Windows 8.1, disponible depuis le 08 novembre sur Windows 7 et non-disponible pour Windows 8!).
  • Windows PowerShell en version 4.0!

 

  • Intégration de plusieurs produits Microsoft, notamment Skype (utilisé par 300 millions d'utilisateurs à travers le monde), SkyDrive, Bing, Outlook.com, etc.
  • L’utilisateur peut synchroniser sur tous ses PCs et tablettes son écran personnalisé, ses applications et fichiers, via la plateforme de stockage Cloud SkyDrive.
  • L’OS étend le multitâche, avec la possibilité d’exécuter jusqu’à 4 applications côte à côte, propose plus de flexibilité pour redimensionner les fenêtres de chaque application et permet de lancer une application depuis une autre.
  • Windows 8.1 est le 1er système d’exploitation à prendre en charge nativement l’impression 3D.
  • Windows Store a subi un rafraîchissement avec un nouveau design afin de faciliter l'accès aux applications.
  • La limite d'utilisation d'une application passera de 5 à 81 appareils à compter du 09 octobre prochain. Les développeurs pourront tirer "plus de revenus pour leurs applications" et Microsoft mettra à disposition une API qui leur permettra de définir leur propre limite du nombre d'appareils sur lesquels leur applications s'exécuteront (http://blogs.windows.com/windows/b/appbuilder/archive/2013/09/27/increasing-the-app-roaming-limits.aspx).
  • Les packages d'applications peuvent désormais atteindre 8Go dans Windows Store 8.1.

 

  • Vous avez dit mise à jour majeure de Windows 8?

Et oui, même si au niveau marketing / réseau de distribution, le système d'exploitation s'appelle Windows 8.1, il aurait très bien pu s'appeler Windows 8 R2! Pourquoi? Le noyau du système d'exploitation passe de la version 6.2 (Windows 8) à la version 6.3 :) (tout comme Windows 2012 R2). Cependant, le terme Rx (Release + numéro de version) est réservé encore aujourd'hui aux versions serveurs de Microsoft.

 

  • Comment appliquer cette mise à jour?
  • Comment mettre à jour votre ordinateur vers Windows 8.1 depuis Windows 8.1 Preview? MAJ gratuite => http://windows.microsoft.com/fr-fr/windows-8/update-from-preview
  • Comment mettre à jour votre ordinateur vers Windows 8.1 depuis Windows 8? MAJ gratuite => http://windows.microsoft.com/fr-fr/windows-8/update-from-windows-8-tutorial#update
  • Comment mettre à jour votre ordinateur vers Windows 8.1 depuis Windows 7? MAJ payante => http://windows.microsoft.com/fr-fr/windows-8/upgrade-from-windows-7-tutorial
  • Comment mettre à jour votre ordinateur vers Windows 8.1 depuis Windows Vista ou Windows XP? MAJ payante => http://windows.microsoft.com/fr-fr/windows-8/upgrade-from-windows-vista-xp-tutorial
  •  

    • Part de marché des OS

     Premier constat, Windows XP est encore bien présent sur les ordinateurs! Ce système d'exploitation à fêté ses 12 bougies (et oui!) et malgré la fin du support prévu en avril 2014, celui-ci occupe la 2e place des OS les plus populaires du monde (31,22% de part de marché)! Selon un récent rapport du cabinet de sécurité AVAST, 96% des écoles américaines utiliseraient encore le système d’exploitation.

    Windows 8.1 qui à maintenant un peu plus d'un mois, possède une part de marché (déjà!) de 2,64%. 6,66% pour Windows 8, son grand frère!


    Prévu pour donner du sang neuf à Windows 8 en corrigeant ses fautes de jeunesse, le couple Windows 8/Windows 8.1 présente un résultat plutôt mitigé. Les deux OS couplés, enregistrent une petite hausse, passant de 9,25 % le mois dernier à 9,3 % ce mois.

    Windows 7 de son coté, se porte bien et continue même à gagner des parts de marché. Le système d’exploitation le plus populaire au monde passe de 46,42 % en octobre à 46,64 % ce mois. Le positionnement de Windows 7 laisse penser de plus en plus à un nouveau scénario similaire à celui de Windows XP.

    De façon globale, Windows a gagné le mois dernier 0,22 point (avec une part de 90,88 %), au détriment de Linux qui a baissé de 0,05 point (1,56 %) et OS X qui perd 0,17 point (7,56 %).

     

    • Part de marché des navigateurs web

    Internet Explorer 6, lancé en 2001 par défaut dans Windows XP, meurt à petit feu (et heureusement pour les développeurs et le manque de sécurité du navigateur) avec 4,87% de part de marché mondiale (22,2% en Chine tout de même! - http://www.modern.ie/en-us/ie6countdown). Internet Explorer 8 reste le navigateur le plus utilisé de la planète avec 21,41% de part de marché. Globalement, le navigateur de Microsoft, toutes versions confondues, enregistre une légère hausse avec 57,79% de part de marché mondiale contre 18,58% pour Mozilla Firefox et 15,98% pour Google Chrome (http://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0)

    Note : Internet Explorer 8 est la dernière version du navigateur Microsoft supporté sur Windows XP.

     

    Sources :

    WINDOWS 8.1 EN DETAIL - http://windows.microsoft.com/fr-fr/windows-8/features#personalize=startscreen

    WHAT'S NEW IN WINDOWS 8.1 - http://technet.microsoft.com/en-us/windows/dn140266.aspx

    Posted by Jordan Laurent | with no comments
    Filed under:

    [Active Directory] - Concepts des annuaires informatiques

    Au niveau le plus élémentaire, tout en sécurité se résume à des sujets et des objets. Les objets sont les choses que vous protégez, et les sujets sont les choses auquel accéderont les objets. Sujets et objets sont utilisés dans l'authentification (prouvez qui vous êtes), l'autorisation (donnant accès à quelque chose), et l'audit (savoir quel sujet a accédé à cet objet). Ces concepts sont fondamentalement très simple. Les sujets sont les utilisateurs. Les objets sont des fichiers. Authentification, autorisation et audit ont tous à voir avec la façon dont les sujets et les objets interagissent.

    C'est pourquoi Active Directory se doit de protéger l'information et répond en ce sens à 3 fondamentaux des annuaires informatiques,

    • IDA : IDentity & Access
    • AAA : Authentication, Authorization, Accounting
    • CIA : Confidentiality, Integrity, Availability & Authenticity

    Windows prend en charge une sémantique immensément riches quand il s'agit de sécurité et a considérablement élargi la définition d'un sujet et d'un objet... Un sujet peut être beaucoup plus qu'un simple utilisateur, et la représentation est beaucoup plus complexe qu'un basique identifiant utilisateur.
    Windows fait également référence à ces sujet et objets de manière différente, vous allez très souvent rencontré le terme d'entité principal de sécurité (Security Principal). En langage Windows, une entité principal de sécurité englobe non seulement le sujet typique (l'utilisateur), mais aussi des groupes et des ordinateurs. Une entité principal de sécurité est tout ce qui peut être assigné à un identificateur de sécurité (SID - Security IDentifier), et qui peut donner la permission d'accéder à quelque chose.

    Afin de mieux comprendre l'interaction entre les objets et les SIDs du monde Microsoft, vous pouvez consulter un article que j'ai également écrit - http://danstoncloud.com/blogs/jordanlaurent/archive/2013/11/28/active-directory-tout-conna-238-tre-224-propos-des-sids.aspx

    Gérer la sécurité revient très souvent à la règle sujet/objet/"action tuple". Le sujet est l'acteur qui tente de prendre des mesures sur un objet. Par exemple, un utilisateur peut essayer d'accéder à un fichier. Pour comprendre cette notion fondamentale, faisons un petit schéma pour que ce soit clair pour tout le monde,

    (Juste un petit mot à  propos du terme "Action-Tuple" qui ne se traduit pas littéralement de l'anglais vers le français en informatique. Pour donner une définition claire à cette expression, nous pourrions dire que cela correspond à une série d'information enregistrées dans une base de données (ici Active Directory) en programmation informatique).

    Lorsqu'un utilisateur tente de lire un fichier, le système d'exploitation vérifie si les autorisations sont définies sur l'objet (ici notre fichier), ce qui permettra à l'objet d'effectuer l'action demandée par l'utilisateur. Si les autorisations sont en place, la demande d'accès réussit. Si les autorisations ne confèrent pas, la demande d'accès est refusé. C'est aussi simple que ça! (Pour le moment ;) )

    Dans un prochain article, vous en apprendrez beaucoup plus sur la façon dont les autorisations et les contrôles d'accès travaillent.

    • Quels sont les types de sujets que nous pouvons rencontrer dans Active Directory?


    Dans un premier temps, afin de dialoguer avec le bon jargon Active Directory, un sujet est une entité principale de sécurité (Security Principal en anglais).

     - Utilisateurs :

    Un utilisateur est une entité distincte qui se connecte à un ordinateur. Fondamentalement, toutes les entités de sécurité sont liées aux utilisateurs. Dans Windows, il peut y avoir deux types d'utilisateurs: utilisateurs locaux (1) et utilisateurs de domaine (2). 

    (1) Un utilisateur local est défini dans la base de données Security Accounts Manager (SAM) local sur un ordinateur. Chaque ordinateur Windows dispose d'un SAM locale qui contient tous les utilisateurs de dudit ordinateur. Chaque base SAM est unique à un ordinateur et chaque utilisateur devra donc être inscrit dans ces différentes bases locales pour utiliser ordinateurs différents.

    Il est souvent dit que les contrôleurs de domaine (DC) n'ont pas de SAM locale et n'ont donc pas d'utilisateurs locaux. Ceci est incorrect. Même un DC a un SAM locale, mais les comptes de sa base SAM peuvent seulement être utilisés en mode restauration Active Directory. Par défaut, deux comptes d'utilisateurs sont toujours présents dans la SAM locale : l'administrateur et l'invité. Le compte Invité (Guest account) est toujours désactivée par défaut (A noter que côté client, le compte administrateur est désactivé par défaut  depuis Windows Vista - NT 6.0). 

    Il est fortement recommandé que vous procédiez à la création de comptes supplémentaires pour chaque personne qui gérera un ordinateur donné. Si les administrateurs ont également besoin d'utiliser l'ordinateur pour des tâches non administratives, ils doivent aussi avoir des comptes non administratifs personnels.

    (2) L'autre type de compte est un compte utilisateur  de domaine. Ceux-ci sont définies dans la base Active Directory de votre organisation (NTDS.DIT) et peuvent être utilisés sur n'importe quel ordinateur du domaine une fois que l'utilisateur à été déclaré dans celle-ci. Les comptes de domaine peuvent avoir un nombre beaucoup plus grand  de propriétés qui leur sont associées par rapport à un compte local, couvrant une variété d'attributs dans un environnement organisationnel, telles que des numéros de téléphone, les comptes e-mail, etc. D'une part, ceci permet de simplifier la gestion de vos utilisateurs au quotidien, et d'autre part de permettre à ceux-ci de trouver des informations de type entreprise comme c'est le cas dans un annuaire civique mais limité au rayon de l'organisation.

    Domain Account

     

    Local Account

    - Ordinateurs :

    Un ordinateur est juste un autre type "d'utilisateur". Dans Active Directory cela est particulièrement vrai et est corroborée par le modèle d'héritage dans Active Directory.

    Premièrement, toutes les classes dans Active Directory dérivent d'une classe racine appelé Top. Deuxièmement, la classe User est dérivée de la classe organizationalPerson. La classe organizationalPerson est dérivé du Top. Troisièmement et c'est la partie la plus intéressante, la classe Computer est dérivée de la classe User. En d'autres termes, dans le langage orienté objet, un ordinateur est un type d'utilisateur. Cela signifie que les ordinateurs doivent être traités comme des "sujets" puisqu'ils ont presque les mêmes caractéristiques que les utilisateurs.

    - Groupes :

    Un sujet est donc quelque chose qui tente d'accéder à un objet. Le système d'exploitation vérifie cette tentative d'accès en vérifiant les autorisations de l'objet. Très tôt, les concepteurs de systèmes d'exploitation ont réalisé qu'il serait difficile d'attribuer des autorisations à chaque objet unique à chaque utilisateur. Pour résoudre ce problème, ils ont permis aux utilisateurs d'être membres de groupes. Cela nous permet d'attribuer des autorisations à des groupes qui contiendraient des utilisateurs. Un groupe ne peut pas être un utilisateur, mais un groupe est toujours un type d'entité de sécurité, car il peut avoir un identifiant (SID), tout comme les utilisateurs et les ordinateurs. Dans Windows, un utilisateur peut être membre de plusieurs groupes et un objet peut avoir des autorisations attribuées par de nombreux groupes. Les groupes imbriqués sont également utilisables, avec certaines restrictions.

    Un contrôleur de domaine ne peut contenir que deux types de groupes: les groupes prédéfinis (built-in groups) et les groupes que les administrateurs ont définis (user-defined groups). Dans Active Directory, vous trouverez six types de groupes de sécurité, nous parlons alors d'étendues (Group Scope),

     * Groupes prédéfinis par Active Directory (built-in groups)

    Groupe de domaine local (Local Domain group) / Groupe global (Global group) / Groupes universel (Universal group)

     * Groupes définis par l'utilisateur (user-defined groups)

    Groupe de domaine local (Local Domain group) / Groupe global (Global group) / Groupes universel (Universal group)

    L'imbrication de ces groupes et leurs limitations peut être résumé par le tableau ci-dessous,

     * Quels sont les groupes par défaut dans Active Directory? (Attention, les groupes contenant " CS* ", " RTC* ", ou encore " *Mailbox* " sont les groupes créés par les produits Microsoft Exchange et Microsoft Lync, si ceux-ci ne sont pas installés dans votre environnement, il est normal que vous ne les trouviez pas dans la console Utilisateurs et Ordinateurs Active Directory).

    Conteneur "Utilisateurs" (Users container)

    Conteneur "Builtin"

    Note : Lors de la création d'un groupe, en plus de définir l'étendue de celui-ci, vous aurez à choisir de le créer de type Sécurité (Security Group) ou Distribution (Distribution Group)! Quel pourrait être la différence entre ces deux groupes? Rien de bien compliqué finalement, un groupe de sécurité est associé à un identifiant de sécurité (SID) et vous pourrez assigner des permissions sur celui-ci qui contiendra des utilisateurs ou ordinateurs (très pratique pour simplifier la gestion de ces permissions sur plusieurs objets à la fois!); un groupe de distribution, quand à lui, n'aura pas d'identifiant de sécurité associé et servira seulement comme liste de distribution vers un produit utilisant cette fonctionnalité (Microsoft Exchange par exemple). Sur un contrôleur de domaine, vous trouverez, par défaut pas moins de 63 groupes par défaut!

     

     - Identités spéciales dans Active Directory :

     - Ouverture de session anonyme (Anonymous Logon)

    Représente les utilisateurs et les services qui accèdent à un ordinateur et ses ressources à travers le réseau sans utiliser un nom de compte, mot de passe, ou nom de domaine. Sur les ordinateurs exécutant Windows NT 4.0 et les versions antérieures, le groupe Anonymous Logon est un membre par défaut du groupe Everyone.

     - Tout le monde (Everyone)

    Représente tous les utilisateurs du réseau, y compris les invités (Guests) et les utilisateurs d'autres domaines. Chaque fois qu'un utilisateur ouvre une session sur le réseau, l'utilisateur est automatiquement ajouté au groupe Everyone.

     - Réseau (Network)

    Représente les utilisateurs qui accèdent en ce moment même à une ressource donnée sur le réseau. Chaque fois qu'un utilisateur accède à une ressource donnée sur le réseau, l'utilisateur est automatiquement ajouté au groupe Réseau.

     - Interactif (Interactive)

    Représente tous les utilisateurs actuellement connectés à un ordinateur particulier et qui accède à une ressource sur celui-ci (par opposition aux utilisateurs qui accèdent à la ressource sur le réseau). Chaque fois qu'un utilisateur accède à une ressource donnée sur un ordinateur, l'utilisateur est automatiquement ajouté au groupe Interactive.

    SOURCES :

    GROUP SCOPE - http://technet.microsoft.com/en-us/library/cc755692(v=ws.10).aspx

    GROUP TYPES - http://technet.microsoft.com/en-us/library/cc781446(v=ws.10).aspx

    DEFAULT GROUPS - http://technet.microsoft.com/en-us/library/cc756898(v=ws.10).aspx

    NESTING GROUPS - http://technet.microsoft.com/en-us/library/cc776499(v=ws.10).aspx

    SPECIAL IDENTITIES - http://technet.microsoft.com/en-us/library/cc778060(v=ws.10).aspx

     

    Posted by Jordan Laurent | with no comments

    [Active Directory] - Comprendre la structure des SIDs dans le monde Microsoft

    Dans le monde Windows, chaque objet déclaré et connu par le service d'annuaire de Microsoft (Active Directory) ou le système d'exploitation Windows est identifié dans la plupart des cas par un identifiant de sécurité (SID - Security IDentifier).

    Afin de mieux comprendre le rôle de cet identifiant, il est important de comprendre auparavant ce qu'est une "entité principale de sécurité" - drôle de terme en français! (Security Principal dans la terminologie Active Directory).

     

    • Que sont les entités principales de sécurités (Security Principals)?

    Une entité principale de sécurité est une objet qui peut avoir un identifiant de sécurité (SID), c'est-à-dire toute entité qui pourra être authentifiée par le système d'exploitation (utilisateur, ordinateur, groupe, etc.)

    Ce sont les fondations pour contrôler l'accès aux ressources de votre environnement Windows (fichiers et dossiers par exemple)

     

    • Comment définir le terme SID?

    Un SID (Security IDentifier) est une représentation numérique d'une entité principal de sécurité, donc d'un compte utilisateur, d'un compte d'ordinateur, d'un groupe, etc.

    Lorsque vous accordez à un utilisateur, un groupe ou un service le droit d'accéder à des ressources, le système d'exploitation met à jour le SID représentant l'objet Active Directory et ses permissions définies dans l'ACL (Access Control List).

     

    • Comment obtenir le SID d'un objet Active Directory?

    Dans Active Directory, le SID de l'objet est renseigné par l'attribut objectSid.

    •   Depuis la console Active Directory Users and Computers, dans le menu "View" cliquer sur "Advanced Features". Ensuite, allez dans les propriétés de l'objet désiré et cliquez sur l'onglet "Attribute Editor", vous trouverez le SID de l'objet dans le champ ObjectSid

     

    •  Grâce à l'outil "psgetsid" de la suite Microsoft SysInternals (http://technet.microsoft.com/en-us/sysinternals/bb897417.aspx), placez-vous en console DOS dans le répertoire des outils SysInternals et tapez psgetsid sAMAccountName. A noter que l'outil fonctionne dans les deux sens, en fournissant l'attribut sAMAccountName de l'objet pour obtenir son SID ou en référençant la valeur de l'attribut objectsid pour afficher le nom de l'objet!

     

     

    • Comment est composé la structure d'un identifiant de sécurité (SID)?

    Un SID inclut des composants qui fournissent des informations sur la structure et les composants qui identifient un objet (rapport objet/droits accordés). Il est constitué des composants suivants:      

    • Les SID commence toujours avec le littéral "S"
    • Le niveau de révision de la structure SID (qui actuellement est toujours 1)
    • La valeur des différentes autorités d'identificateurs sur 48 bits qui permet d'identifier l'émetteur du SID.
    • Un nombre variable de sous-autorité (ou RID - Relative IDentifier) des valeurs qui identifient l'objet par rapport à l'autorité qui a émis le SID.

    soit, S-1-IdentifierAuthority-SubAuthority1-SubAuthority2-...-SubAuthorityN

    ou encore, S-R-I-S - dans cette notation, le caractère littéral "S" identifie le SID lui-même, R est le niveau de révision, I est la valeur identificateur-autorité, et S ... est une ou plusieurs valeurs de sous-autorités.

    Un bon exemple est toujours concret pour comprendre une théorie complexe ;) Pour cela, prenons le SID d'un compte bien connu, celui du groupe "Administrateurs" local d'une machine fonctionnant sous Windows. Son SID est,

    S-1-5-32-544

    S = Identifiant brut du SID  / 1 = Niveau de révision de la structure SID / 5 = Valeur de l'autorité identificateur (SECURITY_NT_AUTHORITY) / 32 = Valeur de la première sous-autorité (SECURITY_BUILTIN_DOMAIN_RID) / 544 = Valeur de la seconde sous-autorité (DOMAIN_ALIAS_RID_ADMINS).

     

    • Quelles sont les autorités primaires des SIDs?

    0 - SECURITY_NULL_SID_AUTHORITY - valeur définie quand l'autorité identifiant l'objet est inconnu (état unknown) - S-1-0-0

    1 - SECURITY_WORLD_SID_AUTHORITY - utilisé pour construire les SIDs qui représentent tous les utilisateurs. Par exemple, le SID du groupe "Everyone" est S-1-1-0, créé en ajoutant le WORLD RID(0) sélectionnant ainsi tous les utilisateurs de cette autorité - S-1-1-0

    2 - SECURITY_LOCAL_SID_AUTHORITY - utilisé pour construire les SIDs représentant les utilisateurs qui s'authentifient sur un ordinateur physique - S-1-2-0

    3 - SECURITY_CREATOR_SID_AUTHORITY - utilisé pour construire les SIDs qui représentent le créateur (CREATOR) ou propriétaire (OWNER) d'un objet. Le CREATOR OWNER SID est S-1-3-0, créé en ajoutant le CREATOR OWNER RID (0) à cette autorité. Si S-1-3-0 est utilisé dans une ACL avec héritage, il sera remplacé par le SID du propriétaire (OWNER) des objets enfant qui héritent de cette ACL. S-1-3-1 sera alors le CREATOR GROUP SID - S-1-3-0

    5 - SECURITY_NT_AUTHORITY - utilisé par le système d'exploitation lui-même. Les SIDs qui commencent par S-1-5 sont émis par Windows (base SAM - Security Account Manager) ou un domaine Active Directory (AD DS). La plupart des SID que vous verrez commenceront avec S-1-5 - S-1-5-0

     

    • Quelles sont les autorités secondaires des SIDs?

    Une fois que l'identifiant de sécurité de l'objet  se soit vu attribué son autorité compétente (voir le point "Quelles sont les valeurs des autorités d'identificateurs SID?"), c'est au tour des sous-autorités d'intervenir dans la construction du SID. Le dernier d'entre eux est appelé identificateur relatif (RID - Relative IDentifier) et est l'identifiant de l'entité de sécurité unique dans le domaine où le SID a été défini. Essayons de clarifier cette dernière phrase par un petit exemple en considérant le SID ci-dessous,

    S-1-5-21-1534169462-1651380828-111620651-500

    Comme vous l'avez vu, le SID commence par S-1-5, indiquant qu'il a été émis par Windows NT (SECURITY_NT_AUTHORITY). La première sous-autorité est 21 - S-1-5-21 - (0x15 en hexadécimal). Le 21 signifie que le SID Windows NT n'est pas assuré d'être universellement (c'est-à-dire totalement) unique. Il sera unique dans le domaine de son émission (exemple : labenv.local), mais il peut y avoir d'autres SID dans l'univers des ordinateurs qui ont exactement la même valeur. La première des sous-autorités est très souvent une sous-autorité bien connue.

    Notre SID a alors trois sous-autorités supplémentaires: 1534169462, 1651380828, et 111620651. Elles n'ont pas en elles-mêmes un sens implicite, mais ensemble elles indiquent le domaine ou l'ordinateur qui a émis le SID. En fait, le SID pour le domaine est S-1-5-21-1534169462-1651380828-111620651, et tous les SID délivrées dans ce domaine commence par cette valeur et se terminer par un RID unique pour l'utilisateur ou l'ordinateur qu'ils désignent. Dans notre exemple, le SID se termine par 500, ce qui est un RID bien connue puisqu'il désigne le compte Administrateur (built-in Administrator account) d'une machine Windows. 501 est le RID pour le compte invité (Guest account) et 502 celui du Kerberos Ticket Granting Ticket (krbtgt).

    Voici les sous-autorités SID les plus communément rencontrées,

    5 - Les SIDs sont établis durant les sessions d'authentifications afin d'activer les permissions à accorder à n'importe quelle application ayant droit. Ces types de SIDs ont leur première sous-autorité défini à 5 - S-1-5-5-x-y

    6 - Lorsqu'un processus se connecte en tant que service, il reçoit un SID spécial dans son jeton afin de le désigner. Ces types de SIDs ont leur première sous-autorité défini à 6 - S-1-5-6-x-y

    21 - SECURITY_NT_NON_UNIQUE - Identifie des SIDs d'utilisateurs et d'ordinateurs qui ne sont pas garantis d'être universellement (totalement) unique.

    32 - SECURITY_BUILTIN_DOMAIN_RID - Identifie des SIDs de comptes prédéfinis (built-in accounts). Par exemple, le SID du groupe administrateurs est S-1-5-32-544 - S-1-5-32-x-y

    80 - SECURITY_SERVICE_ID_BASE_RID - Identifie les SIDs pour les services Windows - S-1-5-80-x-y

     

    • Point spécifique sur les SIDs des services Windows

    Les SIDs des services Windows commencent toujours avec S-1-5-80 et terminent avec un numéro de sous-autorité qui est basé sur le nom du service. Cela signifie qu'un service donné aura le même SID sur tous les ordinateurs! Cela signifie également que vous avez la possibilité d'obtenir le SID d'un service arbitraire même s'il n'existe pas. Pour vous démontrer cela, nous allons utiliser un utilitaire intégré dans le système d'exploitation Windows,

    Exécutez la commande (dans une console MS-DOS), sc showsid toto

    Vous pouvez observer que même si toto n'existe pas comme service sur ma machine ou sur la vôtre, le SID renvoyé par l'utilitaire "SC" sera le même car il se base sur le nom du service!

     

    • RIDs connus

    Quand un développeur écrit un programme pour Windows, il a souvent besoin de connaître le SID de quelque entités principales de sécurité. Habituellement, un SID peut être facilement construit si seulement le RID est connu parce qu'il est tout simplement ajouté à l'ordinateur ou au domaine Active Directory, comme dans le cas du compte d'administrateur. Toutefois, pour plus de commodité, il est souvent souhaitable d'avoir une forme plus courte et statique de quelques SIDs. Pour fournir cela, le modèle de sécurité utilisé dans Windows inclut un nombre important de SIDs connus - SID qui sont toujours les mêmes sur tous les ordinateurs. Quelques SID universellement connus sont les mêmes sur tous les systèmes d'exploitation à l'aide de ce modèle de sécurité. Ce sont les SID qui commencent par S-1-1, S-1-2, ou S-1-3, y compris ceux discuté au cours de cet article, comme le CRÉATEUR PROPRIÉTAIRE SID: S-1-3-0.

    S-1-5-32 est connue, par exemple, pour être  le SID de domaine. Il peut, à son tour, être combiné avec un RID bien connu pour former un SID pour un compte particulier. Par exemple, le SID pour le groupe Administrateurs, que ce soit sur un domaine ou sur un ordinateur autonome, est toujours S-1-5-32-544. Dans le cas de groupes intégrés (built-in groups) un RID peut être combiné avec S-1-5-32 pour former un SID qui est valable sur n'importe quel ordinateur. D'autres comptes sont ajoutés au domaine pour former le SID complet. C'est le cas avec le groupe Admins du domaine qui récupère toujours le RID 512 pour former un SID tel que S-1-5-21-1534169462-1651380828-111620651-512.

    500 - Administrator

    501 - Guest

    502 - krbtgt

    512 - Domain Admins

    513 - Domain Users

    514 - Domain Guests

    515 - Domain Computers

    516 - Domain Controllers

    544 - Built-in Administrators

    545 - Built-in Users

    546 - Built-in Guests

     

    • Et la sécurité dans tout ça?...

    Les SIDs connus pourrait permettre à un attaquant éclairé de trouver un utilisateur ou un groupe. Cependant, cela peut également vous aider à suivre et trouver vos utilisateurs et groupes (ex: phase d'audit). N'oubliez jamais de modifier le nom du compte d'administrateur, afin de masquer la sécurité de ce compte, pour ceux qui ne sont pas informés. La création d'un compte administrateur " pot de miel " est un excellent moyen d'attraper des attaquants, en essayant de se connecter avec ce compte, qui n'est évidemment pas le compte "Administrateur" correct .

    Bien sûr, un attaquant bien informé peut résoudre le SID et déterminer quel utilisateur a le RID 500 , indiquant l'administrateur par défaut. C'est une bonne raison de ne pas autoriser l'accès anonyme, de limiter la translation SID-nom, l'énumération de la SAM, etc.

    Ce sera l'occasion de publier un prochain article sur ce sujet :)

    Vous avez vraiment besoin de limiter mais surtout d'informer votre département informatique des utilisateurs qui serait en mesure d'effectuer une translation SID-nom, ou encore énumérer les utilisateurs et leurs SID. Il y a beaucoup trop d'informations qui peuvent être obtenus à partir de l'une de ces listes, pour un attaquant potentiel.

    • Historique des SIDs (direct from the source! - Richard B. Ward, Architect - Windows Core)

    "The original concept of the SID called out each level of the hierarchy. Each layer included a new sub-authority, and an enterprise could lay out arbitrarily complicated hierarchies of issuing authorities. Each layer could, in turn, create additional authorities beneath it. In reality, this created a lot of overhead for setup and deployment, and made the management model group even more baroque. The notion of arbitrary depth identities did not survive the early stages of development, although the structure was already too deeply ingrained to be removed. In practice, two SID patterns developed. For built-in, predefined identities, the hierarchy was compressed to a depth of two or three sub-authorities. For real identities of other principals, the identifier authority was set to five, and the set of sub-authorities was set to four."

     

    Même si la compréhension des SIDs dans le monde Microsoft peut paraître compliqué, j'espère que cet article vous aura permis de mieux comprendre leurs structures!

     

    Ressources :

     SECURITY CONFIGURATION GUIDANCE SUPPORT  - http://support.microsoft.com/kb/885409/en-us 

    [Windows Blue] - Communication officielle de Microsoft

    Apparue sous forme d’une rumeur en août 2012, l’information selon laquelle Microsoft travaillait sur une évolution de Windows 8 pour l’été 2013 s’est confirmée par le biais de fuites, jusqu’à ce que la confirmation soit officiellement donnée par l’éditeur lui-même hier, dans un post signé Frank X. Shaw, Corporate Vice President of Corporate Communications.

    Microsoft a annoncé mardi la tenue de l'édition 2013 de sa conférence Build, du 26 au 28 juin prochain, au Moscone Center de San Francisco. Traditionnellement dédiée aux développeurs, celle-ci devrait accorder une place certaine à Blue, nom de code de la prochaine évolution de Windows 8. « Blue » porte sur une évolution de la plate-forme Windows, couvre également Windows Server 2012, Windows Phone, ainsi que des versions « Blue » d’applications et services telles que Skydrive et Outlook.com.

    Ce ne sera pas une simple évolution des produits ; comme l’indique Frank Shaw, mais un moyen pour Microsoft d’avancer dans sa transformation d’une « softwares company » vers une « devices & services company ».

     

    • Côté Software

    L'éditeur peaufinerait son interface pour réduire davantages les "tuiles" du noyau 6.2 de Windows tout en offrant des possibilités de personnaliser les couleurs des thèmes graphiques. Coté applications, Windows aura dorénavant de manière native une calculatrice, une alarme et un dictaphone. Le service de stockage SkyDrive serait davantage intégré, a l'instar de Windows Phone il serait doté d'une option pour enregistrer les clichés de la webcam. Il permettrait également de gérer les sauvegardes de plusieurs appareils rattachés au même compte utilisateur. Internet Explorer 11.0 sera également de la partie qui amènera la modification du user agent en utilisant « IE » à la place de « MSIE ». Ces modifications devraient permettre de ne plus obtenir de site Internet spécialement adaptés à IE afin d'obtenir le même rendu que sur Firefox.


    Enfin la barre des charmes s'enrichirait de l'option PlayTo basée sur le standard DLNA permettant de lire un média sur un autre appareil connecté au même réseau local.

     

    • Coté Hardware

    Intel a déjà expliqué à de nombreuses reprises les efforts réalisés au niveau de son architecture pour optimiser la consommation énergétique des futurs Core i "4000" (le fondeur a par exemple promis 10 jours de veille connectée pour les PC portables munis d'un processeur Haswell...), il se murmure chez Cnet que la mise à jour Windows Blue ait en réalité surtout été optimisée pour ces processeurs, avec la mise au point d'un nouveau "power-model" dédié.

    Communication d'une source anonyme - "un PC plus rapide qu'avec un processeur Ivy Bridge, qui tiendra plus longtemps sur batterie en utilisation comme en veille, et ce malgré l'activation des options de synchronisation régulière avec les services Cloud qui feront sortir l'ordinateur de veille pour mettre à jour boîte e-mail et flux sociaux afin de tout avoir à jour au moment où l'utilisateur replonge le nez dans son laptop. Windows Blue est optimisé pour tout ça".

    Un point positif qui pourrait pousser davantage de particuliers et d'entreprises à considérer une migration de leurs ordinateurs sous Windows 8 "Blue".

     

    En conclusion, Blue serait aussi une étape clé pour renforcer la place de l’éditeur sur les marchés de la mobilité et du poste de travail, très menacés aujourd’hui, comme le montre le succès pour le moins mitigé de Windows 8 et Windows Phone 8.

     

    Sources

    MICROSOFT OFFICIAL BLOG - http://blogs.technet.com/b/microsoft_blog/archive/2013/03/26/looking-back-and-springing-ahead.aspx

    CNET - http://news.cnet.com/8301-10805_3-57575826-75/windows-blue-is-aimed-at-intel-haswell-ultrabooks/

     

    Ressources

    DLNA - http://www.dlna.org

    Posted by Jordan Laurent | with no comments
    Filed under:
    More Posts Next page »