La gestion des connexions SMB a changé depuis Windows 11 Pro 24H2.
Elle avait déjà changé pour les versions Education, Pro for workstations, Enterprise de Windows 10 et 11.
Elle reste similaire à avant pour Windows 11 Home.

En conséquence de ces changements, Windows exige maintenant que les connexions SMB soient signées, et la bascule sur un accès invité en cas de défaut de signature est désactivée.
Article chez MS

Dans mon cas, il s’agit de l’accès vers un serveur Samba, dont l’accès invité fonctionne correctement et nativement depuis un poste Windows 10.
Avec Windows 11 Pro 24H2, je suis confronté aux 2 problèmes : la signature de la connexion SMB, et l’accès en tant qu’invité.

À noter que la solution ne semble pas fonctionner pour des profils cloud, que pour les utilisateurs locaux du poste. Question de configuration ?

Accès SMB non signé

https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-signing

Par défaut, Windows 11 Pro (au moins 24H2) exige que les connexions SMB soient signées.
La fonctionnalité de signature ne fonctionne pas avec l’accès invité, il est donc indispensable de la désactiver (source chez MS).

Cela peut se vérifier par la commande Powershell
Get-SmbClientConfiguration | findstr req.*sign
qui doit nous indiquer la valeur de RequireSecuritySignature, probablement à True.

Le problème se manifeste par “Une erreur étendue s’est produite” (si accès depuis la fenêtre “Exécuter”) ou “Windows ne peut pas accéder à my-srv” (si accès depuis la barre d’adresse de l’explorateur).

Pour ceci, j’ai 3 possibilités : le registre, les stratégies locales, ou Powershell.
Ces 3 possibilités sont équivalentes : l’activation (ou désactivation) par une méthode se répercute de manière visible sur les autres méthodes (il faut toutefois fermer/rouvrir les stratégies locales pour actualiser).

Registre :
HKLM\SYSTEM\CurrectControlSet\Services\LanmanWorkstation\Parameters et définir la valeur DWORD
RequireSecuritySignature
à 0

Stratégies locales :
gpedit.msc
Config ordi -> Paramètres Windows -> Paramètres de sécurité -> Stratégies locales -> Options de sécurité
Client réseau Microsoft : communications signées numériquement (toujours)

Powershell :
Set-SmbClientConfiguration -RequireSecuritySignature $false -Force

Connexion en tant qu’invité

Sources pour cette partie :

https://memo.raphaelguetta.fr/post/server-2019-access-guest-share/
https://learn.microsoft.com/en-us/windows-server/storage/file-server/enable-insecure-guest-logons-smb2-and-smb3
https://forum.qnap.com/viewtopic.php?t=175771

Une fois la connexion non-signée autorisée, lorsque je cherche à me connecter à mon serveur, je suis accueilli par une invite d’authentification, sans possibilité de me connecter en invité (alors que mon serveur l’accepte). Ceci car l’accès à des partages sans authentification est désactivé par défaut.

On peut vérifier en lançant la commande Powershell
Get-SmbClientConfiguration | findstr /I enablei
qui nous retourne la valeur de EnableInsecureGuestLogons, probablement False.

Comme pour les signatures, on peut contrôler ce paramètre par le registre, Powershell, ou les stratégies locales.
La stratégie locale a toutefois priorité ! Si elle est est configurée (activée ou désactivée), alors la valeur de l’entrée de registre n’aura aucun impact.
En ce cas, le résultat de Get-SmbClientConfiguration affichera la configuration effective, indépendamment de la valeur de registre.
Set-SmbClientConfiguration continuera de modifier la valeur de registre, mais n’aura pas d’impact sur la stratégie locale.

Registre/Powershell

On peut au choix ouvrir l’éditeur de registre, ouvrir la clé
HKLM\SYSTEM\CurrectControlSet\Services\LanmanWorkstation\Parameters
et ajouter/éditer la valeur DWORD AllowInsecureGuestAuth en la passant à 1.
Il est également possible de lancer la commande Powershell
Set-SmbClientConfiguration -EnableInsecureGuestLogons $true -Force
qui aura pour résultat de créer/modifier cette même valeur registre.

