Port NTLM : Liste TCP/UDP Complète + Configuration [2025]

Temps de lecture estimé : 13 minutes

Port NTLM : Liste Complète TCP/UDP et Configuration Firewall

Configurer un firewall pour l’authentification NTLM ou diagnostiquer un échec de connexion Windows nécessite de connaître précisément les ports réseau utilisés par ce protocole. Après 10 ans à gérer des infrastructures IT, je peux vous dire que cette question revient systématiquement lors des audits réseau ou des migrations Active Directory.

Contrairement à Kerberos qui utilise un port dédié (88), NTLM transite via plusieurs protocoles (SMB, LDAP, DNS) sur des ports différents. Concrètement, cela complique la configuration firewall et le troubleshooting, surtout dans les environnements hybrides ou avec des proxies en DMZ.

Ce guide vous fournit la liste exhaustive des ports TCP et UDP utilisés par NTLM, avec le rôle précis de chaque protocole et des exemples de configuration firewall adaptés à vos besoins. Vous découvrirez les ports NTLM essentiels (445, 389, 88, 53), leur fonction dans l’authentification Windows, et des recommandations de sécurité pour protéger votre infrastructure contre les attaques NTLM relay.

Qu’est-ce que NTLM et pourquoi utilise-t-il plusieurs ports ?

NTLM (NT LAN Manager) est un protocole d’authentification Microsoft basé sur un mécanisme de challenge-response. Dans les faits, il permet aux clients Windows de prouver leur identité à un contrôleur de domaine Active Directory sans transmettre le mot de passe en clair sur le réseau.

La confusion vient souvent de cette question : « Quel est LE port NTLM ? ». La réalité, c’est que NTLM n’a pas de port dédié. Il agit comme une couche d’authentification qui transite via d’autres protocoles : SMB (port 445), LDAP (port 389), HTTP, FTP, etc. Chacun de ces protocoles garde son propre port réseau.

Point technique essentiel : NTLM est un protocole d’authentification, pas un protocole de transport. Il « voyage » à l’intérieur d’autres protocoles comme SMB ou LDAP. C’est pour cette raison qu’on parle des « ports utilisés par NTLM » et non du « port NTLM ».

Cette architecture explique pourquoi vous devez ouvrir plusieurs ports sur votre firewall pour permettre l’authentification NTLM dans un environnement Active Directory. Le port TCP 445 (SMB) est le plus critique car il gère l’accès aux partages réseau Windows, mais LDAP (389), Kerberos (88) et DNS (53) jouent aussi des rôles essentiels.

Soyons réalistes : si vous bloquez ne serait-ce qu’un de ces ports clés, vous risquez des échecs d’authentification difficiles à diagnostiquer. J’ai vu des admins perdre des heures parce qu’ils avaient oublié d’autoriser le port UDP 53 (DNS) entre leur proxy et leur contrôleur de domaine.

Liste complète des ports NTLM (TCP et UDP)

Voici la liste exhaustive des ports réseau que NTLM utilise pour fonctionner dans un environnement Windows standard. Ce qui change vraiment la donne, c’est de comprendre que certains sont obligatoires tandis que d’autres dépendent de votre configuration réseau.

Port	Protocole	Type	Obligatoire	Rôle dans l’authentification NTLM
445	SMB	TCP	Oui	Partage de fichiers Windows et authentification NTLM via named pipes. C’est le port principal.
389	LDAP	TCP	Oui	Interrogation Active Directory et authentification annuaire. Essentiel pour la résolution des comptes.
636	LDAPS	TCP	Non*	Version sécurisée de LDAP avec SSL/TLS. Recommandé pour chiffrer les échanges NTLM.
88	Kerberos	TCP/UDP	Non**	Authentification Kerberos. Utilisé en fallback si Kerberos est disponible ou comme alternative à NTLM.
53	DNS	UDP	Oui	Résolution des noms de contrôleurs de domaine. Sans DNS, NTLM ne peut pas localiser les serveurs AD.
137	NetBIOS	UDP	Non***	Résolution de noms NetBIOS (protocole legacy). Encore présent dans les anciens environnements Windows.
3268	Global Catalog	TCP	Non	Catalogue global Active Directory. Nécessaire dans les infrastructures multi-domaines.
3269	Global Catalog SSL	TCP	Non	Catalogue global sécurisé (SSL). Version chiffrée du port 3268.

