Si vous souhaitez tester Windows 11 22H2 dans une machine virtuelle sans avoir à réaliser l'installation du système, vous pouvez télécharger les nouvelles VMs disponibles sur le site de Microsoft. Cela s'adresse en particulier aux développeurs d'applications, mais tout le monde peut en profiter.

Ces machines virtuelles proposées par Microsoft sont livrées avec Windows 11 22H2 en édition Entreprise, et il y a déjà une préconfiguration effectuée. En effet, Virtual Studio 2022 Community Edition est préinstallé, tout comme Windows Subsystem for Linux avec Ubuntu, ainsi que Windows Terminal et le mode développeur est actif. Au total, cela donne une VM de 20 Go environ. Les détails sur le contenu de la VM sont disponibles sur le site de Microsoft.

Bien que le téléchargement soit gratuit, ces machines virtuelles ne sont pas totalement gratuites, car il faut disposer d'une licence Windows 11. Toutefois, sans avoir besoin d'activer le système, vous pouvez utiliser la VM en l'état jusqu'au 10 janvier 2023. Ensuite, vous devez installer une clé de licence pour continuer à profiter de la VM sans limites de temps.

Microsoft a mis en ligne des machines virtuelles prêtes à l'emploi pour Hyper-V, VMware, VirtualBox et Parallels : de quoi satisfaire la majorité des utilisateurs. Pour le téléchargement, rendez-vous sur cette page :

• Microsoft - VM Windows 11 22H2

Si l'on prend l'exemple de la VM pour VirtualBox, le fichier ZIP téléchargé contient une image OVA, ce qui permet de l'importer facilement dans VirtualBox. D'ailleurs, cette image pour VirtualBox est probablement la même que celle pour VMware car elle est livrée avec un disque au format VMDK.

Source

L'article Voici des VMs Windows 11 22H2 prêtes à l’emploi et distribuées par Microsoft est disponible sur IT-Connect : IT-Connect.

I. Présentation

Cet article de dépannage s'adresse à toutes les personnes qui ont coché l'option "Utiliser WinRM sur HTTPS uniquement" à l'installation de Windows Admin Center et qui se trouvent en difficulté pour administrer des hôtes à distance, à cause d'une erreur de WinRM.

Lors de l'installation de Windows Admin Center, on a la possibilité de cocher l'option "Utiliser WinRM sur HTTPS uniquement" : même si cela part d'une bonne intention pour utiliser uniquement des connexions chiffrées, ce n'est pas forcément l'idéal pour démarrer. En effet, si les machines que vous souhaitez administrer ne sont pas configurées pour utiliser WinRM en HTTPS avec un certificat, alors il ne sera pas possible de les gérer avec Windows Admin Center. Par défaut, WinRM fonctionne en HTTP.

Voici l'option à laquelle je fais référence :

Pour rappel, Windows Admin Center est une solution gratuite proposée par Microsoft qui permet d'administrer ses machines Windows au travers d'un portail Web : aussi bien les serveurs on-premise, que les serveurs dans Azure ainsi que les postes de travail. L'avenir de cet outil est prometteur et Microsoft sort de nouvelles versions régulièrement.

Quand on rencontre ce message d'erreur, on peut avoir le réflexe d'essayer de se connecter avec Enter-PSSession et de constater que ça fonctionne ! C'est normal puisque cette commande va se connecter en HTTP, donc si WinRM est actif en face, la connexion va fonctionner !

Nous allons voir comment désactiver l'option "Utiliser WinRM sur HTTPS uniquement" car ce n'est pas proposé dans les options de Windows Admin Center. Heureusement, la base de Registre va nous permettre d'ajuster la configuration.

II. WAC : désactiver l'option "Utiliser WinRM sur HTTPS uniquement"

Nous devons ajuster une valeur dans le Registre et nous allons procéder avec PowerShell. Toutefois, vous pouvez faire la même chose via l'interface graphique avec Regedit.

Ouvrez une console PowerShell en tant qu'administrateur et exécutez cette commande :

Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\ServerManagementGateway" -Name WinRMHTTPS

