PROJET AUTOBLOG


IT-Connect

Site original : IT-Connect

⇐ retour index

Windows : Supprimer un réseau Wifi

mercredi 15 avril 2015 à 09:05

I. Présentation

Dans ce tutoriel, nous allons voir comment supprimer un réseau Wifi dans Windows. Pour être exhaustif, nous allons effectuer cette manipulation sous les trois derniers OS de Windows :

Cette manipulation est en effet différente selon votre OS, c’est le sens du défi de Windows ;) . Personnellement, j’ai eu besoin d’effectuer cette manipulation lorsque je travaillais sur des tests Wifi, mais il peut y avoir différents contextes dans lesquels on peut avoir besoin de supprimer un ou plusieurs réseaux Wifi dans les profils sauvegardés.

II. Supprimer un réseau Wifi sous Windows 7

Pour Windows 7, il faut aller trouver l’endroit où l’on gère les connexions réseau sans fil. Pour cela, on commence par faire un clic droit sur l’icône réseau en barre de tâche, on sélectionne ensuite “Ouvrir le Centre Réseau et partage” :

supprimer-reseau-wifi-windows-7-01

Dans le “Centre Réseau et partage“, on va ensuite aller sélectionner “Gérer les réseaux sans fil” dans la barre de gauche :

supprimer-reseau-wifi-windows-7-02

Nous y sommes ! Ici, vous verrez toutes les connexions Wifi auxquelles vous vous êtes déjà connectés et qui ont donc créé un “profil” contenant, entre autre, le mot de passe de celui-ci pour ne pas que vous ayez à le ressaisir :

supprimer-reseau-wifi-windows-7-03

Liste des profils Wifi dans Windows 7

Dans cette liste, faites un clic droit sur la connexion Wifi que vous souhaitez supprimer puis sélectionnez “Supprimer un réseau” :

supprimer-reseau-wifi-windows-7-04

Accès à la suppression d’un profil Wifi sous Windows 7

On cliquera ensuite sur “Oui” dans le message de confirmation :

supprimer-reseau-wifi-windows-7-05

III. Supprimer un réseau Wifi sous Windows 8

Windows 8 fait apparaître une astuce très pratique pour effectuer cette manipulation rapidement, il suffit en effet de cliquer sur l’icône réseau présent dans la barre des tâches, puis de faire un clic droit sur le réseau Wifi à supprimer pour enfin sélectionner “Oublier ce réseau” :

supprimer-reseau-wifi-windows-8-01

Accès à la suppression d’un profil Wifi sous Windows 8

IV. Supprimer un réseau Wifi sous Windows 8.1

Sous Windows 8.1, la fonctionnalité vue pour Windows 8 a été retirée, ce qui est bien dommage car elle était bien pratique ! Au lieu de ça, il faut passer par la ligne de commande, plus précisément l’Invite de commande Windows pour procéder.

Avec un utilisateur administrateur du poste, faites donc “Windows + R” puis saisissez “cmd” et cliquez sur “OK” pour ouvrir l’invite de commande.
A partir de là, nous allons utiliser la commande “netsh” qui permet de gérer les interfaces réseau en ligne de commande.
Pour lister les profils réseau Wifi enregistrés, saisissez la commande suivante :

netsh wlan show profiles

On voit ici tous les profils, c’est à dire les réseaux Wifi qui sont enregistrés :

supprimer-reseau-wifi-windows-81-01

Liste des profils Wifi dans Windows 8.1 avec la commande “netsh”

Pour en supprimer un, il suffit de saisir la commande suivante :

netsh wlan delete profile name="profil"

Par exemple :

netsh wlan delete profile name="IIA5"

Pour supprimer tous les profils d’un coup, on peut utiliser l’astuce suivante :

netsh wlan delete profile name=* i=*

Voila ! Nous avons vu commencer supprimer des réseaux Wifi sous les différents systèmes d’exploitation Microsoft, il est un peu dommage que la manipulation soit différentes à chaque fois, mais j’espère que ces petites astuces vous auront dépanné ;)

Thecus publie une mise à jour du ThecusOS 5.0

mardi 14 avril 2015 à 17:15

Cela fait quelque temps que l’on a pas parlé de Thecus… Le fabricant de NAS a récemment publié une mise à jour de son système d’exploitation ThecusOS 5.

Ce qui est surprenant avec Thecus, c’est qu’ils maintiennent à jour deux versions d’OS majeures : ThecusOS 5 et ThecusOS 6.

logo-thecus6Au programme de cette mise à jour : l’ajout de fonctionnalités et l’apport de correctifs pour des vulnérabilités.

