I. Présentation

Dans ce tutoriel, nous allons apprendre à configurer un serveur DHCP de façon à pouvoir faire du boot PXE à la fois en mode BIOS et en mode UEFI, sur le même réseau. Un serveur WDS sous Windows Server 2022 sera utilisé pour tester le bon fonctionnement.

Lorsque l'on effectue un boot PXE sur une machine en mode BIOS (ou Legacy), il faut configurer les options DHCP 66 et 67. Dans le même temps, quand on utilise le mode UEFI (avec ou sans Secure Boot), il faut configurer les options DHCP 60, 66 et 67, mais avec une valeur différente pour l'option 67 qui est commune aux deux modes.

Si l'on a besoin de déployer les deux types de machines et que l'on utilise le même réseau local pour le déploiement (ce qui est généralement le cas), on se retrouve dans l'obligation d'ajuster la configuration de l'étendue DHCP en fonction de la configuration de la machine à déployer (BIOS ou UEFI). Même si l'UEFI devient le mode par défaut et se généralise, la problématique existe toujours. Pour répondre à cette problématique et gérer les deux modes en même temps, nous allons pouvoir créer des stratégies DHCP. C'est ce que nous allons voir.

En ce qui concerne l'environnement utilisé pour cette démo :

• Un serveur virtuel WDS
  • Nom de machine : SRV-WDS
  • Adresse IP : 192.168.14.11
  • Intégré au domaine Active Directory (facultatif)
• Un serveur virtuel contrôleur de domaine et DHCP
  • Nom de machine : SRV-ADDS-01
  • Adresse IP : 192.168.14.10
  • Nom de domaine : it-connect.local
• Une machine virtuelle vierge pour tester le boot PXE

Si vous avez besoin d'aide pour mettre en place le serveur WDS, suivez la vidéo complète puisqu'elle intègre cette partie.

II. VMware Workstation : basculer du mode BIOS au mode UEFI

Le firmware d'une machine virtuelle VMware Workstation Pro peut être configuré en mode "BIOS ou "UEFI". Avec Windows 10, on peut utiliser l'un de ces deux modes, tandis qu'avec Windows 11, il faut utiliser impérativement le mode UEFI pour respecter le prérequis de la puce TPM (vTPM).

Pour basculer d'un mode à l'autre, voici la marche à suivre. Accédez aux paramètres de la machine virtuelle, cliquez sur l'onglet "Options", choisissez "Advanced" dans la liste et sur la droite ajustez le paramètre "Firmware type".

Si vous souhaitez vous exercer sur une machine virtuelle, comme je le fais dans cette démonstration, conservez le mode "BIOS" pour le moment.

III. WDS : boot PXE en mode BIOS

Avant de gérer les deux modes, voyons comment utiliser le mode BIOS seul. Pour cela, nous allons configurer l'étendue "Deploiement" déjà présente sur le serveur DHCP et qui distribue des adresses IP sur le réseau "192.168.14.0/24".

• Installer et configurer un serveur DHCP sous Windows Server

Commencez par ouvrir la console DHCP, sélectionnez l'étendue DHCP utilisée pour le déploiement et effectuez un clic droit sur "Options d'étendue" pour cliquer sur "Configurer les options".

Dans l'onglet "Général", activez les options 066 et 067 en cochant la case située sur la gauche. Renseignez les deux options de cette façon :

• Option 66 : l'adresse IP du serveur PXE, ici c'est le serveur WDS
• Option 67 : le nom du fichier de démarrage, indiquez la valeur générique "boot\x64\wdsnbp.com".

Validez, vous devez obtenir ceci :

C'est suffisant pour faire du boot PXE en mode BIOS !

Pour tester, rien de plus simple : on démarre une machine virtuelle en "boot réseau" et si elle est bien sur le même segment réseau que les serveurs, elle va obtenir une adresse IP et se connecter au serveur WDS. Sur l'exemple ci-dessous, on voit bien qu'elle a pu obtenir une adresse IP et qu'il faut appuyer sur F12 pour démarrer sur le réseau.

C'est tout bon pour le mode BIOS.

IV. WDS : Boot PXE en mode UEFI (et BIOS)

Pour configurer le DHCP avec les options spécifiques au mode UEFI, le principe est le même avec des options et valeurs différentes.

Maintenant, nous allons voir comment configurer le serveur DHCP pour qu'il gère les deux modes : UEFI et BIOS.

Je vous propose de réaliser cette configuration en PowerShell. Voici les étapes à réaliser :

• Activer la prise en charge de l'option 60 dans le serveur DHCP
• Déclarer des classes de fournisseurs pour différencier les machines BIOS et UEFI
• Créer une stratégie pour gérer les machines en mode BIOS
• Créer une stratégie pour gérer les machines en mode UEFI