Cette commande doit retourner la valeur "1" pour WinRMHTTPS. Comme ceci :

Si ce n'est pas le cas et que vous êtes déjà sur 0, mauvaise nouvelle : vos problèmes de connexion ne proviennent pas de là ! Dans le cas où "WinRMHTTPS = 1", vous devez définir cette valeur à 0 :

Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\ServerManagementGateway" -Name WinRMHTTPS -Value 0

Avec cette petite modification dans la config de Windows Admin Center, vous devriez pouvoir vous connecter à vos serveurs au travers de "WinRM over HTTP" ! Redémarrez votre serveur WAC si cela ne fonctionne pas et il ne vous restera plus qu'à tester ! Quand votre infrastructure sera prête à fonctionner avec "WinRM overs HTTPS", vous pourrez réactiver cette option !

Si besoin d'aller plus loin dans le dépannage, vous pouvez suivre cet article :

• Microsoft Learn - Résolution des problèmes de Windows Admin Center

L'article Windows Admin Center – Comment autoriser WinRM via HTTP ? est disponible sur IT-Connect : IT-Connect.

Encore un coup du groupe LockBit ! Les cybercriminels de LockBit affirment qu'ils sont parvenus à compromettre l'infrastructure de l'entreprise allemande Continental. Voici ce que l'on sait pour le moment.

Pour rappel, Continental est une multinationale connue pour ses pneus et qui emploie tout de même plus de 190 000 personnes dans le monde entier.

Lors de cette attaque informatique, LockBit aurait exfiltré des données à partir des serveurs de Continental à en croire le site de LockBit dédié aux fuites de données ! Désormais, les pirates informatiques menacent de les publier dans moins de 24 heures : ce vendredi à 16h45, heure française, pour être précis. Il pourrait y avoir une demande de rançon derrière tout ça... Toutefois, nous ne connaissons pas la nature de ces données et nous ne savons pas non plus quand a eu lieu cette attaque informatique.

De son côté, Continental n'a pas publié de communiqué officiel au sujet d'une éventuelle attaque informatique. Malgré tout, comme l'ont constatés nos confrères du site Bleeping Computer, Continental a mis en ligne un communiqué le 24 août 2022 pour évoquer une cyberattaque : "Lors d'une cyberattaque, des attaquants ont infiltré certaines parties des systèmes informatiques de Continental. L'entreprise a détecté l'attaque au début du mois d'août, puis l'a évitée." - Un communiqué dans lequel on peut lire également : "Immédiatement après la découverte de l'attaque, Continental a pris toutes les mesures défensives nécessaires pour restaurer l'intégrité de ses systèmes informatiques."

Les données que LockBit s'apprête à mettre en ligne sont-elles liées à cette attaque du mois d'août ? Ou s'agit-il d'une nouvelle cyberattaque ? Bonne question... Pour en savoir plus, il vaut mieux attendre que Continental communique à ce sujet. On peut imaginer que du côté de chez Continental, des investigations sont en cours !

Il y a quelques jours, le groupe LockBit a annoncé de nouvelles attaques, notamment à l'encontre de Thales et d'EXCO.

Source

L'article Le groupe LockBit revendique une attaque informatique contre Continental ! est disponible sur IT-Connect : IT-Connect.

Au travers du blog Android Developers, Google a fait une nouvelle annonce au sujet de la prise en charge des jeux Android sur Windows. Les travaux de Google viennent concurrencer ceux de Microsoft avec l'Amazon Appstore. Voici les dernières informations.

En début d'année 2022, Google avait lancé une version bêta de Google Play Games uniquement pour certains pays d'Asie (Corée du Sud, Hong Kong et Taïwan). Alors que l'on approche de la fin d'année, l'entreprise américaine a mis en ligne une nouvelle version bêta, tandis que l'on aurait pu s'attendre à une version stable. Toutefois, Google commence à ouvrir les vannes et à proposer cette solution à d'autres pays ! Même si la France n'a pas encore le droit à "Google Play Games sur Windows" (et que Google n'a pas donné de date), cette bêta-test est disponible en Amérique (aux États-Unis, au Canada, au Mexique, au Brésil) ainsi qu'à d'autres pays d'Asie (Indonésie, en Malaisie, à Singapour, aux Philippines).

