none
Domänencontroller entfernen mit Kontrolle von ev. noch laufenden Anfragen RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    in einem Netz mit mehreren DCs (srv201x) kommen neuen DCs (201x) dazu, die bisherigen werden dauerhaft abschaltet.
    Auf den alten DCs laufen die üblichen Dienste, wie ADDS, DNS, DHCP sowie auch weitere Drittanbieterdienste.

    Das Ziel ist nun, alle Dienste entsprechend zu übernehmen und die alten Server abzuschalten, möglichst ohne dass es die Benutzer mitgekommen (durch unschöne Fehlermeldungen etc.)

    Die neuen DCs haben bereits die ADDS Rolle erhalten, DNS wird brav ausgeführt, DHCP ist umgezogen, FSMO Rollen werden umgezogen; die Drittanbieterdienste wurden auch umgezogen, DNS Verweise auf die alten DCs entfernt bzw. auf die neuen DCs verwiesen.
    Die alten DCs wurden von der Last als GC befreit.

    Um nun sicher stellen zu können, dass die DCs nicht noch "versteckte" Anfragen von Clients mit irgendwo/irgendwann fest eingetragenen IPs zu diesen DCs erhalten (Zeitserver, DNS Anfragen, Anfragen an die Drittanbeiter-Dienste...), wollen wir den eingehenden Netzwerktraffic mitloggen (lokal oder Portspiegelung...); damit sehen wir, von wo ev. noch Anfragen rein kommen und können dies anpassen, bevor wir abschalten und dann jemand schreit.
    Um die Logs möglichst übersichtlich zu halten, hatten wir vor, die DNS SRV der alten DC raus zu nehmen, so dass diese von den Clients bzw. anfragenden Diensten nicht mehr verwendet werden. Ich glaube mich zu erinnern, dass der LogonDienst die SRV Einträge des DCs  regelmässig prüft und ggf. neu erstellt, wenn die nicht da sind - ist dem so?

    Weiterhin wollten wir die ein/ausgehende Replikation deaktivieren, um unnötige, immer wieder kehrende Meldungen auf den anderen DCs zu vermeiden und auch diesen Traffic im Log nicht durchstöbern müssen.

    Wir erwarten doch einiges an Traffic und würden uns leichter tun, wenn wir die obigen Punkte deaktivieren könnten.

    Was meint Ihr dazu?

    Freitag, 8. Mai 2020 09:14
    |