On notera la présence de “Disk Clone and Wipe” qui, comme son nom l’indique, permet la réplication et la destruction de données. Il y a des nouveautés avec un serveur VPN et PPTP, ainsi que pour le stockage la prise en charge de disque dur 4k en natif. Certains appareils pourront même bénéficier du média center Kodi. Quant au kernel Linux, il passe en version 3.10.66.

La nouvelle version 2.05.08 est compatible avec les NAS Thecus suivants :

• N16000, N12000, N16000PRO, N12000PRO, N16000V, N12000V, N8900V, N8900
• N6850, N8850, N10850
• N7710, N7710-G, N8810, N8810-G, N7700PROV2, N8800PROV2
• N2800, N4510U, N4510UPRO, N4800, N4800ECO, N5550, N7510

N’oubliez pas de faire une sauvegarde avant d’effectuer une mise à jour, par précaution.

Déverrouiller votre smartphone avec “OK Google”

mardi 14 avril 2015 à 15:00

Sous Android, il y a différentes manières pour déverrouiller son smartphone, notamment la reconnaissance de visages, le schéma, ou encore un code à quatre chiffres. Désormais, Google va ajouter un nouveau mode nommé “Trusted Voice” et que l’on peut traduire par la voix de confiance.

google-trusted-voice

Vous l’aurez compris, c’est donc par la voix que l’on pourra déverrouiller son smartphone, puisque le mécanisme analysera votre voix lorsque vous prononcerez “OK Google“. Cette commande vocale déjà utilisée pour commander son smartphone permettra maintenant de déverrouiller l’écran.

Google précise que ce mécanisme n’est pas très sécurisé, étant donné qu’une personne peut avoir la même voix ou peut tout simplement enregistrer votre voix… Pour le moment, la fonctionnalité est testée auprès de quelques utilisateurs.

Source

Shadow IT

mardi 14 avril 2015 à 14:00

Shadow IT (parfois Rogue IT) est un terme fréquemment utilisé pour désigner des systèmes d’information et de communication réalisés et mis en œuvre au sein d’organisations sans approbation de la direction des systèmes d’information (Source Wikipédia).

Bon, OK une fois que l’on a dit cela, on ne se rend pas bien compte des dégâts que cela peut poser au sein d’une entreprise et ce, quelle que soit sa taille !

shadow-itImaginez un peu, vous êtes Directeur Commercial au sein d’une PME et vous prenez l’initiative de contacter un plombier pour refaire les sanitaires de votre établissement, sans en parler au Directeur Technique en charge des Moyens Généraux, donc de la gestion des bâtiments de votre entreprise… Cerise sur le gâteau, vous commandez et faites effectuer les travaux et votre Direction Générale vous félicite pour ces magnifiques sanitaires ! Alors moi, si j’étais le Directeur Technique, j’irais voir une boîte de Comm. et je commanderai une nouvelle charte graphique pour l’entreprise ainsi que de nouvelles brochures commerciales… Euh, il n’y a pas comme un « schmilblick » quelque part ou comme une grossière erreur de casting ? Détrompez-vous, bienvenue dans l’entreprise 2.0 !

2.0, vous êtes sûr ? J’aurais tendance à dire -1.0 (moins un point zéro)…

Restons dans les anglicismes et je parlerai alors de deux termes, à priori que je viens d’inventer, et qui sont :

– « The Necessity Shadow IT », sous-entendue la prolifération de systèmes d’information, en dehors de la DSI (Direction des Systèmes d’Information), pour pallier à un manque certain de votre DSI…,

– « The Dark Shadow IT », sous-entendue la prolifération de systèmes d’information, en dehors de la DSI (Direction des Systèmes d’Information), faite en dépit de tout bon sens, par des membres de la Direction de l’entreprise se croyant plus forts que les autres, du style « jeunes loups aux dents longues » et n’ayant aucune légitimité en la matière…

Dans les deux cas, le DSI (la DSI) est mis à mal et, quelque soit la réussite des ces projets effectués dans ces conditions (si si, il y en a qui réussissent…), l’entreprise est mise à mal également, elle devient instable, difficile à gouverner et moins « sécurisée »…