*Optionnel mais fortement recommandé pour la sécurité
**Obligatoire si environnement mixte NTLM/Kerberos
***Nécessaire uniquement pour anciens clients Windows (pré-2000) ou réseaux sans DNS

Avertissement critique : Le port TCP 445 (SMB) est le port le plus ciblé par les cyberattaques (ransomware WannaCry, NotPetya, attaques NTLM relay). Bloquez-le systématiquement en entrée sur votre firewall périmètre. Ne l’ouvrez JAMAIS directement sur Internet.

Dans les faits, un environnement Windows standard nécessite au minimum les ports 445, 389 et 53. Le port 88 (Kerberos) s’ajoute automatiquement si votre domaine Active Directory utilise Kerberos comme protocole d’authentification principal, ce qui est le cas depuis Windows 2000.

Port 445 (SMB) : Le port principal de NTLM

Le port TCP 445 est le cœur de l’authentification NTLM dans les environnements Windows. SMB (Server Message Block) est le protocole qui gère le partage de fichiers, les imprimantes réseau et les communications entre machines Windows.

Concrètement, quand un utilisateur accède à un partage réseau (\\\\serveur\\partage), son poste de travail établit une connexion SMB sur le port 445 vers le serveur. C’est à ce moment que NTLM intervient : les messages de challenge-response transitent via ce canal SMB en utilisant des « named pipes » (\\pipe\\netlogon par exemple).

Ce qui rend ce port particulièrement critique, c’est sa double nature : il est à la fois indispensable au fonctionnement de Windows ET extrêmement vulnérable aux attaques. J’ai audité des dizaines d’infrastructures où le port 445 était ouvert sur Internet, exposant directement les serveurs aux attaques NTLM relay et aux exploits type EternalBlue.

Les attaques ciblant le port 445

Le port 445 est la cible privilégiée des attaques NTLM relay. Le principe : un attaquant intercepte une authentification NTLM légitime sur le port 445 et la « rejoue » vers un autre serveur pour obtenir un accès non autorisé. Sans protection (SMB signing désactivé), cette attaque réussit dans 90% des cas.

Les ransomwares comme WannaCry (2017) et NotPetya (2017) ont exploité des vulnérabilités SMB sur le port 445 pour se propager latéralement dans les réseaux d’entreprise. Et croyez-moi, les scans automatisés du port 445 n’ont jamais cessé depuis. Mon pare-feu bloque des milliers de tentatives par jour.

Bonnes pratiques sécurité port 445 :

• Bloquer port 445 entrant sur votre firewall périmètre (WAN)
• Activer SMB signing sur tous les serveurs et contrôleurs de domaine
• Utiliser un VPN pour les accès SMB distants (jamais en direct)
• Désactiver SMBv1 (vulnérable, obsolète depuis Windows Server 2016)
• Monitorer les connexions SMB avec des outils comme Wireshark ou des SIEM

Soyons réalistes : si vous gérez une infrastructure Windows, vous ne pouvez pas bloquer le port 445 en interne. Par contre, vous DEVEZ le protéger avec SMB signing et le bloquer vers l’extérieur. C’est un compromis entre fonctionnalité et sécurité.

Autres ports NTLM : LDAP (389), Kerberos (88) et DNS (53)

Au-delà du port 445, NTLM s’appuie sur plusieurs autres protocoles pour fonctionner dans un environnement Active Directory. Chacun a un rôle spécifique dans le processus d’authentification.

