Cet article explique comment configurer un pare-feu pour les domaines et approbations.
Réduire cette imageAgrandir cette image
Pas tous les ports qui sont répertoriés dans les tableaux ici sont requis dans tous les scénarios. Par exemple, si le pare-feu sépare les membres et contrôleurs de domaine, vous n'êtes pas obligé d'ouvrir les ports FRS ou DFSR. En outre, si vous savez qu'aucun client n'utilise le protocole LDAP avec SSL/TLS, il est inutile d'ouvrir des ports 3 268 et 636.
Pour établir une approbation de domaine ou un canal de sécurité à travers un pare-feu, les ports suivants doivent être ouverts. N'oubliez pas qu'il existe peut-être des hôtes qui fonctionnent avec des rôles client et serveur des deux côtés du pare-feu. Par conséquent, les règles de ports peuvent avoir à être mises en miroir.
Windows NT
Click here to show/hide solution
Dans cet environnement, un côté de l'approbation est une relation d'approbation Windows NT 4.0, ou l'approbation a été créée en utilisant les noms NetBIOS.
Réduire ce tableauAgrandir ce tableau
| Port (s) client | Port du serveur | Service |
|---|
| 137/UDP | 137/UDP | Nom NetBIOS |
| UDP/138 | UDP/138 | NetBIOS Netlogon et
La navigation |
| 1024-65535/TCP | TCP/139 | Session NetBIOS |
| 1024-65535/TCP | 42/TCP | Réplication WINS |
Windows Server 2003 et Windows 2000 Server
Click here to show/hide solution
Pour un domaine en mode mixte qui utilise des contrôleurs de domaine Windows NT ou des clients hérités, relations d'approbation entre les contrôleurs de domaine Windows Server 2003 et un domaine basé sur Windows 2000 Server contrôleurs peuvent exiger que tous les ports pour Windows NT qui sont répertoriés dans le tableau précédent être ouverts en plus des ports suivants.
Réduire cette imageAgrandir cette image
: Deux contrôleurs de domaine sont tous deux dans le même
forêt, ou les deux contrôleurs de domaine sont tous deux dans une forêt distincte. En outre, les relations d'approbation de la forêt sont
Les approbations Windows Server 2003 ou les approbations d'une version ultérieure.
Réduire ce tableauAgrandir ce tableau
| Port (s) client | Port du serveur | Service |
|---|
| 1024-65535/TCP | 135/TCP | Mappeur de point final RPC |
| 1024-65535/TCP | 1024-65535/TCP | RPC pour LSA, SAM, Netlogon (*) |
| 1024-65535/TCP/UDP | 389/TCP/UDP | LDAP |
| 1024-65535/TCP | 636/TCP | LDAP SSL |
| 1024-65535/TCP | 3268/TCP | LDAP GC |
| 1024-65535/TCP | 3269/TCP | LDAP GC SUR SSL |
| 53,1024-65535/TCP/UDP | 53/TCP/UDP | DNS |
| 1024-65535/TCP/UDP | 88/TCP/UDP | Kerberos |
| 1024-65535/TCP | 445/TCP | PME/PMI |
| 1024-65535/TCP | 1024-65535/TCP | FRS RPC (*) |
Les ports NETBIOS visés pour Windows NT sont également requis pour Windows 2000 et Windows Server 2003 lorsque des approbations de domaines sont configurées qui prennent en charge uniquement les communications basés sur NETBIOS. Systèmes d'exploitation basés sur Windows NT ou des contrôleurs de domaine de tiers qui sont basés sur Samba sont des exemples.
(*) Pour plus d'informations sur la définition des ports du serveur RPC utilisés par les services LSA RPC, consultez les articles suivants de la Base de connaissances Microsoft :
Windows Server 2008 et Windows Server 2008 R2
Click here to show/hide solution
Windows Server 2008 et Windows Server 2008 R2 ont augmenté la plage de ports dynamiques client pour les connexions sortantes. Le nouveau port de démarrage par défaut est 49152, et le port de fin par défaut est 65 535. Par conséquent, vous devez augmenter la plage de ports RPC dans votre pare-feu. Cette modification a été apportée pour se conformer aux recommandations Internet IANA Assigned Numbers Authority (). Cela diffère d'un domaine en mode mixte qui se compose de contrôleurs de domaine Windows Server 2003, les contrôleurs de domaine Windows 2000 Server ou les clients hérités, où la plage de ports dynamiques par défaut est 1025 à 5000.
Pour plus d'informations sur la modification de plage de ports dynamiques dans Windows Server 2008 et Windows Server 2008 R2, consultez les ressources suivantes :
Réduire ce tableauAgrandir ce tableau
| Port (s) client | Port du serveur | Service |
|---|
| 49152 -65535/UDP | 123/UDP | W32Time |
| 49152 -65535/TCP | 135/TCP | Mappeur de point final RPC |
| 49152 -65535/TCP | 464/TCP/UDP | Changement de mot de passe Kerberos |
| 49152 -65535/TCP | 49152-65535/TCP | RPC pour LSA, SAM, Netlogon (*) |
| 49152 -65535/TCP/UDP | 389/TCP/UDP | LDAP |
| 49152 -65535/TCP | 636/TCP | LDAP SSL |
| 49152 -65535/TCP | 3268/TCP | LDAP GC |
| 49152 -65535/TCP | 3269/TCP | LDAP GC SUR SSL |
| 53, 49152 -65535/TCP/UDP | 53/TCP/UDP | DNS |
| 49152 -65535/TCP | 49152 -65535/TCP | FRS RPC (*) |
| 49152 -65535/TCP/UDP | 88/TCP/UDP | Kerberos |
| 49152 -65535/TCP/UDP | 445/TCP | SMB (*) |
| 49152 -65535/TCP | 49152-65535/TCP | DFSR RPC (*) |
Ports NETBIOS visés pour Windows NT sont également requis pour Windows 2000 et Server 2003 lorsque des approbations de domaines sont configurées qui prennent en charge uniquement les communications basés sur NETBIOS. Systèmes d'exploitation basés sur Windows NT ou des contrôleurs de domaine de tiers qui sont basés sur Samba sont des exemples.
(*) Pour plus d'informations sur la définition des ports du serveur RPC utilisés par les services LSA RPC, consultez les articles suivants de la Base de connaissances Microsoft :
(**) Pour l'opération de l'approbation de ce port n'est pas nécessaire, il est utilisé pour la création de confiance uniquement.
Réduire cette imageAgrandir cette image
Approbation externe 123/UDP n'est nécessaire que si vous avez configuré manuellement le Service de temps Windows pour la synchronisation avec un serveur dans l'approbation externe.
Active Directory
Click here to show/hide solution
Windows 2000 et Windows XP, l'ICMP Internet Control Message Protocol () doit être autorisé à traverser le pare-feu à partir des clients sur les contrôleurs de domaine afin que le client de stratégie de groupe Active Directory peut fonctionner correctement à travers un pare-feu. ICMP est utilisé pour déterminer si le lien est une connexion lente ou rapide.
Dans Windows Server 2008 et versions ultérieures, le Service de prise de conscience d'emplacement réseau fournit l'estimation de la bande passante en fonction du trafic avec d'autres stations sur le réseau. Aucun trafic n'est généré pour l'estimation.
Le redirecteur Windows utilise également le protocole ICMP pour vérifier qu'une adresse IP du serveur est résolue par le service DNS avant qu'une connexion est effectuée, et lorsqu'un serveur se trouve à l'aide de DFS. Cela s'applique à l'accès par les membres de domaine SYSVOL.
Si vous souhaitez réduire le trafic ICMP, vous pouvez utiliser les éléments suivants
exemple de règle de pare-feu :
<any> ICMP -> DC IP addr = allow
Contrairement à la couche du protocole TCP et le protocole UDP
couche de protocole ICMP n'a pas un numéro de port. C'est parce que le protocole ICMP est
hébergé directement par la couche IP.
Par défaut, les serveurs DNS Windows 2000 Server et de Windows Server 2003 utilisent les ports éphémères côté client lorsqu'ils interrogent d'autres serveurs DNS. Toutefois, ce comportement peut être modifié par un paramètre de Registre spécifique. Pour plus d'informations, consultez l'article de la Base de connaissances Microsoft
260186 : Clé de Registre DNS SendPort ne fonctionne pas comme prévu
(http://support.microsoft.com/kb/260186)
Pour plus d'informations sur Active Directory et configuration du pare-feu, consultez le
Active Directory dans les réseaux segmentés par des pare-feu
(http://www.microsoft.com/downloads/details.aspx?FamilyID=c2ef3846-43f0-4caf-9767-a9166368434e&displaylang=en)
Livre blanc de Microsoft.Ou bien, vous pouvez établir une approbation à travers le tunnel obligatoire point to Point Tunneling Protocol (PPTP). Cela limite le nombre de ports que le pare-feu doit ouvrir. Pour le protocole PPTP, les ports suivants doivent être activés.
Réduire ce tableauAgrandir ce tableau
| Les Ports du client | Port du serveur | Protocole |
|---|
| 1024-65535/TCP | / TCP 1723 | PPTP |
En outre, vous seriez obligé d'activer le protocole IP 47
(GRE).
Réduire cette imageAgrandir cette image
: Lorsque vous ajoutez des autorisations à une ressource sur un domaine d'approbation pour les utilisateurs dans un domaine approuvé, il existe certaines différences entre les comportements de Windows NT 4.0 et de Windows 2000. Si l'ordinateur ne peut pas afficher une liste des utilisateurs du domaine distant, prenez en compte le comportement suivant :
- Windows NT 4.0 essaie de résoudre les noms tapés manuellement par
contacter le contrôleur principal de domaine de l'utilisateur distant (UDP 138). Si ce
communication échoue, un ordinateur fonctionnant sous Windows NT 4.0 contacte son propre contrôleur principal de domaine, et
puis demande la résolution du nom.
- Windows 2000 et Windows Server 2003 tentent également de contacter de contrôleur principal de domaine de l'utilisateur distant pour la résolution sur le port UDP 138. Toutefois, ils ne comptent pas sur l'utilisation de leur propre contrôleur principal de domaine. Assurez-vous que tous les serveurs membres Windows 2000 et les serveurs membres Windows Server 2003 qui accorderont l'accès aux ressources possèdent une connectivité UDP 138 vers le contrôleur principal de domaine distant.
Numéro d'article: 179442 - Dernière mise à jour: dimanche 23 décembre 2012 - Version: 9.0
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
- Windows Server 2008 Datacenter
- Windows Server 2008 Enterprise
- Windows Server 2008 Standard
- Windows Server 2008 R2 Datacenter
- Windows Server 2008 R2 Enterprise
- Windows Server 2008 R2 Standard
- Microsoft Windows Server 2003, Standard Edition (32-bit x86)
- Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
- Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
- Microsoft Windows 2000 Server
- Microsoft Windows 2000 Advanced Server
- Microsoft Windows 2000 Professionnel
- Microsoft Windows NT Server 4.0 Standard Edition
- Windows Server 2008 Datacenter without Hyper-V
- Windows Server 2008 Enterprise without Hyper-V
- Windows Server 2008 for Itanium-Based Systems
- Windows Server 2008 Foundation
- Windows Web Server 2008 R2
| kbenv kbhowto kbnetwork kbmt KB179442 KbMtfr |
Traduction automatiqueIMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d?articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d?avoir accès, dans votre propre langue, à l?ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s?exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s?efforce aussi continuellement de faire évoluer son système de traduction automatique.
La version anglaise de cet article est la suivante:
179442
(http://support.microsoft.com/kb/179442/en-us/
)
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.
Retour au début
