# 1 Migration Active Directory vers Samba4

## 1.1 Introduction

Ce document décrit comment migrer un domaine Active Directory Windows Server 2022 vers Samba4 AD de façon transparente, en préservant l'intégrité des données et la continuité de service.

## 1.2 Rappels techniques

Afin de comprendre l'utilité de ce document, il convient de rappeler le fonctionnement d'un domaine Active Directory.

Un contrôleur de domaine Active Directory est un serveur chargé de maintenir l'état du domaine. Ce serveur utilise des mécanismes LDAP pour stocker les éléments nécessaires à sa gestion. À la différence d'un poste de travail, les données d'un domaine AD sont destinées à être utilisées sur l'ensemble des machines participant au domaine.

### 1.2.1 Identifiant de domaine (ObjectSid)

Lors de la création d'un domaine, le serveur génère un identifiant unique appelé **Domain Object SID**, qui permet d'identifier toute action liée au domaine. Cet ObjectSID est le préfixe de tout objet dans l'annuaire.

L'utilisation des préceptes LDAP permet d'organiser le domaine sous forme arborescente avec une hiérarchie claire des objets.

**Format du SID** : `S-1-5-21-XXXXXXXXX-XXXXXXXXX-XXXXXXXXX`
- `S-1-5-21` : Préfixe standard pour les domaines Windows
- Les trois groupes de chiffres suivants constituent le Domain SID unique

### 1.2.2 Utilisateurs et objets

Un utilisateur AD représente une personne gérée par le domaine. Cet objet AD est identifié par son **ObjectSID** qui est la concaténation du **Domain SID** avec un **RID** (Relative Identifier - numéro unique).

**Exemple** : `S-1-5-21-1234567890-1234567890-1234567890-1001`
- `S-1-5-21-1234567890-1234567890-1234567890` : Domain SID
- `1001` : RID de l'utilisateur

Cette démarche est identique pour :
- **Groupes de sécurité** et de distribution
- **Comptes d'ordinateur** (Computer Accounts)
- **Autres objets de sécurité** dans le domaine

### 1.2.3 Relations d'approbation et comptes machine

Lors de la jonction d'un poste de travail à un domaine, le poste établit une **relation de confiance** avec le domaine auquel il est inclus. Un **compte d'ordinateur** est créé dans l'AD pour sécuriser les échanges entre les contrôleurs de domaine et le poste de travail.