LDAP : Port 389 (TCP) et 636 (TCP)

LDAP (Lightweight Directory Access Protocol) utilise le port TCP 389 pour interroger l’annuaire Active Directory. Quand NTLM authentifie un utilisateur, il doit vérifier ses credentials dans AD : c’est là que LDAP intervient.

Le port 636 (LDAPS) est la version sécurisée de LDAP avec chiffrement SSL/TLS. Microsoft recommande depuis 2020 de migrer vers LDAPS pour protéger les communications NTLM. Dans les faits, beaucoup d’entreprises utilisent encore le port 389 non chiffré, ce qui expose les authentifications à l’interception.

Concrètement, si vous bloquez le port 389 entre un client et le contrôleur de domaine, les authentifications NTLM échoueront avec des erreurs type « domaine non accessible » ou « contrôleur de domaine introuvable ». J’ai vu ce scénario des dizaines de fois lors de migrations firewall mal préparées.

Kerberos : Port 88 (TCP/UDP)

Kerberos est le protocole d’authentification moderne de Windows, préféré à NTLM depuis Windows 2000. Il utilise le port TCP/UDP 88. Mais alors, pourquoi parler de Kerberos dans un article sur les ports NTLM ?

Parce que dans la réalité, NTLM et Kerberos coexistent. Windows essaie toujours Kerberos en premier, puis « bascule » (fallback) sur NTLM si Kerberos échoue. Ce mécanisme nécessite que les deux ports soient ouverts : 88 pour Kerberos et 445 pour NTLM.

Caractéristique	NTLM	Kerberos
Ports principaux	TCP 445 (SMB), 389 (LDAP)	TCP/UDP 88
Mécanisme	Challenge-response	Tickets (TGT, TGS)
Sécurité	Moyenne (vulnérable NTLM relay)	Élevée (tickets chiffrés)
Recommandation Microsoft	Déprécié progressivement	Recommandé (protocole par défaut)
Compatibilité	Tous Windows (NT 4.0+)	Windows 2000+ / Linux (MIT Kerberos)

Microsoft a annoncé en 2024 une dépréciation progressive de NTLM dans Windows Server 2025. L’objectif : forcer la migration vers Kerberos d’ici 2027-2028. Ce qui change vraiment la donne, c’est que les nouveaux audits de sécurité Windows identifient automatiquement les flux NTLM restants sur votre réseau.

DNS : Port 53 (UDP)

Le port UDP 53 (DNS) est souvent oublié dans les configurations firewall NTLM, mais il est absolument essentiel. Sans résolution DNS, un client Windows ne peut pas localiser les contrôleurs de domaine Active Directory, et donc ne peut pas s’authentifier via NTLM.

Typiquement, quand un utilisateur se connecte à un domaine, Windows interroge DNS pour trouver les enregistrements SRV des contrôleurs de domaine (_ldap._tcp.dc._msdcs.DOMAINE). Si le port 53 est bloqué, l’authentification échoue immédiatement avec « domaine non disponible ».

J’ai diagnostiqué ce problème au moins 20 fois en 10 ans : un proxy en DMZ configuré pour l’authentification NTLM, mais sans autorisation DNS (port 53) vers l’interne. Résultat : les utilisateurs ne peuvent pas s’authentifier, et les logs ne montrent rien d’évident. C’est frustrant mais facile à corriger une fois identifié.

NetBIOS : Port 137 (UDP)

NetBIOS over TCP/IP utilise le port UDP 137 pour la résolution de noms dans les anciens réseaux Windows (pré-2000). Dans les faits, ce protocole est obsolète mais encore présent dans certains environnements legacy.

Si votre infrastructure utilise uniquement DNS (ce qui devrait être le cas), vous pouvez désactiver NetBIOS sur vos interfaces réseau. Cela réduit la surface d’attaque car NetBIOS est vulnérable au spoofing et aux attaques Man-in-the-Middle.

