Migration MFA Entra : Revoquer les Sessions Legacy

Guide de migration MFA vers Entra ID avec revocation des sessions legacy pour securiser l'authentification. Les équipes de sécurité et les professionnels du domaine y trouveront des recommandations applicables immediatement. Cet article fournit une analyse technique approfondie des mécanismes d'attaque et des contre-mesures efficaces, basée sur des retours d'expérience terrain et les recommandations des autorités de référence comme l'ANSSI et le MITRE.

Contexte et Enjeux

La sécurité d'Active Directory reste un enjeu majeur pour les entreprises en 2025-2026. Avec la multiplication des attaques avancées, les équipes IT doivent constamment adapter leurs defenses. Les environnements hybrides combinant AD on-premise et Entra ID (anciennement Azure AD) ajoutent une complexite supplementaire.

Pour comprendre les fondamentaux, consultez notre article sur Forest Trust Abuse Attaque Defense. Les techniques d'attaque evoluent rapidement, comme détaillé dans Kerberoasting Attaque Defense.

Notre avis d'expert

Le modèle de Tiering reste la meilleure défense structurelle contre la compromission totale d'un domaine Active Directory. Sans séparation stricte des niveaux de privilèges, un attaquant ayant compromis un poste de travail peut atteindre le contrôleur de domaine en quelques heures.

Votre modèle de Tiering est-il réellement appliqué ou seulement documenté ?

447
PAGES

Guide Gratuit : Sécuriser Active Directory (447 pages)

Attaques, Tiering Model, durcissement, monitoring — par Ayi NEDJIMI

Télécharger le PDF →

Analyse Technique Detaillee

L'approche technique repose sur plusieurs vecteurs d'attaque complementaires. Les pentesters et red teamers utilisent ces techniques pour identifier les failles dans les configurations AD. La comprehension de la chaine d'attaque complete est essentielle pour mettre en place des defenses efficaces.

⚡

Retour terrain

Dans mes missions de hardening Active Directory, le point le plus sous-estimé est la gestion du groupe 'Opérateurs de compte' et des délégations personnalisées créées au fil des années. Pour un groupe logistique de 1 500 utilisateurs, j'ai trouvé 312 ACL personnalisées dont 89 accordaient des permissions d'écriture sur des attributs sensibles (adminCount, memberOf sur groupes privilégiés) à des comptes d'utilisateurs standards. La dette technique en sécurité AD est souvent invisible jusqu'au premier audit sérieux.

Les outils comme BloodHound, Impacket et Rubeus permettent d'automatiser la détection des chemins d'attaque. Selon les recommandations de CERT-FR, la surveillance des événements critiques (Event ID 4769, 4662, 4724) est indispensable. Notre guide Dcsync Attaque Defense détaillé les procedures d'audit.

La complexite des environnements modernes nécessite une approche en couches. Le modele de tiering recommande par Microsoft et l'ANSSI reste la référence pour segmenter les acces privilegies.

Stratégies de Defense et Remediation

La remediation doit etre progressive et priorisee. Commencez par les quick wins : desactiver NTLM ou possible, activer le Protected Users group, configurer le tiering. Ensuite, abordez les chantiers de fond comme la migration vers le passwordless et le renforcement du Conditional Access.

• Étape 1 : Audit complet avec les scripts recommandes — voir As Rep Roasting Attaque Defense
• Étape 2 : Remediation des configurations critiques
• Étape 3 : Mise en place du monitoring continu
• Étape 4 : Tests de penetration reguliers

Cas concret

La vulnérabilité PrintNightmare (CVE-2021-34527) a exposé la fragilité du service Print Spooler de Windows, permettant l'exécution de code à distance avec des privilèges SYSTEM. Son exploitation triviale a contraint des milliers d'organisations à désactiver en urgence le service d'impression sur leurs contrôleurs de domaine.

Plusieurs outils gratuits facilitent l'audit et le durcissement d'Active Directory. PingCastle, Purple Knight et ADRecon fournissent des rapports detailles. Les références de NVD completent ces outils avec des bonnes pratiques validees. Pour approfondir, consultez Golden Ticket Attaque Defense.

Questions frequentes

Comment securiser un environnement Active Directory ?

