SQL Server Express : configurer l’accès distant sur TCP 1433

Une méthode sous Windows pour aligner l’écoute TCP, le port fixe et les règles du pare-feu.

Pour permettre un accès distant à SQL Server Express sous Windows, vérifiez que TCP/IP est activé pour la bonne instance, configurez un port fixe comme 1433, redémarrez le moteur, puis autorisez ce même port TCP dans le pare-feu pour les postes concernés. Ouvrir 1433 ne suffit pas si l’instance écoute sur un autre port : les instances nommées, dont SQL Server Express, utilisent par défaut des ports dynamiques. [1], [2], [3]

In this article

Comprendre ce qu’il faut réellement configurer
Configurer TCP/IP et le port de la bonne instance
Redémarrer le moteur, puis ouvrir le bon port
Exemple pratique : aligner trois réglages sur 1433
Distinguer TCP 1433 et SQL Server Browser

Comprendre ce qu’il faut réellement configurer

Le protocole et le port sont deux réglages distincts. TCP/IP doit être utilisable par l’instance, et le moteur doit écouter sur le port que vous comptez autoriser. [1]
1433 n’est pas garanti pour Express. C’est le port habituel de l’instance par défaut lorsque TCP est activé ; les instances nommées utilisent normalement des ports dynamiques. [1], [2]
Le pare-feu doit correspondre à l’écoute réelle. Microsoft recommande un port fixe pour simplifier les accès à travers un pare-feu. [2], [3]

Un port dynamique est sélectionné parmi les ports disponibles lorsque le moteur démarre. Son numéro peut changer au redémarrage, mais il ne change pas nécessairement à chaque fois. C’est cette possibilité qui rend une règle entrante figée sur 1433 insuffisante : elle peut autoriser un port sur lequel votre instance n’écoute pas. La solution présentée ici consiste à rendre le numéro prévisible en configurant explicitement un port fixe. Elle concerne le moteur SQL Server sous Windows, avec SQL Server Configuration Manager et le pare-feu Windows. [2], [1], [3]

Configurer TCP/IP et le port de la bonne instance

Ouvrez SQL Server Configuration Manager, développez SQL Server Network Configuration, puis sélectionnez Protocols for <instance name>. Ouvrez les propriétés de TCP/IP. Vérifiez que vous intervenez sur l’instance Express à rendre accessible, et non sur une autre instance installée. L’activation de TCP/IP constitue un préalable à l’écoute TCP ; toutefois, la procédure Microsoft citée détaille surtout l’affectation du port et ne précise pas la manipulation exacte du contrôle d’activation. Il ne faut donc pas considérer le simple fait d’ouvrir ces propriétés comme une activation du protocole. [1]

Dans l’onglet IP Addresses, repérez les sections IP1, IP2, etc., ainsi que IPAll. Elles correspondent notamment aux adresses de la machine ; l’une peut être l’adresse de boucle locale 127.0.0.1. Dans la section applicable, supprimez la valeur 0 de TCP Dynamic Ports si elle est présente, puis saisissez 1433 dans TCP Port. Ces deux champs ne sont pas interchangeables : le premier concerne les ports dynamiques, le second le port d’écoute explicitement choisi. [1]

Avant de modifier une section d’adresse, contrôlez Listen All dans l’onglet Protocol. Lorsque ce réglage vaut Yes, seules les valeurs de TCP Port et TCP Dynamic Ports placées dans IPAll sont utilisées ; les sections IP individuelles sont entièrement ignorées. C’est une distinction décisive : dans cette configuration, renseigner 1433 uniquement dans IP1 ne modifie pas le port effectivement retenu. Utilisez donc IPAll lorsque Listen All vaut Yes, plutôt que de multiplier les modifications dans les sections individuelles. [1]

Redémarrer le moteur, puis ouvrir le bon port

Après validation, redémarrez le moteur SQL Server de l’instance concernée. Le moteur ne commence à écouter sur le nouveau port qu’après ce redémarrage. Ne vous fiez pas uniquement à la valeur désormais affichée dans la configuration : Microsoft précise que SQL Server Browser peut annoncer le nouveau numéro dès la modification, alors que le moteur ne l’utilise pas encore. Le redémarrage évite ce décalage entre le port annoncé et le port réellement utilisé. Le port du moteur figure également dans le journal des erreurs SQL Server, ce qui fournit un point de contrôle. [1], [3]

Configurez ensuite le pare-feu du serveur pour autoriser l’accès à ce port depuis les ordinateurs autorisés. Pour commencer dans l’interface Windows, exécutez WF.msc, ouvrez Règles de trafic entrant, choisissez Nouvelle règle, puis le type Port et le protocole TCP. Dans les ports locaux spécifiques, indiquez le port de l’instance : 1433 dans notre configuration. L’objectif n’est pas d’ouvrir tous les ports associés à SQL Server, mais d’autoriser celui sur lequel votre moteur écoute. [3]

Limitez la règle au périmètre nécessaire plutôt que d’autoriser indistinctement toutes les origines. Microsoft demande de réserver l’accès aux utilisateurs ou ordinateurs autorisés et avertit qu’une ouverture de port peut exposer le serveur à des attaques. Son exemple avec netsh illustre notamment une restriction au sous-réseau local et au profil de domaine ; ce périmètre doit correspondre à votre environnement. Enfin, remplacer 1433 par un numéro moins connu ne constitue pas, à lui seul, une protection robuste : un scanner peut découvrir les ports ouverts. [3], [2], [1]