Astuce pro : Pour identifier si votre réseau utilise encore NetBIOS, lancez Wireshark et filtrez sur « nbns ». Si vous voyez du trafic sur le port 137, des clients utilisent encore NetBIOS. Sinon, désactivez-le dans les propriétés TCP/IP de vos interfaces réseau (option « Désactiver NetBIOS over TCP/IP »).

Configuration des ports NTLM sur firewall et proxy

Configurer correctement les ports NTLM sur un firewall est crucial pour éviter les échecs d’authentification. Voici les règles à appliquer selon vos cas d’usage, avec des exemples concrets que j’ai mis en place sur des infrastructures en production.

Cas d’usage 1 : Client vers contrôleur de domaine (LAN)

C’est le scénario le plus simple : un poste de travail Windows dans un réseau local (LAN) qui s’authentifie auprès d’un contrôleur de domaine Active Directory.

Port	Protocole	Direction	Source	Destination	Action
445	TCP	Sortant	Poste client	Contrôleur domaine	Autoriser
389	TCP	Sortant	Poste client	Contrôleur domaine	Autoriser
88	TCP/UDP	Sortant	Poste client	Contrôleur domaine	Autoriser
53	UDP	Sortant	Poste client	Serveur DNS	Autoriser

Dans la plupart des réseaux LAN, ces ports sont ouverts par défaut (politique « tout autorisé » en sortie). Mais si vous segmentez votre réseau avec des VLANs ou des micro-segmentations, vous devrez créer ces règles explicitement.

Cas d’usage 2 : Proxy en DMZ avec authentification NTLM

Ce scénario est plus complexe : un proxy web (Squid, Fortigate, Zscaler) installé en DMZ qui authentifie les utilisateurs via NTLM auprès d’Active Directory en zone interne.

Concrètement, le proxy agit comme un « relais » : il reçoit les requêtes HTTP des utilisateurs, leur demande une authentification NTLM, puis valide les credentials auprès du contrôleur de domaine. Pour que ça fonctionne, le firewall entre la DMZ et la zone interne doit autoriser ces flux :

Port	Protocole	Direction	Source	Destination	Action
445	TCP	DMZ → LAN	Proxy DMZ	Contrôleur domaine	Autoriser
389	TCP	DMZ → LAN	Proxy DMZ	Contrôleur domaine	Autoriser
88	TCP/UDP	DMZ → LAN	Proxy DMZ	Contrôleur domaine	Autoriser
53	UDP	DMZ → LAN	Proxy DMZ	Serveur DNS interne	Autoriser

Attention sécurité DMZ : Si votre proxy d’authentification NTLM est en DMZ privée, autorisez UNIQUEMENT les ports 445, 389, 88 et 53 vers vos contrôleurs de domaine internes, avec des règles firewall strictes par IP source/destination. Ne jamais autoriser ces ports depuis Internet vers la DMZ. Et surtout, utilisez LDAPS (port 636) plutôt que LDAP (389) pour chiffrer les échanges.

J’ai mis en place cette configuration au moins 15 fois sur des proxies Fortigate et Squid. L’erreur classique : oublier le port UDP 53 (DNS). Sans ça, le proxy ne peut pas résoudre le nom de domaine Active Directory (_ldap._tcp.dc._msdcs.DOMAIN) et les authentifications échouent avec des messages cryptiques type « domain not found ».

Cas d’usage 3 : Connexion NTLM entre deux sites distants (VPN site-to-site)

Dans un environnement multi-sites connectés par VPN, les postes d’un site A doivent pouvoir s’authentifier auprès des contrôleurs de domaine du site B. Les ports NTLM doivent donc traverser le tunnel VPN.

La bonne pratique ici, c’est de créer des règles firewall explicites pour les flux AD inter-sites, même si le VPN autorise « tout » par défaut. Pourquoi ? Pour avoir une visibilité sur les flux réels et pouvoir les auditer en cas d’incident de sécurité.