Pour ceux d’entre vous qui me suivent un petit peu, vous savez que je suis le DSI d’une ETI (Entreprise de Taille Intermédiaire soit une GROSSE PME) et que mon entreprise appartient à deux grands (grands grands…) groupes français… Dans un de ces groupes, j’ai appris récemment qu’au sein d’une division, un tiers des applications « métier » n’étaient pas supportées par la DSI… Pourquoi ? Tout simplement parce que ces applications sont le résultat de développements et de systèmes achetés à l’extérieur sans aucune implication de la DSI de l’entreprise. Je pensais alors que certains « métiers » avaient acheté des solutions « tout-en-un », en mode SaaS (Software as a Service – en français : l’application tourne sur les systèmes mêmes du fournisseur de la solution) ce qui ne choquait qu’à moitié mais NON… Il y a des endroits dans ce grand groupe où tournent des serveurs qui ne sont pas gérés par la DSI !!! Ben comment ils font alors pour la sécurité, la gestion des identités, la gestion des licences et tout le reste ? Mystère…ou plutôt « misère »…

Il y a quelques semaines, j’ai eu vent d’un incident sur une de ces applications dans la mouvance du « Shadow IT » et le mail envoyé par le responsable de cette application fait froid dans le dos, je cite : « le serveur s’est arrêté suite à une panne de courant (ben oui, c’est du « shadow » alors ce n’est pas protégé…) et quand le serveur a redémarré, il s’est emballé (comme un œuf de Pâques?) et la macro Excel s’est plantée !… » Véridique ! Elle n’est pas belle la vie ? En creusant un peu (je suis curieux…), cette macro Excel se connecte à une base de données de l’entreprise (gérée par la DSI…) pour y extraire quelques informations et les renvoyer sur un serveur FTP je ne sais trop où… A priori, il n’y a pas de mal, on sait qu’Excel (beurk…) est l’outil décisionnel et de reporting plébiscité par la majorité des entreprises (c’est sûr ? Oui…oui…) mais quand on apprend que cette extraction quotidienne de données est vitale pour la production d’une partie de cette division, alors là, c’est le pompon de la pomponette…sous-entendu c’est « trop fort », c’est le bouquet, c’est du n’importe quoi, on marche sur la tête…etc… !

Messieurs les dirigeants et autres Directeurs Généraux, soit votre DSI n’est pas le bon et vous lui faites un chèque afin qu’il aille installer Windows 3.11 (for Workgoups!) ailleurs, soit vous virez votre Directeur Commercial mais, de grâce, ne laissez pas votre jardinier faire le réglage du turbo de votre Maserati, vous risquez d’en perdre la garantie !

Quelle version du protocole SMB utilisez-vous ?

mardi 14 avril 2015 à 09:30

I. Présentation

Le protocole SMB est relativement ancien, mais continue d’évoluer au fil du temps, ce qui en fait un protocole très utilisé notamment pour le transfert de données par l’intermédiaire des partages réseau. Pour rappel, SMB signifie Server Message Block.

Dans ce tutoriel, on va commencer par faire un historique de ce protocole, nous verrons ensuite les compatibilités système entre les différentes versions. Enfin, on manipulera la console PowerShell pour vérifier quelle version de SMB vous utilisez.

II. Historique des versions

La première version de SMB ne s’appelle pas SMB, en fait c’est le protocole CIFS (Common Internet File System) qui représente la première version de ce protocole. Autant vous dire que ce n’est pas tout nouveau puisque ce fût créé à l’époque de Windows NT 4.0.

Par la suite, et plus précisément depuis Windows 2000 la première version du protocole SMB est arrivée. Voici un récapitulatif des versions du protocole SMB :

SMB 1.0 : La première version portant le nom de SMB est arrivée avec Windows 2000, et fût utilisée par Windows XP, Windows Server 2003 et Windows Server 2003 R2.

SMB 2.0 : La version utilisée dans Windows Vista (SP1 et supérieur) et son équivalent serveur à savoir Windows Server 2008.

SMB 2.1 : La version utilisée dans Windows 7 et Windows Server 2008 R2.

- SMB 3.0 : La naissance de la v3 du protocole SMB, au lancement de Windows 8 et de Windows Server 2012.

SMB 3.02 : Les premières évolutions du protocole SMB v3 profitent à Windows 8.1 et Windows Server 2012 R2 avec cette version v3.02 du SMB.

Vous avez maintenant connaissance de l’évolution du protocole SMB dans le temps et les versions de Windows qui ont introduit ces différentes versions.

III. Négociation client/serveur : le tableau des compatibilités

Grâce à l’historique énuméré précédemment, on peut déduire le tableau de compatibilité ci-dessous. Effectivement, un serveur Windows Server 2012 R2 ne pourra pas utiliser le SMB v3.02 pour dialoguer avec une machine sous Windows XP qui ne connaît que le protocole SMB v1. De ce fait et en fonction de l’état de votre parc informatique, ce tableau est à prendre en considération.

smb-compatibilité