La sécurisation d'Active Directory repose sur plusieurs piliers : l'implementation du modele de tiering, la restriction des privileges administratifs, la surveillance des événements critiques, le déploiement du Protected Users group, la desactivation des protocoles obsoletes comme NTLM et la mise en place d'audits reguliers.

Qu'est-ce que le modele de tiering Active Directory ?

Le modele de tiering est une architecture de sécurité recommandee par Microsoft et l'ANSSI qui segmente les acces privilegies en trois niveaux : Tier 0 pour les controleurs de domaine, Tier 1 pour les serveurs membres et Tier 2 pour les postes de travail, empechant ainsi la propagation laterale des attaquants.

Pourquoi les attaques Active Directory sont-elles si frequentes ?

Les attaques Active Directory sont frequentes car AD reste le système d'authentification central de la majorite des entreprises. Les configurations par defaut sont souvent permissives, les privileges excessifs repandus et les techniques d'exploitation bien documentees, ce qui en fait une cible privilegiee pour les attaquants.

La mise en pratique de ces concepts nécessite une approche methodique et structuree. Les équipes techniques doivent d'abord evaluer leur niveau de maturite actuel sur le sujet, identifier les lacunes prioritaires et definir un plan d'action realiste. L'implementation progressive, avec des jalons mesurables, garantit une adoption durable et efficace des pratiques recommandees.

Les organisations qui reussissent le mieux dans ce domaine adoptent une culture d'amelioration continue. Cela implique des revues regulieres des processus, une veille technologique active et une formation permanente des équipes. Les indicateurs de performance doivent etre definis des le depart pour mesurer objectivement les progres realises et ajuster la stratégie si necessaire.

L'integration de ces pratiques dans les processus existants de l'organisation est un facteur cle de succes. Plutot que de creer des workflows paralleles, il est recommande d'enrichir les procedures actuelles avec les controles et les verifications necessaires. Cette approche reduit la resistance au changement et facilite l'adoption par les équipes operationnelles.

Recommandations de durcissement

La sécurisation d'un environnement Active Directory passe par une approche méthodique. Le modèle de tiering proposé par Microsoft — avec une séparation stricte des comptes administrateurs Tier 0, Tier 1 et Tier 2 — reste la fondation de toute architecture sécurisée. Pourtant, dans la majorité des audits, on constate que ce modèle n'est que partiellement appliqué.

LAPS (Local Administrator Password Solution) est un autre pilier souvent négligé. Sans LAPS, un seul mot de passe administrateur local compromis peut ouvrir la voie à un mouvement latéral massif. La documentation Microsoft détaille la mise en œuvre, mais l'implémentation sur un parc hétérogène prend du temps et de la planification.

Points de contrôle prioritaires

Les chemins d'attaque les plus courants dans un AD passent par : les délégations Kerberos non contraintes, les comptes de service avec des SPN et des mots de passe faibles (cible du Kerberoasting), les GPO mal configurées qui exposent des credentials, et les ACL permissives sur des objets sensibles comme AdminSDHolder.

BloodHound permet de cartographier ces chemins en quelques minutes. Si vous ne l'avez jamais lancé sur votre environnement de production, la découverte risque d'être instructive. La réalité est souvent plus complexe que ce que les schémas théoriques laissent supposer.

Consultez les recommandations de l'ANSSI et le référentiel MITRE ATT&CK TA0004 (Privilege Escalation) pour structurer votre approche défensive.

Contexte et enjeux actuels

Impact opérationnel

Pour approfondir ce sujet, consultez notre outil open-source kerberos-toolkit qui facilite l'analyse et le test des mécanismes Kerberos.

Les sujets techniques en cybersécurité exigent une approche rigoureuse, fondée sur l'expérimentation et la validation en conditions réelles. Les environnements de laboratoire — qu'ils soient construits avec Proxmox, VMware Workstation ou des services cloud éphémères — sont indispensables pour tester les techniques, les outils et les contre-mesures avant tout déploiement en production.

L'un des écueils les plus fréquents dans la mise en œuvre de solutions techniques de sécurité est le gap entre la documentation officielle et la réalité du terrain. Les guides de déploiement supposent souvent un environnement propre et standardisé, là où la plupart des organisations gèrent un patrimoine applicatif hétérogène, avec des dépendances croisées et des configurations héritées.

