A tűzfal konfigurálása Active Directory-tartományokhoz és -megbízásokhoz

  • 09/08/2020
  • 5 perc olvasás
    • D
    • s

Ez a cikk a tűzfal konfigurálását ismerteti Active Directory-tartományokhoz és -megbízásokhoz.

A termék eredeti verziója: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2 Standard, Windows Server 2012 Standard
Eredeti KB-szám: 179442

Figyelem

Nem minden esetben van szükség az itt található táblázatokban felsorolt összes portra. Ha például a tűzfal elválasztja a tagokat és a DC-ket, nem kell megnyitni az FRS vagy a DFSR portokat. Továbbá, ha tudja, hogy egyetlen ügyfél sem használja az LDAP-ot SSL/TLS protokollal, nem kell megnyitnia a 636-os és a 3269-es portokat.

További információ

Jegyzet

A két tartományvezérlő ugyanabban az erdőben van, vagy a két tartományvezérlő külön erdőben van. Továbbá az erdőben lévő bizalmi kapcsolatok Windows Server 2003 bizalmi kapcsolatok vagy újabb verziójú bizalmi kapcsolatok.

Client port(ok) Server port Service
1024-65535/TCP 135/TCP RPC végpont leképező
1024-65535/TCP 1024-65535/TCP RPC for LSA, SAM, NetLogon (*)
1024-65535/TCP/UDP 389/TCP/UDP LDAP
1024-65535/TCP 636/TCP LDAP SSL
1024-65535/TCP 1024-65535/TCP 3268/TCP LDAP GC
1024-65535/TCP 3269/TCP LDAP GC SSL
53,1024-65535/TCP/UDP 53/TCP/UDP DNS
1024-65535/TCP/UDP 88/TCP/UDP Kerberos
1024-65535/TCP 445/TCP SMB
1024-65535/TCP 1024-65535/TCP FRS RPC (*)

A Windows NT esetében felsorolt NETBIOS-portok a Windows 2000 és a Windows Server 2003 esetében is szükségesek, ha olyan tartományokhoz való bizalmi kapcsolatok vannak konfigurálva, amelyek csak NETBIOS-alapú kommunikációt támogatnak. Ilyenek például a Windows NT-alapú operációs rendszerek vagy a Samba-alapú, harmadik féltől származó tartományvezérlők.

Az LSA RPC-szolgáltatások által használt RPC-kiszolgáló portok meghatározásával kapcsolatos további információkért lásd:

  • Az Active Directory RPC-forgalom korlátozása egy adott portra.
  • A Windows szolgáltatásainak áttekintése és hálózati portkövetelmények a tartományvezérlők és az Active Directory című fejezetben.

Windows Server 2008 és újabb verziók

A Windows Server 2008 újabb verziói megnövelték a kimenő kapcsolatok dinamikus ügyfélport-tartományát. Az új alapértelmezett kezdőport 49152, az alapértelmezett végport pedig 65535. Ezért meg kell növelnie az RPC porttartományt a tűzfalakon. Ez a módosítás az Internet Assigned Numbers Authority (IANA) ajánlásainak való megfelelés érdekében történt. Ez eltér a Windows Server 2003 tartományvezérlőkből, Windows 2000 kiszolgálóalapú tartományvezérlőkből vagy örökölt ügyfelekből álló vegyes üzemmódú tartománytól, ahol az alapértelmezett dinamikus porttartomány 1025 és 5000 között van.

A Windows Server 2012 és Windows Server 2012 R2 dinamikus porttartományának változásával kapcsolatos további információkért lásd:

  • A TCP/IP alapértelmezett dinamikus porttartománya megváltozott.
  • Dinamikus portok a Windows Serverben.
Client port(ok) Server port Service
49152 -65535/UDP 123/UDP W32Time
49152 -.65535/TCP 135/TCP RPC Endpoint Mapper
49152 -65535/TCP 464/TCP/UDP Kerberos jelszó módosítása
49152 -65535/TCP 49152-65535/TCP RPC LSA-hoz, 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 SSL
53, 49152 -65535/TCP/UDP 53/TCP/UDP DNS
49152 -65535/TCP 49152 -65535/TCP FRS RPC (*)
49152 -65535/TCP 49152-65535/TCP/UDP 88/TCP/UDP Kerberos
49152 -65535/TCP/UDP/UDP 445/TCP SMB (**)
49152 -65535/TCP 49152-65535/TCP DFSR RPC (*)

A Windows NT esetében felsorolt NETBIOS-portok a Windows 2000 és Server 2003 esetében is szükségesek, ha olyan tartományokba való bizalmi kapcsolatok vannak konfigurálva, amelyek csak NETBIOS-alapú kommunikációt támogatnak. Ilyenek például a Windows NT-alapú operációs rendszerek vagy a Samba-alapú, harmadik féltől származó tartományvezérlők.