**Caractéristiques du compte machine** :
- Nom : `NOMORDINATEUR$` (nom d'ordinateur + symbole `$`)
- Mot de passe : Généré automatiquement et changé régulièrement (par défaut tous les 30 jours)
- ObjectSID : Domain SID + RID unique
- Utilisé pour l'authentification Kerberos et NTLM

**Processus d'authentification** :
1. L'utilisateur se connecte sur le poste de travail
2. Le poste utilise son compte machine pour s'authentifier auprès du DC
3. L'ObjectSID de l'utilisateur sert d'identifiant unique pour les autorisations
4. Un ticket Kerberos est émis pour la session 

# 2 Procédure de migration

> **NB**: Pour valider le bon déroulement de la procédure, une VM Windows11 est installée dans le réseau, elle sera configurée sur le domaine Windows 2022, puis migrée au domaine Samba.
{.is-info}

## 2.1 Pré-requis

### 2.1.1 Droits et accès nécessaires
- **Droits d'administration** sur le domaine Active Directory source
- **Accès physique ou distant** à la machine cible Linux
- **Connectivité réseau** entre l'environnement Windows et le serveur Linux cible
- **Sauvegarde complète** du domaine AD existant avant migration

### 2.1.2 Outils requis
- Script PowerShell `exportDomain.ps1` (fourni)
- Playbook Ansible pour l'installation Samba4
- Serveur de bastion avec Ansible installé

## 2.2 Préparation de l'environnement cible

Préparer le serveur Linux cible qui hébergera le contrôleur de domaine Samba4 à la fin du processus. Ce serveur est virtualisé et basé sur une distribution Debian GNU/Linux.

### 2.2.1 Création de la machine virtuelle

Créer une VM avec les caractéristiques suivantes :
- **Mémoire RAM** : 2 Go minimum (4 Go recommandés pour de gros domaines)
- **Processeur** : 2 cœurs minimum
- **Disque dur** : 32 Go minimum (50 Go recommandés)
- **Carte réseau** : virtio (pour de meilleures performances)
- **Boot** : UEFI avec Secure Boot désactivé

### 2.2.2 Installation de Debian

Installer Debian 12 (Bookworm) avec la configuration suivante :

**Comptes utilisateur** :
- Compte `root` avec mot de passe sécurisé
- Compte `installer` (utilisé par Ansible)
- Installer `sudo` et autoriser `installer` à lancer les commandes `sudo` sans mot de passe

**Partitionnement LVM** :
```console
/dev/sda1    512M    /boot/efi    (FAT32)
/dev/sda2    reste   LVM Physical Volume
  ├── vg0/root    15G    /         (ext4)
  ├── vg0/var     8G     /var      (ext4)
  ├── vg0/tmp     2G     /tmp      (ext4)
  └── vg0/swap    2G     swap
```

**Paquets à installer** :
- OpenSSH Server
- Utilitaires système de base (`vim`, `curl`, `wget`, `htop`, `sudo`)
- **NE PAS** installer d'environnement graphique

**Configuration réseau** :
- Adresse IP statique **obligatoire**
- Configuration DNS pointant vers les contrôleurs existants

> **NB** : Il est préférable d'utiliser le template SRV01
{.is-info}


### 2.2.3 Installer Debian depuis template

Se connecter sur le Proxmox, faire un click droit sur le template SRV01

Choisir 'Clone'

![cloner.png](/aipice/ssi/migration/cloner.png)
![cloner.png](images/cloner.png)

Puis, Choisir un ID >300, un nom 'DC01' et choisir clone complet

![cloner02.png](/aipice/ssi/migration/cloner02.png)
![cloner02.png](images/cloner02.png)

Sur le clone créé, aller dans 'Hardware' -> 'Add' -> Cloud init drive

![cloudinit-01.png](/aipice/ssi/migration/cloudinit-01.png)
![cloudinit-01.png](images/cloudinit-01.png)

Choisir 'Cloud-Init', puis positionner :
- **User**: installer
- **Password**: `<pwd>` a retenir
- **DNS Domain**: aipice.local - fdqn du domaine
- **DNS servers**: `<dns windows>`
- **Upgrade packages**: 'No' sera effectué par Ansible
- **IP Config**: définir l'ip fixe

![cloudinit-02.png](/aipice/ssi/migration/cloudinit-02.png)
![cloudinit-02.png](images/cloudinit-02.png)

Aller sur 'Console', puis démarrer la VM.

> **NB** : A la fin du démarrage, retirer le disque cloud-init et vérifier que l'adresse est statique


### 2.2.4 Configuration de l'accès SSH depuis le bastion

Depuis le bastion (poste disposant des scripts Ansible), configurer l'accès SSH sans mot de passe :

```console
# Générer une clé SSH si pas déjà fait
$ ssh-keygen -t ed25519 -C "ansible-automation"

# Copier la clé sur le serveur cible
$ ssh-copy-id <IP_SERVEUR_CIBLE>

# Tester la connexion
$ ssh <IP_SERVEUR_CIBLE> 'sudo -l'
Entrées Defaults correspondant pour installer sur DC01 :
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, use_pty

L'utilisateur installer peut utiliser les commandes suivantes sur DC01 :
    (ALL : ALL) ALL
    (ALL) NOPASSWD: ALL

```

## 2.3 Export des données Active Directory

### 2.3.1 Pré-requis pour l'export

**Sur le contrôleur de domaine Windows** :
- Se connecter avec un compte **Administrateur du domaine**
- Copier le fichier `exportDomain.ps1` sur le serveur
- Vérifier que PowerShell peut exécuter des scripts non signés :
  ```powershell
  Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
  ```

### 2.3.2 Procédure d'export

**Ouvrir une session PowerShell en tant qu'Administrateur** et exécuter :

```powershell
# Lancer l'export (peut prendre plusieurs minutes selon la taille du domaine)
.\exportDomain.ps1

# Vérifier les fichiers générés
ls *.csv
```

**Fichiers générés** :
- `ad_export_complete.json` : Données complètes du domaine
- `users_with_sids.csv` : Utilisateurs et leurs attributs
- `groups_export.json` : Groupes et appartenance
- `computers_export.json` : Comptes d'ordinateur

### 2.3.3 Transfert des données vers le serveur Linux Samba

Transférer les fichiers .csv vers le serveur, ou créer un partage.

```powershell
# Depuis le contrôleur Windows (avec WinSCP, scp, ou partage réseau)
# Exemple avec scp si OpenSSH est installé :
scp *.csv installer@<BASTION_IP>:/tmp/migration/
```

## 2.4 Installation et configuration de Samba4

### 2.4.1 Préparation des variables Ansible

**Créer le fichier d'inventaire** (`inventory.yml`) à partir de inventory.sample:

Et renseigner les différents champs.

> **NB**: Le DomainSid sera lu de l'extraction réalisée depuis `ad_export_complete.json`, **conserver le même sid et nom de domaine**
{.is-warning}

```yaml
---
# Ansible Inventory for Samba4 DC Installation
all:
  children:
    samba_servers:
      hosts:
        dc01:
          ansible_host: <IP_SERVER>
          ansible_user: installer
          ansible_ssh_private_key_file: ~/.ssh/id_ed25519
          # Server configuration
          target_hostname: <dc01>
          # Samba4 configuration
          samba_realm: <domain.tld>
          samba_domain: <DOMAIN>
          samba_netbios_name: <DC01>
          samba_admin_password: <AdminPassword>
          samba_domain_sid: <DomainSid>
          dns_servers:
            - 127.0.0.1
            - 8.8.8.8
          # NFS configuration
          nfs_server: <BackupNfsServer>
          nfs_share: <BackupNfsPath>
          nfs_mount_point: /backup
          backup_dir: /backup/samba
```

### 2.4.2 Exécution de l'installation

Tester si le serveur est accessible : 
```console
ansible -m ping dc01
[DEPRECATION WARNING]: DEFAULT_GATHER_TIMEOUT option, the module_defaults keyword is a more generic version and can apply to all calls to the M(ansible.builtin.gather_facts) or M(ansible.builtin.setup) actions, use
module_defaults instead. This feature will be removed from ansible-core in version 2.18. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

PLAY [Ansible Ad-Hoc] ******************************************************************************************************************************************************************************************************

TASK [ping] ****************************************************************************************************************************************************************************************************************
ok: [dc01]

PLAY RECAP *****************************************************************************************************************************************************************************************************************
dc01                       : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

```

Si c'est bon, faire :

```console
cd Ansible
ansible-playbook install-samba4.yml
```

**Le playbook effectue automatiquement** :
1. ✅ Vérification des pré-requis système
2. ✅ Installation des paquets Samba4
3. ✅ Configuration du contrôleur de domaine
4. ✅ Configuration du serveur DNS
5. ✅ Configuration des sauvegardes NFS

> **NB**: A ce stade, vous diposez d'un domaine avec le même Sid que le serveur Windows.
{.is-info}

### 2.4.3 Arrêt serveur Samba

Pour éviter toute interférence, couper temporairement le serveur Samba
```console 
systemctl stop samba
```

### 2.4.4 Création des comptes utilisateurs

- Créer un répertoire pour accueillir les données de transfert

  ```console
  mkdir -p /data/migration
  ```
- Copier les scripts `create_samba_users.sh`,`create_samba_groups.sh`,`create_samba_computers.sh` sur le serveur Linux Samba, depuis le serveur 'bastion'
  ```console
  scp *.sh dc01:/data/migration/
  ```

- Vérifier que les exports en .csv soient également sur ce serveur.

> **NB**: Compte tenu de la taille du domaine et du nombre d'utilisateurs, j'ai choisi de ne pas réintégrer les utilisateurs aux groupes ni de recréer les `ou`. 
{.is-info}

> **NB**: Editer les fichiers .csv pour retirer les comptes inutiles. 
{.is-warning}

Sur le serveur Linux Samba

- Préparer le fichier `Transfert\users.csv`, il doit être conforme à l'exemple suivant : 
  ```csv
  UGIVEN,LOGIN,OBJECTSID,UNAME
  Serge,admin-sn,S-1-5-21-xxxxxxx-xxxxxxxxxx-xxxxxxxxx,NOEL admin
  ```

- Remplacer le mot de passe par défaut dans le script `create_samba_users.sh`

- Lancer le script 
  ```console
  ./create_samba_users.sh
  ```

### 2.4.5 Création des groupes
  
```console  
 ldbmodify -H /var/lib/samba/private/sam.ldb --controls="local_oid:1.3.6.1.4.1.7165.4.3.12:0" group.ldif
```
 
### 2.4.6 Création des comptes d'ordinateurs
  
```console  
 ldbmodify -H /var/lib/samba/private/sam.ldb --controls="local_oid:1.3.6.1.4.1.7165.4.3.12:0" computer.ldif
```  

**Avant de continuer** :
- ✅ Vérifier que tous les utilisateurs sont importés
     ```console
     samba-tool user list
     samba-tool computer list
     samba-tool group list
     ```

- ✅ Tester l'authentification 
- ✅ Vérifier la résolution DNS
- ✅ Configurer les stratégies de groupe essentielles

### 2.4.7 Reconnecter les systèmes et applications

#### **Réinitialisation des comptes machines**

Après la migration, certains systèmes peuvent perdre leur relation de confiance avec le domaine. Ceci est particulièrement fréquent pour :

- **TrueNAS/FreeNAS**
- **Serveurs Linux joints au domaine**
- **Appliances réseau**
- **Systèmes de virtualisation**

#### **TrueNAS - Réinitialisation du compte machine**

**Méthode 1 : Via l'interface Web TrueNAS**

1. Se connecter à l'interface web TrueNAS
2. Aller dans **Directory Services** → **Active Directory**
3. **Désactiver** temporairement Active Directory
4. **Réactiver** Active Directory avec les nouveaux paramètres :
   - **Domain Name** : `aipice.local`
   - **Domain Controller** : `<IP_SAMBA4_DC>`
   - **Username** : Compte administrateur du domaine
   - **Password** : Nouveau mot de passe
5. **Apply** et vérifier la reconnexion

**Méthode 2 : Via SSH sur TrueNAS**

```bash
# Se connecter en SSH sur TrueNAS
ssh root@<TRUENAS_IP>

# Vérifier l'état actuel du domaine
net ads testjoin

# Si échec, quitter le domaine
net ads leave -U Administrator

# Rejoindre le nouveau domaine Samba4
net ads join -U Administrator

# Vérifier la nouvelle relation
net ads testjoin

# Redémarrer les services
service samba_server restart
service activedirectory restart
```

**Méthode 3 : Réinitialisation manuelle du compte machine**

Sur le serveur Samba4 :

```bash
# Lister les comptes machines existants
samba-tool computer list | grep -i truenas

# Supprimer l'ancien compte machine (si nécessaire)
samba-tool computer delete TRUENAS$

# Ou réinitialiser le mot de passe du compte machine
samba-tool computer setpassword TRUENAS$ --newpassword="MotDePasseComplexe123!"

# Vérifier que le compte existe et est actif
samba-tool computer show TRUENAS$
```

#### **Systèmes Linux joints au domaine**

Pour les serveurs Linux utilisant `realmd`, `sssd` ou `winbind` :

```bash
# Vérifier l'état de la jonction
realm list

# Si problème, quitter et rejoindre
sudo realm leave
sudo realm join aipice.local -U Administrator

# Pour les systèmes avec winbind
sudo net ads leave -U Administrator
sudo net ads join -U Administrator

# Redémarrer les services d'authentification
sudo systemctl restart sssd
# ou
sudo systemctl restart winbind
```

#### **Applications nécessitant une reconfiguration**

**Wiki (si authentification AD)**

```bash
# Mettre à jour la configuration du wiki
# Modifier les paramètres LDAP/AD dans le fichier de configuration
# Exemple pour DokuWiki :
vim /var/www/wiki/conf/local.php

# Modifier les paramètres :
$conf['auth']['ad']['server'] = 'dc01.aipice.local';
$conf['auth']['ad']['domain'] = 'aipice.local';
```

**Gitea (si authentification LDAP/AD)**

```bash
# Se connecter à l'interface d'administration Gitea
# Aller dans Site Administration > Authentication Sources
# Modifier la source d'authentification LDAP :
# - Host : dc01.aipice.local
# - Port : 389 (ou 636 pour LDAPS)
# - Bind DN : CN=Administrator,CN=Users,DC=aipice,DC=local
# - User Search Base : CN=Users,DC=aipice,DC=local
```

#### **Vérification post-migration**

**Tests de connectivité TrueNAS**
```bash
# Depuis TrueNAS, tester la résolution DNS
nslookup dc01.aipice.local

# Tester l'authentification
net ads info

# Lister les utilisateurs du domaine
wbinfo -u

# Tester l'authentification d'un utilisateur
wbinfo -a utilisateur%motdepasse
```

**Tests d'accès aux partages**
```bash
# Depuis un poste Windows, tester l'accès aux partages TrueNAS
net use Z: \\truenas.aipice.local\partage /user:aipice.local\utilisateur

# Vérifier les permissions sur les dossiers partagés
```

#### **Dépannage des comptes machines**

**Problème : "Trust relationship failed"**
```bash
# Sur le serveur Samba4, vérifier le compte machine
samba-tool computer show NOMACHINE$

# Si le compte n'existe pas, le recréer
samba-tool computer create NOMACHINE$ --description="Compte machine pour NOMACHINE"

# Forcer la synchronisation des mots de passe
samba-tool domain passwordsettings show
```

**Problème : TrueNAS ne peut pas joindre le domaine**
```bash
# Vérifier la résolution DNS depuis TrueNAS
dig dc01.aipice.local

# Vérifier la connectivité réseau
telnet dc01.aipice.local 389
telnet dc01.aipice.local 636

# Vérifier l'heure système (important pour Kerberos)
ntpdate dc01.aipice.local
```

**Applications à reconfigurer après migration** :
- [ ] **TrueNAS** : Rejoint au domaine et partages accessibles
- [ ] **Wiki** : Authentification LDAP/AD fonctionnelle
- [ ] **Gitea** : Authentification et synchronisation des utilisateurs
- [ ] **Autres applications** utilisant l'authentification AD

## 2.5 Migration des postes de travail

### 2.5.1 Déconnexion d'Azure AD (cas particulier)

> **IMPORTANT** : Si vos postes Windows sont connectés à Azure AD (Azure Active Directory/Entra ID), il faut d'abord les déconnecter avant de pouvoir les joindre au domaine Samba4 local.
{.is-warning}

#### **Identification des postes Azure AD**

**Vérifier si le poste est connecté à Azure AD** :
```powershell
# Ouvrir PowerShell en tant qu'administrateur
dsregcmd /status

# Chercher ces lignes dans la sortie :
# AzureAdJoined : YES
# DomainJoined : NO
# WorkplaceJoined : NO
```

**Ou via l'interface graphique** :
1. **Paramètres Windows** → **Comptes** → **Accès professionnel ou scolaire**
2. Si vous voyez une connexion à votre organisation (ex: "Connecté à [Nom de l'organisation]")

#### **Méthode 1 : Déconnexion avec connexion Internet**

Si le poste a encore accès Internet :
```powershell
# Via PowerShell (en tant qu'administrateur)
Remove-AzureADJoinedDevice

# Ou via l'interface graphique :
# Paramètres > Comptes > Accès professionnel ou scolaire > 
# Cliquer sur la connexion > Se déconnecter
```

#### **Méthode 2 : Déconnexion SANS connexion Internet (Hors ligne)**

**Cette méthode est nécessaire quand le poste n'a plus accès à Internet ou qu'Azure AD n'est plus accessible.**

**Étape 1 : Créer un compte administrateur local**
```powershell
# Ouvrir PowerShell en tant qu'administrateur
# Créer un compte administrateur local de secours
net user admin-local "MotDePasseComplexe123!" /add
net localgroup administrators admin-local /add

# Activer le compte administrateur intégré (si nécessaire)
net user Administrator /active:yes
net user Administrator "MotDePasseComplexe123!"
```

**Étape 2 : Déconnexion forcée d'Azure AD**
```powershell
# Méthode 1 : Commande dsregcmd (Windows 10/11)
dsregcmd /leave

# Si la commande échoue (pas de connexion Internet), utiliser la méthode registre
```

**Étape 3 : Nettoyage manuel via le registre**
```powershell
# Ouvrir l'éditeur de registre
regedit

# Naviguer vers ces clés et les supprimer si elles existent :
# HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ
# HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WorkplaceJoin

# Supprimer également :
# HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments\*
# (Supprimer tous les sous-dossiers dans Enrollments)
```

**Étape 4 : Nettoyage des certificats Azure AD**
```powershell
# Ouvrir la console des certificats
certlm.msc

# Aller dans : Certificats (ordinateur local) > Personnel > Certificats
# Supprimer tous les certificats contenant "MS-Organization-Access" ou Azure AD
# Aller dans : Certificats (ordinateur local) > Autorités de certification racines de confiance
# Supprimer les certificats Azure AD si présents
```

**Étape 5 : Suppression des tâches planifiées Azure AD**
```powershell
# Ouvrir le planificateur de tâches
taskschd.msc

# Aller dans : Bibliothèque du Planificateur de tâches > Microsoft > Windows
# Supprimer les dossiers/tâches suivants :
# - Workplace Join
# - EnterpriseMgmt
# - User Account Control
```

**Étape 6 : Nettoyer les profils utilisateurs Azure AD**
```powershell
# Lister les profils utilisateurs
Get-WmiObject -Class Win32_UserProfile | Where-Object {$_.LocalPath -like "*AzureAD*"}

# Supprimer les profils Azure AD (ATTENTION : sauvegarder les données importantes)
# Les profils Azure AD ont généralement des noms comme :
# C:\Users\AzureAD_nomutilisateur
```

**Étape 7 : Redémarrage et vérification**
```powershell
# Redémarrer le poste
shutdown /r /t 0

# Après redémarrage, vérifier la déconnexion
dsregcmd /status

# Vous devriez voir :
# AzureAdJoined : NO
# DomainJoined : NO
# WorkplaceJoined : NO
```

#### **Méthode 3 : Script automatisé pour déconnexion hors ligne**

**Créer un script PowerShell** `disconnect-azure-offline.ps1` :
```powershell
# Script de déconnexion Azure AD hors ligne
# À exécuter en tant qu'administrateur

Write-Host "=== Déconnexion Azure AD hors ligne ===" -ForegroundColor Yellow

# Vérifier les privilèges administrateur
if (-NOT ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")) {
    Write-Error "Ce script doit être exécuté en tant qu'administrateur"
    exit 1
}

# Étape 1 : Tentative de déconnexion standard
Write-Host "Tentative de déconnexion Azure AD..." -ForegroundColor Cyan
try {
    dsregcmd /leave
    Write-Host "Déconnexion Azure AD réussie" -ForegroundColor Green
} catch {
    Write-Host "Déconnexion standard échouée, passage au nettoyage manuel" -ForegroundColor Yellow
    
    # Étape 2 : Nettoyage du registre
    Write-Host "Nettoyage du registre..." -ForegroundColor Cyan
    
    $registryPaths = @(
        "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ",
        "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WorkplaceJoin",
        "HKLM:\SOFTWARE\Microsoft\Enrollments"
    )
    
    foreach ($path in $registryPaths) {
        if (Test-Path $path) {
            Remove-Item -Path $path -Recurse -Force -ErrorAction SilentlyContinue
            Write-Host "Supprimé: $path" -ForegroundColor Green
        }
    }
    
    # Étape 3 : Suppression des tâches planifiées
    Write-Host "Suppression des tâches planifiées Azure AD..." -ForegroundColor Cyan
    
    $taskPaths = @(
        "\Microsoft\Windows\Workplace Join",
        "\Microsoft\Windows\EnterpriseMgmt"
    )
    
    foreach ($taskPath in $taskPaths) {
        try {
            Unregister-ScheduledTask -TaskPath $taskPath -Confirm:$false -ErrorAction SilentlyContinue
            Write-Host "Tâche supprimée: $taskPath" -ForegroundColor Green
        } catch {
            Write-Host "Tâche non trouvée: $taskPath" -ForegroundColor Yellow
        }
    }
}

# Étape 4 : Vérification finale
Write-Host "Vérification de la déconnexion..." -ForegroundColor Cyan
$status = dsregcmd /status
if ($status -match "AzureAdJoined\s*:\s*NO") {
    Write-Host "SUCCÈS : Le poste est déconnecté d'Azure AD" -ForegroundColor Green
} else {
    Write-Host "ATTENTION : Vérification manuelle nécessaire" -ForegroundColor Red
}

Write-Host "Redémarrage recommandé avant de joindre le domaine local" -ForegroundColor Yellow
```

#### **Cas particuliers et dépannage**

**Poste Azure AD Hybrid (joint à la fois Azure AD et domaine local)**
```powershell
# Vérifier l'état hybride
dsregcmd /status
# Si DomainJoined : YES et AzureAdJoined : YES

# Option 1 : Garder la jointure domaine local, supprimer seulement Azure AD
dsregcmd /leave

# Option 2 : Tout supprimer et recommencer
Remove-Computer -UnjoinDomainCredential (Get-Credential) -WorkgroupName "WORKGROUP" -Force
```

**Erreurs fréquentes**
- **"Access denied"** → Vérifier les droits administrateur
- **"Device not found"** → Le poste était déjà déconnecté
- **"Network error"** → Normal en mode hors ligne, continuer avec le nettoyage manuel

**Après déconnexion d'Azure AD** :
1. ✅ **Redémarrer** le poste obligatoirement
2. ✅ **Vérifier** avec `dsregcmd /status`
3. ✅ **Créer/vérifier** un compte administrateur local
4. ✅ **Procéder** à la jointure au domaine Samba4

### 2.5.2 Préparation des postes avant migration

> **IMPORTANT** Cette procédure préserve les profils utilisateurs grâce à la conservation des ObjectSID identiques.
{.is-success}

#### **Principe de conservation des profils**

Windows associe les profils utilisateurs aux **SID** (Security Identifiers), pas aux noms de domaine. Puisque votre migration Samba4 **conserve les mêmes ObjectSID**, les profils utilisateurs seront **automatiquement retrouvés** après reconnexion.

**Exemple** :
- **Avant migration** : `ANCIEN_DOMAINE\s.noel` (SID: `S-1-5-21-xxx-1106`)
- **Après migration** : `NOUVEAU_DOMAINE\s.noel` (SID: `S-1-5-21-xxx-1106`) 
- **Profil** : `C:\Users\s.noel` → **Conservé automatiquement** ✅

#### **Option A : Retrait temporaire du domaine (Recommandé)**

**Avant la migration** sur chaque poste Windows :

```powershell
# Ouvrir PowerShell en tant qu'administrateur
# Retirer le poste du domaine et le mettre en groupe de travail
Remove-Computer -WorkgroupName "WORKGROUP" -Force -Restart
```

**Ou via l'interface graphique** :
1. **Panneau de configuration** → **Système** → **Paramètres système avancés**
2. **Nom de l'ordinateur** → **Modifier**
3. Sélectionner **Groupe de travail** → Entrer "**WORKGROUP**"
4. **Redémarrer** le poste

#### **Option B : Test et réparation de la relation de confiance**

Si le poste doit rester dans le domaine pendant la migration :

```powershell
# Tester la relation de confiance
Test-ComputerSecureChannel

# Si le test échoue, tenter une réparation
Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

# Si la réparation échoue, utiliser l'Option A
```

#### **Documentation des postes avant migration**

```powershell
# Script pour documenter les postes et leurs profils
Get-ComputerInfo | Select-Object WindowsProductName, TotalPhysicalMemory, CsProcessors, CsDomain, CsWorkgroup | Export-Csv -Path "inventory_postes.csv"

# Lister les profils utilisateurs existants
Get-WmiObject -Class Win32_UserProfile | Where-Object {!$_.Special} | Select-Object LocalPath, SID, LastUseTime | Export-Csv -Path "profils_utilisateurs.csv"
```

### 2.5.3 Reconnexion après migration

#### **Pour les postes retirés du domaine (Option A)**

**Rejoindre le nouveau domaine Samba4** :
```powershell
# Via PowerShell
Add-Computer -DomainName "aipice.local" -Credential (Get-Credential) -Restart

# Ou via interface graphique :
# Panneau de configuration > Système > Paramètres système avancés > 
# Nom de l'ordinateur > Modifier > Domaine > "aipice.local"
```

#### **Pour les postes restés dans le domaine (Option B)**

Sur le poste de travail, ouvrir une session PowerShell en tant qu'administrateur :

```powershell
# Méthode 1 : Reset simple
Reset-ComputerMachinePassword -Credential (Get-Credential) -Server <DC01_IP>

# Méthode 2 : Si échec, forcer la resynchronisation
Test-ComputerSecureChannel -Repair -Server <DC01_IP> -Credential (Get-Credential)

# Méthode 3 : Si les méthodes précédentes échouent
# Retirer et rejoindre le domaine
Remove-Computer -UnjoinDomainCredential (Get-Credential) -WorkgroupName "TEMP" -Force -Restart
# Puis après redémarrage :
Add-Computer -DomainName "aipice.local" -Credential (Get-Credential) -Restart
```

#### **Vérification de la conservation des profils**

Après reconnexion au domaine :

```powershell
# Vérifier la relation de confiance
Test-ComputerSecureChannel

# Vérifier les informations du domaine
Get-ComputerInfo | Select-Object CsDomain, CsDomainRole

# Vérifier que les profils sont toujours associés
Get-WmiObject -Class Win32_UserProfile | Where-Object {!$_.Special} | Select-Object LocalPath, SID

# Test de connexion utilisateur
# Se connecter avec un compte migré et vérifier que le profil est intact
```

### 2.5.4 Résolution des mots de passe utilisateur

Lors de la migration, il n'est pas possible de récupérer les mots de passe utilisateurs, un mot de passe par défaut a été attribué, avec une politique de changement lors de la première connexion.

**Première connexion après migration** :
1. Se connecter avec le **compte utilisateur** habituel
2. Utiliser le **mot de passe par défaut** défini dans les scripts
3. Windows demandera de **changer le mot de passe** 
4. Le **profil utilisateur sera intact** (bureau, documents, paramètres)

> **IMPORTANT** L'intérêt de cette démarche est que la session utilisateur reste identique ! Les SID étant conservés, Windows retrouve automatiquement le profil existant.
{.is-success}

**Tests à effectuer sur les postes migrés** :
- [ ] Connexion utilisateur avec nouveau mot de passe
- [ ] Vérification de l'intégrité du profil (bureau, documents, favoris)
- [ ] Accès aux ressources partagées
- [ ] Synchronisation de l'heure (NTP)
- [ ] Fonctionnement des stratégies de groupe

## 2.6. Vérification finale de la migration

### 2.6.1. Contrôles sur les postes de travail
```bash
# Vérification du domaine actuel
echo $USERDOMAIN
wmic computersystem get domain

# Test de connectivité AD
nltest /dclist:NOUVEAU_DOMAINE
nslookup DC.NOUVEAU_DOMAINE.LOCAL

# Vérification des stratégies de groupe
gpresult /r
```

### 2.6.2. Contrôles sur le serveur Samba4
```bash
# Vérification des objets migrés
samba-tool user list | wc -l
samba-tool group list | wc -l  
samba-tool computer list | wc -l

# Test d'authentification
samba-tool user show utilisateur_test
samba-tool user authenticate utilisateur_test

# Vérification DNS
samba-tool dns query localhost zone_dns @ ALL
```

### 2.6.3. Tests fonctionnels
- [ ] **Authentification** : Connexion utilisateur sur tous les postes
- [ ] **Profils utilisateurs** : Intégrité des données personnelles
- [ ] **Partages réseau** : Accès aux dossiers partagés
- [ ] **Imprimantes** : Configuration et impression
- [ ] **Stratégies de groupe** : Application des GPO
- [ ] **Services réseau** : DNS, DHCP, NTP
- [ ] **Applications métier** : Fonctionnement après migration

> **Important** : Effectuer ces tests sur un échantillon représentatif d'utilisateurs et de postes avant de déclarer la migration complète.
{.is-warning}

# 3 Migration DNS

## 3.1 Export DNS

Le script `exportDns.ps1` sert à extraire les entrées DNS du controleur de domaine en vue de leur intégration sous Samba
Sur le serveur Windows 

```powershell
# Exécuter en tant qu'administrateur sur le serveur DNS
.\exportDns.ps1
```

### 3.1.1 Fichiers générés
Windows (dans C:\temp\dns-export) :
- dns_export_complete.json - Export complet
- dns_zones.csv - Liste des zones
- dns_records_*.csv - Enregistrements par zone
- bind-zones/db.* - Fichiers de zone BIND
- import_dns_samba.sh - Script d'import auto-généré

### 3.1.2 Transfert des fichiers

```console
# Copier les fichiers depuis Windows
scp -r /c/temp/dns-export/ user@samba-server:/data/apps/Migration/
```

Fonctionnalités :

✅ Export complet de toutes les zones DNS
✅ Export des enregistrements (A, AAAA, CNAME, MX, NS, SRV, TXT, etc.)
✅ Classification automatique (zones directes/inverses, primaires/secondaires)
✅ Multiple formats : JSON, CSV, BIND
✅ Génération automatique du script d'import Samba
✅ Statistiques détaillées

## 3.2 Import DNS

importDns.sh (Linux Bash)

Sur le serveur Samba : 

```console
# Installer jq si nécessaire
sudo apt install jq

# Test d'abord (recommandé)
./importDns.sh --dry-run --verbose

# Import réel
./importDns.sh --server localhost --admin-user Administrator

# Avec options avancées
./importDns.sh --server dc01.aipice.local --admin-user Administrator --verbose
```

Fonctionnalités :

✅ Import automatique vers Samba4 DNS
✅ Support dry-run pour tester sans modification
✅ Gestion intelligente des enregistrements système
✅ Création automatique des zones
✅ Statistiques d'import
✅ Validation et gestion d'erreurs
🔧 Utilisation :

# 4 Poste de test

Pour travailler sur ce projet, un poste de test a été utilisé. C'est une version allégée de Windows 11.

## 4.1 RSAT

Installer les outils d'administration du domaine, ouvrir une session Powershell en tant qu'administrateur, puis taper :


```powershell
Add-WindowsCapability -Online -Name "Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0"
```

Lancer Utilisateurs et ordinateurs Active Directory, et vérifier que vos accès fonctionnent.

```powershell
dsa.msc
```


# 5 Dépannage et résolution de problèmes

## 5.1 Problèmes courants

**1. Erreur de résolution DNS**
```bash
# Vérifier la configuration DNS sur le DC Samba4
samba-tool dns query localhost $(hostname -d) NS @
systemctl restart bind9

# Sur les postes clients, vérifier la configuration DNS
nslookup $(hostname -d)
```

**2. Problèmes d'authentification**
```bash
# Vérifier les logs Samba
tail -f /var/log/samba/log.samba
journalctl -u samba-ad-dc -f

# Tester l'authentification manuelle
samba-tool user auth nom_utilisateur --password=motdepasse
```

**3. Synchronisation des mots de passe**
```bash
# Réinitialiser le mot de passe d'un utilisateur
samba-tool user setpassword nom_utilisateur --newpassword=nouveau_motdepasse

# Forcer la synchronisation des stratégies
samba-tool gpo reload
```

**4. Problèmes de comptes machines (TrueNAS, serveurs Linux)**
```bash
# Vérifier l'état du compte machine sur Samba4
samba-tool computer show NOMACHINE$

# Réinitialiser le mot de passe d'un compte machine
samba-tool computer setpassword NOMACHINE$ --random-password

# Ou avec un mot de passe spécifique
samba-tool computer setpassword NOMACHINE$ --newpassword="MotDePasseComplexe123!"

# Lister tous les comptes machines
samba-tool computer list

# Supprimer un compte machine corrompu
samba-tool computer delete NOMACHINE$

# Recréer un compte machine
samba-tool computer create NOMACHINE$ --description="Machine rejointe au domaine"
```

**5. TrueNAS - Dépannage spécifique**
```bash
# Sur TrueNAS, vérifier la jointure au domaine
net ads testjoin

# Afficher les informations du domaine
net ads info

# Quitter et rejoindre le domaine
net ads leave -U Administrator
net ads join -U Administrator

# Tester l'authentification des utilisateurs
wbinfo -u                    # Lister les utilisateurs du domaine
wbinfo -g                    # Lister les groupes du domaine
wbinfo -a utilisateur%motdepasse  # Tester l'auth d'un utilisateur

# Redémarrer les services sur TrueNAS
service samba_server restart
service activedirectory restart
```

**6. Erreurs de synchronisation d'heure (Kerberos)**
```bash
# Vérifier l'heure sur le serveur Samba4
date

# Synchroniser l'heure avec un serveur NTP
ntpdate -s time.nist.gov

# Configurer la synchronisation permanente
timedatectl set-ntp true

# Sur les clients, vérifier la synchronisation
w32tm /query /status
w32tm /resync
```

**7. Problèmes de virtualisation (Proxmox/QEMU)**

```bash
# Erreur qemu-guest-agent.service dependency
# Vérifier l'état du service
systemctl status qemu-guest-agent.service

# Vérifier les dépendances
systemctl list-dependencies qemu-guest-agent.service

# Solution 1 : Réinstaller qemu-guest-agent
sudo apt update
sudo apt remove qemu-guest-agent
sudo apt install qemu-guest-agent

# Solution 2 : Vérifier la présence du device virtio-serial
ls -la /dev/virtio-ports/
# Doit contenir : org.qemu.guest_agent.0

# Solution 3 : Configuration VM Proxmox (ÉTAPES OBLIGATOIRES)
# ÉTAPE 1 : Dans Proxmox : VM > Options > QEMU Guest Agent > Activé
# ÉTAPE 2 : VM > Hardware > Add > Serial Port > 
#           - Serial Port : serial0
#           - Type : virtio-serial-pci
# ÉTAPE 3 : Redémarrer la VM pour activer le périphérique série
# ÉTAPE 4 : Vérifier que le bon périphérique est créé dans la VM

# Solution 4 : Configuration du service qemu-guest-agent

# IMPORTANT : Après configuration Proxmox, vérifier le périphérique disponible
ls -la /dev/virtio-ports/
# org.qemu.guest_agent.0 DOIT exister

# Configuration standard (périphérique org.qemu.guest_agent.0)
cat > /etc/systemd/system/qemu-guest-agent.service << 'EOF'
[Unit]
Description=QEMU Guest Agent
After=multi-user.target

[Service]
ExecStart=/usr/sbin/qemu-ga -m virtio-serial -p /dev/virtio-ports/org.qemu.guest_agent.0 -d
Restart=always
RestartSec=10
Type=forking

[Install]
WantedBy=multi-user.target
EOF


# Étapes finales pour TOUTES les configurations
# Arrêter tous les processus qemu-ga existants
pkill qemu-ga

# Recharger la configuration systemd
systemctl daemon-reload

# Activer et démarrer le service
systemctl enable qemu-guest-agent
systemctl restart qemu-guest-agent

# Solution 5 : Démarrage manuel si nécessaire
sudo systemctl enable qemu-guest-agent
sudo systemctl start qemu-guest-agent

# Solution 5 : Si le périphérique virtio-serial manque
# Arrêter la VM, ajouter le périphérique série dans Proxmox, redémarrer

# Vérification finale - TOUTES LES MÉTHODES
systemctl is-active qemu-guest-agent
systemctl is-enabled qemu-guest-agent
systemctl status qemu-guest-agent --no-pager

# Le service doit afficher :
# Active: active (running)
# Loaded: loaded (/etc/systemd/system/qemu-guest-agent.service; enabled)

# Test de communication avec l'hyperviseur
sudo qemu-ga --version

# Vérification de la communication Proxmox-VM
# Les logs doivent montrer des messages comme :
# "guest-ping called" - confirme la communication Proxmox → VM
systemctl status qemu-guest-agent --no-pager | grep "guest-ping"

# Test depuis l'interface Proxmox
# Dans l'interface Proxmox : VM > Summary
# - L'agent doit apparaître comme "running" avec version affichée
# - L'adresse IP doit être visible dans la section "IPs"
# - Les boutons Shutdown/Reboot fonctionnent proprement
```

**8. Problèmes réseau après clonage VM**

```bash
# Régénérer les IDs réseau après clonage
sudo rm /etc/machine-id
sudo systemd-machine-id-setup

# Régénérer les configurations réseau
sudo rm /etc/systemd/network/70-*
sudo systemctl restart systemd-networkd

# Nettoyer les règles udev réseau
sudo rm /etc/udev/rules.d/70-persistent-net.rules
sudo udevadm control --reload-rules
sudo udevadm trigger
```

### 5.1.1 Sauvegarde et restauration d'urgence

**Sauvegarde manuelle avant migration** :
```bash
# Utiliser le script automatisé
/usr/local/bin/samba-backup.sh

# Ou sauvegarde manuelle complète
systemctl stop samba-ad-dc
rsync -av /var/lib/samba/ /mnt/backup/samba-$(date +%Y%m%d)/
rsync -av /etc/samba/ /mnt/backup/samba-config-$(date +%Y%m%d)/
systemctl start samba-ad-dc
```

**Restauration d'urgence** :
```bash
# Utiliser le script de restauration automatisé
/usr/local/bin/samba-restore.sh

# Sélectionner la sauvegarde à restaurer dans le menu interactif
```

## 5.2 Checklist de validation finale

### 5.2.1 Avant la bascule en production
- [ ] ✅ Export AD Windows Server réussi
- [ ] ✅ Installation Samba4 terminée sans erreur
- [ ] ✅ Import des données vérifié (utilisateurs, groupes, ordinateurs)
- [ ] ✅ Tests d'authentification réussis
- [ ] ✅ Résolution DNS fonctionnelle
- [ ] ✅ Sauvegarde automatique configurée et testée
- [ ] ✅ Plan de restauration validé
- [ ] ✅ Tests sur poste pilote réussis

### 5.2.2 Après la bascule
- [ ] ✅ Tous les postes rejoignent le nouveau domaine
- [ ] ✅ Authentification utilisateur fonctionnelle
- [ ] ✅ Stratégies de groupe appliquées
- [ ] ✅ Accès aux ressources réseau préservé
- [ ] ✅ Monitoring et alertes configurés
- [ ] ✅ Documentation mise à jour
- [ ] ✅ Formation des administrateurs

# 6 Gestion des credentials Git après migration

## 6.1 Problème des mots de passe Git

Après la migration du domaine Active Directory vers Samba4, les mots de passe des utilisateurs changent (mot de passe par défaut défini dans les scripts de migration). Ceci affecte également l'accès aux repositories Git qui utilisent l'authentification du domaine.

**Symptômes** :
- `git push` échoue avec erreur d'authentification
- `git pull` demande à nouveau les credentials
- Erreur 401 ou 403 lors des opérations Git

## 6.2 Méthodes de mise à jour des credentials

### 6.2.1 Méthode 1 : Suppression et ressaisie des credentials

**Pour credential.helper=store (fichier ~/.git-credentials)** :
```bash
# Voir la configuration actuelle
git config --list | grep credential

# Supprimer le fichier de credentials stockés
rm ~/.git-credentials

# Ou éditer le fichier pour modifier seulement le mot de passe
vim ~/.git-credentials
# Format : https://username:password@serveur.com

# Lors du prochain push/pull, Git redemandera les credentials
git push origin main
```

**Pour credential.helper=cache** :
```bash
# Vider le cache des credentials
git credential-cache exit

# Les prochaines opérations Git demanderont les nouveaux credentials
git push origin main
```

### 6.2.2 Méthode 2 : Mise à jour directe du fichier credentials

```bash
# Localiser le fichier de credentials
ls -la ~/.git-credentials

# Éditer le fichier (format : https://username:password@serveur.com)
nano ~/.git-credentials

# Exemple de contenu à modifier :
# AVANT : https://s.noel:ancien_motdepasse@gitea.aipice.local
# APRÈS : https://s.noel:nouveau_motdepasse@gitea.aipice.local

# Sauvegarder et tester
git push origin main
```

### 6.2.3 Méthode 3 : Configuration des credentials par repository

```bash
# Pour un repository spécifique, configurer l'URL avec credentials
git remote set-url origin https://username:nouveau_password@gitea.aipice.local/AIPICE/Migration.git

# Ou utiliser la commande interactive
git config credential.helper store
git push origin main
# Git demandera les nouveaux credentials
```

### 6.2.4 Méthode 4 : Utilisation de tokens d'accès (Recommandé)

**Sur Gitea/GitLab/GitHub** :
1. Se connecter à l'interface web avec le nouveau mot de passe
2. Aller dans **Paramètres** → **Tokens d'accès** ou **Access Tokens**
3. Créer un nouveau token avec les permissions nécessaires
4. Utiliser le token comme mot de passe

```bash
# Configurer Git pour utiliser le token
git remote set-url origin https://username:TOKEN@gitea.aipice.local/AIPICE/Migration.git

# Ou stocker le token dans les credentials
echo "https://username:TOKEN@gitea.aipice.local" > ~/.git-credentials
```

## 6.3 Gestion globale des credentials

### 6.3.1 Configuration du gestionnaire de credentials

```bash
# Voir la configuration actuelle
git config --global credential.helper

# Configurer le stockage des credentials (plusieurs options) :

# Option 1 : Stockage en fichier (permanent, moins sécurisé)
git config --global credential.helper store

# Option 2 : Cache temporaire (sécurisé, expire)
git config --global credential.helper cache
git config --global credential.helper 'cache --timeout=3600'  # 1 heure

# Option 3 : Gestionnaire système (Linux)
git config --global credential.helper 'store --file=/path/to/secure/location'
```

### 6.3.2 Mise à jour en masse pour plusieurs repositories

**Script pour mettre à jour tous les repositories locaux** :
```bash
#!/bin/bash
# update-git-credentials.sh - Mise à jour des credentials Git en masse

OLD_PASSWORD="ancien_motdepasse"
NEW_PASSWORD="nouveau_motdepasse"
USERNAME="s.noel"
SERVER="gitea.aipice.local"

# Fonction pour mettre à jour un repository
update_repo_credentials() {
    local repo_path="$1"
    
    echo "Mise à jour des credentials pour : $repo_path"
    
    cd "$repo_path" || return 1
    
    # Récupérer l'URL actuelle
    current_url=$(git remote get-url origin)
    
    # Vérifier si l'URL contient nos credentials
    if [[ "$current_url" == *"$SERVER"* ]]; then
        # Construire la nouvelle URL avec le nouveau mot de passe
        new_url="https://$USERNAME:$NEW_PASSWORD@$SERVER$(echo "$current_url" | sed "s|https://[^@]*@$SERVER||; s|https://$SERVER||")"
        
        # Mettre à jour l'URL remote
        git remote set-url origin "$new_url"
        
        echo "✅ Credentials mis à jour pour $repo_path"
        
        # Tester la connexion
        if git ls-remote origin &>/dev/null; then
            echo "✅ Test de connexion réussi"
        else
            echo "❌ Test de connexion échoué"
        fi
    else
        echo "⏭️  Repository ignoré (serveur différent)"
    fi
    
    echo ""
}

# Chercher tous les repositories Git dans le répertoire de l'utilisateur
find "$HOME" -name ".git" -type d 2>/dev/null | while read -r git_dir; do
    repo_path=$(dirname "$git_dir")
    update_repo_credentials "$repo_path"
done

echo "Mise à jour terminée !"
```

## 6.4 Sécurisation des credentials

### 6.4.1 Bonnes pratiques

```bash
# Sécuriser le fichier de credentials
chmod 600 ~/.git-credentials

# Éviter de stocker les credentials dans l'historique
echo "*.git-credentials" >> ~/.gitignore_global
git config --global core.excludesfile ~/.gitignore_global

# Utiliser des tokens au lieu de mots de passe
# Les tokens peuvent être révoqués facilement
```

### 6.4.2 Vérification et dépannage

```bash
# Vérifier la configuration Git
git config --list | grep -E "(credential|user|remote)"

# Tester l'authentification
git ls-remote origin

# Voir les credentials stockés (attention : contient les mots de passe)
cat ~/.git-credentials

# Débugger les problèmes d'authentification
GIT_CURL_VERBOSE=1 git push origin main

# Vérifier les logs Git
git config --global credential.helper 'cache --timeout=300'
```

## 6.5 Automatisation post-migration

**Script à exécuter après changement des mots de passe utilisateurs** :
```bash
#!/bin/bash
# post-migration-git-update.sh

echo "=== Mise à jour des credentials Git post-migration ==="

# Supprimer l'ancien cache de credentials
git credential-cache exit 2>/dev/null
rm -f ~/.git-credentials

echo "Anciens credentials supprimés"
echo "Lors de votre prochain git push/pull, entrez vos nouveaux credentials"
echo ""
echo "Rappel du nouveau mot de passe par défaut : [MOT_DE_PASSE_DEFAUT]"
echo "Vous devrez le changer lors de votre première connexion au domaine"
```

---

**Durée totale estimée** : 4-8 heures selon la taille du domaine  
**Fenêtre de maintenance recommandée** : Weekend ou heures creuses  
**Rollback possible** : Oui, via restauration de sauvegarde (< 30 minutes)