Exemple pratique : aligner trois réglages sur 1433

Prenons un exemple hypothétique : vous souhaitez rendre une instance Express accessible à des postes autorisés, en utilisant 1433 comme port fixe. Dans ses propriétés TCP/IP, Listen All vaut Yes. Vous configurez donc IPAll : suppression du 0 dans TCP Dynamic Ports s’il est présent, puis saisie de 1433 dans TCP Port. Vous redémarrez ensuite le moteur et configurez une règle entrante TCP sur 1433 pour les postes concernés. L’intérêt de cet exemple est l’alignement : le port déclaré, le port utilisé après redémarrage et le port autorisé doivent être identiques. [1], [3]

Le tableau distingue les principaux décalages possibles dans cet exemple. Il ne s’agit pas d’une liste exhaustive des causes d’échec d’une connexion SQL Server, mais d’un contrôle ciblé de la configuration réseau décrite ici. [1], [2], [3]

Situation	Conséquence pour cette configuration	Correction ciblée
1433 autorisé, instance encore en port dynamique	La règle peut ne pas viser le port du moteur.	Configurer un port fixe et aligner la règle. [2], [3]
1433 saisi uniquement dans IP1, Listen All = Yes	La valeur d’IP1 est ignorée.	Configurer les champs correspondants dans IPAll. [1]
Nouveau port enregistré, moteur non redémarré	Le moteur n’utilise pas encore le nouveau port.	Redémarrer le moteur de l’instance. [1]
Moteur sur 1433, accès non autorisé au pare-feu	La configuration d’écoute seule ne permet pas le passage.	Autoriser TCP 1433 pour les postes concernés. [3]

Distinguer TCP 1433 et SQL Server Browser

SQL Server Browser n’est pas une étape obligatoire de la méthode à port fixe. Ce service permet aux clients de trouver le port d’une instance sans le connaître à l’avance, notamment lorsqu’elle n’écoute pas sur 1433. Son utilisation nécessite l’ouverture de UDP 1434. Il faut donc distinguer le port TCP du moteur et le port UDP servant à cette découverte : ouvrir UDP 1434 ne remplace pas l’autorisation du port TCP de l’instance. [3]

Pour réduire l’exposition, Microsoft recommande de laisser Browser arrêté et de configurer les clients pour utiliser directement le numéro de port. Dans la méthode présentée, cela signifie conserver un port fixe connu, puis renseigner ce port côté client. Avant de modifier davantage le serveur en cas d’échec, revérifiez donc les points déterminants : bonne instance, section IPAll applicable, redémarrage effectué et correspondance entre le port d’écoute et la règle entrante. [3], [1]

Frequently asked questions

SQL Server Express utilise-t-il toujours le port 1433 ?

Non. Les instances nommées, dont SQL Server Express, utilisent par défaut des ports dynamiques. Le port 1433 correspond au port habituel de l’instance par défaut lorsque TCP est activé. Pour Express, vérifiez le port réellement configuré au lieu de déduire son numéro du nom du produit. [1], [2]

Faut-il ouvrir UDP 1434 en plus de TCP 1433 ?

Pas pour une connexion configurée directement avec le numéro de port du moteur. UDP 1434 concerne SQL Server Browser et la découverte du port. Microsoft recommande, pour un environnement plus sûr, de laisser Browser arrêté et de renseigner le numéro de port dans les clients. [3]

Pourquoi mon changement dans IP1 n’a-t-il aucun effet ?

Vérifiez Listen All. Lorsqu’il vaut Yes, les sections IP individuelles sont ignorées et seules les valeurs TCP Port et TCP Dynamic Ports d’IPAll sont prises en compte. Modifier IP1 dans cette situation ne change donc pas le port retenu. [1]

Où contrôler le port utilisé par le moteur ?

Microsoft indique que le port du moteur apparaît dans le journal des erreurs SQL Server. Ce contrôle est utile après le redémarrage : la configuration enregistrée ou le numéro annoncé par Browser ne suffisent pas toujours à établir que le moteur a déjà adopté le nouveau port. [3], [1]

Un port différent de 1433 sécurise-t-il suffisamment le serveur ?

Non. Microsoft précise qu’un changement de numéro n’est pas une mesure de sécurité robuste, car les ports ouverts peuvent être découverts par balayage. Restreindre l’accès du pare-feu aux ordinateurs autorisés reste une mesure directement pertinente pour cette configuration. [1], [3]

Conclusion

La méthode repose sur une cohérence simple : TCP/IP utilisable, port fixe correctement placé, moteur redémarré et pare-feu aligné. Pour SQL Server Express, ne présumez pas que 1433 est déjà utilisé. Si vous le choisissez, configurez-le explicitement dans la section applicable — IPAll lorsque Listen All vaut Yes — puis autorisez uniquement les accès nécessaires. SQL Server Browser reste une option de découverte, et non un prérequis lorsque les clients connaissent le port. [1], [2], [3]

Source notes

La manipulation exacte du contrôle d’activation de TCP/IP n’est pas détaillée dans les passages disponibles. Les étapes précises présentées portent sur l’affectation du port et le pare-feu Windows.

Cette procédure traite l’écoute réseau et le pare-feu ; elle ne constitue pas un guide de configuration de l’authentification ni de la syntaxe de connexion propre à chaque application cliente.

Explore next

Sources

Open a source or expand its cited passages.

Relevance scores are model estimates of how well each source addresses this question, not probabilities or fact-check ratings. Reasoned guidance is identified on hover.