(*) Az LSA RPC-szolgáltatások által használt RPC-kiszolgáló portok meghatározásával kapcsolatos információkért lásd:

  • Az Active Directory RPC-forgalom korlátozása egy adott portra.
  • A tartományvezérlők és az Active Directory szakasz a Szolgáltatások áttekintése és hálózati portkövetelmények a Windows számára című fejezetben.

(**) A megbízhatóság működéséhez ez a port nem szükséges, csak a megbízhatóság létrehozásához használatos.

Figyelem

A 123/UDP külső bizalmi portra csak akkor van szükség, ha a Windows Time Service-t manuálisan úgy konfigurálta, hogy a külső bizalmi porton keresztül szinkronizáljon egy kiszolgálóval.

Active Directory

A Windows 2000 és Windows XP rendszerekben az Internet Control Message Protocol (ICMP) protokollt a tűzfalon keresztül kell engedélyezni az ügyfelektől a tartományvezérlőkhöz, hogy az Active Directory csoportpolitikai ügyfél a tűzfalon keresztül is megfelelően működhessen. Az ICMP segítségével határozható meg, hogy a kapcsolat lassú vagy gyors kapcsolatról van-e szó.

A Windows Server 2008 és újabb verziókban a hálózati helyismereti szolgáltatás a hálózat más állomásaival folytatott forgalom alapján becsült sávszélességet biztosít. A becsléshez nem keletkezik forgalom.

A Windows Redirector ICMP Ping-üzenetekkel is ellenőrzi, hogy egy kiszolgáló IP-címét a DNS-szolgáltatás feloldja-e, mielőtt a kapcsolat létrejönne, illetve amikor egy kiszolgálót a DFS segítségével talál meg. Ha minimalizálni szeretné az ICMP-forgalmat, használhatja a következő mintatűzfalszabályt:

<any> ICMP -> DC IP addr = allow

A TCP protokollrétegtől és az UDP protokollrétegtől eltérően az ICMP-nek nincs portszáma. Ennek oka, hogy az ICMP közvetlenül az IP-rétegben található.

A Windows Server 2003 és a Windows 2000 Server DNS-kiszolgálók alapértelmezés szerint efemer ügyféloldali portokat használnak, amikor más DNS-kiszolgálókat kérdeznek le. Ez a viselkedés azonban megváltoztatható egy speciális registry-beállítással. Vagy létrehozhat egy bizalmi kapcsolatot a PPTP (Point-to-Point Tunneling Protocol) kötelező alagúton keresztül. Ez korlátozza a tűzfal által megnyitandó portok számát. A PPTP esetében a következő portokat kell engedélyezni.

Kliens portok Kiszolgáló port Protokoll
1024-.65535/TCP 1723/TCP PPTP

Ezeken kívül, engedélyeznie kell az IP PROTOCOL 47 (GRE) szolgáltatást.

Megjegyzés

Ha egy megbízható tartományban lévő felhasználó számára ad engedélyeket egy erőforráshoz egy megbízható tartományban, akkor van néhány különbség a Windows 2000 és a Windows NT 4.0 viselkedése között. Ha a számítógép nem tudja megjeleníteni a távoli tartomány felhasználóinak listáját, vegye figyelembe a következő viselkedést:

  • A Windows NT 4.0 a kézzel beírt neveket a távoli felhasználó tartományának PDC-jével való kapcsolatfelvétel útján próbálja feloldani (UDP 138). Ha ez a kommunikáció sikertelen, a Windows NT 4.0-alapú számítógép kapcsolatba lép a saját PDC-jével, majd kéri a név feloldását.
  • A Windows 2000 és a Windows Server 2003 szintén megpróbál kapcsolatba lépni a távoli felhasználó PDC-jével feloldás céljából az UDP 138-on keresztül. Ezek azonban nem támaszkodnak a saját PDC használatára. Győződjön meg arról, hogy minden Windows 2000-alapú tagkiszolgáló és Windows Server 2003-alapú tagkiszolgáló, amely hozzáférést biztosít az erőforrásokhoz, rendelkezik UDP 138-as kapcsolattal a távoli PDC-hez.

Hivatkozás

A Windows szolgáltatásainak és hálózati portkövetelményeinek áttekintése egy értékes forrás, amely felvázolja a Microsoft Windows Server rendszerben a Microsoft ügyfél- és kiszolgáló operációs rendszerek, kiszolgálóalapú programok és azok alkomponensei által használt szükséges hálózati portokat, protokollokat és szolgáltatásokat. A rendszergazdák és a támogatási szakemberek útitervként használhatják a cikket annak meghatározásához, hogy a Microsoft operációs rendszerei és programjai milyen portokat és protokollokat igényelnek a hálózati kapcsolathoz egy szegmentált hálózatban.

A Windows tűzfal konfigurálásához nem szabad a Windows szolgáltatási áttekintése és hálózati portkövetelmények a Windows számára című dokumentumban található portinformációkat használni. A Windows tűzfal konfigurálásával kapcsolatos információkat a Fokozott biztonságú Windows tűzfal című fejezetben talál.

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.