Ich verwalte ein System, das aus Gründen, die außerhalb meiner Kontrolle liegen, einen disjunkten DNS-Namespace hat. Mir gefällt das nicht, aber so ist es nun einmal und ich habe keine Möglichkeit, das zu ändern. Der Grund ist, dass die Server mit einer bereits vorhandenen DNS-Infrastruktur koexistieren müssen.
Die Windows-Domäne hat einen Namen wie ad.example.com mit einem NETBIOS-Namen von AD. Alle DNS-Server haben jedoch ihr primäres DNS-Suffix entweder auf "example.com" oder auf "sub.example.com" gesetzt, je nachdem, wo im Netzwerk sie sich befinden. Ich habe das Attribut msDS-AllowedDNSSuffixes in der Domäne entsprechend demErstellen Sie einen Disjoint Namespace-Artikel auf Technet.
Der DNS für die Domäne ad.example.com wird auf den beiden Domänencontrollern in der Umgebung ausgeführt, und der DNS für example.com und sub.example.com wird auf anderen DNS-Servern ausgeführt, die nicht von Microsoft stammen.
In dieser Umgebung wird DNS manuell verwaltet, anstatt sich auf dynamische DNS-Registrierung und -Updates zu verlassen.
Die Umgebung funktioniert einwandfrei, abgesehen von einigen lästigen Warnfehlern in den Ereignisprotokollen, die folgendermaßen aussehen:
The system failed to register host (A or AAAA) resource records (RRs) for
network adapter with settings:
Adapter Name : <censored>
Host Name : <censored>
Primary Domain Suffix : sub.example.com
DNS server list :
<censored> (These are the domain controllers for ad.example.com)
Sent update to server : <?>
IP Address(es) :
<censored> (This is the IP address of the host in question)
The reason the system could not register these RRs was because of a security related
problem. The cause of this could be (a) your computer does not have permissions
to register and update the specific DNS domain name set for this adapter, or
(b) there might have been a problem negotiating valid credentials with the DNS
server during the processing of the update request.
You can manually retry DNS registration of the network adapter and its settings
by typing 'ipconfig /registerdns' at the command prompt. If problems still persist,
contact your DNS server or network systems administrator. See event details for
specific error code information.
Die Fehler erscheinen im Systemprotokoll mit der Quelle „DNS-Client-Ereignisse“ auf der Warnstufe und der Ereignis-ID 8015.
Bei einem Paket-Sniffing scheint es, als würden die Windows-Boxen dynamische DNS-Updates an den autoritativen DNS-Server von sub.example.com senden, der dynamische Updates nicht unterstützt (und wir möchten sie auch nicht aktivieren).
Daher haben wir uns die Aufgabe gestellt, die dynamischen DNS-Updates mithilfe der Gruppenrichtlinie zu deaktivieren.
Am Freitag habe ich eine Gruppenrichtlinie erstellt und sie wie im folgenden Screenshot oben in der Domäne verknüpft:
Die Richtlinie „Computerkonfiguration/Richtlinien/Administrative Vorlagen/Netzwerk/DNS-Client/Dynamische Updates“ wurde auf „Deaktivieren“ gesetzt.
Allerdings werden diese Ereignisse auch nach mehreren Tagen (ausreichend Zeit, damit die Gruppenrichtlinie repliziert und auf die Server angewendet werden kann) weiterhin in den Protokollen angezeigt.
Ich habe mit GPRESULT überprüft, ob die Richtlinie tatsächlich auf dem betreffenden Server angewendet wurde.
Die Ausgabe gpresult /scope Computer /vist hier unten (wobei einige irrelevante Daten zu Anonymisierungszwecken entfernt wurden):
Microsoft (R) Windows (R) Operating System Group Policy Result tool v2.0
© 2013 Microsoft Corporation. All rights reserved.
Created on 2015-10-05 at 15:06:54
RSOP data for AD\ad79632 on BESTLA : Logging Mode
--------------------------------------------------
OS Configuration: Member Server
OS Version: 6.3.9600
Site Name: Example
Roaming Profile: N/A
Local Profile: C:\Users\ad79632
Connected over a slow link?: No
COMPUTER SETTINGS
------------------
CN=BESTLA,OU=Servers,OU=Computers,OU=SHEM,DC=ad,DC=example,DC=com
Last time Group Policy was applied: 2015-10-05 at 14:09:58
Group Policy was applied from: dc02.example.com
Group Policy slow link threshold: 500 kbps
Domain Name: AD
Domain Type: Windows 2008 or later
Applied Group Policy Objects
-----------------------------
<some GPOs omitted for security reasons>
Disable Dynamic DNS Updates
The following GPOs were not applied because they were filtered out
-------------------------------------------------------------------
Local Group Policy
Filtering: Not Applied (Empty)
The computer is a part of the following security groups
-------------------------------------------------------
BUILTIN\Administrators
Everyone
BUILTIN\Users
RDS Endpoint Servers
RDS Management Servers
RDS Remote Access Servers
NT AUTHORITY\NETWORK
NT AUTHORITY\Authenticated Users
This Organization
BESTLA$
Day-active Computers
Domain Computers
Authentication authority asserted identity
System Mandatory Level
Resultant Set Of Policies for Computer
---------------------------------------
Software Installations
----------------------
N/A
Startup Scripts
---------------
N/A
Shutdown Scripts
----------------
N/A
Account Policies
----------------
<some GPOs omitted for security reasons>
Audit Policy
------------
N/A
User Rights
-----------
N/A
Security Options
----------------
<some GPOs omitted for security reasons>
Event Log Settings
------------------
N/A
Restricted Groups
-----------------
N/A
System Services
---------------
N/A
Registry Settings
-----------------
N/A
File System Settings
--------------------
N/A
Public Key Policies
-------------------
N/A
Administrative Templates
------------------------
<some GPOs omitted for security reasons>
GPO: Disable Dynamic DNS Updates
Folder Id: SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\RegistrationEnabled
Value: 0, 0, 0, 0
State: Enabled
<some GPOs omitted for security reasons>
Der betreffende Registrierungsschlüssel wurde tatsächlich aktualisiert, wie in diesem Screenshot zu sehen ist:
Also, was übersehe ich?
Antwort1
Es scheint, dass ich alles richtig gemacht habe, außer dass ein Neustart notwendig war, um das Auftreten dieser Meldungen zu verhindern, wie @Brian in einem Kommentar vorgeschlagen hat.
Ich werde einfach bis zu unserem nächsten Patch-Fenster warten, was ohnehin einen Neustart der Server bedeutet, da dies kein kritisches Problem ist. Ich gehe davon aus, dass diese Meldung dann auf allen Servern verschwunden ist.