Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Dieser Artikel hilft Ihnen bei der Problembehandlung, bei dem mehrere Datensätze mit derselben IP-Adresse registriert sind. Das Problem wird durch die Konfigurationen des Dns-Gerüsts (Domain Name System) und der DHCP-Leasedauer (Dynamic Host Configuration Protocol) verursacht.
Szenario
Stellen Sie sich folgendes Szenario vor:
Auf einem DHCP-Server haben Sie die folgenden Konfigurationen:
- Ein DHCP-Bereich hat seine Leasedauer auf die standard acht Tage festgelegt.
- Der DHCP-Bereich ist bei verfügbaren IP-Adressen gering.
- Der Kunde A verlängert seine IP-Adress-Lease nicht in acht Tagen und läuft ab.
- Client B fordert eine neue IP-Adresse an.
- Der DHCP-Server weist Client B der Adresse zu, die an Client A geleastet wird.
Dieses Szenario ist typisch und alles funktioniert ordnungsgemäß.
Auf einem DNS-Server haben Sie die folgenden Konfigurationen:
- Eine integrierte ACTIVE Directory(AD)-DNS-Zone ist auf das Gerüst veralteter Ressourceneinträge festgelegt.
- Das DNS-Eintragsgerüst verwendet Standardeinstellungen: No-refresh interval = 7 Days, Refresh interval = 7 days, and Scavenging period = 7 days.
- Client A erneuerte seinen DNS-Eintrag vor acht Tagen, als die DHCP-Lease des Clients zuletzt aktualisiert wurde.
- Standardmäßig ist Client A der Besitzer seines DNS-Eintrags, sodass der Eintrag nicht vom DHCP-Server gelöscht werden kann.
- Client B registriert seinen DNS-Eintrag mit der neuen IP-Adresse, die vom DHCP-Server empfangen wurde, was dem eintrag entspricht, der für Client A registriert ist.
In diesem Szenario kann der DNS-Server den DNS-Eintrag von Client A für weitere sechs Tage nicht gerüsten. Jetzt haben Client A und Client B dieselbe IP-Adresse, die in DNS registriert ist.
Problemanalyse
Mehrere Probleme treten aufgrund desselben DNS-Eintrags für verschiedene Namen auf. Beispiel: Installationsproblem mit Microsoft System Center Configuration Manager (SCCM)-Clients.
Hier sehen Sie ein weiteres Beispiel. Wenn Sie auf eine Freigabe auf Client A zugreifen, erhalten Sie die folgende Fehlermeldung, auch wenn Client A nicht aktiviert ist.
Dieser Fehler wird verursacht, weil ein Kerberos-Ticket, das für einen Computer vorgesehen ist, an einen anderen Computer gesendet wird. Der folgende Abschnitt führt durch den gesamten Prozess.
Netzwerkflüsse während des Anmeldefehlers
Der Computer (Infra-App1) führt eine DNS-Abfrage für client-a.corp.contoso.com. DNS-Antworten zurück mit der IP-Adresse 10.0.0.100.
Was DNS betrifft, ist das Ergebnis richtig. Client A hat 10.0.0.100 als IP-Adresse aufgeführt, d. h. Client B.
Anschließend fordert der Computer Infra-App1 ein Kerberos-Ticket an. Die DNS-Abfrage ist für Client A bestimmt, sodass die Ticket-Bewilligungsdienst-Anforderung (TGS) auch für Client A gilt.
Der TGS-Antrag:
Antwort des Domänencontrollers:
Nachdem der Computer Infra-App1 das Ticket erhält, versucht der Computer, eine Verbindung mit Client A herzustellen. Das Kerberos-Ticket ist in diesem Frame enthalten.
Schließlich gibt der Remoteclient einen Fehler zurück, da der Computer Infra-App1 eine Verbindung mit Client B herstellt.
Der Fehler wird erwartet, da Sie das richtige Ticket für das richtige Konto vorlegen müssen, damit Kerberos funktioniert.
Notiz
Weitere Informationen zu Kerberos finden Sie unter Kerberos für den Beschäftigt-Administrator.
Dieses Problem tritt nicht auf, wenn Sie anstelle des vollqualifizierten Domänennamens (Fully Qualified Domain Name, FQDN) ip-Adresse verwenden, da anstelle der Kerberos-Authentifizierung die NTLM-Authentifizierung (New Technology LAN Manager) verwendet wird. Wenn Sie die IP-Adresse zum Herstellen einer Verbindung mit dem Client verwenden, wird davon ausgegangen, mit welchem Client eine Verbindung hergestellt wird. Daher muss der Computer zuerst NTLM aushandeln. Für das Beispiel im Szenarioabschnitt gibt kerberos eine gültige Antwort zurück, sodass der Computer nicht fehlschlägt, um NTLM zu verwenden.
Auflösungen
Da dieses Problem mit veralteten DNS-Einträgen zusammenhängt, können Sie verschiedene Lösungen verwenden, um zu verhindern, dass das Problem auftritt.
Notiz
Für jede Auflösung wird empfohlen, das Gerüstintervall auf ein bis drei Tage zu senken. Der Standard für sieben Tage erweitert den Zeitraum, in dem ungültige Einträge im DNS verbleiben.
Lösung 1
Erhöhen Sie die DHCP-Leasedauer so, dass sie den Intervallen "No-refresh+ Refresh " entspricht. Im Beispiel im Szenarioabschnitt können Sie die DHCP-Lease auf 14 Tage erhöhen.
Vorteil:
DHCP-Leases verbleiben, bis der DNS-Eintrag gerüstet wird. Kein anderer Client empfängt und registriert die Adresse im DNS.
Nachteil:
Wenn der DHCP-Bereich bereits niedrig für Adressen ist, können die IP-Adressen ausfallen.
Ein kleiner Prozentsatz von Datensätzen kann aufgrund kleiner Zeitunterschiede nicht vor Ablauf der Lease gerüstet werden. Durch Festlegen des Gerüstintervalls auf einen Tag wird sichergestellt, dass die veralteten Datensätze am nächsten Tag entfernt werden.
Lösung 2
Verringern Sie die Intervalle "No-refresh+ Refresh ", um der DHCP-Lease zu entsprechen. Im Beispiel im Szenarioabschnitt können Sie sowohl "Keine Aktualisierung" als auch "Aktualisieren" auf vier Tage verringern.
Vorteil:
Der vorhandene DNS-Eintrag wird früher abgerüstet, um die gleichen Ergebnisse wie in der ersten Lösung zu erzielen.
Nachteil:
Wenn es sich hierbei um integrierte AD-DNS-Zonen handelt, erhöht sich die AD-Replikationshäufigkeit. Dies liegt daran, dass die DNS-Einträge häufiger von den Clients aktualisiert werden. Beispielsweise alle vier Tage statt alle sieben Tage.
Ein kleiner Prozentsatz von Datensätzen kann aufgrund kleiner Zeitunterschiede nicht vor Ablauf der Lease gerüstet werden. Durch Festlegen des Gerüstintervalls auf einen Tag wird sichergestellt, dass die veralteten Datensätze am nächsten Tag entfernt werden.
Auflösung 3
Zulassen, dass der DHCP-Server die Adressen im Auftrag der Clients registriert.
Vorteil:
Der DHCP-Server kann den DNS-Eintrag entfernen, sobald die Lease abläuft. Wenn das Setup korrekt ist, sollten keine doppelten Datensätze vorhanden sein.
Nachteil:
Die Einrichtung ist stärker beteiligt.
Ein Dienstkonto muss für die Ausführung des DHCP-Diensts eingerichtet werden, oder alle DHCP-Server müssen der DNSUpdateProxy-Gruppe (weniger sicher) hinzugefügt werden. Die Konfiguration fügt Komplexität hinzu.
Informationen hierzu finden Sie unter Konfigurieren dynamischer DNS-Updates in Windows.
Experimentieren Sie mit der DHCP-Leasedauer, dem No-Refresh-Intervall und dem Aktualisierungsintervall . Möglicherweise müssen Sie vollständig von den Standardwerten abweichen. Niedrige DHCP-Leasedauern (in den Stunden) werden manchmal für drahtlose Subnetze verwendet. Achten Sie jedoch auf die Leistung Ihrer Server, insbesondere, wenn Ein DNS-Server alle paar Stunden in großen DNS-Zonen gerüstet ist.
Identifizieren von Datensätzen mit doppelten IPs
In diesem Abschnitt wird erläutert, wie Sie PowerShell verwenden, um die doppelten Datensätze zu identifizieren. Das Skript zielt darauf ab, Einträge in DNS zu finden, die doppelte IP-Adressen enthalten.
#Import the Active Directory Module
import-module activedirectory
#Define an empty array to store computers with duplicate IP address registrations in DNS
$duplicate_comp = @()
#Get all computers in the current Active Directory domain along with the IPv4 address
#The IPv4 address is not a property on the computer account so a DNS lookup is performed
#The list of computers is sorted based on IPv4 address and assigned to the variable $comp
$comp = get-adcomputer -filter * -properties ipv4address | sort-object -property ipv4address
#For each computer object returned, assign just a sorted list of all
#of the IPv4 addresses for each computer to $sorted_ipv4
$sorted_ipv4 = $comp | foreach {$_.ipv4address} | sort-object
#For each computer object returned, assign just a sorted, unique list
#of all of the IPv4 addresses for each computer to $unique_ipv4
$unique_ipv4 = $comp | foreach {$_.ipv4address} | sort-object | get-unique
#compare $unique_ipv4 to $sorted_ipv4 and assign just the additional
#IPv4 addresses in $sorted_ipv4 to $duplicate_ipv4
$duplicate_ipv4 = Compare-object -referenceobject $unique_ipv4 -differenceobject $sorted_ipv4 | foreach {$_.inputobject}
#For each instance in $duplicate_ipv4 and for each instance
#in $comp, compare $duplicate_ipv4 to $comp If they are equal, assign
#the computer object to array $duplicate_comp
foreach ($duplicate_inst in $duplicate_ipv4)
{
foreach ($comp_inst in $comp)
{
if (!($duplicate_inst.compareto($comp_inst.ipv4address)))
{
$duplicate_comp = $duplicate_comp + $comp_inst
}
}
}
#Pipe all of the duplicate computers to a formatted table
$duplicate_comp | ft name,ipv4address -a
Hier ist ein Beispiel für die Ausgabe:
Dieses PowerShell-Skript ist einfach. Betrachten Sie das Skript als Beispiel. Dieses Skript gibt nur doppelte IP-Adressen zurück, die für tatsächliche Computerkonten in AD registriert sind. Denken Sie daran, dass das Skript jeden Computer in einer AD-Domäne abfragt. Anschließend wird eine DNS-Abfrage zum Abrufen der IP-Adresse verwendet. Wenn Sie über viele Computer verfügen, verwenden Sie den -searchbase Schalter get-adcomputer , um die Anzahl der Computer zu begrenzen, die jedes Mal zurückgegeben werden. Wenn der Computer nicht mit AD verbunden ist, wird der Computer nicht vom get-adcomputer Befehl zurückgegeben.