Approche méthodique recommandée

Pour chaque implémentation technique, la méthodologie suivante a fait ses preuves : audit de l'existant, définition des prérequis, déploiement en environnement de test, validation fonctionnelle et sécurité, déploiement progressif en production avec rollback plan, puis monitoring post-déploiement. Chaque étape doit être documentée.

Les référentiels MITRE ATT&CK et MITRE D3FEND fournissent un cadre structuré pour aligner les mesures techniques sur les menaces réelles. D3FEND, en particulier, cartographie les contre-mesures défensives face aux techniques d'attaque, ce qui facilite la priorisation des investissements en sécurité.

La documentation interne — runbooks, playbooks, procédures d'exploitation — est le maillon souvent manquant. Sans elle, la connaissance reste dans la tête des experts, et chaque départ ou absence crée un risque opérationnel. Avez-vous documenté vos procédures critiques de manière à ce qu'un nouveau membre de l'équipe puisse les exécuter de manière autonome ?

Sources et références : MITRE ATT&CK Privilege Escalation · ADSecurity.org

Conclusion

La sécurisation d'Active Directory est un processus continu qui nécessite une vigilance constante. Les nouvelles menaces de 2026 renforcent la nécessite d'adopter une approche proactive, combinant audit regulier, monitoring en temps reel et formation des équipes.

Article suivant recommandé

ADCS 2026 : Bilan ESC1 a ESC15 et Remediation en 2026 →

Bilan exhaustif des vulnérabilités AD Certificate Services de ESC1 a ESC15 avec stratégies de remediation completes.

Kerberoasting : Technique d'attaque ciblant les Service Principal Names (SPN) dans Active Directory pour extraire et craquer hors ligne les tickets de service Kerberos.

Les techniques d'attaque Active Directory décrites nécessitent une autorisation écrite préalable. Testez uniquement sur des environnements de lab ou dans le cadre d'un audit mandaté.

Utilisez BloodHound Community Edition pour cartographier les chemins d'attaque Active Directory avant un audit. La visualisation graphique révèle des vecteurs invisibles à l'analyse manuelle.

Votre Active Directory est-il compromis ?

Audit AD complet, détection de chemins d'attaque, durcissement Tier Model — intervention sous 48h.

Audit AD — Devis gratuit [email protected]

Script PowerShell Complet : Révocation de Tokens Entra ID à Grande Échelle

La révocation des sessions actives est une étape critique lors d'une migration MFA ou d'une compromission de compte. Microsoft Graph API expose les endpoints nécessaires, accessibles via PowerShell avec le module Microsoft.Graph. Le script suivant révoque les tokens d'un utilisateur, d'un groupe, ou de l'ensemble du tenant :

# Installation du module Microsoft Graph
Install-Module Microsoft.Graph -Scope CurrentUser

# Connexion avec permissions requises (User.ReadWrite.All, Directory.ReadWrite.All)
Connect-MgGraph -Scopes "User.ReadWrite.All","Directory.ReadWrite.All","Policy.ReadWrite.AuthenticationMethod"

# Révoquer les sessions d'un utilisateur spécifique
$userId = "[email protected]"
Revoke-MgUserSignInSession -UserId $userId
Write-Host "Sessions révoquées pour $userId"

# Révoquer les sessions de tous les membres d'un groupe
$groupId = "12345678-1234-1234-1234-123456789abc"
$members = Get-MgGroupMember -GroupId $groupId -All
foreach ($member in $members) {
    Revoke-MgUserSignInSession -UserId $member.Id
    Write-Host "Sessions révoquées pour $($member.Id)"
    Start-Sleep -Milliseconds 200  # Throttling protection
}

# Révocation tenant-wide (URGENCE - compromission massive)
# Utiliser avec précaution : déconnecte TOUS les utilisateurs
$allUsers = Get-MgUser -All -Filter "accountEnabled eq true"
$allUsers | ForEach-Object -Parallel {
    Import-Module Microsoft.Graph.Users
    Revoke-MgUserSignInSession -UserId $_.Id
} -ThrottleLimit 10

Write-Host "Révocation terminée : $($allUsers.Count) utilisateurs"

Audit Post-Révocation via Graph API

