Archives de la catégorie ‘Windows Client’

OpenSSH : Un Quick Overview

OpenSSH est une Collection d’utilitaires Client/Server qui vous permettent d’établir des connexions distantes sécurisées, le (Secure) transfert de fichiers à distance ainsi que le Public/Private Key (Pair) Management.

OpenSSH est un outil extrêmement puissant qui a été créé dans le cadre du projet OpenBSD et qui, reste toujours utilisé depuis de nombreuses années dans les écosystèmes BSD, Linux, MacOS et Unix.

Pour en savoir plus sur OpenSSH, je vous invite à consulter cette page.

 

OpenSSH sur Windows 10, Amazing, Non  ^__^ ?

Je ne sais pas si vous êtes au courant, mais Microsoft à introduit (depuis quelques temps déjà :)) une super fonctionnalité (Optional Feature) au niveau de son OS Client « Windows 10 ». Il s’agit du client OpenSSH (Disponible en version « Beta » au moment de l’écriture de ce post).

Donc, si vous étiez jaloux de vos MacOS & Linux Friends, qui peuvent le faire depuis des siècles, eh bien ne le soyez plus :).

Allez, découvrons comment le Built-in OpenSSH Client peut être installé/activé et utilisé sur Windows 10 :).

 

Options d’installation du Client OpenSSH

Le Client OpenSSH peut être installé/activé via différents tools, à savoir :

Windows PowerShell

DISM.exe

Outil « GUI » : Applications et fonctionnalités

Note : l’installation du client OpenSSH nécessite un reboot de la machine !

 

 HowTo : Installer OpenSSH Client via Windows PowerShell

Pour installer/activer le client OpenSSH via PowerShell, lancez la console PowerShell (en tant qu’Admin) et saisissez la commande suivante :

Add-WindowsCapability –Online –Name OpenSSH.Client~~~~0.0.1.0

Tip : pour supprimer le client OpenSSH via Windows PowerShell, exécutez la commande suivante :

Note : un reboot post-suppression du client OpenSSH est également requis !

 

 HowTo : Installer OpenSSH Client via l’outil DISM.exe

L’outil DISM.exe (Deployment Image Servicing and Management) peut également être utilisé pour installer le client OpenSSH.

Pour ce faire, exécutez la commande suivante depuis une Invite de commande (CMD.exe) ou console PowerShell lancée en tant qu’Admin :

DISM /Online /Add-Capability /CapabilityName:OpenSSH.Client~~~~0.0.1.0

Vous êtes invité à redémarrer votre machine pour que l’install soit prise en compte.

Tip : pour supprimer le client OpenSSH via l’outil DISM, exécutez la commande suivante :

DISM /Online /Remove-Capability /CapabilityName:OpenSSH.Client~~~~0.0.1.0

 

 HowTo : Installer OpenSSH Client via la console « Paramètres Windows > Applications et fonctionnalités »

Depuis l’application « Paramètres Windows« , saisissez « Applications.. », localisez et cliquez sur « Applications et fonctionnalités »

La fenêtre suivante apparaît, cliquez sur « Gérer les fonctionnalités facultatives » :

Enfin, cliquez sur « Ajouter une fonctionnalité« , cherchez et localisez le client OpenSSH sur la liste et enfin, cliquez sur « Installer » pour l’activer sur votre machine.

Tip : la console « Applications et Fonctionnalités » peut être accessible directement depuis le « Search Menu » ou « Menu Exécuter » en saisissant la commande suivante :

ms-settings:appsfeatures


Check post-installation du Client OpenSSH

Vous pouvez utiliser les techniques ci-dessous pour vérifier que le client OpenSSH a bien été installé

Check depuis Windows PowerShell

Exécutez la commande suivante :

Get-WindowsCapability -Online | ? Name -like 'OpenSSH.Client'

Check depuis DISM

Exécutez la commande suivante :

DISM /Online /Get-CapabilityInfo /CapabilityName:"OpenSSH.Client~~~~0.0.1.0"

Le résultat suivant vous est retourné normalement :

Check depuis la console « Applications et Fonctionnalités »

Depuis la console « Gérer les fonctionnalités facultatives« , vérifiez que le client OpenSSH (Beta) fasse bien parti de la liste des Features installées :

 

HowTo : se connecter à l’aide du client OpenSSH Windows 10

Une fois installé, il suffit de saisir SSH suivi du nom d’utilisateur @ nom ou adresse IP du serveur distant pour se connecter via le client OpenSSH.