Cette version donne accès à un ensemble de 85 jeux mobiles accessibles directement depuis Windows, en mode natif. Google cite les jeux suivants à titre d'exemple : 1945 Air Force, Blade Idle, Cookie Run: Kingdom, et Evony: The King’s Return. Pour que l'expérience soit complète, Google affirme que les manettes, les claviers et les souris seront pris en charge. Ce qui est particulièrement intéressant, c'est le fait que l'expérience repose sur Google Play Games puisque cela va permettre aux joueurs de synchroniser leur progression entre le PC et le smartphone.

En comparaison de la solution Windows Subsystem for Android proposée par Microsoft, celle-ci supporte Windows 10 (à partir de v2004) et Windows 11. Au niveau du matériel, vous devez aussi avoir 8 Go de RAM, un CPU avec au moins 4 cœurs, et 20 Go d'espace de stockage sur un disque SSD.

En attendant une version stable, vous pouvez profiter des applications Android sur Windows en utilisant "Windows Subsystem for Android + Amazon Appstore". Mon tutoriel à ce sujet est disponible :

• Tutoriel - Applications Android sur Windows

Reste à savoir si nous aurons le droit à une version stable d'ici la fin de l'année...

Source

L'article Windows – Bientôt les jeux Android sur PC grâce à Google Play Games est disponible sur IT-Connect : IT-Connect.

I. Présentation

Après avoir vu comment installer Exchange Server 2019 sur Windows Server 2022, nous allons voir comment protéger l'interface d'administration d'Exchange appelée "Centre d'administration Exchange" (ou ECP / EAC) en limitant l'accès à quelques adresses IP sources.

• Tutoriel - Installation de Microsoft Exchange Server 2019

Je vous rappelle que par défaut, le Centre d'administration Exchange est accessible depuis le serveur Exchange en lui-même, depuis une machine du réseau local, mais aussi à partir d'Internet (si vous avez autorisé le flux HTTPS pour un accès au Webmail). Pour des raisons évidentes de sécurité, il est préférable de limiter l'accès à la console d'administration à partir de certaines adresses IP, ou au pire, à partir du réseau local. Il vaut mieux éviter que cette console soit accessible depuis l'extérieur.

Puisque le protocole HTTPS est utilisé aussi pour accéder au Webmail, nous ne pouvons pas jouer directement avec le pare-feu de Windows, car on couperait aussi l'accès au Webmail. La restriction doit être appliquée sur une couche supérieure. Nous avons deux solutions pour appliquer des restrictions par adresses IP :

• Configurer le serveur Web IIS grâce au module de restriction par adresses IP
• Configurer une "Client Access Rules" dans Exchange 2019 (pas disponible sur les versions antérieures)

II. Méthode n°1 : restriction via IIS

A. Installer la fonction "Restrictions par adresse IP et domaine"

Commençons par cette première méthode, plus traditionnelle on peut dire.

• Tutoriel - IIS - Restriction par adresse IP

Sur votre serveur Exchange, dégainez la console PowerShell en tant qu'administrateur et exécutez la commande suivante :

Install-WindowsFeature -Name Web-IP-Security

Cette commande revient à installer la fonctionnalité suivante dans IIS, à partir du gestionnaire de serveur :

Une fois l'installation effectuée, passez à la suite. Il n'est pas utile de redémarrer le serveur.

B. Restreindre l'accès à l'ECP d'Exchange

Ouvrez la console de management d'IIS et déroulez la section "Sites". Ici, cliquez sur "Default Web Site" (1), puis sur "ecp" (2) afin d'accéder à "IP Address and Domain Restrictions" (ou  "Restrictions par adresse IP et domaine" en français).

Dans la section qui s'ouvre, cliquez sur "Add Allow Entry" (1) pour ajouter une nouvelle autorisation. L'objectif ici est d'indiquer quel est la machine ou le sous-réseau autorisé à accéder au Centre d'administration Exchange. Il est possible d'ajouter plusieurs règles d'autorisation. Dans cet exemple, j'autorise les connexions à ECP aux machines du sous-réseau "10.10.100.0/24" (2). Quand c'est fait, validez avec "OK" (3).