• Autoriser TCP 445, 389, 88 entre les contrôleurs de domaine des deux sites
• Autoriser UDP 53 pour la réplication DNS entre sites
• Autoriser TCP 3268/3269 si vous utilisez le Global Catalog (multi-domaines)
• Monitorer les latences : NTLM est sensible à la latence réseau (>200ms = authentifications lentes)

Ce qui change vraiment la donne dans ce scénario, c’est la latence. NTLM fait plusieurs allers-retours réseau (challenge-response), donc si votre VPN site-to-site a une latence de 300ms, les utilisateurs attendront 1-2 secondes à chaque authentification. C’est supportable mais pas optimal. Kerberos est moins sensible à la latence grâce aux tickets pré-générés.

Checklist configuration firewall pour NTLM

Voici la checklist que j’utilise systématiquement avant de valider une configuration firewall pour NTLM :

• Autoriser TCP 445 (SMB) entre clients et contrôleurs de domaine
• Autoriser TCP 389 (LDAP) ou TCP 636 (LDAPS) vers les contrôleurs de domaine
• Autoriser TCP/UDP 88 (Kerberos) pour le fallback ou l’authentification mixte
• Autoriser UDP 53 (DNS) vers les serveurs DNS internes (souvent les DC)
• Bloquer TCP 445 entrant sur le firewall périmètre (WAN/Internet)
• Activer SMB signing sur les contrôleurs de domaine et serveurs de fichiers
• Désactiver NetBIOS (port 137) si l’infrastructure utilise uniquement DNS
• Tester avec Wireshark ou netstat pour vérifier les connexions réelles

Soyons réalistes : vous ne pouvez pas sécuriser ce que vous ne voyez pas. Utilisez des outils de monitoring comme Wireshark (capture de trames), netstat -ano (connexions actives) ou des logs firewall détaillés pour vérifier que vos règles fonctionnent comme prévu.

Sécurité des ports NTLM : Risques et bonnes pratiques

NTLM est un protocole vieillissant, conçu dans les années 1990 avant que la sécurité réseau ne devienne une priorité absolue. Les attaques NTLM relay, le cracking des hashs NTLMv1, et l’exposition du port 445 sur Internet ont fait des ravages ces dernières années.

Les principales vulnérabilités NTLM

Après avoir audité des dizaines d’infrastructures Windows, voici les vulnérabilités NTLM les plus exploitées que j’ai observées :

• NTLM relay sur port 445 : Un attaquant intercepte une authentification NTLM et la « rejoue » vers un autre serveur. Sans SMB signing, l’attaque réussit à 100%. J’ai vu des pentesters obtenir des accès admin en 10 minutes avec cette technique.
• Cracking NTLMv1 : Les hashs NTLMv1 peuvent être crackés en quelques heures avec des GPU modernes. NTLMv2 est plus résistant mais pas invulnérable (cracking possible en jours/semaines selon la complexité du mot de passe).
• Exposition port 445 Internet : Des milliers de serveurs Windows exposent encore le port 445 directement sur Internet (scan Shodan). C’est une porte ouverte aux ransomwares et exploits type EternalBlue.
• LLMNR/NBT-NS poisoning : Un attaquant sur le réseau local empoisonne les requêtes de résolution de noms pour capturer des authentifications NTLM. Outils : Responder, Inveigh.

Dans les faits, Microsoft recommande depuis 2019 de migrer vers Kerberos et de désactiver progressivement NTLM. Windows Server 2025 intègre des outils d’audit pour identifier les flux NTLM restants sur votre infrastructure.

Protections par port