A. DHCP : ajouter la prise en charge de l'option 60

Dans la liste des options DHCP, l'option 60 n'est pas disponible dans la liste. À l'aide de PowerShell (ou de netsh), nous allons pouvoir remédier à cela.

Sur le serveur DHCP, en l'occurrence SRV-ADDS-01 dans mon exemple, ouvrez une console PowerShell en tant qu'administrateur et exécutez cette commande :

Add-DhcpServerv4OptionDefinition -ComputerName SRV-ADDS-01 -Name PXEClient -Description "PXE Support" -OptionId 060 -Type String

Après avoir actualisé la console DHCP, on peut voir que cette option est accessible :

Passons à la suite.

B. DHCP : déclarer les classes de fournisseurs

Pour la suite, je vous recommande d'utiliser PowerShell ISE ou Visual Studio Code pour écrire les commandes au fur et à mesure.

Commençons par définir trois variables que l'on va appeler tout au long de la procédure :

# Nom d'hôte du serveur DHCP
$DhcpServerName = "SRV-ADDS-01"
# Adresse IP du serveur WDS (PXE)
$PxeServerIp = "192.168.14.11"
# Adresse réseau de l'étendue DHCP ciblée
$Scope = "192.168.14.0"

Puis, grâce aux commandes ci-dessous, nous allons définir trois classes de fournisseurs DHCP correspondantes à des architectures différentes. Par exemple, la valeur "PXEClient:Arch:00007" correspond à du boot PXE pour l'UEFI en x64.

Exécutez les trois commandes suivantes :

Add-DhcpServerv4Class -ComputerName $DhcpServerName -Name "PXEClient - UEFI x64" -Type Vendor -Data "PXEClient:Arch:00007" -Description "PXEClient:Arch:00007"
Add-DhcpServerv4Class -ComputerName $DhcpServerName -Name "PXEClient - UEFI x86" -Type Vendor -Data "PXEClient:Arch:00006" -Description "PXEClient:Arch:00006"
Add-DhcpServerv4Class -ComputerName $DhcpServerName -Name "PXEClient - BIOS x86 et x64" -Type Vendor -Data "PXEClient:Arch:00000" -Description "PXEClient:Arch:00000"

Les modifications effectuées par ces commandes sont visibles dans :

Passons à la suite.

C. Créer les stratégies DHCP pour le BIOS et l'UEFI

Désormais, il faut créer les stratégies DHCP. Dans l'ordre suivant (même si l'ordre n'a pas d'importance) :

• Une première stratégie pour le mode BIOS x86 et x64.
• Une seconde stratégie pour le mode UEFI x86
• Une troisième stratégie pour le mode UEFI x64.

Ces stratégies vont s'appliquer sur l'étendue ciblée (variable définie précédemment) sur le serveur DHCP.

Pour créer la première stratégie :

$PolicyNameBIOS = "PXEClient - BIOS x86 et x64"
Add-DhcpServerv4Policy -Computername $DhcpServerName -ScopeId $Scope -Name $PolicyNameBIOS -Description "Options DHCP pour boot BIOS x86 et x64" -Condition Or -VendorClass EQ, "PXEClient - BIOS x86 et x64*"
Set-DhcpServerv4OptionValue -ComputerName $DhcpServerName -ScopeId $Scope -OptionId 066 -Value $PxeServerIp -PolicyName $PolicyNameBIOS
Set-DhcpServerv4OptionValue -ComputerName $DhcpServerName -ScopeId $Scope -OptionId 067 -Value boot\x64\wdsnbp.com -PolicyName $PolicyNameBIOS

Pour créer la seconde stratégie :

$PolicyNameUEFIx86 = "PXEClient - UEFI x86"
Add-DhcpServerv4Policy -Computername $DhcpServerName -ScopeId $Scope -Name $PolicyNameUEFIx86 -Description "Options DHCP pour boot UEFI x86" -Condition Or -VendorClass EQ, "PXEClient - UEFI x86*"
Set-DhcpServerv4OptionValue -ComputerName $DhcpServerName -ScopeId $Scope -OptionId 060 -Value PXEClient -PolicyName $PolicyNameUEFIx86
Set-DhcpServerv4OptionValue -ComputerName $DhcpServerName -ScopeId $Scope -OptionId 066 -Value $PxeServerIp -PolicyName $PolicyNameUEFIx86
Set-DhcpServerv4OptionValue -ComputerName $DhcpServerName -ScopeId $Scope -OptionId 067 -Value boot\x86\wdsmgfw.efi -PolicyName $PolicyNameUEFIx86