Dans l’exemple suivant, nous établissons une connexion sur l’hôte 10.100.10.10 en utilisant un compte utilisateur local nommé « hkroo » (déclaré sur la machine/serveur SSH distant) :

SSH hkroot@10.100.10.10

Cette commande peut être exécutée depuis l’Invite de commande ou une console Windows PowerShell (lancée en tant qu’Administrateur).

Note : si vous devez établir une connexion SSH à l’aide d’un compte faisant parti d’un domaine AD (hkadmin du domaine hklab.lan dans l’exemple suivant), la syntaxe devient la suivante :

SSH hkadmin@hklab@10.100.10.10

 

OpenSSH, toujours en version Beta (au 05/05/2018)

Comme vous avez pu le constater, le Client et Server OpenSSH sont toujours en mode « Beta Release » (au moment de la publication du présent post), il n’est donc pas recommandé de déployer cette Feature dans vos environnements de Production.

D’ailleurs, n’hésitez pas à remonter vos feedbacks /remarks /comments à MS si vous souhaitez contribuer à l’amélioration/évolution de cette super fonctionnalité :).

A bientôt

#HK

Publicités

 

Les questions suivantes m’ont récemment été posées par l’équipe « Ingés Systèmes MS » chez un de mes clients ?

Est-il possible de déplacer le fichier pagefile.sys vers un nouvel emplacement (nouveau Disk) via l’interface CLI Windows (via un outil en ligne de commande Windows) ?

Y’a-t-il un risque /impact post-déplacement de ce fichier ?

 

Mes réponses étaient :

Oui, le fichier Pagefile.sys peut être déplacé vers un nouvel emplacement (au niveau de la même partition/disque ou vers un nouveau disque).

Non, aucun risque/impact, si bien évidemment l’opération de déplacement se fait correctement :).

 

Suis-je obliger de déplacer mon fichier pagefile.sys ? Quels « Cases » ?

Avant d’envisager un déplacement du fichier pagefile.sys, commencez d’abord par vérifier que c’est bien ce fichier qui occupe le plus d’espace disque sur votre serveur.

Notez que par défaut, le fichier pagefile.sys est placé dans la partition système C:\ > C:\pagefile.sys

Dans l’exemple suivant, nous exécutions l’outil TreeSize pour connaître les dossiers et fichiers occupant le plus d’espace sur le disque C: de mon DC (il s’agit ici d’un DC physique).

Comme illustré dans la console TreeSize ci-dessous, le fichier pagefile.sys de mon D(omain) C(ontroller) occupe lui seul 25GB de la partition système (C:).

 

Dans le cas de mon client, toutes les partitions C: (de 70GB) n’avaient quasiment plus d’espace disque libre, voir l’exemple suivant avec 9MB d’espace libre :S

Dans ce cas de figure, avec un pagefile.sys à 25GB (~40% de la taille globale de C:), il FAUT obligatoirement le déplacer pour libérer de l’espace disque dans l’immédiat car avec une telle configuration votre DC finira par crasher, rapidement !

 

Requirements

Vous devez bien évidemment avoir un autre disque connecté sur votre serveur « Physique » ou ajoutez un nouveau vDisk à votre serveur Virtuel. Notez que ce dernier doit avoir suffisamment d’espace disque libre pour accueillir votre nouveau fichier pagefile.sys

Important : la configuration d’un nouvel emplacement du fichier pagefile.sys nécessite le Reboot de votre serveur pour que cette modification soit prise en compte.

Déplacer le fichier pagefile.sys vers une nouveau Disque

Exécutez les commandes suivantes pour :

Créer un nouveau fichier Pagefile.sys et le placer dans disque dédié (Lettre D:)

wmic pagefileset create name=D:\pagefile.sys

Définir sa taille (Maximale) à 8192 MB (8GB)

wmic pagefileset where name=D:\pagefile.sys set InitialSize=2048,MaximumSize=8192

Supprimer l’ancien fichier Pagefile.sys (placé dans C:\ dans notre cas)

wmic pagefileset where name=C:\pagefile.sys delete

 

Vérifier que le nouveau fichier pagefile.sys a bien été créé et déplacé

Pour visualiser l’emplacement du nouveau fichier Pagefile.sys, saisissez la commande wmic pagefileset list ou wmic pagefileset list /format:list pour avoir un output au format « Liste ».

