Momentan sunteți offline, așteptați să vă reconectați la internet

Cum se configurează un paravan de protecție pentru domenii şi trusturi

Asistența pentru Windows Server 2003 s-a încheiat la 14 iulie 2015

Microsoft a încheiat asistența pentru Windows Server 2003 14 iulie 2015. Această schimbare a afectat actualizările de software și opțiunile de securitate. Aflați ce înseamnă aceasta pentru dvs. și cum puteți rămâne protejat.

IMPORTANT: Acest articol a fost tradus de software-ul de traducere automată Microsoft, si nu de un traducător. Microsoft vă oferă atât articole traduse de persoane, cât şi articole traduse automat, astfel incat aveti access la toate articolele din Baza noastră de informatii în limba dvs. materna. Totuşi, un articol tradus automat nu este întotdeauna perfect. Acesta poate conţine greşeli de vocabular, sintaxă sau gramatică, la fel cum un vorbitor străin poate face greşeli vorbind limba dvs. materna. Compania Microsoft nu este responsabilă pentru nici o inexactitate, eroare sau daună cauzată de traducerea necorespunzătoare a conţinutului sau de utilizarea traducerii necorespunzătoare de către clienţii nostri. De asemenea, Microsoft actualizează frecvent software-ul de traducere automată.

Faceți clic aici pentru a vizualiza versiunea în limba engleză a acestui articol: 179442
Dacă sunteţi un client de afaceri mici, găsi suplimentare de depanare şi de învăţare a resurselor la Suport pentru Small Business site-ul.
Rezumat
Acest articol descrie cum se configurează un paravan de protecție pentru domenii şi Trust.

Notă: Nu toate porturile care sunt listate în tabelele aici sunt necesare în toate scenariile. De exemplu, dacă firewall-ul separă membrii şi DCs, nu aveţi pentru a deschide porturile FRS sau DFSR. De asemenea, dacă ştiţi că clienţii nu utilizează LDAP cu SSL/TLS, nu aveţi pentru a deschide porturile 636 şi 3269.
Informaţii suplimentare
Pentru a stabili un trust de domeniu sau un canal de securitate peste un paravan de protecţie, trebuie să se dechidă următoarele porturi. Fiţi conştient de faptul că pot exista gazde funcționarea cu roluri atât client şi server pe ambele maluri ale paravanului de protecţie. Prin urmare, porturile reguli trebuie să fi reflectat.

Windows NT

În acest context, o parte de încredere este un trust de Windows NT 4.0 sau trust a fost creat utilizând nume NetBIOS.
Porturile clientServer PortService
137/UDP137/UDPnume de sign-in din NetBIOS
138/UDP138/UDPNetBIOS Netlogon şi Navigare
1024-65535/TCP139/TCPSesiune NetBIOS
1024-65535/TCP42/TCPVICTORII Replication

Windows Server 2003 şi Windows 2000 Server

Pentru un domeniu amestecat-model care utilizează controlere de domeniu Windows NT sau clienti moştenire, încredere în relaţiile dintre controlerele de domeniu Windows Server 2003 şi Windows 2000 Server domeniu controlere poate solicita că toate porturile pentru Windows NT, care figurează în tabelul anterior trebuie deschis pe lângă următoarele porturi.

Notă Controlerii de domeniu două sunt atât în acelaşi pădure sau controlerii de domeniu două sunt atât într-o pădure separată. De asemenea, Trusturile din Pădurea sunt Trusturi Windows Server 2003 sau ulterior versiunea trusturi.
Porturile clientServer PortService
1024-65535/TCP135/TCPRPC Endpoint Mapper
1024-65535/TCP1024-65535/TCPRPC pentru LSA, SAM, Netlogon luni(**)
1024-65535/TCP/UDP389/TCP/UDPLDAP
1024-65535/TCP636/TCPLDAP SSL
1024-65535/TCP3268/TCPLDAP GC
1024-65535/TCP3269/TCPLDAP GC SSL
53,1024-65535/TCP/UDP53/TCP/UDPDNS
1024-65535/TCP/UDP88/TCP/UDPKerberos
1024-65535/TCP445/TCPSMB
1024-65535/TCP1024-65535/TCPFRS RPC LUNI(**)
NETBIOS porturile enumerate pentru Windows NT, de asemenea, sunt necesare pentru Windows 2000 şi Windows Server 2003 când trusturi domenii sunt configurate care acceptă numai comunicare bazate pe NETBIOS. Exemple sunt sisteme de operare bazate pe Windows NT sau al treilea-petrecere controlerii de domeniu, care sunt bazate pe Samba.

(*) Pentru informaţii despre cum să se definească serverul RPC porturile utilizate de serviciile LSA RPC, consultaţi următoarele articole din bază de cunoştinţe Microsoft:

Ferestre a servi 2008 şi Ferestre a servi 2008 R2

Ferestre a servi 2008 şi Ferestre a servi 2008 R2 au crescut în zona de portul clientul dinamic pentru conexiuni de ieşire. Portul de pornire implicită nou este 49152, iar portul prestabilit sfârşitul este 65535. Prin urmare, trebuie să crească zona portuară RPC în firewall-uri dumneavoastră. Această schimbare a fost făcută în conformitate cu recomandările Internet atribuit Numbers Authority (IANA). Aceasta diferă de la un mod amestecat domeniu care constă din controlerele de domeniu Windows Server 2003, controlerele de domeniu Windows 2000 Server sau clienţi moştenire, în cazul în care gama dinamică portul implicit este 1025 prin 5000.