Une fois que votre règle est définie (c'est modifiable par la suite), cliquez sur "Edit Feature Settings" (1) afin de modifier l'action à appliquer pour les clients non autorisés. Par défaut, c'est autorisé, donc nous devons inverser ce comportement. Choisissez "Deny" (2) et pour l'action à réaliser, choisissez "Abort" (3) pour couper la connexion avec le client qui tente de se connecter. Validez avec "OK" (4).

Pour finir, cliquez sur "Default Web Site" à gauche puis à droite sur le bouton "Restart" pour redémarrer le site IIS dans le but d'appliquer la modification.

À partir d'un client autorisé, l'accès au Centre d'administration Exchange doit fonctionner normalement. Tandis qu'à partir d'un client non autorisé, une erreur doit s'afficher, comme ceci :

III. Méthode n°2 : Client Access Rules

Pour protéger le centre d'administration Exchange, nous pouvons mettre en place une règle Client Access Rules. C'est une méthode officielle dont la configuration s'effectue uniquement en PowerShell à partir de l'Exchange Management Shell.

Note : avec les règles Client Access Rules, il est possible d'aller plus loin qu'une restriction basée sur les adresses IP. Par exemple, on peut s'appuyer sur la valeur d'un attribut dans l'Active Directory.

Je vous invite à ouvrir la console Exchange Management Shell.

Tout d'abord, vous pouvez lister les règles en place. Par défaut, il n'y en a pas.

Get-ClientAccessRule

Ensuite, nous allons mettre en place une règle pour toujours autoriser le Remote PowerShell afin de ne pas perdre la main sur l'Exchange si l'on créer une mauvaise règle... C'est une recommandation de Microsoft et l'entreprise américaine fournie même la commande pour créer cette règle :

New-ClientAccessRule -Name "Always Allow Remote PowerShell" -Action AllowAccess -AnyOfProtocols RemotePowerShell -Priority 1

La règle avec la priorité 1 sera donc celle-ci. Ensuite, nous allons créer une nouvelle règle sur le même principe. Cette règle permet de refuser l'accès au Centre d'administration Exchange sauf pour les machines qui appartiennent au réseau "10.10.100.0/24". Ce qui donne :

New-ClientAccessRule -Name "Allow ECP console only for 10.10.100.0/24" -Action DenyAccess -AnyOfProtocols ExchangeAdminCenter -ExceptAnyOfClientIPAddressesOrRanges 10.10.100.0/24 -Priority 2

Suite à l'exécution de cette commande, vous pouvez lister vos règles :

Une fois la règle en place, vous pouvez tester pour voir si la restriction s'applique bien... Là, je parviens à me connecter à la page d'authentification d'ECP, et même à me connecter. Par contre, je ne peux pas aller plus loin, car la règle se déclenche comme le montre l'image ci-dessous. On peut dire que c'est cohérent : ce n'est pas IIS qui me bloque, mais Exchange.

Ce n'est pas ce que vous souhaitiez ? Pas de soucis, vous pouvez supprimer la règle en précisant son nom :

Remove-ClientAccessRule "Allow ECP console only for 10.10.100.0/24"

L'aide complète sur les Client Access Rules d'Exchange 2019 est disponible sur le site de Microsoft :

• Microsoft Learn - Exchange 2019 - Client Access Rules

IV. Conclusion

Nous venons de voir comment restreindre l'accès au centre d'administration Exchange en appliquant une restriction basée sur les adresses IP. Cela n'a pas d'impact sur le Webmail Exchange en lui-même, mais c'est une action recommandée pour protéger l'interface d'administration. L'idéal étant de permettre l'accès à partir d'une ou plusieurs machines de management (ou un VLAN de management), et refuser les accès en provenance de l'extérieur ainsi que les accès provenant du réseau local (hors machines déclarées).

L'article Désactiver les accès externes au Centre d’administration Exchange est disponible sur IT-Connect : IT-Connect.