116617
Jun 17, 2014, updated at 10:07:47 (UTC)
4858
9
0
Nicht definierte Subnetze im AD erkennen
Guten Tag,
Ich habe folgende Problemstellung vor mir:
Wir betreiben ein Active Directory mit Windows Server 2008 R2 und wollen Standorte definieren. Momentan sind 6 Domänencontroller in einer Site ohne definierte Subnetze konfiguriert. Das soll sich ändern. Zwei der Domänencontroller stehen physikalisch an einem jeweils anderem Standort und sind mit dem Hauptsandort A per Gigabit angebunden und bilden zusammen mit den anderen die FirstSite. Zukünftig sollen sie als Standortdomänencontroller konfiguriert werden. Jetzt habe ich unseren Netzwerkern den Auftrag gegeben mir alle Subnetze zukommen zu lassen, um diese dann alle dem Hauptstandort A zuzuweisen und die Betreffenden auf die jeweiligen Standorte zu verteilen. Ich möchte vorweg sicherstellen, das wir alle Subnetze wirklich abgefangen und definiert haben. Gibt es eine Möglichkeit herauszufinden, aus welchen Subnetzen sich die Clients im Active Directory anmelden? Ich dachte da vielleicht an Powershell oder Aktivierung eines bestimmten Audits im Windows Server 2008 R2 als Beispiel. Ich meine auch gelesen zu haben, das wenn man die Standorte über die Subnetze definiert hat, eine Ereignislogmeldung erzeugt wird, wenn Clients sich aus einem nicht definierten Subnetz anmelden wollen. Ist das richtig?
Gruß
Skywalkersz
Ich habe folgende Problemstellung vor mir:
Wir betreiben ein Active Directory mit Windows Server 2008 R2 und wollen Standorte definieren. Momentan sind 6 Domänencontroller in einer Site ohne definierte Subnetze konfiguriert. Das soll sich ändern. Zwei der Domänencontroller stehen physikalisch an einem jeweils anderem Standort und sind mit dem Hauptsandort A per Gigabit angebunden und bilden zusammen mit den anderen die FirstSite. Zukünftig sollen sie als Standortdomänencontroller konfiguriert werden. Jetzt habe ich unseren Netzwerkern den Auftrag gegeben mir alle Subnetze zukommen zu lassen, um diese dann alle dem Hauptstandort A zuzuweisen und die Betreffenden auf die jeweiligen Standorte zu verteilen. Ich möchte vorweg sicherstellen, das wir alle Subnetze wirklich abgefangen und definiert haben. Gibt es eine Möglichkeit herauszufinden, aus welchen Subnetzen sich die Clients im Active Directory anmelden? Ich dachte da vielleicht an Powershell oder Aktivierung eines bestimmten Audits im Windows Server 2008 R2 als Beispiel. Ich meine auch gelesen zu haben, das wenn man die Standorte über die Subnetze definiert hat, eine Ereignislogmeldung erzeugt wird, wenn Clients sich aus einem nicht definierten Subnetz anmelden wollen. Ist das richtig?
Gruß
Skywalkersz
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 241122
Url: https://administrator.de/contentid/241122
Printed on: April 24, 2024 at 07:04 o'clock
9 Comments
Latest comment
Hallo Skywalkersz,
ich würde dazu einfach die Doku konsultieren, normalerweise richtet man sowas aber direkt bei der Einrichtung ein.
Grüße,
Christian
ich würde dazu einfach die Doku konsultieren, normalerweise richtet man sowas aber direkt bei der Einrichtung ein.
Grüße,
Christian
1
Hallo Christian,
Ich möchte dir nicht die Konzernstruktur näher bringen, die dir erläutern würde, warum ich der bestehenden Doku nicht trauen kann.^^ Ich brauche eine technische Lösung ,die die Doku untermauert oder eben vervollständigt um sie dann auch aktiv nutzen zu können.
Gruß
Florian
Ich möchte dir nicht die Konzernstruktur näher bringen, die dir erläutern würde, warum ich der bestehenden Doku nicht trauen kann.^^ Ich brauche eine technische Lösung ,die die Doku untermauert oder eben vervollständigt um sie dann auch aktiv nutzen zu können.
Gruß
Florian
Hallo Florian,
dann solltest du oder ein dritter dich hinsetzen und die Doku checken, ist zwar mühsam, aber danach hast du wenigstens eine, der du trauen kannst. Gerade bei einem solchen Netz ohne Zweifel sinnvoll.
Grüße,
Christian
dann solltest du oder ein dritter dich hinsetzen und die Doku checken, ist zwar mühsam, aber danach hast du wenigstens eine, der du trauen kannst. Gerade bei einem solchen Netz ohne Zweifel sinnvoll.
Grüße,
Christian
mhmm ok scheinbar habe ich mich nicht unmissverständlich ausgedrückt.. also anders: Gehe mal davon aus, das es Netze geben kann, die uns nicht bekannt sind, aber durchaus Clients beinhalten können, die sich im AD anmelden. Wir haben 7000 Clients im Netzwerk, Bereiche die im Konzern durch eine eigene IT verwaltet werden und nicht von mir. Somit sind die Netze in der Dokumentation NICHT definiert. Ich brauche eine TECHNISCHE LÖSUNG die diesen Misstand eben bereinigen kann, um Standorte definieren zu können.
Gruß
Florian
Gruß
Florian
Nein, hast du nicht, aber die Technische Lösung ist es die Doku auf den Vordermann zu bringen, wenn du das nicht kannst (aus welchen Gründen auch immer) bist du vermutlich der falsche für den Job.
Vor allem, was ist das für eine Organisation, in der der externe nicht weiss, wie das Interne Netz strukturiert ist? Geht in Richtung Topfschlagen.
Vor allem, was ist das für eine Organisation, in der der externe nicht weiss, wie das Interne Netz strukturiert ist? Geht in Richtung Topfschlagen.
Hi,
falls du eine automatisierte Lösung suchst, ich glaube die gibt es nicht.
Ich, an deiner Stelle, würde jeder Standort in ein eigener IP Bereich stecken.
Jeder Standort bekommt dann einen DC, oder einen "Read Only DC" falls die Umgebung dort nicht besonders vertrauenswürdig ist.
Falls die Remote Standorte sich per VPN verbinden, sollte man auf dem Firewall nur Packete erlauben die aus von dir definiertem IP Bereich stammen.
Dann noch auf DC schauen wer und mit welcher Adresse sich verbindet, und die vergessene Netze in deine Strucktur integrieren, oder Sperren. Je nach dem was mit fremden Netzen passieren soll.
MfG.
falls du eine automatisierte Lösung suchst, ich glaube die gibt es nicht.
Ich, an deiner Stelle, würde jeder Standort in ein eigener IP Bereich stecken.
Jeder Standort bekommt dann einen DC, oder einen "Read Only DC" falls die Umgebung dort nicht besonders vertrauenswürdig ist.
Falls die Remote Standorte sich per VPN verbinden, sollte man auf dem Firewall nur Packete erlauben die aus von dir definiertem IP Bereich stammen.
Dann noch auf DC schauen wer und mit welcher Adresse sich verbindet, und die vergessene Netze in deine Strucktur integrieren, oder Sperren. Je nach dem was mit fremden Netzen passieren soll.
MfG.
Hallo,
Je kleiner eine Firma ist um so eher kann mal etwas auf dem so genannten "kl. Dienstweg"
regeln und um so größer eine Firma wird um so mehr muss bzw. sollte man tunlichst alles
miteinander regeln und zwar so das man es auch in gewissen Situationen noch beherschen
kann, und am besten noch so das alle wissen was sie zu tun haben!
Hast Du keine Dokumentation die alle Bereich erfasst und beschreibt, bekommst Du bzw.
Euer Betrieb früher oder später immer mal wieder ein kleines oder ein großes Problem.
Ist nicht zwingend, aber leider immer öfter als einem lieb ist der Fall!
und ist erforderlich. Was wollt Ihr denn machen wenn Ihr erst mal 25.000 Leute seit?
Bei 7000 Nutzern würde ich mal sagen wäre eine Meldung pro IT Abteilung an eine bestimmte
Person am Donnerstag recht sinnvoll, die dann am Freitag mit allen anderen Personen die
eine IT Abteilung vertreten eine kleine Konferenz abhalten!
- Was lief in der Vergangenheit nicht und wo gab es Probleme
- Wo stehen wir heute und was wird gerade umgesetzt
- Welchen Aufgaben stellen wir uns morgen bzw. zukünftig
- Eintragen sich verändert hat in der Einzel und Gesamtstruktur für die Dokumentation
- Rückmeldung und Mitteilung an die IT Abteilungen und kurze Erläuterung dazu.
So schafft man sich einen guten Gesamtüberblick und das ist sicherlich auch hinsichtlich
der Informationslage der GL & GF nicht abträglich.
Dokumentation vor Ort die dann aber auch immer passen und stimmen muss, also
aktuell gehalten ist.
von dem niemand etwas weiß nur eben Eure Leute vor Ort, dann kann das natürlich auch
bei den anderen Standorten so aussehen und wie möchte man diese denn nun erfassen?
Die sind mitunter völlig autark vom restlichen Netzwerk vor Ort und somit nicht zu erfassen.
So nun zu der technische Lösung, da stehen dann sicherlich mehrere
Möglichkeiten zur Verfügung die man aber mitunter auch kombinieren
kann, nur das muss dann eben auch wieder jeder selber wissen wie er
das am besten bei sich vor Ort umsetzt!
Ich nenne jetzt einmal drei unterschiedliche Methoden dazu:
Möglichkeit 1:
- PRTG mit einer Lizenz
- Eine eigene Appliance pro Standort dazu bzw. dafür
- Verbunden über einen eigenen VPN Server in der DMZ
Das würde ich mal sagen wäre der Klassiker, schnell und einfach aufzusetzen und
zu warten mit Support und einfach zu lernen.
Vorteile; Schnelle Implementierung, kann zu Clustern zusammen gefasst werden
die sich gegenseitig ersetzen und/oder ergänzen, schnelle Einfindung in das Programm,
automatische Updates des Netzwerkes in Echtzeit, es lassen sich alle Netzwerkgeräte überwachen.
Nachteile: Es kostet erst einmal Geld, und ein eigene Hardware sollte es dann auch sein.
Möglichkeit 2:
- Incinga oder Nagios auf einem eigenen Server
- Und dann eben zwei Programmierer einstellen die alles anpassen bzw.
alles von extern anpassen lassen
Ist auch ein Klassiker, nur eben auf OpenSource Basis.
Vorteile: Ausgewogene Kosten, man kann selber bestimmen was alles überwacht wird.
Kann immer wieder den persönlichen und/oder betrieblichen Bedürfnissen angepasst werden.
Nachteil: Ist der Programmierer "weg" ist eine weitere Anpassung meist schwer!
Möglichkeit 3:
- Pro Standort einmal Dokusnap, Zabbix oder Spiceworks durchlaufen lassen
und alles an eine einzige Stelle leiten wo dann die gesamten Strukturen
in einen Masterplan oder Master- bzw. Hauptdokumentation eingetragen werden.
das muss dann aber jedes Mal wieder erfolgen und man muss das dann auch wieder
gemeldet und eingetragen werden um es aktuell zu halten!
Vorteil: Geringe Kosten, Kann auch ohne Einarbeitung schnell laufen
Nachteil: Viel Handarbeit, Manpower und keine automatische Aktualisierung
Gruß
Dobby
mhmm ok scheinbar habe ich mich nicht unmissverständlich ausgedrückt.. also anders:
Wir haben das schon verstanden nur Du den Christian wohl nicht so recht!Je kleiner eine Firma ist um so eher kann mal etwas auf dem so genannten "kl. Dienstweg"
regeln und um so größer eine Firma wird um so mehr muss bzw. sollte man tunlichst alles
miteinander regeln und zwar so das man es auch in gewissen Situationen noch beherschen
kann, und am besten noch so das alle wissen was sie zu tun haben!
Hast Du keine Dokumentation die alle Bereich erfasst und beschreibt, bekommst Du bzw.
Euer Betrieb früher oder später immer mal wieder ein kleines oder ein großes Problem.
Ist nicht zwingend, aber leider immer öfter als einem lieb ist der Fall!
Gehe mal davon aus, das es Netze geben kann, die uns nicht bekannt sind, aber
durchaus Clients beinhalten können, die sich im AD anmelden.
Also an einem AD den Du kontrollierst wird das wohl eher nicht der Fall sein, oder?durchaus Clients beinhalten können, die sich im AD anmelden.
Wir haben 7000 Clients im Netzwerk, Bereiche die im Konzern durch eine eigene IT
verwaltet werden und nicht von mir.
Siehst Du das meinte ich weiter oben! Je größer der "Laden" wird, je mehr Zusammenarbeitverwaltet werden und nicht von mir.
und ist erforderlich. Was wollt Ihr denn machen wenn Ihr erst mal 25.000 Leute seit?
Bei 7000 Nutzern würde ich mal sagen wäre eine Meldung pro IT Abteilung an eine bestimmte
Person am Donnerstag recht sinnvoll, die dann am Freitag mit allen anderen Personen die
eine IT Abteilung vertreten eine kleine Konferenz abhalten!
- Was lief in der Vergangenheit nicht und wo gab es Probleme
- Wo stehen wir heute und was wird gerade umgesetzt
- Welchen Aufgaben stellen wir uns morgen bzw. zukünftig
- Eintragen sich verändert hat in der Einzel und Gesamtstruktur für die Dokumentation
- Rückmeldung und Mitteilung an die IT Abteilungen und kurze Erläuterung dazu.
So schafft man sich einen guten Gesamtüberblick und das ist sicherlich auch hinsichtlich
der Informationslage der GL & GF nicht abträglich.
Somit sind die Netze in der Dokumentation NICHT definiert.
Dann ist diese auch nichts richtig wert! Oder aber jede IT Abteilung hat seine eigeneDokumentation vor Ort die dann aber auch immer passen und stimmen muss, also
aktuell gehalten ist.
Ich brauche eine TECHNISCHE LÖSUNG die diesen Misstand eben bereinigen kann,
um Standorte definieren zu können.
??? Wie soll das funktionieren? Wenn Ihr bei Euch ein Labornetzwerk oder Testnetz habt,um Standorte definieren zu können.
von dem niemand etwas weiß nur eben Eure Leute vor Ort, dann kann das natürlich auch
bei den anderen Standorten so aussehen und wie möchte man diese denn nun erfassen?
Die sind mitunter völlig autark vom restlichen Netzwerk vor Ort und somit nicht zu erfassen.
So nun zu der technische Lösung, da stehen dann sicherlich mehrere
Möglichkeiten zur Verfügung die man aber mitunter auch kombinieren
kann, nur das muss dann eben auch wieder jeder selber wissen wie er
das am besten bei sich vor Ort umsetzt!
Ich nenne jetzt einmal drei unterschiedliche Methoden dazu:
Möglichkeit 1:
- PRTG mit einer Lizenz
- Eine eigene Appliance pro Standort dazu bzw. dafür
- Verbunden über einen eigenen VPN Server in der DMZ
Das würde ich mal sagen wäre der Klassiker, schnell und einfach aufzusetzen und
zu warten mit Support und einfach zu lernen.
Vorteile; Schnelle Implementierung, kann zu Clustern zusammen gefasst werden
die sich gegenseitig ersetzen und/oder ergänzen, schnelle Einfindung in das Programm,
automatische Updates des Netzwerkes in Echtzeit, es lassen sich alle Netzwerkgeräte überwachen.
Nachteile: Es kostet erst einmal Geld, und ein eigene Hardware sollte es dann auch sein.
Möglichkeit 2:
- Incinga oder Nagios auf einem eigenen Server
- Und dann eben zwei Programmierer einstellen die alles anpassen bzw.
alles von extern anpassen lassen
Ist auch ein Klassiker, nur eben auf OpenSource Basis.
Vorteile: Ausgewogene Kosten, man kann selber bestimmen was alles überwacht wird.
Kann immer wieder den persönlichen und/oder betrieblichen Bedürfnissen angepasst werden.
Nachteil: Ist der Programmierer "weg" ist eine weitere Anpassung meist schwer!
Möglichkeit 3:
- Pro Standort einmal Dokusnap, Zabbix oder Spiceworks durchlaufen lassen
und alles an eine einzige Stelle leiten wo dann die gesamten Strukturen
in einen Masterplan oder Master- bzw. Hauptdokumentation eingetragen werden.
das muss dann aber jedes Mal wieder erfolgen und man muss das dann auch wieder
gemeldet und eingetragen werden um es aktuell zu halten!
Vorteil: Geringe Kosten, Kann auch ohne Einarbeitung schnell laufen
Nachteil: Viel Handarbeit, Manpower und keine automatische Aktualisierung
Gruß
Dobby
Hi,
auf den DC werden ggf. im Systemlog folgende Events gelogt: (siehe unten)
siehe dann %SystemRoot%\debug\netlogon.log
da stehen dann Einträge wie z.B.
01/22 09:14:29 XXXXXXX: NO_CLIENT_SITE: YYYYYYY 192.168.241.2
mfg
E.
Protokollname: System
Quelle: NETLOGON
Datum: 17.06.2014 11:47:21
Ereignis-ID: 5807
Aufgabenkategorie:Keine
Ebene: Warnung
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: XXXXXXXXX
Beschreibung:
Während der letzten 4.10 Stunden gab es 43 Verbindungen zu diesem Domänen- controller von Clientcomputern, deren IP-Adressen keinem existierenden Standort in der Organisation zugeordnet werden können. Diese Clients haben demzufolge undefinierte Standorte und können sich mit jedem Domänencontroller, einschließlich solcher, die weit von den Clients entfernt sind, verbinden. Der Standort eines Clients wird bestimmt durch die Zuordnung seines Subnetzes zu einem existierenden Standort. Erstellen Sie Subnetzobjekte, die die oben angegeben IP-Adressen abdecken und die einem existierenden Standort zugeordnet sind, um die oben angegebenen Client einem der Standort zuzuordnen. Die Namen und IP-Adressen der betroffenen Clients sind auf diesem Computer in der folgenden Protokolldatei protokolliert: "%SystemRoot%\debug\netlogon.log" und möglicherweise auch in der Protokoll- datei "%SystemRoot%\debug\netlogon.bak", die erstellt wird, falls die erste Datei voll sein sollte. Die Protokoller enthalten möglicherweise zusätzliche Debuginformationen. Suchen Sie nach Zeilen, die folgenden Text enthalten: "NO_CLIENT_SITE:", um die erforderlichen Informationen herauszufiltern. Das erste Wort, das auf dieser Zeichenkette folgt, ist der Clientname und das zweite Wort ist die IP-Adresse des Clients. Die maximale Größe der Protokolle wird durch folgenden DWORD-Wert in der Registrierung festgelegt: "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\LogFileMaxSize". Der Standardwert beträgt 20000000 Bytes. Die aktuelle maximale Größe beträgt 20000000 Bytes. Erstellen Sie den obigen Registrierungswert, und legen Sie gewünschte maximale Größe in Bytes fest, um die maximale Größe zu verändern.
Ereignis-XML:
auf den DC werden ggf. im Systemlog folgende Events gelogt: (siehe unten)
siehe dann %SystemRoot%\debug\netlogon.log
da stehen dann Einträge wie z.B.
01/22 09:14:29 XXXXXXX: NO_CLIENT_SITE: YYYYYYY 192.168.241.2
mfg
E.
Protokollname: System
Quelle: NETLOGON
Datum: 17.06.2014 11:47:21
Ereignis-ID: 5807
Aufgabenkategorie:Keine
Ebene: Warnung
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: XXXXXXXXX
Beschreibung:
Während der letzten 4.10 Stunden gab es 43 Verbindungen zu diesem Domänen- controller von Clientcomputern, deren IP-Adressen keinem existierenden Standort in der Organisation zugeordnet werden können. Diese Clients haben demzufolge undefinierte Standorte und können sich mit jedem Domänencontroller, einschließlich solcher, die weit von den Clients entfernt sind, verbinden. Der Standort eines Clients wird bestimmt durch die Zuordnung seines Subnetzes zu einem existierenden Standort. Erstellen Sie Subnetzobjekte, die die oben angegeben IP-Adressen abdecken und die einem existierenden Standort zugeordnet sind, um die oben angegebenen Client einem der Standort zuzuordnen. Die Namen und IP-Adressen der betroffenen Clients sind auf diesem Computer in der folgenden Protokolldatei protokolliert: "%SystemRoot%\debug\netlogon.log" und möglicherweise auch in der Protokoll- datei "%SystemRoot%\debug\netlogon.bak", die erstellt wird, falls die erste Datei voll sein sollte. Die Protokoller enthalten möglicherweise zusätzliche Debuginformationen. Suchen Sie nach Zeilen, die folgenden Text enthalten: "NO_CLIENT_SITE:", um die erforderlichen Informationen herauszufiltern. Das erste Wort, das auf dieser Zeichenkette folgt, ist der Clientname und das zweite Wort ist die IP-Adresse des Clients. Die maximale Größe der Protokolle wird durch folgenden DWORD-Wert in der Registrierung festgelegt: "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\LogFileMaxSize". Der Standardwert beträgt 20000000 Bytes. Die aktuelle maximale Größe beträgt 20000000 Bytes. Erstellen Sie den obigen Registrierungswert, und legen Sie gewünschte maximale Größe in Bytes fest, um die maximale Größe zu verändern.
Ereignis-XML:
Danke emeriks das wir mir helfen.
Zu Dobby und Christian: Schon unfassbar.. ich werde hier bei einer technischen Frage an den Pranger gestellt für Dinge die ich nicht ´zu verantworten habe in diesem Konzern..... zu mal ihr überhaupt nicht wisst wie hier etwas läuft....was auch nicht Bestandteil der Frage war. Kommt mal runter von eurem hohen Ross...und schmeißt mal den Anker.
Zu Dobby und Christian: Schon unfassbar.. ich werde hier bei einer technischen Frage an den Pranger gestellt für Dinge die ich nicht ´zu verantworten habe in diesem Konzern..... zu mal ihr überhaupt nicht wisst wie hier etwas läuft....was auch nicht Bestandteil der Frage war. Kommt mal runter von eurem hohen Ross...und schmeißt mal den Anker.
1