Il est à noter qu’une machine qui supporte la version v3 du protocole SMB, sera tout à faire capable d’utiliser les versions plus anciennes si cela est nécessaire pour dialoguer avec un client spécifique. Cela requiert tout de même que les anciennes versions du protocole soient laissées actives sur la machine (c’est le cas par défaut). Si c’est bien le cas, la négociation SMB s’effectuera en toute transparence.

IV. Quelle version du SMB utilise mon serveur ?

Pour savoir quelle version de SMB utilise votre serveur, ou plutôt quelle est la version la plus récente qu’il est capable de gérer, on peut très bien se référencer au tableau vu précédemment.
Par précaution, il vaut mieux vérifier par soi-même en PowerShell. Pour ma part, je me trouve sur un poste de travail en Windows 8.1 (ce serait la même chose pour son équivalent Windows Server 2012 R2).

Pour obtenir cette information, on va simuler une connexion SMB sur la boucle locale de notre machine, tout simplement en listant le contenu du lecteur C: via SMB. Ce qui donnera :

dir \\localhost\c$

Et rapidement, vous devez enchaîner avec la commande ci-dessous avant que la session SMB se clôture.

Get-SmbConnection -ServerName localhost

Cette commande permet de lister les connexions SMB en cours sur l’hôte local (localhost). La valeur qui nous intéresse est celle de la colonne “Dialect” qui permet de savoir le numéro de version du protocole SMB utilisé pour cette connexion.

smb-dialect1

Le fait de voir “3.02” permet de déterminer que notre machine est capable d’utiliser le SMB v3.02. C’est tout l’intérêt de faire ce test sur la boucle locale, car on est à la fois le client et le serveur, ce qui permet d’obtenir un résultat cohérent.

V. Pourquoi passer à SMBv3 ?

Les changements apportés par la version v3.0 du protocole SMB sont conséquents puisqu’ils améliorent la disponibilité, les performances et la sécurité.

On retrouve notamment la possibilité de faire des snapshots VSS pour des fichiers distants, la gestion multichannel (SMB Multichannel), le chiffrement des échanges en s’appuyant sur de l’AES-CCM, le SMB Direct qui tire profit du RDMA (débit augmenté, faible latence et moins de cycles d’utilisation du processeur), etc. De plus, SMB peut être configuré et géré grâce à de nombreuses commandes PowerShell, un atout supplémentaire sans aucun doute.

Il n’y a que de bonnes raisons à vouloir passer à SMBv3, mais il faut s’assurer au préalable de la compatibilité de tous les clients potentiels, avant de passer sur un serveur capable de gérer le SMBv3. Après, vous pouvez laisser actifs SMBv1 et/ou SMBv2 pour les quelques clients incompatibles.

Je tiens à préciser que le SMBv3 est fortement recommandé pour utiliser des machines virtuelles Hyper-V stockées sur un espace de stockage accessible par le réseau.

Je terminerais cette partie en parlant des implémentations tierces du SMB, à savoir non-Windows. Il est important de préciser que sous Linux, Samba 4.1 intègre SMBv3, de la même manière qu’il existe un client Linux pour SMBv3 disponible depuis le noyau Linux 3.11. Par ailleurs, les NAS comme ceux de chez Asustor et les distributeurs de baies de stockage tels que EMC et NetApp proposent le SMBv3.

VI. Désactiver le SMBv1 et/ou SMBv2

Pour finir, et si vous êtes prêt à basculer sur du 100% SMBv3, on va voir comment désactiver le SMBv1 voir même le SMBv2, en PowerShell.

Set-SmbServerConfiguration –EnableSMB1Protocol $false

Comme son nom l’indique, la commande ci-dessus permet de modifier la configuration du SMB, en l’occurrence ici le paramètre qui sert à rendre actif ou non la version 1 du protocole SMB. Si vous souhaitez effectuer la même chose pour SMBv2, répétez l’opération en modifiant le nom du paramètre :

Set-SmbServerConfiguration –EnableSMB2Protocol $false

Avec la commande “Get-SmbServerConfiguration” on peut vérifier que les deux paramètres “EnableSMB1Protocol” et “EnableSMB2Protocol” sont bien sur l’état false.

EnableSMB1Protocol : False
EnableSMB2Protocol : False

Ce tutoriel est désormais terminé, j’espère qu’il vous permettra de prendre conscience des différentes versions SMB qui existent, et de faire évoluer votre infrastructure en “migrant” vers cette nouvelle version. Il est recommandé de passer à chaque fois à la version du SMB la plus récente, pour obtenir une implémentation plus performante et plus sécurisée.