A bientôt pour de nouvelles Tips & Tricks Windows, stay connected :).

#HK | Just Another IT Guy

 

Le planificateur de tâches Windows vous permet de créer et gérer des tâches planifiées afin d’automatiser les tâches fastidieuses d’administration Windows (periodic check, lancement de scripts pour déploiement, configuration, …Etc)

Certaines applications crééent de manière automatique des tâches planifiées pour un « Automatic Update » ou simplement réaliser certaines opérations liées à l’application de manière périodique.

Le planificateur de tâches Windows correspond à l’outil/snap-in MMC Taskschd.msc

Pour le lancer, saisissez simplement Taskchd.msc depuis le Menu Exécuter ou Menu Démarré

Dans l’exemple suivant, mon planificateur de tâches contient des tâches « auto-générées » par une Application présente sur mon OS Server (Optimize Start ****), mais aussi deux autres créées « manuellement » : reboot & Update check

Si vous souhaitez migrer votre plateforme Windows Server (2008 R2 ou ultérieur) vers un nouveau matériel (New Hardware) ou nouvelle VM, le planificateur de tâches vous offre la possibilité de migrer (exporter) vos tâches planifiées une par une, si vous en avez 100 ou 200 tâches planifiées … vous devriez donc les exporter à la main, une par un … 😦

HowTo : migrer toutes vos tâches planifiées en une seule opération 🙂

La migration des tâches planifiées d’un serveur à un autre est assez simple.

Il faut savoir que « par défaut », toute tâche planifiée créée est automatiquement placée dans le dossier suivant :

C:\Windows\System32\Tasks

Si je reprends l’exemple précédent, mes tâches planifiées « Optimize Start… » ainsi que « Reboot & Update check » sont donc bien présentes dans C:\Windows\System32\Tasks, voir Screenshot ci-dessous :

Pour les migrer vers un nouveau serveur (Physique ou Virtuel), il suffit de copier le dossier C:\Windows\System32\Tasks et copier son contenu et le coller dans le même dossier du nouveau Serveur.
Et voilà le tour est joué :).

Hello Windows Guys,

Quand vous déployez un Windows Server ou Client (Windows 7 >10 /2008 R2 >2016), les binaires du client Telnet sont bien présents sur la partition « System » mais la fonctionnalité n’est malheureusement pas activée par défaut.

Vous comme moi, connaissez l’utilité de ce super tool, surtout quand vous êtes amené à valider le fonctionnement d’une solution /service ou simplement appelés à troubleshooter un service.

Si vous lancez CMD.exe sur une machine Windows (Client ou Server), et que vous saisissez Telnet, le résultat suivant vous est retourné :

Pour installer le Client Telnet depuis la même Invite de commande sans avoir besoin de lancer /utiliser le Server Manager ou « Programmes et Fonctionnalités » Windows, exécutez la commande suivante et aller boire le K.fé 🙂

Note : l’invite de commande (CMD.exe) doit être lancée en tant qu’Administration

DISM /Online /Enable-Feature:TelnetClient

Maintenant que le client Telnet est installé, je peux tester la connectivité de mon WebSite sur le port 443 🙂

 

Malgré l’ajout des ~2300 nouvelles Cmd-lets PowerShell sur Windows Server 2012 R2 et 2016, le meilleur outil de gestion du Networking & Firewalling Windows reste (pour moi :D) le super Command-Line Tool Netsh.exe (Windows Network Shell).

En effet, Windows PowerShell fonctionne aujourd’hui qu’avec un sous-ensemble de fonctionnalités de management Windows Server, n’incluant pas la possibilité de configurer et gérer le Pare-feu Windows et ses fonctions avancées.

J’ai donc décidé de vous regrouper dans le présent post les « Top 10″ des Commandes Netsh que vous devez connaître pour créer, configurer et gérer vos Pare-feu Windows (Client & Server).

Les commandes détaillées ci-dessous peuvent aussi vous être utile lors de la configuration du Firewall Windows IaaS (E.g : VM Azure ou AWS)

 

1.Afficher /Lister une règle spécifique ou toutes les règles du Pare-feu Windows
  • Afficher toutes les règles : netsh advfirewall firewall show rule name=all
  • Afficher une règle spécifique (« SQL » dans l’exemple suivant) : netsh advfirewall firewall show rule name=SQL