Antworten

  • Question
    Anmelden
    1
    Anmelden


    Was meint Ihr dazu?

    Richtige Problemstellung, falscher Lösungsansatz. Ihr werdet tonnenweise Logs durchsieben müssen, und die Ausbeute wird nicht zu 100% ausreichend sein, die noch anzupassenden Stellen zu finden.

    Gehen wir das mal durch:

    1. DHCP auf DCs ist sowieso gegen die Best Practices (Security), und die Migration war eure Chance, das zu ändern. Ist es immer noch :-)
    2. DNS. Das ist in der Regel die Stelle, wo euer "technical debt" euch am Empfindlichsten beißt. Will heißen, es ist nicht lückenlos dokumentiert, wo überall die alten DCs eingetragen sind, sonst bräuchtet ihr ja nicht zu sniffen. Da seid ihr übrigens in bester Gesellschaft, und die typische "Lösung" für dieses Problem ist, dass die neuen DCs die IP-Adressen der alten übernehmen. Das eliminiert zwar nicht den "technical debt", macht die Migration aber "geräuschloser" :-)
    3. DNS weiter. Die DNS-Server werden auf zwei Wegen gefunden: Entweder sie sind im anfragenden Client eingetragen (s. oben) oder der Client fragt nach dem NS Record der Domäne und nimmt einen DNS-Server von dort. Oder beides. In den Logs werdet ihr beide Szenarien vorfinden, ohne sie 100%-ig trennen zu können. Daher lasst die alten DCs einfach DNS machen, bis sie rausgehen und konzentriert euch darauf, auf den Client die Konfigurationen zu finden und anzupassen, wo die Nameserver eingetragen sind. Für Windows-basierte Domain Members kostet es eine Zeile PowerShell, das für alle herauszufinden, und zwei Zeilen PowerShell, das an die neuen Gegebenheiten anzupassen. Die Nicht-Member unter Windows könnte man auch abfrühstücken, wenn für jeden ein Admin-Konto bekannt ist. Schwieriger sind Linux-Kisten, Drucker, Netzwerkgeräte, Appliances usw. Siehe die "typische Lösung" im vorherigen Punkt.
    4. LDAP und Kerberos. Das ist ähnlich wie im vorherigen Punkt. Bei manchen Nicht-Domain-Clients wird ein DC für diese Dienste direkt eingetragen, andere fragen SRV-Records ab. Zweitere sind euch egal, denn die SRV-Records verschwinden mit dem Demoten, haurtsache, DNS ist korrigiert. Erstere zu finden, fällt auch unter "technical debt". Ich würde kritische Systeme identifizieren (z.B. RADIUS, NAP, Zugangskontrolle, Mail, ERP usw.) und diese explizit anschauen und bei Bedarf anpassen. Den Rest kann man, wenn es nicht dokumentiert ist, auf sich zukommen lassen.
    5. NTP. Falls Nicht-AD-Systeme NTP gegen DCs machen, ist es nahezu immer ein expliziter Eintrag. Viel Spaß damit, siehe "typische Lösung" im vorherigen Punkt. Vielleicht war jemand klug und hat dafür einen DNS Alias erstellt :-) Aber es gibt genug Systeme, wo man nur eine IP-Adresse als NTP eintragen kann.
    6. Third Party Stuff. Hat auf DCs generell nichts verloren, aber falls doch vorhanden, wird es ja vermutlich keine SRV-Records bemühen. Somit sind die Verweise immer explizit und fallen, falls nicht lückenlos dokumentiert, unter "technical debt". Diese könnt ihr aber wirklich mit Traffic Logging verfolgen, denn in der Regel ist die Third-Party-Kommunikation nicht mit den Standard-Protokollen zu verwecheln.

    Von der Deaktivierung der Replikation halte ich überhaupt nix. Macht deutlich mehr Probleme, als dass es hilft. Es wäre ja auch DNS betroffen. Macht eigentlich *nur* Probleme. Das ist für Disaster Recovery-Szenarien gedacht und hat dort seinen Platz - aber eben nur dort.

     

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Freitag, 8. Mai 2020 10:18
    |
  • Question
    Anmelden
    1
    Anmelden


    >...und die typische "Lösung" für dieses Problem ist, dass die neuen DCs die IP-Adressen der alten übernehmen...

    Ich bin aber eher untypisch ;)   Auch wenn es IP Adresstechnisch bzw. organisatorisch gegangen wäre (was nicht so ist), ich hätte diesen Weg nicht beschritten; so bekommen wir nun auch raus, wo dummerweise feste IP Adressen von DC/DNS/NTP etc. drin stehen und können das verbessern mit DNS Einträgen/Aliasen/LOAD Balancer Einträgen.

    Wenn ihr IP-Adressräume wechselt, lag die Idee mit den Sites natürlich ein Stück weit auf der Hand :-) Das Problem dabei ist, dass die meisten betroffenen Systeme vermutlich noch im alten Subnetz stehen und somit in der alten Site landen würden :-)

    Es gibt natürlich auch einen Mittelweg: Für Systeme, die nicht im AD sind und nur die Namensauflösung brauchen, stellt man einen DNS-Server bereit (kann Linux sein), der auf die alten IP-Adressen horcht und die Anfragen einfach nur weiterleitet. Und da er nicht im NS Record der Zonen steht, sind in *seinen* Logs wirklich nur die zu ändernden Systeme enthalten. Und ihr habt keinerlei Disruption im Betrieb.

    >...konzentriert euch darauf, auf den Client die Konfigurationen zu finden und anzupassen, wo die Nameserver eingetragen sind. Für Windows-basierte Domain Members kostet es eine Zeile PowerShell, das für alle herauszufinden, und zwei Zeilen PowerShell, das an die neuen Gegebenheiten anzupassen...

    Das stimmt (fast bzw. je nach dem, wie lange die eine/2 Zeilen PS sind) und liegt auch auf dem Brainstorming-Stapel.


    Die eine Zeile ist relativ kurz:

    Get-WmiObject -Class Win32_NetworkAdapterConfiguration -ComputerName (Get-ADComputer -Filter * | Select-Object -ExpandProperty DNSHostName) | Select-Object IPAddress, DNSServerSearchOrder

    oder so ähnlich, und dann halt filtern, um die alten Adressen zu finden. 

    Unter XP gab es sogar eine Gruppenrichtlinie, um DNS-Server verbindlich zu setzen, leider nur unter XP :-(

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Freitag, 8. Mai 2020 12:27
    |
  • Question
    Anmelden
    0
    Anmelden

    Hi André

    Ich gehe jeweils so vor:
    -LDAP monitoring auf den alten DC aktivieren -> welche Clients/Applikation etc. verbinden noch
    -Neue AD Site für die neuen Domain Controller erstellen
    -Subnetze unter Sites and Services von den alten DC (alte AD Site) auf die neue AD Site moven. (Auswirkung nur auf Windows Client Server etc., nicht auf Linux, Unix Systeme)

    -Logins monitoren (aber erst wenn LDAP, AD Site gewechselt wurde, sonst zu viele Events..)
    -Info an Applikationen (Umstellen falls IP oder fix DC in Connection Settings eingetragen sind

    DNS habe ich nicht auf den DC's resp. wir nutzten nicht MS DNS. DNS Einträge zu manipulieren würde ich nicht empfehlen-> Replikation. Ebenfalls würde ich die Replikation nicht verändern, gibt nur Probleme und macht eigentlich nichts wenn die Replikation weiterhin auf allen (alt und neu) läuft.

    Es gibt die Möglichkeit per Reg Key, den DC so zu konfigurieren, dass keine Authentifizierungsversuche mehr entgegengenommen werden -> google.com
    Ich glaube auch es gibt ein solches Setting für DNS abfragen.

    Für LDAP/LDAPS Anfragen würde ich Dir empfehlen, LDAP per Loadbalancer zu Verfügung stellen. So bist Du bei weiteren Migrationen flexibel und die Applikationen müssen sich nicht darum kümmern resp. nÄderungen an Verbindungen vornehmen. Oder, aber das hat bei uns nie geklappt, nicht auf DC zu verbinden sondern auf den Domain Alias.

    Ich habe die Erfahrung gemacht, dass ich leider nie alle "erwischt" habe die noch auf alte DC's verbinden. Daher über mehrere Wochen monitoren, Infos an Applikationen resp. an alle "Bezüger" von AD.

    Gruss, DaHa

    Freitag, 8. Mai 2020 10:05
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hi André

    Ich gehe jeweils so vor:
    -LDAP monitoring auf den alten DC aktivieren -> welche Clients/Applikation etc. verbinden noch
    -Neue AD Site für die neuen Domain Controller erstellen
    -Subnetze unter Sites and Services von den alten DC (alte AD Site) auf die neue AD Site moven. (Auswirkung nur auf Windows Client Server etc., nicht auf Linux, Unix Systeme)

    -Logins monitoren (aber erst wenn LDAP, AD Site gewechselt wurde, sonst zu viele Events..)
    -Info an Applikationen (Umstellen falls IP oder fix DC in Connection Settings eingetragen sind

    DNS habe ich nicht auf den DC's resp. wir nutzten nicht MS DNS. DNS Einträge zu manipulieren würde ich nicht empfehlen-> Replikation. Ebenfalls würde ich die Replikation nicht verändern, gibt nur Probleme und macht eigentlich nichts wenn die Replikation weiterhin auf allen (alt und neu) läuft.

    Es gibt die Möglichkeit per Reg Key, den DC so zu konfigurieren, dass keine Authentifizierungsversuche mehr entgegengenommen werden -> google.com
    Ich glaube auch es gibt ein solches Setting für DNS abfragen.

    Für LDAP/LDAPS Anfragen würde ich Dir empfehlen, LDAP per Loadbalancer zu Verfügung stellen. So bist Du bei weiteren Migrationen flexibel und die Applikationen müssen sich nicht darum kümmern resp. nÄderungen an Verbindungen vornehmen. Oder, aber das hat bei uns nie geklappt, nicht auf DC zu verbinden sondern auf den Domain Alias.

    Ich habe die Erfahrung gemacht, dass ich leider nie alle "erwischt" habe die noch auf alte DC's verbinden. Daher über mehrere Wochen monitoren, Infos an Applikationen resp. an alle "Bezüger" von AD.

    Gruss, DaHa

    Freitag, 8. Mai 2020 10:05
    |
  • Question
    Anmelden
    1
    Anmelden


    Was meint Ihr dazu?

    Richtige Problemstellung, falscher Lösungsansatz. Ihr werdet tonnenweise Logs durchsieben müssen, und die Ausbeute wird nicht zu 100% ausreichend sein, die noch anzupassenden Stellen zu finden.

    Gehen wir das mal durch:

    1. DHCP auf DCs ist sowieso gegen die Best Practices (Security), und die Migration war eure Chance, das zu ändern. Ist es immer noch :-)
    2. DNS. Das ist in der Regel die Stelle, wo euer "technical debt" euch am Empfindlichsten beißt. Will heißen, es ist nicht lückenlos dokumentiert, wo überall die alten DCs eingetragen sind, sonst bräuchtet ihr ja nicht zu sniffen. Da seid ihr übrigens in bester Gesellschaft, und die typische "Lösung" für dieses Problem ist, dass die neuen DCs die IP-Adressen der alten übernehmen. Das eliminiert zwar nicht den "technical debt", macht die Migration aber "geräuschloser" :-)
    3. DNS weiter. Die DNS-Server werden auf zwei Wegen gefunden: Entweder sie sind im anfragenden Client eingetragen (s. oben) oder der Client fragt nach dem NS Record der Domäne und nimmt einen DNS-Server von dort. Oder beides. In den Logs werdet ihr beide Szenarien vorfinden, ohne sie 100%-ig trennen zu können. Daher lasst die alten DCs einfach DNS machen, bis sie rausgehen und konzentriert euch darauf, auf den Client die Konfigurationen zu finden und anzupassen, wo die Nameserver eingetragen sind. Für Windows-basierte Domain Members kostet es eine Zeile PowerShell, das für alle herauszufinden, und zwei Zeilen PowerShell, das an die neuen Gegebenheiten anzupassen. Die Nicht-Member unter Windows könnte man auch abfrühstücken, wenn für jeden ein Admin-Konto bekannt ist. Schwieriger sind Linux-Kisten, Drucker, Netzwerkgeräte, Appliances usw. Siehe die "typische Lösung" im vorherigen Punkt.
    4. LDAP und Kerberos. Das ist ähnlich wie im vorherigen Punkt. Bei manchen Nicht-Domain-Clients wird ein DC für diese Dienste direkt eingetragen, andere fragen SRV-Records ab. Zweitere sind euch egal, denn die SRV-Records verschwinden mit dem Demoten, haurtsache, DNS ist korrigiert. Erstere zu finden, fällt auch unter "technical debt". Ich würde kritische Systeme identifizieren (z.B. RADIUS, NAP, Zugangskontrolle, Mail, ERP usw.) und diese explizit anschauen und bei Bedarf anpassen. Den Rest kann man, wenn es nicht dokumentiert ist, auf sich zukommen lassen.
    5. NTP. Falls Nicht-AD-Systeme NTP gegen DCs machen, ist es nahezu immer ein expliziter Eintrag. Viel Spaß damit, siehe "typische Lösung" im vorherigen Punkt. Vielleicht war jemand klug und hat dafür einen DNS Alias erstellt :-) Aber es gibt genug Systeme, wo man nur eine IP-Adresse als NTP eintragen kann.
    6. Third Party Stuff. Hat auf DCs generell nichts verloren, aber falls doch vorhanden, wird es ja vermutlich keine SRV-Records bemühen. Somit sind die Verweise immer explizit und fallen, falls nicht lückenlos dokumentiert, unter "technical debt". Diese könnt ihr aber wirklich mit Traffic Logging verfolgen, denn in der Regel ist die Third-Party-Kommunikation nicht mit den Standard-Protokollen zu verwecheln.

    Von der Deaktivierung der Replikation halte ich überhaupt nix. Macht deutlich mehr Probleme, als dass es hilft. Es wäre ja auch DNS betroffen. Macht eigentlich *nur* Probleme. Das ist für Disaster Recovery-Szenarien gedacht und hat dort seinen Platz - aber eben nur dort.

     

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Freitag, 8. Mai 2020 10:18
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo DaHa, Hallo Evgenij,

    danke für die superschnelle Rückmeldungen :)

    Kurz zu Euren Antworten:

    @DaHa:
    Die Idee mit den Sites finde ich gar nicht schlecht. Dann nutzen die Clients (idealerweise) die alten DCs nicht mehr, falls sie nicht böderweise im gleichen Subnetz sind :(    Weniger Login-Event-Durchsuchungen....Danke :)
    Bzgl. der Drittanbieter-Apps: Hier sind wir wohl auf Mitschniffen der (bekannten) Ports angewiesen, da unklar ist, wo überall auf welchem Client feste Einträge Richtung dieser Dienste auf den alten DCs noch drin stehen.
    Das gleiche werden wir für DNS machen müssen.

    > Es gibt die Möglichkeit per Reg Key, den DC so zu konfigurieren, dass keine Authentifizierungsversuche mehr entgegengenommen werden -> google.com;Ich glaube auch es gibt ein solches Setting für DNS abfragen.

    Hört sich gut an, schau mer mal :)

    LDAP/S Monitoring brauchen wir nicht, da haben wir eine LoadBalancer davor bzw. verwenden einen passenden DNS Eintrag Richtung LB.

    >Ich habe die Erfahrung gemacht, dass ich leider nie alle "erwischt" habe die noch auf alte DC's verbinden. Daher über mehrere Wochen monitoren, Infos an Applikationen resp. an alle "Bezüger" von AD.

    Ich kann nur sagen: JA. Davon gehen wir auch aus, wäre nur schön, wenn wir 98% vorab erwischen würden.

    @Evgenij:

    > DHCP und Best Practice: Da gebe ich Dir Recht, steht nun auf die Liste der zu erledigenden Punkte. Danke.

    >...und die typische "Lösung" für dieses Problem ist, dass die neuen DCs die IP-Adressen der alten übernehmen...

    Ich bin aber eher untypisch ;)   Auch wenn es IP Adresstechnisch bzw. organisatorisch gegangen wäre (was nicht so ist), ich hätte diesen Weg nicht beschritten; so bekommen wir nun auch raus, wo dummerweise feste IP Adressen von DC/DNS/NTP etc. drin stehen und können das verbessern mit DNS Einträgen/Aliasen/LOAD Balancer Einträgen.

    >In den Logs werdet ihr beide Szenarien vorfinden, ohne sie 100%-ig trennen zu können

    Wir könnten die Nameserverrecords der Domäne so anpassen, dass hier die alten DCs nicht aufgeführt werden; somit hätten wir dann im Log "nur" noch die Direktanfragen von fest eingetragenen DNS.

    >...konzentriert euch darauf, auf den Client die Konfigurationen zu finden und anzupassen, wo die Nameserver eingetragen sind. Für Windows-basierte Domain Members kostet es eine Zeile PowerShell, das für alle herauszufinden, und zwei Zeilen PowerShell, das an die neuen Gegebenheiten anzupassen...

    Das stimmt (fast bzw. je nach dem, wie lange die eine/2 Zeilen PS sind) und liegt auch auf dem Brainstorming-Stapel.

    >...Ich würde kritische Systeme identifizieren (z.B. RADIUS, NAP, Zugangskontrolle, Mail, ERP usw.) und diese explizit anschauen und bei Bedarf anpassen...

    Server bzw. solche Dienste werden explizit angeschaut, es geht um die Dinge, die wir nicht in der Doku drin haben. Diese Vorgehensweise ist auch unsere Meinung.

    >den Rest kann man, wenn es nicht dokumentiert ist, auf sich zukommen lassen....

    Nunja, das kommt immer drauf an, in welchem Umfeld man sich bewegt; im Büro ist das leicht, in Produkltionsumgebung eher doof, nachts um 3h angerufen zu werden, weil grad jetzt der Controller meint, nach einem 12h Timeout zu melden, das er "seinen" 3rd Party Dienst aufgrund eines nicht erreichbaren DNS mehr  nicht erreichen kann.

    >...NTP Vielleicht war jemand klug und hat dafür einen DNS Alias erstellt :-)

    War er, ähm Ich vor langer Zeit schon für so manchen Dienst  :)  Dooferweise gibt es auch im Jahr 2020 neu hergestellte Geräte (vornehmlich Produktionssteuerungen und anderes technisches Zeugs, was IP sprechen will bzw muss), welche nur IPs zulassen...
    Aber zukünftigt kein Problem, LoadBalancer eintragen :)

    >Third Party Stuff. Hat auf DCs generell nichts verloren

    Jo, 100% deckungsgleich; dies war auf den alten so und wir auf den neuen so nicht mehr gemacht, ggf.  habe ich mich ungünstig ausgedrückt.

    >Von der Deaktivierung der Replikation halte ich überhaupt nix. Macht deutlich mehr Probleme, als dass es hilft. Es wäre ja auch DNS betroffen. ..

    DNS für den DC wäre insoweit betroffen, dass er keine aktuellen DNS Einträge mehr empfängt; abfragen könnte er die aber schon per Einträgung der anderen, neuen DC/DNS Server in seinen Netzwerkeinstellungen.
    Ich nehme trotzdem Deine Hinweise dazu auf, hier fehlt mir einfach noch die Erfahrung damit. Danke.

    Vielen, vielen Dank an Euch für die Anstöße!

    Freitag, 8. Mai 2020 11:05
    |
  • Question
    Anmelden
    1
    Anmelden


    >...und die typische "Lösung" für dieses Problem ist, dass die neuen DCs die IP-Adressen der alten übernehmen...

    Ich bin aber eher untypisch ;)   Auch wenn es IP Adresstechnisch bzw. organisatorisch gegangen wäre (was nicht so ist), ich hätte diesen Weg nicht beschritten; so bekommen wir nun auch raus, wo dummerweise feste IP Adressen von DC/DNS/NTP etc. drin stehen und können das verbessern mit DNS Einträgen/Aliasen/LOAD Balancer Einträgen.

    Wenn ihr IP-Adressräume wechselt, lag die Idee mit den Sites natürlich ein Stück weit auf der Hand :-) Das Problem dabei ist, dass die meisten betroffenen Systeme vermutlich noch im alten Subnetz stehen und somit in der alten Site landen würden :-)

    Es gibt natürlich auch einen Mittelweg: Für Systeme, die nicht im AD sind und nur die Namensauflösung brauchen, stellt man einen DNS-Server bereit (kann Linux sein), der auf die alten IP-Adressen horcht und die Anfragen einfach nur weiterleitet. Und da er nicht im NS Record der Zonen steht, sind in *seinen* Logs wirklich nur die zu ändernden Systeme enthalten. Und ihr habt keinerlei Disruption im Betrieb.

    >...konzentriert euch darauf, auf den Client die Konfigurationen zu finden und anzupassen, wo die Nameserver eingetragen sind. Für Windows-basierte Domain Members kostet es eine Zeile PowerShell, das für alle herauszufinden, und zwei Zeilen PowerShell, das an die neuen Gegebenheiten anzupassen...

    Das stimmt (fast bzw. je nach dem, wie lange die eine/2 Zeilen PS sind) und liegt auch auf dem Brainstorming-Stapel.


    Die eine Zeile ist relativ kurz:

    Get-WmiObject -Class Win32_NetworkAdapterConfiguration -ComputerName (Get-ADComputer -Filter * | Select-Object -ExpandProperty DNSHostName) | Select-Object IPAddress, DNSServerSearchOrder

    oder so ähnlich, und dann halt filtern, um die alten Adressen zu finden. 

    Unter XP gab es sogar eine Gruppenrichtlinie, um DNS-Server verbindlich zu setzen, leider nur unter XP :-(

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Freitag, 8. Mai 2020 12:27
    |