Stratégies locales

gpedit.msc
Configuration ordinateur -> Modèles d'administration -> Réseau -> Station de travail LANMAN
Activer les ouvertures de session invité non sécurisées -> Activé

Poste joint à AzureAD

Le compte est de la forme nom.prenom@domain.com.
Un whoami sur le poste cible renvoie azuread\nomprenom .

Si le paramètre NLA est activé, seul un poste Windows pourra y accéder ; freerdp ne semble pas gérer l’authenfication Kerberos pour le moment ? Voir cette issue.
Pour se connecter depuis Windows, lancer mstsc.exe, aller dans l’onglet Avancé puis Cocher “Utiliser un compte web pour vous connecter à l’ordinateur distant”. On peut laisser le mot de passe vide.
Une fenêtre de connexion web va s’ouvrir.
La connexion reste ensuite établie, et ne demande plus le mot de passe.

On peut également désactiver NLA (sur le poste cible, paramètres avancés du système -> Utilisation à distance).
En ce cas on peut se connecter depuis FreeRDP avec
xfreerdp /v:10.0.10.100 /d:AzureAD /u:nomprenom /p:mypassword /sec:tls
ou encore
xfreerdp /v:10.0.10.100 /u:"AzureAD\nomprenom" /p:mypassword /sec:tls
ou encore
xfreerdp /v:10.0.10.100 /u:AzureAD\\nomprenom /p:mypassword /sec:tls

Compte perso ?

“MicrosoftAccount\nomprenom” ??

Compte créé en tant que compte local

Supposons que le compte utilisé soit un compte local, que l’on appellera “admin”.
En ce cas :

• whoami donner hostname\admin

Les paramètres mentionneront “Compte local” en haut à gauche.
L’appareil apparaît dans la liste des appareils sur :
https://account.microsoft.com/devices

Si on va dans Paramètres -> Comptes, des infos sur le stockage cloud etc. sont affichées
Si on va dans Paramètres -> Comptes -> E-mail et comptes, on voit le compte mentionné comme “Compte Microsoft” et on ne peut pas le supprimer, on ne peut que le “Gérer” (ce qui ouvre le site web de MS)

Les applis MS sont connectées automatiquement

Compte créé via un compte MS perso

Si dès la création du compte, on se connecte avec un compte MS
Le username est hostname\abcde avec abcde qui sont les 5 premières lettres du mail associé au compte MS

Les paramètres mentionnent l’adresse mail en haut à gauche.

Déconnexion

Compte perso

Aller dans les Paramètres -> Comptes -> Vos informations
et choisir “Se connecter plutôt avec un compte local”

Une fois déconnecté, le compte Windows devient effectivement un compte local, mais les informations de connexion sont toujours enregistrées. Ainsi, même après déconnexion de Teams, il suffit de sélectionner le compte dans la liste pour l’ouvrir à nouveau, sans besoin de taper le mot de passe.

Ceci est dû au fait qu’après suppression du compte MS, le compte reste dans les Paramètres -> Comptes -> E-mail et comptes
Mais en déroulant ses infos, on peut ici le supprimer. Ainsi, toute re-connexion à ce compte nécessitera le mot de passe.

Compte pro/scolaire

Paramètres -> Comptes -> Accès professionnel ou scolaire

NE FONCTIONNE PAS FINALEMENT lors du chiffrement systeme du 2e OS, l’entete du 1er OS déjà chiffré est remplacée par l’entete du 2nd. Le 1er OS est alors “déverrouillé” avec le password du 2e OS, mais la partition est illisible et ça fait écran bleu avec fichier introuvable. On peut réparer la situation uniquement avec le veracrypt rescue disk créé au moment du chiffrement du 1er os, et choisir l’option “k” . Ceci rendra toutefois le 2e OS non bootable à son tour.

