Badack's blog

EMET ou Enhanced Mitigation Experience Toolkit est un outil mis au point par Microsoft dont l’objectif est de fournir une protection contre l’exploitation de failles critiques découvertes sur des applications tiers (Acrobat, Office, ….).

Par exploitation, il faut comprendre l’utilisation de la faille par du code malveillant.

Vu le temps que peut prendre le développement d’un correctif et au vu de la criticité de certaines failles, Microsoft a mis au point un outil permettant d’isoler l’application de 6 types d’exploitations (mitigation):

1. Dynamic Data Excecution Prevention (DEP)
2. Structure Exception Handler Overwrite Protection (SEHOP)
3. Heap Spray Allocation
4. Null Page Allocation
5. Export Address Table Access Filtering
6. Mandatory Address Space Layout Randomization (ASLR)

Certains type d’exploitations peuvent être détecté par l’OS (DEP depuis Windows XP, SEHOP depuis Windows Vista) et mettre en place une politique de protection, mais d’autres non.

C’est dans ce cadre que cet outil a été mis à disposition.

Voici un exemple de son utilisation une fois le produit installé:

Dès lors, lorsque cette application sera lancée, emet surveillera l’utilisation de la mémoire par l’application et si une des 6 méthodes d’exploitation est détectée, il rentrera en action pour protéger le poste de travail de toutes tentatives malveillante.

Je trouve que cet outil manque un peu de visibilité car il me semble qu’il est encore assez peu connu, d’où la raison de cet article.

Je vous invite donc à prendre connaissance des détails ici.

Source:

Technet Blog

Enjoy!!!!

Cette erreur peut survenir lorsque vous désirez déployer un second Management Server se connectant au DataStore0(la base de donnée SQL App-V) se trouvant sur un autre Management Server.

Cette erreur est générée dans l’Event Viewer avec un ID de 1005 :

Le fichier log de l’installation se trouve à l’emplacement suivant:

Settings\Temp\SoftGrid-server-setup.txt

En analysant le fichier, vous allez trouver l’erreur suivante qui n’est pas des plus explicites mais qui, grâce à l’aide de notre amis Google, est suffisante pour trouver de l’information quand à sa nature.

Voici le scénario qui m’a amené à rencontrer cette erreur.

A. Scénario :

Server1.MyDomain.Lab est le serveur principal de mon infrastructure App-V. Pour des raison d’équilibrage de charges, de redondance, je décide d’installer un second Management Server qui sera Server2.MyDomain.Lab.

Comme vous pouvez le voir sur le schéma, il n’est nullement question d’installer une seconde instance d’SQL Server. Je vous rappelle qu’avant la version 4.5 SP2, vous ne pouviez avoir qu’une seule instance de votre DataStore (à moins de clusteriserle tout).

Le service SQL Service fonctionne sous un compte de domain créé à cet effet : MyDomain\SQL2005SRVC.

Ce compte possède les droits d’administrateur local sur le Server1.MyDomain.Lab mais est un simple utilisateur au niveau du domain.

Lorsque je désire installer mon second management server, l’erreur se produit.

J’ai exécuté l’installation de App-V sous un compte ayant des droits Domain Admin pour écarter tout soucis à ce niveau.

Mais pourquoi diable cette erreur apparait donc ?

B. Explication :

Le fichier log de l’installation contient l’information sur l’erreur : Cannot generate SSPI context.

Qui dit SSPI, dit authentification intégrée Windows donc Kerberos.

Comme mon service SQL Server tourne dans un contexte autre que Local System ou qu’un compte Domain Admin, il lui manque des informations relatives à son Service Principal Name.

Dans mon cas, le compte de service n’avait pas les droits d’écrire de nouvelles valeurs pour son SPN.

Evidement, lorsque votre service SQL Server tourne dans un contexte Local System ou Domain Admin, il n’y a aucun problème de droit pour modifier le SPN.

C. Solution :

Au travers de l’outil ADSIEDIT.MSC, nous allons octroyer les droits de lecture et d’écriture à notre compte de Service : MyDomain\Sql2005Srvc.

1. Démarrer la console ADSIEDIT.MSC



2. Faites un clique droit sur le compte de service (en vous rendant dans le bon container) et sélectionnez Properties.



3. Allez dans l’onglet Security et cliquez sur Advanced



4. Sélectionnez l’entrée portant le nom SELF (si vous ne l’a trouvez pas, ajoutez là) et sélectionnez Edit.



5. Allez dans l’onglet Properties et cochez les 2 entrées suivantes :

• Read servicePrincipalName => Allow
• Write servicePrincipalName => Allow

6. Validez le tout et recommencez l’installation de votre second Management Server.

Pour plus d’information, voici le lien d’un article Microsoft traitant du sujet : Lien

Enjoy !!!!