Présentation

Présentation chez MS
Planification
Guide de déploiement

Fonctionne par groupe de synchronisation (sync group), qui associe un/plusieurs point(s) de terminaison local (server endpoint : le chemin sur le serveur) et un point de terminaison distant (cloud endpoint : un partage Azure Files).
Pass par l’installation d’un agent sur chaque serveur à configurer (supporté à partir de Server 2016, ou 2012R2 avec Windows Management Framework).

Sur le serveur, il est nécessaire que le lecteur soit en accès direct (propriétaire du filesystem), et en NTFS.
Les liens durs et symboliques seront ignorés.

L’accès par clé doit être activé sur le compte de stockage.

Les données seront synchro en bi-directionnel ; toutefois, la propagation cloud -> serveurs locaux sera plus lente que le sens inverse (“This is because Azure Files today lacks an efficient change detection mechanism like Windows Server has, so changes to the Azure file share directly will take time to propagate back to the server endpoints”).
En gros une tâche planifiée (“change detection job”) est déclenchée toutes les 24h, l’agent va alors scanner tous les fichiers et détecter les changements.

Il faut déployer un “Storage Sync Service”.
Un serveur ne peut faire partie que d’un seul “Storage sync Service”. MS conseille globalement d’utiliser un seul SSS.

Maximum 30 partages par serveur.

Mise en place de l’infrastructure

Préparation du serveur

Sur chaque serveur sur lequel l’agent de sync sera installé, désactiver “Internet Explorer Enhanced Security Configuration”.
Gestionnaire de serveur -> Serveur local -> Section “Proprietés” -> Configuration de sécurité renforcée d’IE -> les 2 à Non

Création du Storage Sync Service (SSS)

Azure portal -> Create ressource
chercher “Azure File Sync” -> Create
Choisir l’abonnement Azure ; choisir le groupe de ressources concerné ; donner un nom ;
Le réseau devrait être ok par défaut; Valider la création.

Installation de l’agent de synchronisation

Télécharger ici le paquet correspondant à la version du serveur.
Install classique.
Sera installé dans le dossier : C:\Program Files\Azure\StorageSyncAgent\
Peut être configuré pour utiliser Windows Update.

Inscription du serveur auprès du service de sync

Il faut avoir les rôles Owner ou Contributor sur le SSS.

Au lancement de l’interface Azure Files Sync, il est demandé d’inscrire le serveur. On choisit “AzureCloud”, on se connecte, et on sélectionne la bonne ressource.
Si l’interface ne se lance pas, lancer C:\Program Files\Azure\StorageSyncAgent\ServerRegistration.exe

On peut alors le voir sur le portail Azure, sur la ressource SSS, dans “Sync -> Registered servers”

Création du groupe de synchro

Un groupe de synchro équivaut à un dossier cloud.
Il faut faire la suite pour chaque nouveau groupe de synchronisation.

