PI Services

Le blog des collaborateurs de PI Services

Sécurité : Windows KB pour Wanna Cry

 

Suite à l'attaque du virus Wanna Cry, tout le monde a souhaité corriger la faille de sécurité au plus vite.

Avec tout ce qu'on a pu lire ou trouver sur internet on ne sait plus vraiment qui fait quoi et si nous sommes réellement protégé.

Liste des KB de Sécurité

Voici la liste des KB de sécurité couvrants la faille (pour information les KB se remplacent d'un mois à l'autre : exemple la KB du mois d'avril remplace celle de Mars):

  1. Pour Windows XP, Vista, 8, Windows Server 2003 et 2008 : 
    1. Mars 2017
      1. KB4012598
  2. Pour Windows 7 SP1 et Windows Server 2008 R2 SP1:
    1. Mars 2017
      1. Security only update : KB4012212
      2. Monthly Rollup : KB4012215
      3. Preview of Monthly Rollup : KB4012218
    2. Avril 2017
      1. Security only update : KB4015546
      2. Monthly Rollup : KB4015549
      3. Preview of Monthly Rollup : KB4015552
    3. Mai 2017
      1. Security only update : KB4019263
      2. Monthly Rollup : KB4019264
      3. Preview of Monthly Rollup : KB4019265
  3. Pour Windows Server 2012 :
    1. Mars 2017
      1. Security only update : KB4012214
      2. Monthly Rollup : KB4012217
      3. Preview of Monthly Rollup : KB4012220
    2. Avril 2017
      1. Security only update : KB4015548
      2. Monthly Rollup : KB4015551
      3. Preview of Monthly Rollup : KB4015554
    3. Mai 2017
      1. Security only update : KB4019214
      2. Monthly Rollup : KB4019216
      3. Preview of Monthly Rollup : KB4019218
  4. Pour Windows 8.1 et Windows 2012 R2 :
    1. Mars 2017
      1. Security only update : KB4012213
      2. Monthly Rollup : KB4012216
      3. Preview of Monthly Rollup : KB4012219
    2. Avril 2017
      1. Security only update : KB4015547
      2. Monthly Rollup : KB4015550
      3. Preview of Monthly Rollup : KB4015553
    3. Mai 2017
      1. Security only update : KB4019213
      2. Monthly Rollup : KB4019215
      3. Preview of Monthly Rollup : KB4019217
  5. Pour Windows 10 (Release 1511) :
    1. Mars 2017
      1. KB4013198
      2. KB4016636
    2. Avril 2017
      1. KB4015219
    3. Mai 2017
      1. KB4019473
  6. Pour Windows 10 (Release 1607) :
    1. Mars 2017 
      1. KB4013429
      2. KB4015438
      3. KB4016635
    2. Avril 2017
      1. KB4015217
    3. Mai 2017
      1. KB4019472
      2. KB4023680
  7. Pour Windows 10 LTSB : 
    1. Mars 2017 
      1. KB4012606
      2. KB4016637
    2. Avril 2017
      1. KB4015221
    3. Mai 2017
      1. KB4019474

En espérant que cela pourra vous servir.

Pour télécharger les KB : http://www.catalog.update.microsoft.com/home.aspx

 

 

Le fichier NetSetup.log

Bonjour à tous,

Qui n'a jamais rencontré d'échecs lors de la mise en domaine d'un poste ?

Les messages d'erreurs fournis à cette occasion ne sont pas forcément des plus explicites, ni des plus détaillés.

Heureusement il y a une solution et celle-ci s'appelle NetSetup.log

Vous trouverez ce fichier dans le dossier C:\Windows\debug.

Pour ce qui est de la structure du fichier, vous pouvez vous référer à la capture ci-dessous, mais voici un résumé des informations contenues dans celui-ci :

  • Nom du contrôleur de domaine contacté pour la jonction au domaine
  • Nom du site Active Directory détecté
  • Identifiants utilisés pour la jonction
  • OU de destination du poste
  • Résultats lors de la création de l'objet ordinateur (SPNs, Nom DNS, ... )
  • Etc ...

Bonne découverte !

 

Clients disparaissant aléatoirement dans la console WSUS

Contexte

Lors du déploiement d'un nouveau serveur WSUS, des serveurs ou postes de travail apparaissent et disparaissent de la console sans raison logique au premier abord.

Explication

Si les clients apparaissent et disparaissent de la console par intermittence, le soucis vient probablement du SUSClientID.

Cette situation peut arriver quand un serveur est cloné et que les clés de registre liées au SUSclientID ne sont pas modifiées, ou dans le cas des postes de travail, le problème peut se poser si les postes sont déployés via une image système mal configurée (pas de sysprep). 

Résolution

La solution a ce problème est relativement simple une fois que les différents clients concernés ont été identifiés.

Sur chaque client concerné, supprimez clés de registre suivantes:

  • SusClientId
  • SusClientIDValidation

Ces clés sont situées à la racine de la ruche: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate

Ouvrez ensuite une invite de commande en mode administrateur et exécutez les commandes suivantes:

  • wuauclt.exe /resetauthorization / detectnow
  • wuauclt.exe /detectnow

Il faut refaire ces actions sur chaque poste client/serveur concerné.

Les clients devraient ensuite remonter sans soucis dans la console WSUS.

 

Poste de Travail : Fixer le Navigateur par Défaut

Voici comment fixer le navigateur par défaut de vos utilisateurs.

Via PowerShell:

Exécutez les commandes suivantes à l'ouverture de session utilisateur sous forme de script powershell en fonction de votre choix.

Pour Internet Explorer:

Set-Location HKCU:\
    Set-ItemProperty 'HKCU:\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\ftp\UserChoice' -name ProgId IE.FTP
    Set-ItemProperty 'HKCU:\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice' -name ProgId IE.HTTP
    Set-ItemProperty 'HKCU:\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\https\UserChoice' -name ProgId IE.HTTPS

 

Pour Mozilla Firefox:

Set-Location HKCU:\
    Set-ItemProperty 'HKCU:\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\ftp\UserChoice' -name ProgId FirefoxURL
    Set-ItemProperty 'HKCU:\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice' -name ProgId FirefoxURL
    Set-ItemProperty 'HKCU:\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\https\UserChoice' -name ProgId FirefoxURL

Vous pouvez aussi le faire par GPO dans "Configuration Utilisateur > Paramètres Windows > Registre"

Powershell : Découverte des postes en DHCP et IP fixes

Qui n'a jamais été confronté à un conflit d'adresse IP dans son réseau?

Le plus énervant quand cela arrive c'est de déterminer qui a une IP fixe sur sa machine alors que l'ensemble du parc est censé être en DHCP.

Afin de se se faciliter la tâche et de ne pas devoir passer sur chaque poste voici un script qui va vous permettre de savoir quels postes sont éteints, quels postes sont en DHCP et surtout lesquels ne le sont pas et avec quelle adresse IP (ou plutôt l'ensemble des configurations de chaque carte réseau).

Les Outils :

Pour ce faire vous aurez besoin d'un fichier texte avec les informations suivantes:

  • La première ligne doit s'appeler "Ordi"
  • le reste du fichier contient le nom de vos machines

Exemple :

Dans mon cas le fichier s'appelle DHCP.txt (le nom sera réutilisé dans le Script)

Une fois que le fichier est créé passons à la seconde partie le script:

Dans votre cas il suffira de modifier les lignes:

  • 3
  • 10
  • 17
  • 18
  • 19 
# Script pour détecter l'état des cartes réseaux

$CSV = "C:\Users\XXX\Documents\DHCP.txt"  # Ici on déclare le chemin d'accès au fichier créé plus tôt

# Import du fichier
Import-Csv -Path $CSV | ForEach-Object {

# Déclaration des variables
$Postes = $_.ordi
$Destination = "C:\Users\XXX\Documents\Audit\DHCP\$Postes.txt" # Attention Ici lorsque vous modifiez le chemin ne supprimez pas $Postes.txt

# Test de connexion afin de vérifier que le poste est démarré
If ((Test-connection $Postes -count 2 -Quiet) -eq "True") {

# Déclaration des variables
$Postes = $_.ordi
$Destination = "C:\Users\XXX\Documents\Audit\DHCP\$Postes.txt" # Attention Ici lorsque vous modifiez le chemin ne supprimez pas $Postes.txt
$Poste_DHCP = "C:\Users\XXX\Documents\Audit\OK.txt" # Ici on déclare le chemin et le fichier dans lequel seront inscrit les postes en DHCP
$Poste_Off = "C:\Users\XXX\Documents\Audit\NOK.txt" # Ici on déclare le chemin et le fichier dans lequel seront inscrit les postes éteints

# Récupération des paramètres de la ou des cartes réseaux
Get-WmiObject Win32_NetworkAdapterConfiguration -ComputerName $Postes | ForEach-Object {
$IP = $_.IPAddress
$DHCP = $_.DHCPEnabled
if (($DHCP -eq $False) -and ($IP -ne $null)) {Get-WmiObject Win32_NetworkAdapterConfiguration -ComputerName $Postes | Select-Object -Property ServiceName,Description,DHCPEnabled,IPEnabled,IPAddress | fl | Out-File $Destination}
Elseif (($DHCP -eq $True) -and ($IP -ne $null)) {Write-Output "Le poste $Postes est en DHCP" | Add-Content -Path $Poste_DHCP}
}
}
Else {
Write-Output "Le poste $Postes est éteint" | Add-Content -Path $Poste_Off
}}

 

En espérant que cela vous servira.

Le Service Pack 2 pour Windows 7 SP1 et Windows Server 2008 R2 SP1

Suite à l'interrogation d'un client à propos des différentes versions d'OS et de leurs Services Pack, force m'a été de constater que le "Convenience Rollup Update for Windows 7 SP1 and Windows Server 2008 R2 SP1" paru en avril 2016, soit 5 ans après le SP1 (février 2011), n'était pas fourni directement par Microsoft via Windows update.

En effet, ce qui s'apparente à un service pack mais qui n'en est pas un, n'est mis à disposition que sur le "Microsoft Catalog Update".

Ce "CRU" de 316 à 476Mo selon le package, contient un peu plus de 200 mises à jour soit toutes celles depuis le SP1 jusqu'au mois de mai 2016 (à l'heure ou j'écris ces lignes). 

 

Prérequis :

Pour pouvoir installer le Rollup package vous devrez disposer des éléments suivants:

  1. Service Pack 1 for Windows 7 or Windows Server 2008 R2 (KB976932)
  2. April 2015 servicing stack update for Windows 7 and Windows Server 2008 R2 (KB3020369)
  3. 4Go d'espace libre sur le disque
  4. Utiliser Internet Explorer pour le téléchargement (Vous aurez un message comme ci-dessous avec les autres navigateurs)

Sans Internet Explorer

 

Téléchargement :

Pour télécharger le package utilisez Internet Explorer puis rendez vous sur l'URL : Microsoft Catalog Update

Ici un Pop-up vous invitant à installer un module complémentaire apparaît, cliquez sur "installer"

Module à installer

Ensuite à l'aide du menu contextuel recherchez la KB3125574 (vous n'êtes pas obligé d'écrire KB le numéro suffit).

KB3125574

3 packages s'offrent à vous : 

  1. Le premier pour Windows 7 SP1 32 bits
  2. Le deuxième pour Windows Serveur 2008 R2 SP1 64 bits
  3. Le troisième pour Windows 7 SP1 64bits

Sélectionnez celui ou ceux qui vous intéressent à l'aide du bouton "Ajouter"

Packages

Puis cliquez sur "Afficher le panier"

 Panier

Et enfin "Télécharger". Download

Une fenêtre s'ouvre pour afin que vous puissiez indiquer le répertoire de destination de votre téléchargement, à la suite de quoi le téléchargement débutera automatiquement.

Directory

En cours

Fin

 

Une fois ce dernier terminé il ne vous reste plus qu'a vous rendre dans le répertoire que vous avez indiqué plus tôt; dedans se trouvera un ou plusieurs répertoires portant le nom du ou des packages récupérés.

CRU

 

Vous n'aurez plus qu'à ouvrir le "Package autonome Microsoft Update (.msu)" précédemment téléchargé et attendre sagement que les mises à jours s'installent.

Package autonome Microsoft Update (.msu)

Nota bene :

Microsoft n'a prévu aucun correctif pour le navigateur "Internet Explorer", la firme américaine vous propose simplement de télécharger et installer la dernière version disponible et bien entendu de faire les mises à jours via Windows update.

 

 

https://support.microsoft.com/en-us/kb/3125574

https://support.microsoft.com/en-us/kb/3156417

 

 

 

Dysfonctionnement sur Microsoft Office suite à la mise à jour de sécurité MS14-082 (Décembre 2014)

 

Suite à la distribution de la mise à jour de sécurité Office MS14-082 le 9 décembre 2014, vous rencontrez un problème avec l’exécution de vos documents Excel contenant des macros et contrôles ActiveX ? Si la réponse est oui, cet article peut vous intéresser.

Comment se matérialise l’incident ?

Selon l’article officiel disponible ici, Microsoft liste plusieurs symptômes permettant d’identifier l’incident. Pour faire simple suite à l'application de la mise à jour, l’incident vous empêche d’exploiter vos fichiers Office contenant des macros et contrôles ActiveX. Dans notre situation, l’activation du contenu actif d’un fichier Excel contenant des macros était devenue tout simplement impossible.

Dans le détail : L’installation de la mise à jour créée une désynchronisation des bibliothèques de types de contrôle mises en cache (Fichiers portant l’extension .exd)

Vous trouverez ci-dessous les références des mises à jour qui génèrent l’incident :

· Security Update for Microsoft Office 2007 suites (KB2596927)

· Security Update for Microsoft Office 2010 (KB2553154)

· Security Update for Microsoft Office 2013 (KB2726958)

Quels sont les produits impactés ?

Les suites Office 2007, 2010 et 2013 peuvent être impactées par l’installation du correctif. En détail :

· Microsoft Excel 2013

· Microsoft Word 2013

· Microsoft PowerPoint 2013

· Microsoft Visio Standard 2013

· Microsoft Visio Professional 2013

· Microsoft Excel 2010

· Microsoft Word 2010

· Microsoft PowerPoint 2010

· Microsoft Visio Professional 2010

· Microsoft Visio Premium 2010

· Microsoft Visio Standard 2010

· Microsoft Office Excel 2007

· Microsoft Office Word 2007

· Microsoft Office PowerPoint 2007

· Microsoft Office Visio Professional 2007

· Microsoft Office Visio Standard 2007

Comment résoudre le problème ?

Vous pouvez appliquer la solution préconisée ci-dessous :

1. Fermer les classeurs Excel

2. Ouvrir l'explorateur Windows

3. Sélectionner le disque C:

4. Saisir dans la barre de recherche la chaîne de caractères suivante : *.exd

5. Lancer la recherche (attendre que la recherche soit terminée)

6. Plusieurs éléments portant l'extension exd vont être trouvés. Sélectionner et supprimer l'ensemble des éléments trouvés

7. Ouvrez de nouveau votre fichier Excel. Le problème devrait disparaître.

Sources d’informations

Si besoin vous trouverez des informations complémentaires sur les liens ci-dessous :

http://stackoverflow.com/questions/27497444/excel-2010-command-button-no-longer-activate-its-click-event

https://social.technet.microsoft.com/Forums/en-US/b8f0af82-0bb8-4799-aa62-1dbcbc5b7742/excel-2010-macros-does-not-work-after-updates-9dec2014?forum=excel

http://blogs.technet.com/b/the_microsoft_excel_support_team_blog/archive/2014/12/11/forms-controls-stop-working-after-december-2014-updates-.aspx

Windows – Changement de domaine Active directory d’un poste connecté en VPN.

 

Comme toute migration ou changement de domaine d’un poste de travail cette opération doit rester la plus transparente possible pour l’utilisateur final.

Cet article aborde la migration d’un poste connecté au réseau d’entreprise par un VPN.

Dans cette situation ce n’est pas la migration du poste qui pose une difficulté, mais l’impossibilité pour l’utilisateur de pouvoir ouvrir une session sur son poste.

Les informations d’authentification du compte (en cache) du domaine Active Directory qu’on peut utiliser même si le domaine n’est pas disponible, ce qu’on décrit comme le mode hors connexion, ne sont plus disponibles après le changement du domaine.

Par défaut Windows 7 cache jusqu’à dix comptes.

Le cache est enregistré dans la ruche suivante : HKEY_LOCAL_MACHINE\SECURITY\Cache.

clip_image002

Pour accéder à cette ruche il faut utiliser un outil tel que PsExec de SysInternal afin de débloquer l’accès.

La ligne de commande est la suivante : psexec -i -d -s c:\windows\regedit.exe

Après le changement de domaine les données mentionnées dans les valeurs NL$ seront supprimées (remises à zéro).

L’utilisateur ne peut donc plus ouvrir de session !

Pour ma part j’ai eu à traiter des utilisateurs travaillant dans des coins très reculés.J’ai eu part exemple le cas d’un VIP travaillant en Australie à plus de 3000 kms d’une agence disposant d’un réseau connecté à l’entreprise. La marge de manœuvre est quasiment nulle…

Pour contourner ce problème je propose deux techniques.

La première technique consiste à démarrer la connexion VPN donc l’authentification avant l’authentification Windows.

Il faut donc avant la migration configurer le client VPN afin qu’il se lance avant l’authentification Windows.

Sur les clients VPN récents de CheckPoint l’option Enable Secure Domain Logon permet ce mécanisme.

clip_image004

Vous verrez un icône supplémentaire dans la fenêtre d’authentification Windows.

Pour information cette option pour le client CheckPoint sur Windows XP n’est pas fonctionnelle.

La seconde technique si l’on ne souhaite pas ou si l’on ne peut pas démarrer la connexion VPN avant l’authentification Windows, consiste à ouvrir une session locale puis à lancer une application qu’on exécute en tant que avec son compte de domaine. Bien entendu la connexion VPN doit être démarrée.

En résumé :

· Création d’un compte local (admin si possible, bien utile pour se sortir de situation délicate) avant la migration.

· Après migration, authentification avec ce compte local.

· Lancer le VPN.

· Lancer une application. Exécuter en tant que (ex Notepad) avec son compte de domaine. (Pour information le RunAS ne fonctionne pas sous XP).

· Fermer la session et ouvrir une session avec son compte de domaine Active Directory.

Le VPN n’étant pas démarré, les informations mis en cache lors du lancement de Notepad exécuté « En tant que » précédemment seront utilisées.

La migration sous un VPN étant très délicate il faut bien entendu bien valider son processus avant de passer au concret.

Je conseille fortement quel que soit le scénario, de créer un compte local admin et de faire installer un outil tel que Team Viewer qui s’affranchit de l’adresse IP pour l’aide à distance.

Powershell : Définir la liste d'adresse par défaut d'Outlook

Problème rencontré

Lors d'une migration Exchange inter organisation visant à la consolidation des infrastructure de messagerie des filiales d'une entreprise, il s'est présenté la problématique suivante. Il fallait que les utilisateurs aient accès dans leur client Outlook à une liste d'adresse correspondant à leur filiale. Cette dernière devait être la liste visible par défaut.

Solution proposée

Pour se faire, il est nécessaire de modifier une clé de registre sur les postes clients.
Dans la ruche : "HKCU:\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\", sont listés les profiles du client Outlook. Une ruche est présente dans chacun de ceux-ci : "9207f3e0a3b11019908b08002b2a56c2". Celle-ci contient la clé "01023d06" qui définit la liste d'adresse qui sera affiché par défaut à l'ouverture du carnet d'adresse. Attention la valeur est encodé au format Bytes HEX. Nous verrons comment la définir.

S'agissant d'appliquer une modification du registre à l'ensemble des postes clients d'une filiale, la solution la plus simple était d'implémenter cela dans le login script. Cela sera fait en Powershell. Il est bien entendu aussi possible de réaliser cette opération en VBS.
 
Il est à savoir que la vue par défaut du carnet d'adresse est la "Global Address List". De plus, si une valeur erronée est inscrite dans la clé de registre (ne correspondant à aucune liste d'adresse) alors Outlook repositionnera automatiquement le carnet d'adresse sur la liste d'adresse globale.

Récupération des paramètres

Afin de connaitre la valeur que nous devons positionner sur la clé "01023d06", il faut paramétrer manuellement Outlook afin de récupérer la valeur que l’on devra positionner. Pour cela, on définit la liste d’adresse sur laquelle on souhaite que nos utilisateurs se trouvent par défaut.

3

Ensuite, on peut ouvrir la clé de registre qui nous intéresse et observer sa valeur.

1

Si l'on modifie plusieurs fois cette valeur, on remarque le phénomène suivant. Elle se découpe en 3 parties :
- Une première qui est généré dynamiquement par utilisateur (avant le trait rouge)
- Une seconde qui est fixe qui va nous être utile pour récupérer la partie dynamique (entre le trait rouge et vert).
- Une troisième partie fixe (après le trait vert).

Ces trois éléments ont toujours une longueur fixe.

Il faut ensuite reformater les deux dernières parties sous forme de tableau de bytes. Il suffit devant chaque valeur en byte d’ajouter “0x” et de mettre une virgule entre toutes les bytes (syntaxe d'un tableau en Powershell).
Exemple :

01 00 00 00 00 01 00 00 2F devient 0x01,0x00,0x00,0x00,0x00,0x01,0x00,0x00,0x2F. Dans le script cette valeur sera définit par la variable $GALSuffix.

67 75 69 64 3D 38 42 34 39 43 31 36 34 45 44 35 41 36 34 30 39 34 42 30 42 4236 35 43 34 45 38 46 39 42 39 00 devient 0x67,0x75,0x69,0x64,0x3D,0x34,0x38,0x42,0x34,0x39,0x43, 0x31,0x36,0x34,0x45,0x44,0x35,0x41,0x36,0x34,0x30,0x39,0x34,0x42,0x30,0x42,0x42, 0x36,0x35,0x43,0x34,0x45,0x38,0x46,0x39,0x42,0x39,0x00.

Dans le script cette valeur sera définit par la variable $GALDefaultValue.

Script

Ci-dessous, le script commenté, où l'on va appliquer les paramètres que l'on a récupéré précédemment. Ceux-ci seront comparés avec ceux que l'on retrouve dans la clé de registre "11023d05" qui contient une configuration de sauvegarde. Cela permet de récupérer la première partie qui est dynamique.

2

Entre la ligne 37 et 47 on compare un à un les bytes rencontrés dans la clé de registre "11023d05" afin de retrouver l’index ou se trouve le tableau de bytes contenu dans $GALSuffix. Une fois cette valeur obtenue, on sait que la partie dynamique à rechercher est définie dans les 20 bytes précédentes.