Après révocation, vérifier via les Sign-in Logs qu'aucune session résiduelle n'est active. Les tokens refresh peuvent survivre jusqu'à 90 jours si non révoqués explicitement :

# Vérifier les connexions actives après révocation (attendu : 0 session non-MFA)
$uri = "https://graph.microsoft.com/v1.0/auditLogs/signIns?`$filter=userId eq '$userId' and createdDateTime ge $(Get-Date -Format 'yyyy-MM-ddT00:00:00Z')&`$top=50"
$response = Invoke-MgGraphRequest -Method GET -Uri $uri
$response.value | Select-Object createdDateTime, appDisplayName, clientAppUsed, conditionalAccessStatus, mfaDetail

# Lister les méthodes MFA enregistrées par l'utilisateur
Get-MgUserAuthenticationMethod -UserId $userId

Continuous Access Evaluation (CAE) : Révocation en Temps Réel

Le Continuous Access Evaluation (CAE) est une technologie Microsoft qui permet la révocation des tokens en temps quasi-réel (latence <15 minutes) sans attendre l'expiration naturelle. Sans CAE, les access tokens Entra ID ont une durée de vie de 60-90 minutes et ne peuvent pas être révoqués avant expiration — une fenêtre critique lors d'une compromission.

CAE fonctionne via un protocole d'événements critiques : lorsqu'un administrateur révoque les sessions d'un utilisateur, Entra ID envoie un claim challenge aux applications compatibles CAE (Exchange Online, SharePoint Online, Teams, Azure Resource Manager). L'application valide immédiatement le token auprès d'Entra ID et le rejette si révoqué. Les événements déclencheurs incluent : révocation de session, changement de mot de passe, désactivation de compte, modification de politique d'accès conditionnel, et détection de risque Identity Protection.

# Vérifier si CAE est activé pour le tenant (activé par défaut depuis 2023)
Get-MgPolicyContinuousAccessEvaluationPolicy

# Consulter les événements CAE dans les logs
$uri = "https://graph.microsoft.com/v1.0/auditLogs/signIns?`$filter=conditionalAccessStatus eq 'success' and authenticationRequirement eq 'continuousAccess'"
Invoke-MgGraphRequest -Method GET -Uri $uri

Gestion des Managed Identities Entra ID

Les Managed Identities (MI) permettent aux ressources Azure (VMs, App Services, Functions, AKS pods) de s'authentifier auprès des services Azure sans gérer de secrets. Deux types existent : System-Assigned (liée au cycle de vie de la ressource) et User-Assigned (indépendante, partageable entre ressources). La migration MFA ne s'applique pas aux MI (elles n'utilisent pas de tokens MFA), mais leur gestion sécurisée est critique :

# Lister toutes les User-Assigned Managed Identities du tenant
Get-MgServicePrincipal -Filter "servicePrincipalType eq 'ManagedIdentity'" -All |
  Select-Object DisplayName, AppId, Id |
  Format-Table

# Auditer les permissions accordées à une MI (API permissions)
$miId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $miId |
  Select-Object PrincipalId, ResourceId, AppRoleId

# Vérifier les rôles RBAC Azure assignés à une MI
az role assignment list --assignee $miId --all --output table

# Bonne pratique : MI ne doit pas avoir le rôle Owner ou Contributor au niveau subscription
# Utiliser des rôles custom à moindre privilège

Troubleshooting MFA : Scénarios Courants et Résolutions

Reset MFA pour un Utilisateur Bloqué

Lorsqu'un utilisateur perd accès à sa méthode MFA (téléphone perdu, application supprimée), la procédure de réinitialisation sécurisée est :

# 1. Identifier les méthodes MFA enregistrées
Get-MgUserAuthenticationMethod -UserId "[email protected]"

# 2. Supprimer la méthode MFA compromise (ex: méthode TOTP perdue)
$methodId = "totp-method-id-from-above"
Remove-MgUserAuthenticationMicrosoftAuthenticatorMethod -UserId "[email protected]" -MicrosoftAuthenticatorAuthenticationMethodId $methodId

# 3. Créer un TAP (Temporary Access Pass) pour re-enregistrement sécurisé
$tapBody = @{
    "startDateTime" = (Get-Date -Format "yyyy-MM-ddTHH:mm:ssZ")
    "lifetimeInMinutes" = 60
    "isUsableOnce" = $true
}
New-MgUserAuthenticationTemporaryAccessPassMethod -UserId "[email protected]" -BodyParameter $tapBody

Comptes d'Urgence (Break-Glass Accounts)

Tout tenant Entra ID doit disposer de 2 comptes d'urgence exemptés de MFA pour maintenir l'accès administrateur en cas de défaillance du système MFA. Ces comptes doivent : utiliser un mot de passe complexe de 64+ caractères stocké physiquement (coffre-fort), être exclus des politiques d'accès conditionnel MFA, ne jamais utiliser de téléphone ou app mobile comme facteur (utiliser un token FIDO2 physique conservé séparément), faire l'objet d'alertes Sentinel sur toute utilisation, et être vérifiés trimestriellement (connexion test documentée).

Politiques MFA : Tenant-Wide vs Per-User et Accès Conditionnel

Microsoft recommande l'abandon du MFA per-user (legacy, géré dans l'onglet "Per-user MFA" du portail Azure) au profit des politiques d'Accès Conditionnel (CA) ou des Security Defaults. Comparaison :