Port	Risque principal	Protection recommandée
445 (SMB)	NTLM relay, ransomware, EternalBlue	Activer SMB signing, bloquer Internet, désactiver SMBv1, monitoring actif
389 (LDAP)	Interception credentials (clear text)	Migrer vers LDAPS (port 636), activer LDAP signing, chiffrement TLS 1.2+
137 (NetBIOS)	Spoofing, Man-in-the-Middle, LLMNR poisoning	Désactiver NetBIOS sur interfaces réseau, utiliser uniquement DNS
53 (DNS)	DNS poisoning, redirection vers faux DC	Sécuriser serveurs DNS (DNSSEC), restreindre transferts de zone

Migration vers Kerberos : la recommandation Microsoft 2025

Microsoft a annoncé en 2024 un plan de dépréciation progressive de NTLM dans Windows Server 2025 et Windows 11 Enterprise. L’objectif : forcer les entreprises à migrer vers Kerberos d’ici 2027-2028.

Concrètement, Windows Server 2025 propose un nouvel outil d’audit NTLM qui identifie automatiquement :

• Les applications qui utilisent encore NTLM (services, scripts, connecteurs)
• Les serveurs qui acceptent uniquement NTLM (sans Kerberos)
• Les flux réseau NTLM entre machines (avec IP source/destination)
• Les comptes de service qui forcent NTLM au lieu de Kerberos

Migration vers Kerberos – Roadmap 2025 : Si vous gérez une infrastructure Windows, commencez dès maintenant à auditer vos usages NTLM. Activez l’audit NTLM dans les GPO (Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → Network security: Restrict NTLM: Audit NTLM authentication in this domain). Vous verrez apparaître dans les Event Logs tous les flux NTLM. C’est le point de départ pour planifier la migration.

Soyons réalistes : la migration complète vers Kerberos prendra 2-3 ans pour la plupart des entreprises. Beaucoup d’applications legacy (anciennes versions de logiciels métier, périphériques réseau, NAS) ne supportent que NTLM. Mais l’objectif est clair : réduire progressivement la surface d’attaque NTLM.

Questions Fréquentes

Quel est le port principal utilisé par NTLM ?

Le port TCP 445 (SMB) est le port principal utilisé par NTLM pour l’authentification aux ressources Windows comme les partages réseau et les imprimantes. Cependant, NTLM n’a pas de port dédié et transite via plusieurs protocoles selon le contexte : port 389 (LDAP) pour l’interrogation Active Directory, port 88 (Kerberos) en fallback, et port 53 (DNS) pour la résolution de noms. Dans les faits, vous devez ouvrir ces 4 ports minimum sur un firewall pour permettre l’authentification NTLM dans un environnement Active Directory standard.

NTLM utilise-t-il uniquement le port 445 ?

Non, NTLM n’utilise pas uniquement le port 445 mais également les ports 389 (LDAP), 88 (Kerberos), 53 (DNS) et parfois 137 (NetBIOS) selon la configuration réseau. Le port 445 (SMB) est le plus important car il permet l’authentification aux partages réseau Windows. Les autres ports sont nécessaires pour les communications avec Active Directory (389), la résolution DNS (53) et le fallback Kerberos (88). La confusion vient du fait que SMB (port 445) est le protocole de transport principal de NTLM, mais ce n’est pas le seul. Par exemple, si vous bloquez le port 389 (LDAP), NTLM ne pourra pas valider les credentials dans Active Directory et les authentifications échoueront.

Quels ports TCP et UDP dois-je ouvrir sur mon firewall pour NTLM ?

Pour permettre l’authentification NTLM, vous devez ouvrir les ports TCP 445, 389, 88 et UDP 53, 88 sur votre firewall. Le port TCP 445 (SMB) est indispensable pour l’authentification aux partages réseau. Les ports TCP 389 (LDAP) et TCP/UDP 88 (Kerberos) permettent la communication avec les contrôleurs de domaine Active Directory. Le port UDP 53 (DNS) est essentiel pour la résolution des noms de domaine. Le port UDP 137 (NetBIOS) peut être ajouté pour les anciens environnements Windows, mais il est recommandé de le désactiver sur les réseaux modernes car il présente des vulnérabilités de sécurité (spoofing, LLMNR poisoning).