Pour créer la troisième stratégie :

$PolicyNameUEFIx64 = "PXEClient - UEFI x64"
Add-DhcpServerv4Policy -Computername $DhcpServerName -ScopeId $Scope -Name $PolicyNameUEFIx64 -Description "Options DHCP pour boot UEFI x64" -Condition Or -VendorClass EQ, "PXEClient - UEFI x64*"
Set-DhcpServerv4OptionValue -ComputerName $DhcpServerName -ScopeId $Scope -OptionId 060 -Value PXEClient -PolicyName $PolicyNameUEFIx64
Set-DhcpServerv4OptionValue -ComputerName $DhcpServerName -ScopeId $Scope -OptionId 066 -Value $PxeServerIp -PolicyName $PolicyNameUEFIx64
Set-DhcpServerv4OptionValue -ComputerName $DhcpServerName -ScopeId $Scope -OptionId 067 -Value boot\x64\wdsmgfw.efi -PolicyName $PolicyNameUEFIx64

Une nouvelle fois, cette configuration est visible dans la console DHCP. Ici, il faut accéder à la partie "Stratégies" de l'étendue DHCP ciblée. Voici le résultat :

Si l'on regarde les options de notre étendue DHCP, on peut voir qu'il y a beaucoup de valeurs. Effectivement, nous avons plusieurs fois les mêmes options, mais avec des valeurs différentes, et la bonne valeur sera appliquée en fonction de la machine qui initie la connexion.

Le serveur DHCP est correctement configuré !

D. Tester le boot PXE en UEFI

