NLA auf Domänencontroller - unerwartetes Verhalten

Moin.

Hier ist gerade folgendes Verhalten aufgefallen:
Wir haben 2 DCs. Nach einem geplanten Reboot (Wartung am Stromnetz) ist der eine einige Minuten vor dem anderen wieder hochgefahren worden.

Während der zweite kein Problem hat, hat sich die Netzwerkkarte des zuerst gebooteten DCs in das Netzwerkprofil "öffentlich" anstatt "Domäne" gesetzt, was zur Folge hatte, dass diverse Ports geschlossen waren, die offen sein sollen. Dieser Zustand änderte sich auch nicht von alleine, sondern die Karte musste erst deaktiviert, dann wieder aktiviert werden.

Dafür ist ja der Dienst "network location awareness" ("NLA") verantwortlich. Nun schreibt ja Microsoft

the domain network location type is detected when the local computer is a member of an Active Directory domain, and the local computer can authenticate to a domain controller for that domain through one of its network connections.

was ja auch stimmt, nur wie soll das bei DCs denn überhaupt funktionieren, wenn einmal wie bei uns beide down sind?

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 519946

Url: https://administrator.de/forum/nla-auf-domaenencontroller-unerwartetes-verhalten-519946.html

Ausgedruckt am: 12.04.2025 um 07:04 Uhr

14 Kommentare

Neuester Kommentar

Moin,

ist bei dem betreffenden DC denn auch als DNS erst er selbst und dann der zweite eingetragen?
Die ganze NLA Thematik kann echt ein Graus sein.
In dieser Konstellation sollte das eigentlich nicht auftreten. Ansonsten wurde mal empfohlen den NLA Dienst verzögert zu starten.

Gruß
Spirit

Moin,

ich mache das seit Jahren anders rum, also erster DNS der andere und dann als zweiten den eigenen, hakt auch nicht wenn beide DCs down sind/waren, ist aber größtenteils noch 2008R2, vielleicht sind neuere Server Versionen empfindlicher.

Gruss

Moin,

welche Serverversionen sind das und ob das feste IPs sind, muss ich bei Dir nicht fragen

Gruss

Hi,

schau dir mal diesen Beitrag an.
https://serverfault.com/questions/362374/domain-controller-thinks-its-on ...

Hatte das Problem auch und hab den NLA Dienst auf verzögerter Start gesetzt und weg wars.

Grüße

Um gleich auf alle 4 einzugehen:

-feste IPs ist klar.
-Server 2016 1607 (aktuell)
-in seiner NIC ist als erster DNS der andere DC eingetragen und als zweiter 127.0.0.1 (das ist so empfohlen von MS)

Ich denke auch, dass ich bei NLA einfach eine Abhängigkeit von den Diensten NTDS und DNS einrichten werde, und fertig.

Hallo DWW,
das wird ein Nebeneffekt des Insel-Effekts sein. Da der erste DC beim Start allein war, und ich vermute die DNS-Zone AD-integriert ist, hat er sein AD nicht rechtzeitig starten können und das NLA hat zwischenzeitlich keine Domäne ermitteln können.

Dafür haben bei uns folgenden Würgarround eingesetzt:

Wir haben einen Nicht-DC als DNS mit klassicher Sekundär-Zone
bei geplanten Blackouts (alle DC aus) bekommt der "Master"-DC (mit dem bevorzugtend DNS) diesen Member-Server-DNS temporär als 1. DNS-Server eingetragen.
der Member-Server-DNS wird nach dem Blackout als erstes gestartet
dann der "Master"-DC
dann alle anderen DC's
dann der "Master"-DC wieder auf "normal" konfiguriert

Bei ungeplanten Blackouts muss man eben von Hand eingreifen. Aber sowas passiert bei uns im Rechenzentrum hoffentlich nie. Bisher noch nicht.

E.

Ich denke, mein Würgaround gefällt mir da besser, emeriks. Aber ja, ich denke auch, der Inseleffekt ist es.

Sers,

das Problem kenne ich leider auch. Tritt übrigends auch auf, wenn du nur einen DC hast.

was ja auch stimmt, nur wie soll das bei DCs denn überhaupt funktionieren, wenn einmal wie bei uns beide down sind?

Eigentlich sollte der DC ja auf sich selbst auflösen können. Klappt halt nicht, wenn der NLA sich mal wieder verhaspelt hat. Wie so oft...

Ich habs mit einem PoSh Skript gelöst, das nach dem Systemstart auf den Servern läuft.
Vereinfacht:

while((Get-NetConnectionProfile).name -ne "domain.name")  
{
   Restart-Service -Name "NlaSvc" -Force  
   Start-Sleep -Seconds 60
}

@psannz
Interessanter Ansatz. Aber warum dann nicht gleich mit Set-NetConnectionProfile vorgeben, statt den Dienst neu zu starten?

@psannz

Jou, das hatte ich auch als Möglichkeit gesehen. @emeriks: weil es nicht geht. Versuch es mal, spaßeshalber (auf einem Client).

Warum soll das nicht gehen?

$P = Get-NetConnectionProfile -InterfaceAlias Ethernet
$P.NetworkCategory = "DomainAuthenticated"  
Set-NetConnectionProfile -InputObject $P

Oder was übersehe ich?

Du übersiehst den Unterschied zwischen Theorie und Praxis.
Windows erlaubt es nicht, manuell auf Domäne umzustellen, da dies ein Herabsetzen der Firewallregeln bedeutet.
Nur Windows selbst darf entscheiden dass die Karte Teil eines Domänenverbundenen PCs ist, nicht einmal der Admin.