Pentru mai multe informaţii despre modificarea gamă dinamică portul Ferestre a servi 2008 şi Ferestre a servi 2008 R2, consultaţi următoarele resurse:
Porturile clientServer PortService
49152-65535/UDP123/UDPW32Time
49152-65535/TCP135/TCPRPC Endpoint Mapper
49152-65535/TCP464/TCP/UDPSchimbare parolă Kerberos
49152-65535/TCP49152-65535/TCPRPC pentru LSA, SAM, Netlogon luni(**)
49152-65535/TCP/UDP389/TCP/UDPLDAP
49152-65535/TCP636/TCPLDAP SSL
49152-65535/TCP3268/TCPLDAP GC
49152-65535/TCP3269/TCPLDAP GC SSL
53, 49152-65535/TCP/UDP53/TCP/UDPDNS
49152-65535/TCP49152-65535/TCPFRS RPC LUNI(**)
49152-65535/TCP/UDP88/TCP/UDPKerberos
49152-65535/TCP/UDP445/TCPSMB
49152-65535/TCP49152-65535/TCPRPC DFSR LUNI(**)
NETBIOS porturile enumerate pentru Windows NT, de asemenea, sunt necesare pentru Windows 2000 şi Server 2003 când trusturi domenii sunt configurate care acceptă numai comunicare bazate pe NETBIOS. Exemple sunt sisteme de operare bazate pe Windows NT sau al treilea-petrecere controlerii de domeniu, care sunt bazate pe Samba.

(*) Pentru informaţii despre cum să se definească serverul RPC porturile utilizate de serviciile LSA RPC, consultaţi următoarele articole din bază de cunoştinţe Microsoft:
Notă: Încredere externe 123/UDP este necesar doar dacă aţi manual configurat serviciul Windows Time să efectuați sincronizarea cu un server de peste încrederea externe.

Director Active

În Windows 2000 şi Windows XP, Internet Control Message Protocol (ICMP) trebuie să se admită prin paravanul de protecție la clienții pentru controlerii de domeniu client Active Directory Group Policy poate funcţiona corect prin paravanul de protecție. ICMP este utilizat pentru a determina dacă legătura este un link lent sau un link rapid.

În Windows Server 2008 şi versiunile ulterioare, locaţie reţea conştientizare serviciu provides estimarea latime de banda pe baza traficul cu alte posturi pe reţea. Nu există nici un trafic generat pentru estimarea.

Windows Redirector utilizează de asemenea ICMP să verifice că un IP serverul se rezolvă prin serviciul de DNS înainte un unire is made, şi atunci când un server este situat utilizând DFS. Aceasta se aplică SYSVOL acces către membrii de domeniu.

Dacă doriţi pentru a minimiza traficul ICMP, puteţi utiliza următoarele probă paravan de protecţie regulă:
<any> ICMP -> DC IP addr = allow

Spre deosebire de stratul de Protocolul TCP şi UDP strat de Protocolul ICMP nu are un număr de port. Acest lucru se datorează faptului că ICMP este găzduit direct de stratul de IP.

implicit, Windows Server 2003 şi Windows 2000 Server DNS fermă de servere folosi efemere partea client porturile atunci când le interoga alte fermă de servere DNS. Cu toate acestea, acest comportament pot fi modificate de o setare de registry specifice. Pentru mai multe informaţii, consultaţi Microsoft Knowledge Base articolul 260186: SendPort DNS registru cheie nu funcţionează conform aşteptărilor

Pentru mai multe informaţii despre Active Directory şi configuraţia paravanului de protecţie, consultaţi Director active în reţelele segmentate de firewall-uriMicrosoft carte albă.Sau, puteţi stabili un trust prin tunelul obligatorie Protocol de tunel punct la punct (PPTP). Aceasta limitează numărul de porturi care are Paravanul de protecţie pentru a deschide. Pentru PPTP, trebuie activate următoarele porturi.
Porturile clientServer PortProtocolul
1024-65535/TCP1723/TCPPPTP
În plus, ar trebui să activaţi IP PROTOCOL 47 (GRE).

Notă Când adăugaţi permisiunile la o resursă într-un domeniu de încredere pentru utilizatorii dintr-un domeniu de încredere, există unele diferenţe între Windows 2000 şi Windows NT 4.0 comportament. Dacă computerul nu afişează o listă a utilizatorilor de domeniu de la distanţă, luaţi în considerare următorul comportament:
  • Windows NT 4.0 încearcă de rezolvare a numelor introduse manual de contactarea PDC pentru domeniul utilizatorului la distanţă (138-UDP). Cazul în care comunicare eşuează, un computer Windows NT 4.0 contacte PDC proprie, şi apoi cere resolution de nume de sign-in.
  • Windows 2000 şi Windows Server 2003, de asemenea, încercaţi să contactaţi PDC utilizatorului la distanţă pentru rezoluţia peste UDP 138. Cu toate acestea, ele nu se bazează pe folosind propriile lor PDC. Asiguraţi-vă că toate serverele bazate pe Windows 2000 membre şi serverele bazate pe Windows Server 2003 membre care vor fi acordare acces la resurse UDP 138 conectivitate de la distanţă PDC.
Resurse suplimentare
tcpip

Avertisment: acest articol a fost tradus automat

Proprietăți

ID articol: 179442 - Ultima examinare: 08/10/2012 17:41:00 - Revizie: 4.0

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 Professional Edition, 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 KbMtro
Feedback
lementsByTagName("head")[0].appendChild(m);