RPC-verkeer van Active Directory beperken tot een specifieke poort
In dit artikel wordt beschreven hoe u RPC-verkeer (Remote Procedure Calls) van Active Directory (AD) kunt beperken naar een specifieke poort in Windows Server.
Van toepassing op: alle ondersteunde versies van Windows Server
Origineel KB-nummer: 224196
Samenvatting
Standaard worden externe procedureaanroepen (RPC) voor Active Directory-replicatie dynamisch uitgevoerd via een beschikbare poort via RPC Endpoint Mapper (RPCSS) met behulp van poort 135. Een beheerder kan deze functionaliteit overschrijven en de poort opgeven die al het RPC-verkeer van Active Directory passeert. Met deze procedure wordt de poort vergrendeld.
Wanneer u poorten opgeeft die moeten worden gebruikt met behulp van de registervermeldingen in Meer informatie, worden zowel Active Directory-replicatieverkeer op de server als het RPC-verkeer van de client naar deze poorten verzonden door de eindpunttoewijzing. Deze configuratie is mogelijk omdat alle RPC-interfaces die door Active Directory worden ondersteund, worden uitgevoerd op alle poorten waarop wordt geluisterd.
Opmerking
In dit artikel wordt niet beschreven hoe u AD-replicatie configureert voor een firewall. Er moeten extra poorten worden geopend om de replicatie via een firewall te laten werken. Er moeten bijvoorbeeld poorten worden geopend voor het Kerberos-protocol. Zie Serviceoverzicht en netwerkpoortvereisten voor Windows voor een volledige lijst met vereiste poorten voor services in een firewall.
Meer informatie
Belangrijk
Deze sectie, methode of taak bevat stappen voor het bewerken van het register. Als u het register op onjuiste wijze wijzigt, kunnen er echter grote problemen optreden. Het is dan ook belangrijk dat u deze stappen zorgvuldig uitvoert. Maak een back-up van het register voordat u wijzigingen aanbrengt. Als er een probleem optreedt, kunt u het register altijd nog herstellen. Raadpleeg Een back-up maken van en het herstellen van het register in Windows voor meer informatie over het maken van een back-up en het herstellen van het register.
Wanneer u verbinding maakt met een RPC-eindpunt, neemt de RPC-runtime op de client contact op met de RPCSS op de server op een bekende poort (135). En het verkrijgt de poort waarmee verbinding moet worden gemaakt voor de service die de gewenste RPC-interface ondersteunt. Hierbij wordt ervan uitgegaan dat de client de volledige binding niet kent. Het is de situatie met alle AD RPC-services.
De service registreert een of meer eindpunten wanneer deze wordt gestart en heeft de keuze uit een dynamisch toegewezen poort of een specifieke poort.
Als u Active Directory en Netlogon configureert om te worden uitgevoerd op poort x zoals in de volgende vermelding, worden dit de poorten die zijn geregistreerd bij de eindpunttoewijzing, naast de standaard dynamische poort.
Gebruik Register Editor om de volgende waarden te wijzigen op elke domeincontroller waarop de beperkte poorten moeten worden gebruikt. Lidservers worden niet beschouwd als aanmeldingsservers. Statische poorttoewijzing voor NTDS heeft dus geen effect op lidservers.
Lidservers hebben de Netlogon RPC-interface, maar deze wordt zelden gebruikt. Enkele voorbeelden zijn het ophalen van externe configuraties, zoals nltest /server:member.contoso.com /sc_query:contoso.com
.
Registersleutel 1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Registerwaarde: TCP/IP-poort
Waardetype: REG_DWORD
Waardegegevens: (beschikbare poort)
Start de computer opnieuw op om de nieuwe instelling van kracht te laten worden.
Registersleutel 2
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Registerwaarde: DCTcpipPort
Waardetype: REG_DWORD
Waardegegevens: (beschikbare poort)
Start de Netlogon-service opnieuw om de nieuwe instelling van kracht te laten worden.
Opmerking
Wanneer u de DCTcpipPort
registervermelding gebruikt en deze instelt op dezelfde poort als de TCP/IP Port
registervermelding, ontvangt u Netlogon-fout gebeurtenis 5809 onder NTDS\Parameters
. Dit geeft aan dat de geconfigureerde poort in gebruik is en dat u een andere poort moet kiezen.
U ontvangt dezelfde gebeurtenis wanneer u een unieke poort hebt en u de Netlogon-service opnieuw start op de domeincontroller. Dit gedrag is inherent aan het ontwerp van het product. Dit gebeurt vanwege de manier waarop de RPC-runtime de serverpoorten beheert. De poort wordt gebruikt na het opnieuw opstarten en de gebeurtenis kan worden genegeerd.
Beheerders moeten controleren of de communicatie via de opgegeven poort is ingeschakeld als tussenliggende netwerkapparaten of software wordt gebruikt om pakketten tussen de domeincontrollers te filteren.
Vaak moet u ook handmatig de RPC-poort van de File Replication Service (FRS) instellen, omdat AD- en FRS-replicatie met dezelfde domeincontrollers worden gerepliceerd. De FRS RPC-poort moet een andere poort gebruiken.
Ga er niet vanuit dat clients alleen de RPC-services van Netlogon gebruiken en dus alleen de instelling DCTcpipPort
is vereist. Clients gebruiken ook andere RPC-services, zoals SamRPC, LSARPC en ook de Interface van Directory Replication Services (DRS). U moet altijd beide registerinstellingen configureren en beide poorten op de firewall openen.
Bekende problemen
Nadat u de poorten hebt opgegeven, kunnen de volgende problemen optreden:
- Lange aanmeldingstijd nadat u een specifieke statische poort hebt ingesteld voor NTDS en Netlogon in een domeinomgeving op basis van Windows Server 2008 R2
- AD-replicatie mislukt met een RPC-probleem nadat u een statische poort hebt ingesteld voor NTDS in een Windows-domeinomgeving
- Aanmelden mislukt nadat u RPC-clientverkeer beperkt tot DC-verkeer in Windows Server 2012 R2 of Windows Server 2008 R2
Installeer de updates die in de artikelen worden vermeld om de problemen op te lossen.
Gegevensverzameling
Als u hulp nodig hebt van Microsoft-ondersteuning, raden we u aan de gegevens te verzamelen door de stappen te volgen die worden vermeld in Gegevens verzamelen met behulp van TSS voor replicatieproblemen met Active Directory.
Feedback
https://aka.ms/ContentUserFeedback.
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie:Feedback verzenden en weergeven voor