Essayer avec bitlocker pour le 2e OS ?

Ancien article :

But : avoir 2 installs Windows distinctes (en + d’une debian), chacune chiffrée par Veracypt, et que le choix se fasse via GRUB et sans avoir à choisir au sein de windows boot manager.

Si 2 installs Windows coexistent au sein d’une même ESP, alors ils partageront la même BCD, et comme le choix de l’OS intervient après le boot de l’OS et donc du déchiffrement Veracrypt, ça rend la solution non viable.

Solution (hacky) : avoir 2 ESP.

Structure du disque (table GPT) :

• 1 partition ESP1 (FAT32, 500m, flag boot)
• 1 partition ESP2 (FAT32, 500m, SANS le flag boot)
• 1 partition WIN1 (NTFS, 50G ou +)
• 1 partition WIN2 (NTFS, 50G ou +)
• partitions nécessaires pour Debian, avec éventuellement LUKS (auquel cas 1 partition pour /boot )

Démarche générale :

• Installer Win1

• Installer Debian

• Vérifier le double-boot via GRUB

• Installer Veracrypt sur Win1, chiffrer la partition système (ceci remplace notamment EFI\Microsoft\Boot\bootmgfw.efi par le lanceur de Veracrypt)

• Vérifier le boot de Win1 chiffré en direct, puis via GRUB. Remettre GRUB en lanceur par défaut dans l’UEFI

• Booter Debian, copier le code GRUB (section dans /boot/grub/grub.cfg) de lancement de Win1 dans /etc/grub.d/40_custom pour être sûr de le conserver(on peut renommer l’entrée pour + de clarté)

• Via efibootmgr, supprimer les 2 entrées Veracrypt et Windows Boot Manager (essentiel pour éviter les conflits)

• Via Gparted enlever le flag boot sur ESP1, le positionner sur ESP2

• update-grub (il ne devrait plus avoir d’autre OS détécté par os-prober, seulement l’entré manuelle)

• Installer Win2

• Vérifier le triple-boot via GRUB

• Installer Veracrypt sur Win2, chiffrer la partition système

• Booter Debian, copier le code GRUB de lancement de Win2 dans /etc/grub.d/40_custom

• Via efibootmgr, supprimer les 2 entrées Veracrypt et Windows Boot Manager

• Via Gparted enlever le flag boot sur ESP2, le positionner sur ESP1

• update-grub

Normalement grub sera le seul OS référencé par l’EFI, il y’aura 1 entrée pour chacun des windows chiffrés, et chaque windows sera complètement indépendant d’un point de vue fichiers de démarrage.
On peut toutefois toujours monter la partition d’une install windows depuis l’autre en fonctionnement.

BitLocker est un système de chiffrement de périphérique. Le contenu d’une partition est chiffré grâce à la FVEK (Full-Volume Encryption Key), elle-même chiffrée par la VMK (Volume Master Key), elle-même pouvant être chiffrée par différents moyens (les “protecteurs”, par exemple un password, ou le TPM).

Si il y’a un triangle jaune sur un périphérique, c’est que BitLocker n’est pas réellement activé. Les données sont chiffrées, mais aucun protecteur n’est en place pour protéger la clé de déchiffrement.

Lors d’une installation Windows sur un poste possédant une puce TPM, l’installation sera automatiquement (à vérifier ?) chiffrée pour utiliser Bitlocker.

Bitlocker se gère via le panneau de configuration (sur un Win10 Famille, c’est “Chiffrement de l’appareil)” ou en CLI avec manage-bde.

en CLI

Sous Windows avec le disque déverrouillé :
manage-bde -status
manage-bde -protectors C: -get

Si pas de protecteurs, on peut simplement désactiver le chiffrement avec
manage-bde -off LETTER:
Ça prendra un certain temps, pour réécrire les données non-chiffrées.

Linux

Si on veut accéder à cette partition depuis Linux, il faut utiliser l’outil dislocker, disponible dans les dépôts Debian.
sudo apt install disklocker