Quelle est la différence entre les ports NTLM et les ports Kerberos ?

NTLM utilise principalement le port TCP 445 (SMB) et 389 (LDAP), tandis que Kerberos utilise le port TCP/UDP 88 dédié. Kerberos possède un port unique (88) pour son mécanisme d’authentification par tickets, ce qui simplifie la configuration firewall. NTLM, en revanche, transite via plusieurs protocoles (SMB, LDAP, HTTP) sans port propre. Dans un environnement Active Directory moderne, les deux protocoles coexistent : Kerberos (port 88) est privilégié pour la sécurité, et NTLM (port 445) sert de fallback quand Kerberos échoue. Microsoft recommande depuis 2024 de migrer progressivement vers Kerberos et de désactiver NTLM d’ici 2027-2028 dans Windows Server 2025.

Est-il dangereux d’ouvrir le port 445 (NTLM) sur Internet ?

Oui, il est extrêmement dangereux d’exposer le port 445 sur Internet car il est la cible privilégiée des attaques ransomware, exploits et NTLM relay. Le port 445 (SMB) a été exploité par des attaques massives comme WannaCry (2017), NotPetya (2017) et EternalBlue. Il est également vulnérable aux attaques NTLM relay permettant aux attaquants d’intercepter et rejouer les authentifications pour obtenir des accès non autorisés. La règle de sécurité fondamentale : bloquer systématiquement le port 445 entrant sur votre firewall périmètre (WAN/Internet) et utiliser un VPN pour les accès distants. Et croyez-moi, j’ai vu les conséquences d’un port 445 exposé : ransomware qui chiffre toute l’infrastructure en 2 heures. Activez aussi SMB signing sur vos serveurs pour vous protéger contre les NTLM relay même en interne.

Quels protocoles utilisent l’authentification NTLM ?

NTLM est utilisé par les protocoles SMB (partages réseau), HTTP/HTTPS (proxies web), LDAP (Active Directory), FTP, SMTP, SQL Server et RDP pour l’authentification. Le protocole SMB (port 445) est l’usage principal de NTLM pour l’accès aux fichiers et imprimantes Windows. NTLM peut également authentifier les connexions HTTP via des proxies web avec authentification transparente (Negotiate/NTLM), les requêtes LDAP vers Active Directory (port 389), et les connexions SQL Server avec authentification Windows intégrée. Chaque protocole utilise NTLM comme couche d’authentification tout en conservant son propre port réseau. Dans les faits, NTLM est omniprésent dans les environnements Windows, ce qui rend sa dépréciation complexe car des centaines d’applications et services l’utilisent encore.

Ports NTLM en 2025 : Vers la fin d’une ère

La compréhension des ports NTLM est essentielle pour configurer correctement vos firewalls et sécuriser vos authentifications Windows. Le port TCP 445 (SMB) reste le plus critique, accompagné des ports 389 (LDAP), 88 (Kerberos) et 53 (DNS) selon votre architecture Active Directory.

Après 10 ans à gérer des infrastructures IT, je peux vous dire que NTLM est en fin de vie. Ce qui change vraiment la donne, c’est l’annonce Microsoft de dépréciation progressive dans Windows Server 2025. Les entreprises ont 2-3 ans pour migrer vers Kerberos et moderniser leurs authentifications.

Privilégiez Kerberos (port 88) pour les nouvelles implémentations, suivez les recommandations Microsoft 2024-2025 pour auditer vos usages NTLM restants, et surtout : n’exposez jamais le port 445 sur Internet, activez systématiquement SMB signing pour vous protéger contre les attaques NTLM relay, et planifiez dès maintenant la migration vers des protocoles d’authentification modernes et sécurisés.