• Security Defaults : MFA obligatoire pour tous, pas de personnalisation, gratuit. Adapté aux PME sans Entra ID P1.
• Per-user MFA (legacy) : activation individuelle, pas de contexte (location, device compliance), interactions avec CA problématiques. À migrer vers CA.
• Conditional Access : politiques granulaires basées sur utilisateur, groupe, application, localisation, conformité device, niveau de risque Identity Protection. Nécessite Entra ID P1 (6 €/utilisateur/mois) ou P2 (9 €/utilisateur/mois pour les fonctions de risque adaptatif).

# Créer une politique CA : MFA obligatoire pour tous sauf comptes break-glass
$policy = @{
    "displayName" = "Require MFA for All Users"
    "state" = "enabled"
    "conditions" = @{
        "users" = @{
            "includeUsers" = @("All")
            "excludeGroups" = @("break-glass-group-id")
        }
        "applications" = @{"includeApplications" = @("All")}
    }
    "grantControls" = @{
        "operator" = "OR"
        "builtInControls" = @("mfa")
    }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $policy

Audit de Conformité MFA avec Microsoft Graph API

Un audit complet de la conformité MFA du tenant doit produire : pourcentage d'utilisateurs avec MFA activé, méthodes utilisées (authenticator app, SMS, voice, FIDO2, certificats), utilisateurs sans aucune méthode MFA enregistrée, et connexions récentes sans MFA (indicateur de comptes de service ou legacy auth actifs).

# Rapport complet : utilisateurs sans MFA
$allUsers = Get-MgUser -All -Filter "accountEnabled eq true" -Property Id,DisplayName,UserPrincipalName
$noMFA = @()
foreach ($user in $allUsers) {
    $methods = Get-MgUserAuthenticationMethod -UserId $user.Id
    # Exclure la méthode password (toujours présente)
    $mfaMethods = $methods | Where-Object { $_.AdditionalProperties.'@odata.type' -ne '#microsoft.graph.passwordAuthenticationMethod' }
    if ($mfaMethods.Count -eq 0) {
        $noMFA += $user.UserPrincipalName
    }
}
Write-Host "Utilisateurs sans MFA : $($noMFA.Count) / $($allUsers.Count)"
$noMFA | Export-Csv -Path "no_mfa_report.csv" -NoTypeInformation

Deployment MFA a Grande Echelle : Stratégie de Communication et Change Management

Plan de Communication aux Utilisateurs

La dimension technique du deploiement MFA n'est que la moitié du defi. L'échec des projets MFA est majoritairement imputable a une resistance utilisateur mal anticipée. Un plan de communication efficace se déploie sur 6 semaines avant le basculement obligatoire :

• J-42 (6 semaines avant) : email d'annonce direction, expliquant la motivation (conformité, protection des données), la date d'effet, et les ressources disponibles.
• J-28 : tutoriels vidéo (3-5 min) par profil utilisateur (Windows, Mac, mobile iOS/Android), accessibles depuis l'intranet et envoyés par email.
• J-14 : ouverture de la période d'auto-inscription MFA volontaire avec incitation (ex: accès à des fonctionnalités premium). Cibler 30-40% d'adoption spontanée.
• J-7 : notification individuelle aux utilisateurs non-inscrits avec lien direct vers aka.ms/mfasetup et support helpdesk dédié.
• J-0 : basculement obligatoire. Ligne helpdesk MFA renforcée (x2 agents) pendant 48h. Procedure de déblocage rapide (TAP) en 10 minutes.

SSPR (Self-Service Password Reset) : Complément Naturel du MFA

Le Self-Service Password Reset (SSPR) Entra ID permet aux utilisateurs de réinitialiser leur mot de passe sans contacter le helpdesk, en utilisant leurs méthodes MFA enregistrées comme facteur de vérification. Son activation conjointe avec le MFA réduit les tickets helpdesk de 20-30% selon les retours d'expérience des DSI françaises. Configuration SSPR via PowerShell :

# Activer SSPR pour tous les utilisateurs (nécessite Entra ID P1)
$ssprPolicy = @{
    "selfServicePasswordResetEnabled" = $true
    "policies" = @{
        "numberOfAuthenticationMethodsRequired" = 2
        "allowedAuthenticationMethods" = @("email","mobilephone","officephone","microsoftAuthenticator","securityQuestion")
    }
}
Invoke-MgGraphRequest -Method PATCH   -Uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy"   -Body ($ssprPolicy | ConvertTo-Json -Depth 5)

# Vérifier le nombre de réinitialisations SSPR (indicateur de succès)
$uri = "https://graph.microsoft.com/v1.0/reports/getCredentialUserRegistrationCount"
Invoke-MgGraphRequest -Method GET -Uri $uri

MFA pour les Comptes de Service et Applications Legacy

Les comptes de service (utilisés par des applications, scripts, flux d'intégration) ne peuvent pas utiliser le MFA interactif. La migration MFA doit identifier et traiter ces cas avant le basculement obligatoire. Stratégies recommandées :

• Managed Identities : migrer les applications Azure vers des Managed Identities (elimine tout credential, MFA non applicable)
• Workload Identity Federation : pour les applications hors Azure (GitHub Actions, Jenkins, Kubernetes), federer via OIDC au lieu d'utiliser des secrets de service principal
• Client credentials flow + certificate : pour les applications legacy qui ne peuvent pas utiliser MI, remplacer les secrets partagés (client secret) par des certificats (expiration plus longue, rotation automatisable)
• Exclusion CA ciblée : créer une politique Conditional Access excluant explicitement les comptes de service (groupe "service-accounts-exclus-MFA"), avec monitoring renforcé de ces comptes (alertes sur toute connexion depuis une IP imprévue)

Conformité et Reporting MFA : Exigences Réglementaires

Le MFA est devenu une exigence explicite dans plusieurs référentiels réglementaires applicables en France. NIS 2 (transposée par la loi SREN en 2024) impose le MFA pour les opérateurs essentiels et importants sur les accès aux systèmes d'information. DORA (Digital Operational Resilience Act, applicable janvier 2025) l'impose aux entités financières. La politique ANSSI v2.0 de l'IGS (Infrastructure Globale de Sécurité) rend le MFA obligatoire pour tous les accès d'administration. Générer un rapport de conformité MFA pour les audits réglementaires :

# Rapport de conformité MFA : pourcentage d'adoption par département
$depts = Get-MgUser -All -Property Department,UserPrincipalName,Id |
    Group-Object Department

foreach ($dept in $depts) {
    $total = $dept.Count
    $withMFA = 0
    foreach ($user in $dept.Group) {
        $methods = Get-MgUserAuthenticationMethod -UserId $user.Id
        $mfaMethods = $methods | Where-Object {
            $_.'@odata.type' -ne '#microsoft.graph.passwordAuthenticationMethod'
        }
        if ($mfaMethods.Count -gt 0) { $withMFA++ }
    }
    $pct = [math]::Round($withMFA/$total*100, 1)
    Write-Output "$($dept.Name): $withMFA/$total ($pct%)"
}

# Exporter vers Excel pour le COMEX/RSSI
# (nécessite le module ImportExcel : Install-Module ImportExcel)
$report | Export-Excel -Path "MFA_Compliance_$(Get-Date -Format 'yyyyMMdd').xlsx" -AutoSize