2.Activer /Désactiver un ou plusieurs profils du Pare-feu Windows
  • Activer tous les profils du Pare-feu Windows : Netsh advfirewall set allprofiles state on
  • Désactiver tous les profils du Pare-feu Windows : Netsh advfirewall set allprofiles state off
  • Activer le profil « Public » du Pare-feu Windows : Netsh advfirewall set publicprofile state on
  • Désactiver le profil « Privé » du Pare-feu Windows : Netsh advfirewall set privateprofile state off
  • Activer le profil « Domaine » du Pare-feu Windows : Netsh advfirewall set domainprofile state on

3.Réinitialiser les stratégies (par défaut) du Pare-feu Windows
  • netsh advfirewall reset

4.Afficher et Configurer les fichiers Logs du Pare-feu Windows

Notez que le chemin par défaut des fichiers « Logs » liés au Pare-feu Windows est le suivant : C:\Windows\system32\LogFiles\Firewall\pfirewall.log

Vous pouvez visualiser ce chemin par défaut (pour tous les profils du Pare-feu) en exécutant la commande suivante :

  • netsh advfirewall show allprofiles logging

Nous allons définir dans l’exemple suivant le chemin « D:\WSFirewall\Logs\pfirewall.log », pour tous les profils du Pare-feu Windows (Domaine – Privé – Public)

  • netsh advfirewall set allprofiles logging filename « D:\WSFirewall\Logs\pfirewall.log« 

Note : après configuration d’un nouvel emplacement du fichier log pfirewall.log, l’ancien fichier log placé dans le chemin par défaut est automatiquement déplacé et renommé en .old


5.Autoriser ou Refuser le « Ping »
  • Autoriser le « Ping »: netsh advfirewall firewall add rule name= »All ICMP V4″ dir=in action=allow protocol=icmpv4
  • Refuser le « Ping » : netsh advfirewall firewall add rule name= »All ICMP V4″ dir=in action=block protocol=icmpv4

6.Ajouter (Autoriser) ou Supprimer un Port spécifique
  • Ajouter une nouvelle règle autorisant le port 1433 (port par défaut utilisé par SQL Server) : netsh advfirewall firewall add rule name= »Autoriser_Port_SQL Server » dir=in action=allow protocol=TCP localport=1433
  • Supprimer la règle précédente autorisant le port 1433 (port par défaut utilisé par SQL Server) : netsh advfirewall firewall delete rule name= »Autoriser_Port_SQL Server » protocol=tcp localport=1433

7.Autoriser un Programme
  • Dans l’exemple suivant, le Programme « IPScan » placé dans C:\Program Files\IPScan\IPScan.exe » sera autorisé : netsh advfirewall firewall add rule name= »Autoriser_IPScan » dir=in action=allow program= »%ProgramFiles%\IPScan\IPScan.exe »

8.Activer la gestion à distance
  • netsh advfirewall firewall set rule group= »Gestion à distance de Windows » new enable=yes


9. Activer /autoriser Les Connexions Bureau à distance
  • netsh advfirewall firewall set rule group= »Bureau à distance » new enable=Yes


10.Exporter ou importer la configuration & paramètres du Pare-feu Windows
  • Pour exporter toute la configuration du Pare-feu Windows vers D:\WSFirewall : netsh advfirewall export « D:\WSFirewall\WFconfiguration.wfw »

  • Pour exporter toute la configuration du Pare-feu Windows vers D:\WSFirewall : netsh advfirewall export « D:\WSFirewall\WFconfiguration.wfw »

Je vous laisse Run > Netsh Advfirewall /? et découvrir le reste des commandes.

Enfin, toujours gardez à l’esprit que le CLI Netsh.exe fait parti des outils en ligne de commande Windows les plus puissants (et compliqué aussi). Toujours PoC(er), Tester et Valider l’opération sur un LaB /Environnement d’Intégration /PréProd …Etc avant toute application sur les serveurs de Production.

A bientôt

Une question intéressante m’a été récemment posée par un de mes clients :

Comment obtenir la liste complètes des Updates Windows installées sur un Windows Server distant ?

Typiquement un serveur distant exécutant Windows Server 2008 R /2012 /2012 R2 ou encore 2016 en mode Core.

Je vous détaille à travers cet article la ligne de code qui vous permet de le faire.

HowTo : Obtenir la liste des Updates Windows d’un serveur distant 

La technique consiste simplement à utiliser une Cmd-Let nommée « Get-Hotfix » en spécifiant le hostname de votre serveur distant au niveau du paramètre -ComputerName.