Pour tester cette configuration, il convient de basculer la machine virtuelle en mode UEFI (avec le Secure Boot actif tant qu'à faire) et de tester un boot sur le réseau. Si le serveur DHCP est correctement configuré, la machine virtuelle doit parvenir à contacter le PXE et il suffira d'appuyer sur Entrée pour initier le boot réseau et charger l'image de démarrage.

V. Conclusion

Nous venons de voir comment configurer un serveur DHCP pour prendre en charge le boot PXE en mode BIOS et en mode UEFI. Dans cet exemple, le serveur PXE est représenté par un serveur WDS mais il pourrait s'agir d'une autre solution.

Si vos serveurs sont dans un réseau différent des machines à déployer (VLANs différents, par exemple), vous devez déclarer l'adresse IP du serveur DHCP et du serveur WDS dans les options de relais DHCP de votre passerelle (routeur/pare-feu).

The post Serveurs WDS et DHCP – Comment faire du boot PXE BIOS et UEFI sur le même réseau ? first appeared on IT-Connect.

Hyper-V is next to ESX one the most used Hypervisors to run VMs. Hyper-V is available for free, and you can install Hyper-V on Windows Server and on Windows 10 and 11, allowing you to run and manage multiple VMs on your computer. In this ... Read moreHow to Install and Configure Hyper-V

The post How to Install and Configure Hyper-V appeared first on LazyAdmin.

I. Présentation

Dans ce tutoriel, nous allons apprendre à configurer FSRM sur notre serveur de fichiers de manière à déployer une première barrière de protection contre les ransomwares. Pour cela, nous allons utiliser un script PowerShell prêt à l'emploi, développé par mes soins et personnalisable pour votre environnement.

Pour rappel, un ransomware, en français rançongiciel, est un logiciel malveillant qui va chiffrer vos données et vous demander de payer une rançon si vous souhaitez obtenir la clé de déchiffrement dans le but de récupérer vos données. Dans certains cas, les données sont également exfiltrées dans le but d'être divulguées ou revendues.

• Lecture recommandée : FSRM et le filtrage de fichiers

II. L'intérêt de cette protection

Avec le filtrage de fichiers de FSRM, on va pouvoir bannir certaines extensions de fichiers (et noms de fichiers) sur notre serveur de fichiers Windows Server. En bloquant les extensions associées aux ransomwares, on empêchera le ransomware de chiffrer les fichiers, car il ne pourra pas enregistrer le fichier dans son nouveau format.

Prenons un exemple. L'extension ".locky" associée au ransomware Locky. S'il est exécuté par un pirate sur votre serveur de fichiers, il ne pourra pas chiffer vos données, car l'extension ".locky" est bloquée sur les volumes/dossiers où sont situées vos données grâce à la règle mise en place et déployée via le script PowerShell.

Cette technique est connue depuis plusieurs années et mérite d'être toujours mise en place aujourd'hui puisqu'elle se met en place facilement et qu'elle protège vos données.

III. Que va faire ce script ?

Lorsque le script BlockRansomwares.ps1 sera exécuté sur votre serveur de fichiers, que va-t-il faire ?

Ce script sert à configurer le filtrage de fichiers dans FSRM sur votre serveur et à maintenir à jour la configuration. Ce script va :

• Créer un groupe de fichiers

Ce groupe de fichiers contiendra la liste de toutes les extensions associées aux attaques par ransomware. Pour cela, on va s'appuyer sur la liste accessible à cette adresse qui est la relève du site fsrm.experiant.ca puisque la liste n'est plus maintenue après des années d'existences. Cette liste contient tous les noms de fichiers et toutes les extensions qui ont été utilisées par des ransomwares.

Cette liste sera mise à jour par le script (que l'on exécutera en tâche planifiée) pour tenir compte des changements apportés dans la liste téléchargée via l'API.

• Créer un modèle de groupe de fichiers

Un modèle de groupe de fichiers sera créé pour effectuer du filtrage actif sur les extensions correspondantes à notre groupe de fichiers précédemment créé. Cela va aussi activer les notifications par e-mail et l'avertissement dans le journal des événements.

• Créer les règles de filtre de fichiers

Pour finir, ce script va mettre en place les règles de filtrages de fichiers pour protéger les dossiers et volumes de votre choix.

• Logs et rapports

Les actions réalisées par ce script seront journalisées dans des fichiers de logs et un rapport par e-mail pourra être envoyé à destination du service informatique à chaque exécution. Ce rapport contient la liste des nouvelles extensions ajoutées et des extensions supprimées.

IV. Déployer BlockRansomwares

Le projet BlockRansomwares se découpe en trois fichiers :

• Prerequis-BlockRansomwares.ps1 : un script qui sert à vérifier la version PowerShell du serveur et à installer le rôle FSRM s'il n'est pas installé
• BlockRansomwares.ps1 : le script qui sert à déployer la configuration et qu'il faut exécuter en tâche planifiée (au moins une fois par jour) pour mettre à jour la liste des extensions
• BlockRansomwares.psd1 : un fichier de configuré appelé par le script de configuration qui vous permet de personnaliser le fonctionnement de l'outil

Voyons plus en détail comment cela se passe...

A. Prérequis

La première étape consiste à exécuter le script qui vérifie les prérequis, en tant qu'administrateur. Un retour de la console sera généré.

.\Prerequis-BlockRansomwares.ps1

B. Personnaliser la configuration

La seconde étape consiste à personnaliser la configuration avec "BlockRansomwares.psd1".

Chaque paramètre est commenté, mais voici quelques informations complémentaires :

• ClientName : nom de l'entreprise qui ressortira dans les rapports envoyés par e-mail (voir plus loin dans l'article)
• APIMode :
  • En mode "Incremental", on ajoute les nouvelles extensions ajoutées dans la liste récupérée sur GitHub mais on ne supprime pas celles qui seraient supprimées dans cette même liste
  • En mode "Sync", on se calque à l'identique de la liste, pour tenir compte des ajouts et suppressions
• ExtensionsToExclude : s'il y a une extension qui vous pose problème et qu'elle est dans la liste récupérée, vous pouvez l'exclure ici (plusieurs valeurs possibles)
• ExtensionsToInclude : s'il y a une ou plusieurs extensions à ajouter, en plus de celles présentes dans la liste
• ProtectAllShares :
  • Si ce paramètre est sur vrai ($true), le script va protéger tous les partages de fichiers du serveur, sauf ceux correspondants aux chemins déclarés dans DirToExclude
  • Si ce paramètre est sur faux ($false), le script va protéger uniquement les chemins déclarés dans DirToProtect
• SMTP : les paramètres pour envoyer les e-mails, attention cela va venir écraser vos paramètres dans FSRM (si c'est déjà configuré) donc remettez vos valeurs

Une fois que la configuration est prête, le script de mise en place peut être exécuté.

C. Déployer la protection anti-ransomware dans FSRM

On exécute le script :

.\BlockRansomwares.ps1

Par défaut, il va chercher le fichier de configuration dans le même répertoire que le script. Sinon, il faut spécifier le paramètre -Config.

La sortie dans la console permet de voir ce qu'il se passe.

Un nouveau groupe de fichiers sera créé :

Un nouveau modèle de filtre de fichiers sera créé :

Enfin, la protection sera déployée sur tous les partages ciblés d'après la configuration de l'outil. Il est à noter que c'est uniquement de l'ajout : si une nouvelle exclusion est ajoutée dans la liste, ou que l'on change de mode, la protection n'est pas supprimée. Actuellement, on fait uniquement de l'ajout et actualisation.

Dans le même temps, un rapport par e-mail est envoyé. Voici à quoi il ressemble :

D. Créer une tâche planifiée pour la mise à jour automatique

Pour que la liste des extensions soit actualisée fréquemment, on va créer une tâche planifiée qui s'exécuter une fois par jour et qui va relancer le script BlockRansomwares.ps1.

Cette tâche doit être créée par vos soins et exécuter le script via PowerShell. Ce qui donnera :

V. Conclusion

Grâce à la mise en place de ce filtrage, une barrière de protection très intéressante est en place sur votre serveur de fichiers ! Ce qui peut, potentiellement, vous éviter quelques sueurs froides....

Ce script est disponible en libre accès sur mon GitHub :

• GitHub - Projet BlockRansomwares.ps1

Vous pouvez aussi consulter ce projet similaire et qui mérite d'être connu :

• FSRM-ANTICRYPTO de David ANDE

Pour aller plus loin, on pourrait :

• Désactiver temporairement le service de partage de fichiers du serveur de manière à bloquer l'attaque (attention aux éventuels faux positifs...)
• Créer une règle de refus sur le partage pris pour cible en bloquant l'utilisateur qui a cherché à créer le fichier avec une extension bannie

Qu'en pensez-vous ? N'hésitez pas à laisser un commentaire si vous avez des idées d'amélioration.

Si vous souhaitez déployer cette solution sur votre serveur, vous pouvez me solliciter pour l'intégration !

The post Windows Server 2022 et FSRM : comment se protéger des ransomwares ? first appeared on IT-Connect.

Des chercheurs en sécurité ont émis une alerte légitime au sujet de la faille de sécurité CVE-2023-21554 située dans le service Windows Message Queuing et qui vient d'être corrigée par Microsoft. D'après eux, des centaines de milliers de machines sont vulnérables et pourraient être compromises. Faisons le point.

Naturellement, la faille de sécurité zero-day CVE-2023-28252 attire l'attention puisqu'elle est déjà utilisée dans le cadre d'attaques, notamment par le gang de ransomware Nokoyawa. Toutefois, au sein de son Patch Tuesday d'avril 2023, Microsoft a corrigé plusieurs failles de sécurité critiques, dont la CVE-2023-21554 qui inquiète particulièrement.

Si l'on se réfère au site Microsoft, on constate que cette faille de sécurité critique située dans le service Windows Message Queuing hérite d'un score CVSS de 9.8 sur 10. On peut lire aussi qu'elle affecte toutes les versions de Windows et Windows Server, y compris les installations en mode "Core", ainsi que Windows Server 2022 et Windows 11 22H2.

En exploitant cette vulnérabilité, un attaquant non authentifié sur la machine ciblée peut exécuter du code à distance grâce à des paquets MSMQ spécifiques. Puisqu'il n'y a pas besoin d'interaction de la part de l'utilisateur et que l'attaque est réalisable via le réseau, c'est particulièrement dangereux.

Qu'est-ce que Windows Message Queuing alias MSMQ ?

MSMQ est une fonctionnalité optionnelle de Windows et Windows Server qui a pour objectif de permettre l'échange asynchrone de messages entre plusieurs serveurs. Les applications envoient des messages aux files d'attente, et ces messages seront lus par d'autres serveurs destinataires. Sauf erreur de ma part, c'est un système dans le même esprit que RabbitMQ, pour ceux qui connaissent.

Il est clair que si MSMQ n'est pas activé sur votre machine, elle n'est pas exposé. C'est clairement précisé sur le site de Microsoft : "Le service Windows Message Queuing, un composant de Windows, doit être activé pour qu’un système puisse être exploité par cette vulnérabilité."

Cette fonctionnalité optionnelle s'active avec PowerShell ou à partir de l'interface graphique.

360 000 serveurs MSMQ exposés et vulnérables ?

D'après des chiffres publiés par Check Point Research, il y aurait au moins 360 000 serveurs avec MSMQ actifs qui sont exposés sur Internet. C'est déjà un chiffre élevé, et il ne tient pas compte des serveurs qui ne sont pas exposés directement sur Internet.

Parfois, le service MSMQ peut être installé par une application tierce qui en a besoin en tant que dépendance, donc ce n'est pas parce que vous ne l'avez pas installé qu'une application ne l'a pas fait à votre place. Même après désinstallation d'une application, ce service peut rester actif.

D'ailleurs, les chercheurs de Check Point mentionnent un exemple très simple : Microsoft Exchange. Si la case "Automatically install Windows Server roles and features that are required to install Exchange" a été cochée lors de l'installation d'Exchange Server, alors MSMQ a été activé.

Comment se protéger ?

Pour se protéger, la meilleure solution c'est de mettre à jour son serveur puisque les mises à jour d'avril 2023 corrigent cette faille de sécurité dans MSMQ. Toutefois, si vous ne pouvez pas installer le correctif dans l'immédiat, vous pouvez toujours filtrer les accès sur le port 1801/TCP de votre serveur. En effet, MSMQ écoute sur ce port comme le précise Microsoft dans sa documentation.

D'ailleurs, si votre serveur écoute sur le port 1801/TCP, c'est que le service MSMQ est actif (voir les ports d'écoute en PowerShell). Il y a aussi un service associé et un processus nommé "mqsvc.exe".

Source

The post Faille critique dans MSMQ (CVE-2023-21554) : au moins 360 000 machines Windows vulnérables ! first appeared on IT-Connect.

When you have an environment with a lot of notebooks or other mobile devices that come and go, then stale DNS records are bound to happen. Stale DNS records can cause problems with name resolution, so it’s important to clean up the old DNS records, ... Read moreDNS Scavenging – Everything you need to know

The post DNS Scavenging – Everything you need to know appeared first on LazyAdmin.

I. Présentation

Dans ce tutoriel, nous allons apprendre à mettre en place un message d'erreur personnalisé lorsqu'un utilisateur sous Windows essaie d'accéder à un répertoire sur lequel il n'a pas les droits. En complément, nous pourrons aussi lui permettre d'effectuer une demande d'assistance, toujours à partir de cette même fenêtre !

Le constat : sous Windows, lorsqu'un utilisateur essaie d'accéder à un répertoire partagé auquel il n'a pas accès, une erreur "Windows ne peut pas accéder à \\....." s'affiche à l'écran, et dans le détail c'est clairement qu'il s'agit d'un problème d'autorisation. Ce message bloque l'utilisateur, mais ne lui indique pas la marche à suivre s'il estime qu'il devrait avoir accès à ce répertoire.

Pour trouver une solution, il faut s'orienter vers la console FSRM que nous allons continuer d'explorer après avoir vu la gestion des quotas et le filtrage de fichiers. FSRM va nous offrir la possibilité de :

• Définir un message d'erreur global
  • Configurer les options > Assistance en cas d'accès refusé > Afficher le message suivant
• Définir un message d'erreur spécifique pour un dossier ou une arborescence
  • Gestion de la classification > Propriétés de classification > Définir les propriétés de gestion des dossiers > Message d'assistance en cas d'accès refusé > Ajouter

Voyons dans la pratique comment effectuer cette configuration.

II. FSRM et l'assistance en cas d'accès refusé

Tout d'abord, à partir de la console FSRM, effectuez un clic droit sur la racine de l'arborescence et choisissez "Configurer les options".

Ici, c'est l'onglet "Assistance en cas d'accès refusé" qui va nous intéresser. Nous devons cocher l'option "Activer l'assistance en cas d'accès refusé" et définir un message d'erreur personnalisé (zone de texte en dessous). Ce message s'affichera lorsqu'un accès refusé sera généré sur Windows (comme celui montré en introduction).

Cliquez ensuite sur le bouton "Configurer les demandes par courrier électronique". Si vous souhaitez permettre à l'utilisateur de faire une demande d'accès par e-mail, c'est cette section qu'il faut renseigner. Tout d'abord, il faut cocher l'option "Autoriser les utilisateurs à demander de l'assistance" avant de s'intéresser aux autres options.

Quand votre configuration est prête, cliquez sur le bouton "Aperçu" visible sur la fenêtre principale des options. Cela permet d'avoir une prévisualisation de la fenêtre "Accès refusé" telle qu'elle sera côté utilisateur.

III. Tester la configuration

Après avoir mis en place cette configuration, nous allons effectuer un test comme à chaque fois. Ici, il suffit de prendre un utilisateur n'ayant pas accès à un répertoire spécifique, que ce soit un sous-répertoire d'un partage ou un répertoire racine. Et là, on voit le message "Problème d'accès à \\...." qui s'affiche avec :

• Le message d'erreur personnalisé défini dans FSRM
• Le bouton pour demander de l'aide

Si l'on clique sur le bouton "Demander de l'aide", une zone de saisie s'affiche afin que l'utilisateur puisse expliquer pourquoi il a besoin d'accéder à ce répertoire. Une fois qu'il a complété sa demande, il ne lui reste plus qu'à cliquer sur "Envoyer un message".

Côté administrateur, un e-mail sera reçu (envoyé depuis FSRM) avec les détails de la demande : utilisateur à l'origine de la mande, chemin d'accès concerné, justification de l'utilisateur, ainsi que les autorisations actuelles de cet utilisateur. Ensuite, libre à vous de répondre positivement ou non à cette demande.

IV. Message d'erreur spécifique sur un dossier

Nous venons de configurer un message d'erreur spécifique qui s'appliquera sur les différents répertoires partagés du serveur. Si l'on souhaite définir un message spécifique sur un répertoire spécifique, c'est possible aussi, toujours via la console FSRM.

Pour configurer ce message, il faut accéder à "Gestion de la classification" et faire un clic droit sur "Propriétés de classification" pour cliquer sur "Définir les propriétés de gestion des dossiers".

Ici, on va choisir la propriété "Message d'assistance en cas d'accès refusé" et cliquer sur le bouton "Ajouter" car la liste est vide par défaut.

On sélectionne le répertoire, par exemple "P:\Partage\PrivéAdm" et on indique le message d'erreur spécifique à ce répertoire dans la zone "Valeur". On valide.

Désormais, lorsqu'un utilisateur va tenter d'accéder à ce répertoire, il aura le message personnalisé grâce à la règle que nous venons de créer. Voici un exemple :

Pour aller plus loin, il convient de configurer aussi la propriété "Adresse de messagerie du propriétaire du dossier". Ce qui va permettre d'alerter la bonne personne lorsqu'il y a une demande d'aide : on pourrait préciser ici l'adresse e-mail du responsable de service, s'il s'agit d'un répertoire propre à un service de l'entreprise. Généralement, c'est le responsable du service en question qui donne son accord ou non lorsqu'il y a une demande d'accès, et ensuite, elle est mise en place par le service informatique.

V. Conclusion

Grâce à cette fonctionnalité très intéressante de FSRM mais qui est un peu cachée on va dire, nous pouvons rendre plus accessible les demandes d'accès aux répertoires partagés sans avoir besoin d'utiliser un outil tiers, ou sans obliger l'utilisateur à faire la demande par e-mail. Ici, le flux est géré par FSRM et la demande d'aide va générer aussi un événement visible dans l'Observateur d'événements de Windows Server.

The post Windows Server 2022 et FSRM – Message d’erreur personnalisé sur un accès refusé first appeared on IT-Connect.

In an IT professional’s life, several situations require you to know a server’s hardware specification. The specification helps you when working on a hardware upgrade, troubleshooting problems, or assessing server resource capacity. 

Unfortunately, a server’s hardware specification is hardly ever readily available. You can, however, use several methods to identify a server’s hardware. In this article, I’ll show you 3 crucial methods to help you out.

3 Methods to Identify a Server’s Hardware Specification

Quick note: the first two methods will rely on built-in features in your device, whereas the third will require some external interference. But I’ll explain everything in detail for you. Let’s jump in!

Method 1: Device Manager

The first option we’ll cover for identifying a server’s hardware specification is to use the Windows Device Manager, which you can see in the image below. Device Manager is often a convenient option because it is easy to use and is built into Windows. With a few clicks, the user can access all hardware specifications without knowing any executable commands and how to run them. 

When talking to different administrators, you’ll often find that some look down their noses at this method and prefer to use PowerShell or command prompts for everything. Sure, it’s great to flex or dust off your keyboard, but typing anything is often slower than clicking a GUI. One of the biggest benefits of using Device Manager is the speed of accessing hardware details.

The main disadvantage of using the Device Manager is that it’ll only work in some situations. For example, Windows servers running a server core configuration don’t include the Device Manager. At one time, it was possible to use a Device Manager on a Windows desktop to access a server’s device information remotely. But Microsoft removed this capability some time ago. Using Device Manager will only be an option for servers equipped with Desktop Experience.

Overall, Device Manager is a highly effective and convenient means of gaining system information quickly. Let’s now turn our attention to our next method!

Method 2: PowerShell

A second option is to use PowerShell to gather system information. Unlike the first method, you use programmatic instruction to query and retrieve your system hardware specification. 

The biggest benefit of using PowerShell is the control and flexibility you have when accessing and retrieving data from various types of onsite and remote servers. 

The disadvantages of using this method are that it takes time to execute commands, and Powershell is only typically present on Windows servers. 

To understand how PowerShell can help you retrieve server hardware specifications, let’s look at the following example. Suppose you wanted to gather information on your server’s CPU for a moment. You could leverage the power of WMI and enter the following command into PowerShell:

Get-WmiObject Win32_processor

This command and returned response in the screenshot below shows some basic information about the system’s CPUs. As handy as that might be, you would have to use a different cmdlet to gather information on the system’s memory:

 Get-WMIObject Win32_PhysicalMemory 

Additionally, for information about the system’s disks, you’ll need to use: Get-PhysicalDisk.

An easier alternative to using individual PowerShell cmdlets is to use the Get-ComputerInfo cmdlet. This cmdlet returns a detailed summary of the system’s hardware and software configuration, as shown below.

Method 3: Third-Party Solution

A third option for gathering hardware information is to use a third-party system information tool . One of my favorite utilities for examining system hardware is Belarc Advisor. But many other tools are available on the market. 

One of the most significant advantages is that you can choose from a wide variety of tools, some of which are free. Often, third-party tools will display highly detailed information about your hardware configuration.

Please note that while some third-party tools do work remotely, many have to be installed directly on the system. Also, if a third-party hardware utility does not support operations, it may not work with systems configured to run a server core configuration.

Overall, if you’re happy running third-party software to collect information about your hardware specification, this can be a useful way to quickly gather what you need. Some solutions can also create monitoring and auditing reports for you, saving you time. If you’re considering this method, only go with a reputable vendor. Also, consider how adding another piece of software will impact your system’s performance. Finally, consider if you’re getting good value for the money required to implement the solution. 

Final Thoughts

You can retrieve information about a server’s hardware specification in several ways, with pros and cons associated with each method. As such, only some of the methods discussed are suitable for some situations. 

Using the Device Manager to retrieve your system specification is among the most popular. It uses the Windows GUI to retrieve and display information through simple clicks. But, Windows servers running a server core configuration don’t include the Device Manager utility, which makes it impossible to use this option in this use case. 

Microsoft is continuing to use PowerShell for all programmatic execution of tasks. This method helps you to retrieve system specifications across servers and is one of the most flexible ways of retrieving hardware information. The drawback of this method is it requires you to remember commands. Additionally, you’ll need to have some degree of PowerShell knowledge and know how to execute commands correctly.

If you have the time and savvy, you could create your script for automating routine checks tailored to your system. This method can also help you create reports for system monitoring activities and audits. An alternative to using native Windows tools is to leverage third-party utilities to help automate data collection. This method can be highly convenient as you don’t need any prior knowledge. The drawback is that you often pay for the convenience it affords. 

Learn more about server hardware specification assessment and related topics in the FAQ and Resources sections below!

FAQ

Why might installing a third-party hardware utility directly on a server be a problem?

Many administrators are hesitant to install any unnecessary software on their servers. At the very least, such software consumes resources that might be better used for running production workloads. At worst, though, third-party utilities might cause system stability issues, with the potential for free utilities to be bundled with malware.

How can the information generated by the Get-ComputerInfo cmdlet be written to a text file?

PowerShell makes it easy to create a text file containing the summary information generated by the Get-ComputerInfo cmdlet. The easiest way to accomplish this is to append the Out-File cmdlet, followed by the path and filename you want to use. For example, you might type Get-ComputerInfo | Out-File C:\data\summary.txt. 

Can I narrow down the information generated by the Get-ComputerInfo command?

The easiest way to narrow down the Get-ComputerInfo cmdlet’s output is to append the Select-Object cmdlet and the names of the objects you want to include in the output. You can also use wildcards as an alternative to individual object names. If, for example, you were only interested in seeing BIOS-related information, you could type: Get-ComputerInfo | Select-Object BIOS*.

Can the Get-WMIObject Win32_Processor cmdlet produce more detailed information than what is shown in the screen capture?

Generally speaking, PowerShell Get cmdlets, including those that use WMI, are designed to surface the most relevant information and suppress likely irrelevant information. If you want to see all of the available processor-related details, you’ll need to append the Select-Object cmdlet and an asterisk. The command would be Get-WMIObject Win32_Processor | Select-Object *.

Did Microsoft remove the ability to connect Device Manager to a remote machine?

In Windows 10, you can open the Computer Management console and select the Connect to Another Computer command from the Action menu. However, attempts to connect to Windows Server will fail. Some workarounds will allow remote device manager use, but these workarounds have yet to be officially supported by Microsoft.

Resources

TechGenix: An Article on Purchasing Hardware

Read more on making sure you purchase hardware that will last.

TechGenix: An Article on Post P2V Conversion

Find out how to clean up Device Manager after a P2V conversion.

TechGenix: An Article on Hardware Resource Consultation

Discover how PowerShell can help estimate hardware resource consumption.

Microsoft: An Article on Resolving Device Manager Error Messages

Read more on Device Manager error messages and what they mean.

Spiceworks: An Article on Finding Detailed CPU Information

Get to grips with how to use PowerShell to retrieve detailed CPU information. 

The post How Can I Find Out a Server’s Hardware Specification? appeared first on TechGenix.