Azure Portal -> trouver la ressource (par exemple via le groupe de ressource, ou le menu de service “Storage Sync Services”

Sync -> Sync groups -> Create sync group
On donne un nom, on choisit l’abonnement, le compte de stockage, le partage Azure
Le groupe de synchro est alors créé, mais n’a aucun “server endpoint”

Création du point de terminaison serveur

Il faut maintenant créer un SEP (Server EndPoint).
À faire sur chacun des serveurs qui sera dans le groupe de synchro.
Attention, le choix du lecteur et du chemin sur le serveur est définitif ! Il ne pourra pas être modifié par la suite.

Ouvrir le groupe de synchro -> Add server endpoint
Choisir le serveur
Entrer le chemin local des données à synchroniser (avec la lettre de lecteur)
Activer si besoin le cloud tiering

Initial sync : uniquement disponible pour le 1e serveur que l’on synchronise.
MS conseille de conserver “Merge” dans la majorité des cas, même si la source ou la destination est vide.

Initial download : aucun impact si le partage est vide.
“Namespace first, then content” semble adapté pour avoir toutes les données en local.
Ne pourra pas être changé par la suite !

On peut alors valider ; ça va créer le SEP, et la synchro sera déclenchée quelques temps plus tard.

Forcer la synchro

On peut forcer la synchro depuis le cloud vers le serveur avec la commande Invoke-AzStorageSyncChangeDetection.
https://learn.microsoft.com/en-us/powershell/module/az.storagesync/invoke-azstoragesyncchangedetection

On définit nos ressources :

$rgname = "myressourcegroup"  
$sss = "mysyncservice"  
$sgname = "mysyncgroup"

Ensuite, on récupère le GUID du point de terminaison cloud :

$cep = (Get-AzStorageSyncCloudEndpoint -ResourceGroupName $rgname -StorageSyncServiceName $sss -SyncGroupName $sgname).CloudEndpointName

puis on force la synchro :

Invoke-AzStorageSyncChangeDetection -ResourceGroupName $rgname -StorageSyncServiceName $sss -SyncGroupName $sgname -Name $cep

Dépannage

https://learn.microsoft.com/en-us/troubleshoot/azure/azure-storage/files/file-sync/file-sync-troubleshoot-sync-errors

Décommissioner un serveur

https://learn.microsoft.com/en-us/azure/storage/file-sync/file-sync-server-endpoint-delete

Si on veut retirer un serveur, il faut d’abord s’assurer que tous ses changements on bien été transférés vers le cloud.
Observateur d'evts -> Journaux des applications et services -> Microsoft -> File Sync -> Agent -> Telemetry
Chercher un evt 9102 récent.

Autres indications sur le portail Azure :
Storage accounts -> file share -> used size
SSS -> Sync group

• 0 persistent sync error
• server endpoint -> sync status
• Upload et Download ont des timestamps récents

Pour être sûrs que des nouvelles données ne soient plus écrites sur le serveur, on désactive le partage réseau du serveur.
ATTENTION, ne pas modifier les droits d’accès sur le serveur pour empêcher l’accès, sinon cette modification sera répliquée sur Azure.
S’il n’est pas possible de supprimer le partage (par exemple plusieurs dossiers partagés sous un seul chemin), il faudra changer le chemin d’accès sur le serveur (par ex. renommer le dossier) à la fin de la manip.

On peut alors supprimer le “server endpoint”, puis le “cloud endpoint”, puis le groupe de synchro.

Powershell

cd 'C:\Program Files\Azure\StorageSyncAgent'
Import-Module -Name .\StorageSync.Management.ServerCmdlets.dll/subscriptions/xx-xxxx-xxxx/resourceGroups/MonGroupeRessources/providers/Microsoft.StorageSync/storageSyncServices/ServiceSynchroFichiers/registeredServers/xxx-xxx-xxx

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.

https://www.thomas-krenn.com/en/wiki/Link_Aggregation_and_LACP_basics
https://fr.wikipedia.org/wiki/IEEE_802.3ad

LAG : Link Aggregation Group : agrégation statique (tous les paramètres sont manuels)

LACP : Link Aggregation control Protocol : configuration automatique des propriétés du lien entre 2 périphériques ; les 2 doivent supporter LACP sinon ça ne fonctionne pas. Spécification IEEE 802.3ad

Synology

Selon mes tests, le Adaptative Load Balancing répartit bien le flux lors d’un téléchargement sur 2 PC en parallèle (le Synology choisit le chemin), mais le flux n’est pas réparti en envoi (le switch envoie les 2 connexions sur le même port).

En mode LACP (si le switch le supporte), la connexion est répartie aussi bien en envoi qu’en réception (1Gbps sur 2 connexions simultanées).

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

Cette ligne crée un nouveau document dont le nom suffixé de “-grayscale” input=mycolordoc.pdf output=$(echo "$input" | sed 's/.pdf$/-grayscale.pdf/') gs -sDEVICE=pdfwrite -sColorConversionStrategy=Gray -dProcessColorModel=/DeviceGray -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -sOutputFile="${output}" "${input}"

https://superuser.com/questions/104656/convert-a-pdf-to-greyscale-on-the-command-line-in-floss

Généralités

DC : Domain Component (ce qui définit le domaine lui-même) OU : Organisation Unit (une organisation à l’intérieur du domaine, décidée par le service informatique ; non obligatoire) CN : Common Name (le nom courant d’un objet, par exemple “myUser”) DN : Distinguished Name (+- un chemin absolu, qui identifie l’objet de manière unique dans le répertoire ; comprend forcément des références aux DC et au CN, et éventuellement aux OU)

Exemple de DN : CN=OpenVPN,OU=OpenVPN,OU=IT,DC=paris,DC=myCompany,DC=com
Il s’agit du nom courant “OpenVPN” (un utilisateur), situé dans l’OU “OpenVPN”, elle-même située dans l’OU “IT”, elle-même située dans le domaine “paris.mycompany.com”

On peut obtenir le DN de n’importe quel objet dans Utilisateurs et ordinateurs Active Directory en faisant un clic-droit sur l’objet -> Éditeur d'attributs, puis en cherchant l’attribut distinguishedName (taper dist au clavier devrait amener dessus).

Recherche dans l’Active Directory depuis Linux

On peut utiliser le logiciel ldapsearch, disponible dans le paquet ldap-utils.

sudo apt install ldap-utils

On utilisera les flags suivants :

-H pour spécifier l'annuaire ldap (ou le serveur AD)
-x pour une authentification simple
-W pour demander le password
-D pour spécifier l'utilisateur utilisé pour se connecter auprès de l'AD ; ce peut être l'adresse mail (user@contoso.com) ou le DN de l'objet
-b pour définir le chemin de base de la recherche ; par exemple DC=paris,DC=myCompany,DC=com
-LLL pour supprimer les commentaires et la version de LDAP de l'affichage des résultats

On peut ensuite définir un ou plusieurs filtres pour sélectionner les objets désirés ; par exemple (sAMAccountName=Administrateur)" pour sélectionner l’objet dont le nom de compte est Administrateur ; on peut passer plusieurs filtres, avec la syntaxe suivante : (&(sAMAccountName=Administrateur)(memberOf=CN=myGroup,OU=Groups,OU=IT,DC=paris,DC=myCompany,DC=com)

Enfin, on peut choisir un attribut à afficher, pour ne récupérer que ce champ dans la liste des résultats. Par exemple "name" pour récupérer le nom du compte.

Ceci nous donne la syntaxe suivante pour rechercher le nom des membres du groupe

ldapsearch -H ldap://192.168.10.100 -x -W -D “CN=myGroup,OU=Groups,OU=IT,DC=paris,DC=myCompany,DC=com” -b “DC=DC=paris,DC=myCompany,DC=com” “(&(memberOf=CN=myGroup,OU=Groups,OU=IT,DC=paris,DC=myCompany,DC=com))” “name”

Point-to-point setup

https://www.wireguard.com/quickstart/
https://wiki.archlinux.org/index.php/WireGuard

## INSTALL
# Install wireguard
apt install wireguard

## KEYS
# Create storage
cd /etc/wireguard
mkdir keys && chmod go-rwx ./keys && cd keys

# Generate private key
(umask 0077; wg genkey > peer_A.key)
# Derive public key
wg pubkey < peer_A.key > peer_A.pub

# Optionnal - Generate Pre-Shared Key ; 1 for each peer pair
wg genpsk > peer_A-peer_B.psk


## NETWORKING
# Create interface
ip link add dev wg0 type wireguard

# Assign address and mask
ip address add dev wg0 192.168.2.1/24

# Set port
wg set wg0 listen-port 51871


wg set wg0 listen-port 51871 private-key ./peer_A.key

Un peu de lecture ici.

nethogs

sudo apt install nethogs
sudo nethogs

Exemple de docker-compose (pour Medalla)

https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/domain-joined-machines-cannot-detect-domain-profile

Profiles

Observateur event
Journaux apps services
Microsoft -> Windows -> NetworkProfile -> Operationnel

On y voit le GUID du profil choisi une fois l’identificxation NLA effectuée

Get-NetConnectionProfile

https://learn.microsoft.com/en-us/powershell/module/netconnection/set-netconnectionprofile
Set-NetConnectionProfile -InterfaceIndex “18” -NetworkCategory “Private”

Pas possible de définit le profil Domaine ; ceci est fait automatiquement par Windows

https://superuser.com/questions/1725191/network-names-in-windows

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles
Signatures

Pour diagnostiquer la connectivité réseau avec le controlleur de domaine
Test-ComputerSecureChannel

dcdiag

Serveur toujours en non identifié

Essayer de juste redémarrer le service NLA ; ça devrait fonctionner, mais ça recommencera au prochain reboot

https://glennopedia.com/2024/06/01/network-location-awareness-service-revisited/

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters
DWORD “AlwaysExpectDomainController” “1”

MTU

connaitre le MTU en powershell :
netsh interface ipv4 show subinterfaces