Dans l’exemple suivant, nous allons obtenir la liste complètes des mises à jour Windows installées sur le serveur Core distant « LABRDS2016 » :

Get-HotFix -ComputerName LABRDS2016 | Select HotfixID, Description, InstalledOn | Sort-Object -Descending

les MàJ Windows installées sur ma machine distante sont affichées dans l’image suivante :

 

S’applique à : Windows 10 et Windows Server 2016

Remote Credential Guard, qu’est-ce que c’est ?

Le géant américain a lancé l’année dernière le « Credential Guard », une fonctionnalité de sécurité native dans Windows 10 Enterprise et Windows Server 2016. Credential Guard aide à empêcher le vol d’informations d’identification et permet de réduire l’efficacité des attaques Kerberos telles que Overpass-The-Hash et Pass-the-Ticket.

Récemment, avec la publication de la mise à jour « Anniversaire » Windows 10, Microsoft a annoncé la disponibilité du « Remote Credential Guard », une nouvelle fonctionnalité de sécurité qui vise elle aussi à protéger les informations d’identification sur les connexions Bureau à distance en générant des tickets de service nécessaires à partir de la machine source au lieu de copier les informations d’authentification (Haches et TGT) vers la machine cible.

Notez que Remote Credential Guard a été introduite sur Windows 10 version 1607.

Cette fonctionnalité peut être considérée comme le successeur /remplaçant du mode « Restricted Admin ».
En effet, les deux fonctionnalités s’activent et fonctionnent de la même manière, la seule différence réside dans le fait que le Remote Credential Guard ne limite pas l’accès aux autres ressources du réseau en redirigeant de nouveau toutes les demandes d’identifications vers la machine cliente du réseau.

Si vous voulez en savoir plus sur le mode « Restricted Admin », je vous invite à consulter cet article.

Enfin, un article détaillé sur le « Remote Credential Guard » a été rédigé et publié par CyberArk, je vous invite à consulter pour en savoir plus sur cette nouvelle fonctionnalité :
https://www.cyberark.com/blog/no-pass-hash-exploring-limitations-remote-credential-guard/

Prérequis

La fonctionnalité « Remote Credential Guard » est prise en charge par les OS suivants uniquement :

  • OS Server : Windows Server 2016
  • OS Client : Windows 10 (Entreprise)

Vous pouvez donc l’implémenter uniquement pour sécuriser des Connexions Bureau à distance établies depuis et vers les OS cités ci-dessus.

HowTo : Activer ou Désactiver le mode « Remote Credential Guard »

Le mode « Remote Credential Guard » est désactivé par défaut.

Il s’active de la même manière que le mode « Restricted Admin », il suffit donc de créer /ajouter la clé de Registre suivante sur vos machines cibles :

Chemin: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa

Valeur DWORD (32-bits) : DisableRestrictedAdmin

Données de la valeur : 0

Note importante : Cette clé de Registre peut également être crée en exécutant la commande suivante (depuis CMD.exe lancée en tant qu’Admin) :

Reg.exe Add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /V DisableRestrictedAdmin /D 0 /T REG_DWORD

Utiliser le mode « Remote Credential Guard »

Une fois activé, le mode « Remote Credential Guard » doit être forcé sur l’ensemble des machines du réseau (cibles) sur lesquelles vous vous connectez via Bureau à distance.

Cette configuration peut être effectuée d’une manière centralisée sur un ensemble de serveurs /postes de travail via GPO, et ce via l’utilisation du paramètre de Stratégie de groupe suivant :

Chemin : Configuration Ordinateur | Stratégies | Modèles d’administration | Système | Délégation d’informations d’identification

Paramètre : Limiter la délégation d’informations d’identification à des serveurs distants

Valeur du paramètre : Activé

Mode restreint : Requérir Credential Guard à distance

Le mode « Remote Credential Guard » ou « Credential Guard à distance » est représenté par un paramètre de l’outil MSTSC.exe et plus précisément le paramètre /remoteGuard, lancez MSTSC /? depuis l’invite de commande (CMD.exe) ou le Menu Démarrer et constatez la disponibilité du mode « /remoteGuard » :

Dans l’exemple suivant, nous allons établir une Connexion Bureau à distance en mode « remoteGuard » sur le serveur distant « LABRDS01 » :


Ceci est un extrait de l’eBook « RDS 2016 – Securisation et Hardening [2ème Edition] »