13
AD Join oder Subdomain oder ganz anders
Hallo zusammen,
ich bräuchte ein paar Denkanstöße. Zunächst mal folgendes Szenario: AD-Netzwerk auf Server 2019er Basis mit Terminalserver, Exchange On Prem und diverse Datenbank und IIS-Server in einem Rechenzentrum. 5 Standorte, die per OpenVPN Site2Site mit dem Rechenzentrum verbunden sind mit Windows Thick Clients, die lediglich per RDP auf dem Terminalserver arbeiten und nicht Mitglied der Domäne sind.
Nun will der Kunde, dass alle Clients (unterschiedlichste Modelle, Updatestand, AV-Lösung; z.T. Defender, z.T. Kapsersky, z.T. ESET) in die Domäne aufgenommen werden, der AV Schutz soll vereinheitlicht werden und via AD Join mit Gruppenrichtlinien zentral verwaltet werden können. Klingt ja erstmal nicht schlecht.
Ich sehe das allerdings aus sicherheitstechnischen Gesichtspunkten etwas schwieriger. Zum Einen erhöht das natürlich die Verwaltbarkeit und Administration, erhöht zum Anderen aber auch die Anfälligkeit der gesamten AD Struktur, da es schlicht mehr Angriffsflächen gibt.
Wie würdet ihr da vorgehen? Vom AD Join abraten und stattdessen das Management von z.B. ESET übernehmen lassen?
Ich spiele auch mit dem Gedanken einer eigenen Subdomain für die Remotestandorte, habe damit aber keine Erfahrungen. Die Idee dabei wäre, dass die Subdomain quasi nicht auf die Hauptdomain zugreifen kann und lediglich die Benutzer und Computer der Remotestandorte verwaltet, man über die Hauptdomain die Subdomain aber verwalten und managen kann. Wäre das eine valide Idee oder totaler Quatsch? Falsches Verständnis einer Windows Subdomain?
Ich freue mich über Rückmeldungen,
danke!
MfG
ich bräuchte ein paar Denkanstöße. Zunächst mal folgendes Szenario: AD-Netzwerk auf Server 2019er Basis mit Terminalserver, Exchange On Prem und diverse Datenbank und IIS-Server in einem Rechenzentrum. 5 Standorte, die per OpenVPN Site2Site mit dem Rechenzentrum verbunden sind mit Windows Thick Clients, die lediglich per RDP auf dem Terminalserver arbeiten und nicht Mitglied der Domäne sind.
Nun will der Kunde, dass alle Clients (unterschiedlichste Modelle, Updatestand, AV-Lösung; z.T. Defender, z.T. Kapsersky, z.T. ESET) in die Domäne aufgenommen werden, der AV Schutz soll vereinheitlicht werden und via AD Join mit Gruppenrichtlinien zentral verwaltet werden können. Klingt ja erstmal nicht schlecht.
Ich sehe das allerdings aus sicherheitstechnischen Gesichtspunkten etwas schwieriger. Zum Einen erhöht das natürlich die Verwaltbarkeit und Administration, erhöht zum Anderen aber auch die Anfälligkeit der gesamten AD Struktur, da es schlicht mehr Angriffsflächen gibt.
Wie würdet ihr da vorgehen? Vom AD Join abraten und stattdessen das Management von z.B. ESET übernehmen lassen?
Ich spiele auch mit dem Gedanken einer eigenen Subdomain für die Remotestandorte, habe damit aber keine Erfahrungen. Die Idee dabei wäre, dass die Subdomain quasi nicht auf die Hauptdomain zugreifen kann und lediglich die Benutzer und Computer der Remotestandorte verwaltet, man über die Hauptdomain die Subdomain aber verwalten und managen kann. Wäre das eine valide Idee oder totaler Quatsch? Falsches Verständnis einer Windows Subdomain?
Ich freue mich über Rückmeldungen,
danke!
MfG
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7685541759
Url: https://administrator.de/contentid/7685541759
Ausgedruckt am: 24.11.2024 um 13:11 Uhr
13 Kommentare
Neuester Kommentar
Hallo,
kommt drauf an wie die Bedingungen sind
wie sind die Standorte denn mit euch verbunden? Bestehen Standleitungen? welche Bandbreiten hast du zur Verfügung?. Wie groß sind die Netze in den Standorten?
Vielleicht hilft dir das folgende Microsoft Artikel
learn.microsoft.com/de-de/windows-server/remote/remote-access/ras/multisite/plan/step-2-plan-the-multisite-infrastructure
LG
kommt drauf an wie die Bedingungen sind
wie sind die Standorte denn mit euch verbunden? Bestehen Standleitungen? welche Bandbreiten hast du zur Verfügung?. Wie groß sind die Netze in den Standorten?
Vielleicht hilft dir das folgende Microsoft Artikel
learn.microsoft.com/de-de/windows-server/remote/remote-access/ras/multisite/plan/step-2-plan-the-multisite-infrastructure
LG
Zitat von @O.Gensch:
Hallo,
kommt drauf an wie die Bedingungen sind
wie sind die Standorte denn mit euch verbunden? Bestehen Standleitungen? welche Bandbreiten hast du zur Verfügung?. Wie groß sind die Netze in den Standorten?
Vielleicht hilft dir das folgende Microsoft Artikel
learn.microsoft.com/de-de/windows-server/remote/remote-access/ras/multisite/plan/step-2-plan-the-multisite-infrastructure
LG
Hallo,
kommt drauf an wie die Bedingungen sind
wie sind die Standorte denn mit euch verbunden? Bestehen Standleitungen? welche Bandbreiten hast du zur Verfügung?. Wie groß sind die Netze in den Standorten?
Vielleicht hilft dir das folgende Microsoft Artikel
learn.microsoft.com/de-de/windows-server/remote/remote-access/ras/multisite/plan/step-2-plan-the-multisite-infrastructure
LG
Hi,
mit uns sind die Standorte gar nicht verbunden. Es geht um die Remotestandorte des Kunden, die auf das Rechenzentrums-Netzwerk des Kunden zugreifen (gemieteter dedizierter Server). An den Standorten arbeiten jeweils zwischen 5 und 15 Mitarbeiter und 1-2 Drucker pro Standort, mit eigenen "normalen" asymmetrischen DSL-Anschlüssen (50k, 100k). An den Standorten gibt es jeweils eine OPNsense Firewall, die eine Client Site2Site aufbauen. Im Rechenzentrum gibt es eine virtuelle OPNsense VM, die Site2Site Server und Roard-Warrior-Server spielt und das RZ Netzwerk bereit stellt.
Ich bin mir unsicher, was ich mit dem Link für RAS anfangen soll. An den Remotestandorten gibt es keine Server-Hardware in irgendeiner Form und die VPN wird über OpenVPN realisiert.
MfG
Zitat von @support-m:
Hi,
mit uns sind die Standorte gar nicht verbunden. Es geht um die Remotestandorte des Kunden, die auf das Rechenzentrums-Netzwerk des Kunden zugreifen (gemieteter dedizierter Server). An den Standorten arbeiten jeweils zwischen 5 und 15 Mitarbeiter und 1-2 Drucker pro Standort, mit eigenen "normalen" asymmetrischen DSL-Anschlüssen (50k, 100k). An den Standorten gibt es jeweils eine OPNsense Firewall, die eine Client Site2Site aufbauen. Im Rechenzentrum gibt es eine virtuelle OPNsense VM, die Site2Site Server und Roard-Warrior-Server spielt und das RZ Netzwerk bereit stellt.
Ich bin mir unsicher, was ich mit dem Link für RAS anfangen soll. An den Remotestandorten gibt es keine Server-Hardware in irgendeiner Form und die VPN wird über OpenVPN realisiert.
MfG
Hi,
mit uns sind die Standorte gar nicht verbunden. Es geht um die Remotestandorte des Kunden, die auf das Rechenzentrums-Netzwerk des Kunden zugreifen (gemieteter dedizierter Server). An den Standorten arbeiten jeweils zwischen 5 und 15 Mitarbeiter und 1-2 Drucker pro Standort, mit eigenen "normalen" asymmetrischen DSL-Anschlüssen (50k, 100k). An den Standorten gibt es jeweils eine OPNsense Firewall, die eine Client Site2Site aufbauen. Im Rechenzentrum gibt es eine virtuelle OPNsense VM, die Site2Site Server und Roard-Warrior-Server spielt und das RZ Netzwerk bereit stellt.
Ich bin mir unsicher, was ich mit dem Link für RAS anfangen soll. An den Remotestandorten gibt es keine Server-Hardware in irgendeiner Form und die VPN wird über OpenVPN realisiert.
MfG
Hallo,
sorry dann hab ich das falsch verstanden... dann passt das auch mit dem Link nicht.......
Zitat von @support-m:
Hallo zusammen,
ich bräuchte ein paar Denkanstöße. Zunächst mal folgendes Szenario: AD-Netzwerk auf Server 2019er Basis mit Terminalserver, Exchange On Prem und diverse Datenbank und IIS-Server in einem Rechenzentrum. 5 Standorte, die per OpenVPN Site2Site mit dem Rechenzentrum verbunden sind mit Windows Thick Clients, die lediglich per RDP auf dem Terminalserver arbeiten und nicht Mitglied der Domäne sind.
Hallo zusammen,
ich bräuchte ein paar Denkanstöße. Zunächst mal folgendes Szenario: AD-Netzwerk auf Server 2019er Basis mit Terminalserver, Exchange On Prem und diverse Datenbank und IIS-Server in einem Rechenzentrum. 5 Standorte, die per OpenVPN Site2Site mit dem Rechenzentrum verbunden sind mit Windows Thick Clients, die lediglich per RDP auf dem Terminalserver arbeiten und nicht Mitglied der Domäne sind.
d.h. die werden alle zu Fuß administriert? Das macht ja schon wenig Sinn.
Nun will der Kunde, dass alle Clients (unterschiedlichste Modelle, Updatestand, AV-Lösung; z.T. Defender, z.T. Kapsersky, z.T. ESET) in die Domäne aufgenommen werden, der AV Schutz soll vereinheitlicht werden und via AD Join mit Gruppenrichtlinien zentral verwaltet werden können. Klingt ja erstmal nicht schlecht.
Macht Sinn.
Ich sehe das allerdings aus sicherheitstechnischen Gesichtspunkten etwas schwieriger. Zum Einen erhöht das natürlich die Verwaltbarkeit und Administration, erhöht zum Anderen aber auch die Anfälligkeit der gesamten AD Struktur, da es schlicht mehr Angriffsflächen gibt.
Du siehst im AD Join ein Sicherheitsproblem? Welches soll das sein? Nur weil die PCs einem AD angehören steigt doch dadurch nicht die Angriffsfläche. Die steigt eher durch fehlerhafte Konfiguration z.B. von Gruppenrichtlinien oder komischen Netzfreigaben etc., aber doch nicht durch die Zugehörigkeit zu einem AD?
Wie würdet ihr da vorgehen? Vom AD Join abraten und stattdessen das Management von z.B. ESET übernehmen lassen?
Von ESET halte ich zumindest schon mal gar nichts. 1. kann man die Software ohne Passwort nur im abgesicherten Modus deinstallieren - macht sich gut, wenn man nur remote an die Büchse kommt und 2. habe ich den Mist mal auf einem PC getestet und hinterher ließ sich Kaspersky nicht installieren.
Ich spiele auch mit dem Gedanken einer eigenen Subdomain für die Remotestandorte, habe damit aber keine Erfahrungen. Die Idee dabei wäre, dass die Subdomain quasi nicht auf die Hauptdomain zugreifen kann und lediglich die Benutzer und Computer der Remotestandorte verwaltet, man über die Hauptdomain die Subdomain aber verwalten und managen kann. Wäre das eine valide Idee oder totaler Quatsch? Falsches Verständnis einer Windows Subdomain?
Ich freue mich über Rückmeldungen,
danke!
MfG
Ich freue mich über Rückmeldungen,
danke!
MfG
Grüße
1
Hallo,
informiere Dich mal über Remote Credential Guard: https://learn.microsoft.com/de-de/windows/security/identity-protection/r ...
Momentan werden Deine RDP-Anmeldeinformationen ja über NTLM genutzt. Das ist unsicher. Innerhalb einer Domäne läuft die Anmeldung über Kerberos, im Besten Fall über die Verwendung von Remote Credential Guard. Das wäre ein Sicherheitsgewinn.
Wir verwenden ein zentral gemanagetes ESET. Funktioniert. Die Deinstallation mit Passwort wäre für einen Admin, der seine Passwörter sichert, ja kein Problem. Dafür ist es ein Sicherheitsgewinn am Client.
Gedanken sollte man sich wegen der Erreichbarkeit der DCs. Wir haben an jedem Standort einen DC. RoDCs wären auch möglich.
Grundsätzlich halte ich eine sauber und aktuell administrierte Domäne für sicherer als ein diversifiziertes System, das man irgendwann nicht mehr beherrscht.
Grüße
lcer
informiere Dich mal über Remote Credential Guard: https://learn.microsoft.com/de-de/windows/security/identity-protection/r ...
Momentan werden Deine RDP-Anmeldeinformationen ja über NTLM genutzt. Das ist unsicher. Innerhalb einer Domäne läuft die Anmeldung über Kerberos, im Besten Fall über die Verwendung von Remote Credential Guard. Das wäre ein Sicherheitsgewinn.
Wir verwenden ein zentral gemanagetes ESET. Funktioniert. Die Deinstallation mit Passwort wäre für einen Admin, der seine Passwörter sichert, ja kein Problem. Dafür ist es ein Sicherheitsgewinn am Client.
Gedanken sollte man sich wegen der Erreichbarkeit der DCs. Wir haben an jedem Standort einen DC. RoDCs wären auch möglich.
Grundsätzlich halte ich eine sauber und aktuell administrierte Domäne für sicherer als ein diversifiziertes System, das man irgendwann nicht mehr beherrscht.
Grüße
lcer
1Zitat von @lcer00:
Hallo,
Wir verwenden ein zentral gemanagetes ESET. Funktioniert. Die Deinstallation mit Passwort wäre für einen Admin, der seine Passwörter sichert, ja kein Problem. Dafür ist es ein Sicherheitsgewinn am Client.
Grüße
lcer
Hallo,
Wir verwenden ein zentral gemanagetes ESET. Funktioniert. Die Deinstallation mit Passwort wäre für einen Admin, der seine Passwörter sichert, ja kein Problem. Dafür ist es ein Sicherheitsgewinn am Client.
Grüße
lcer
Dumm nur, wenn man einen Kunden übernimmt und der alte Dienstleister es nicht kapiert, dass er da nichts mehr mit zu tun hat, kein Geld mehr bekommt und den Kram nicht deinstalliert. Wenn ich Software nicht als lokaler/Domänenadmin deinstallieren kann, ohne extra Klimmzüge wie den abgesicherten Modus zu starten, dann ist das unbrauchbar. Meine Meinung.
Hallo,
Aber ich kann Deinen Groll nachvollziehen.
Grüße
lcer
Zitat von @Xaero1982:
Dumm nur, wenn man einen Kunden übernimmt und der alte Dienstleister es nicht kapiert, dass er da nichts mehr mit zu tun hat, kein Geld mehr bekommt und den Kram nicht deinstalliert.
Na ja, aus Sicht des alten Dienstleisters ist das ja eher vorteilhaft. Dumm nur, wenn man einen Kunden übernimmt und der alte Dienstleister es nicht kapiert, dass er da nichts mehr mit zu tun hat, kein Geld mehr bekommt und den Kram nicht deinstalliert.
Aber ich kann Deinen Groll nachvollziehen.
Grüße
lcer
Da ja die Frage war wie wir vorgehen würden hier ein paar Antworten:
Also als erstes, da Ihr ja ein Dienstleister seit, versuchen das ganze auf EINHEITLICHE STANDARDS umzustellen.
Ich würde alle Clients / Server entsprechend in das vorhandene? Ad aufnehmen. Zentral im AD eingebunden heißt nicht automatisch sicherer oder unsicherer. Kommt auf die Konfiguration an.
Entsprechende Sicherheitsrichtlinien für die Clients definieren ( Interaktive / RDP Anmeldung / Lokale Anmeldung / Netzwerkanmeldung / ........ ). Einen Einheitlichen AV für ALLE Clients.
Verwaltung der Grundkonfig per GPO soweit möglich. Versuchen so viel wie möglich per GPO und Scripts bzw. Powershell machen.
Ihr müsst dem Kunden eben erklären was er davon hat.
Also als erstes, da Ihr ja ein Dienstleister seit, versuchen das ganze auf EINHEITLICHE STANDARDS umzustellen.
Ich würde alle Clients / Server entsprechend in das vorhandene? Ad aufnehmen. Zentral im AD eingebunden heißt nicht automatisch sicherer oder unsicherer. Kommt auf die Konfiguration an.
Entsprechende Sicherheitsrichtlinien für die Clients definieren ( Interaktive / RDP Anmeldung / Lokale Anmeldung / Netzwerkanmeldung / ........ ). Einen Einheitlichen AV für ALLE Clients.
Verwaltung der Grundkonfig per GPO soweit möglich. Versuchen so viel wie möglich per GPO und Scripts bzw. Powershell machen.
Ihr müsst dem Kunden eben erklären was er davon hat.
1Zitat von @lcer00:
Hallo,
Aber ich kann Deinen Groll nachvollziehen.
Grüße
lcer
Hallo,
Zitat von @Xaero1982:
Dumm nur, wenn man einen Kunden übernimmt und der alte Dienstleister es nicht kapiert, dass er da nichts mehr mit zu tun hat, kein Geld mehr bekommt und den Kram nicht deinstalliert.
Na ja, aus Sicht des alten Dienstleisters ist das ja eher vorteilhaft. Dumm nur, wenn man einen Kunden übernimmt und der alte Dienstleister es nicht kapiert, dass er da nichts mehr mit zu tun hat, kein Geld mehr bekommt und den Kram nicht deinstalliert.
Aber ich kann Deinen Groll nachvollziehen.
Grüße
lcer
Nö, er sieht ja kein Geld mehr, aber das rafft er irgendwie nicht
Moin,
Ich würde ebenfalls alles vereinheitlichen. Dazu am besten mal jeden Standort erstmal ho sichtlich Hard- und Software inventarisieren.
Weiß „ich“, was alles wo installiert ist und habe ich alle Lizenzschlüssel gesichert, würde ich die Clients Neu, mit einem Standard-Image aufsetzen und dann in die AD-Infrastruktur aufnehmen.
Im Vorfeld sind natürlich alle GPOs erstellt und den richtigen OUs zugeordnet worden.
Ja, macht Arbeit, die eurer Kunde zu Beginn investieren muss, aber hintenraus lohnt sich das: alles einheitlich, und deutlich pflegeleichter.
Alternativ/ Zusätzlich:
Alles auf eine ZeroTrust-Policy ausrichten. Denn dann ist es (fast) egal, ob da ein verseuchter Client anklopft oder nicht. Das kann/ wird aber mit Sicherheit deutlich teurer werden.
Ich würde ebenfalls alles vereinheitlichen. Dazu am besten mal jeden Standort erstmal ho sichtlich Hard- und Software inventarisieren.
Weiß „ich“, was alles wo installiert ist und habe ich alle Lizenzschlüssel gesichert, würde ich die Clients Neu, mit einem Standard-Image aufsetzen und dann in die AD-Infrastruktur aufnehmen.
Im Vorfeld sind natürlich alle GPOs erstellt und den richtigen OUs zugeordnet worden.
Ja, macht Arbeit, die eurer Kunde zu Beginn investieren muss, aber hintenraus lohnt sich das: alles einheitlich, und deutlich pflegeleichter.
Alternativ/ Zusätzlich:
Alles auf eine ZeroTrust-Policy ausrichten. Denn dann ist es (fast) egal, ob da ein verseuchter Client anklopft oder nicht. Das kann/ wird aber mit Sicherheit deutlich teurer werden.
1
Ich spiele auch mit dem Gedanken einer eigenen Subdomain für die Remotestandorte, habe damit aber keine Erfahrungen. Die Idee dabei wäre, dass die Subdomain quasi nicht auf die Hauptdomain zugreifen kann und lediglich die Benutzer und Computer der Remotestandorte verwaltet, man über die Hauptdomain die Subdomain aber verwalten und managen kann. Wäre das eine valide Idee oder totaler Quatsch? Falsches Verständnis einer Windows Subdomain?
Also habe ich das richtig verstanden dass die Standorte von der Unternehmensstruktur zu euch gehören? Oder handelt es sich um eine "Bereitstellung"-Dienstleistung?
Variante 1 - Wenn euch die Standorte gehören, dann würde ich eine Subdomain vorziehen, dann splittest hart in der Verwaltung. Das macht aber nur Sinn, wenn die Subdomain auf keine Ressourcen der Maindomain zugreift.
Variante 2 - Dienstleistung! Dann nix mit in die Domain oder sonstiges. Dann würde ich die Administration und Verwaltung vollständig dediziert am Standort X aufbauen. Sind wir ehrlich, ein kleiner Domain-Controller ist jetzt auch nicht die Welt.
Du siehst im AD Join ein Sicherheitsproblem? Welches soll das sein? Nur weil die PCs einem AD angehören steigt doch dadurch nicht die Angriffsfläche. Die steigt eher durch fehlerhafte Konfiguration z.B. von Gruppenrichtlinien oder komischen Netzfreigaben etc., aber doch nicht durch die Zugehörigkeit zu einem AD?
Allein der Zugriff auf den TS ist ja schon "offen" und geht über die VPN. Also ist ein gewisser Zugriff in deine Maindomain ja bereits vorhanden. Aber das muss ja sein, sonst klappt es nicht.
Grüße
1
Hallo zusammen,
erstmal danke für eure zahlreichen Antworten.
Bisher ja. Aber im Grunde beschränkt auf Automatische Windows Updates und AV Signaturen, also es steht alles auf automatisch aktualiseren und werden ehrlich gesagt ansonsten vernachlässigt...
Ein DC an jedem Standort wird vermutlich nicht umsetzbar sein. Macht AD Join der Clients dann überhaupt Sinn?
Danke!
erstmal danke für eure zahlreichen Antworten.
Bisher ja. Aber im Grunde beschränkt auf Automatische Windows Updates und AV Signaturen, also es steht alles auf automatisch aktualiseren und werden ehrlich gesagt ansonsten vernachlässigt...
Zitat von @Xaero1982:
Du siehst im AD Join ein Sicherheitsproblem? Welches soll das sein? Nur weil die PCs einem AD angehören steigt doch dadurch nicht die Angriffsfläche. Die steigt eher durch fehlerhafte Konfiguration z.B. von Gruppenrichtlinien oder komischen Netzfreigaben etc., aber doch nicht durch die Zugehörigkeit zu einem AD?
Ich denke da z.B. an Exchange Server, die genutzt werden können um faktisch die komplette Domäne zu übernehmen. Und ich dachte, dass "Gast" Computer weniger Angriffsfläche als "AD gejointe Computer" bieten? Oder ist eher der Gegenteil der Fall?Du siehst im AD Join ein Sicherheitsproblem? Welches soll das sein? Nur weil die PCs einem AD angehören steigt doch dadurch nicht die Angriffsfläche. Die steigt eher durch fehlerhafte Konfiguration z.B. von Gruppenrichtlinien oder komischen Netzfreigaben etc., aber doch nicht durch die Zugehörigkeit zu einem AD?
Zitat von @lcer00:
informiere Dich mal über Remote Credential Guard: https://learn.microsoft.com/de-de/windows/security/identity-protection/r ...
Danke für den Tipp, klingt sinnvoll!informiere Dich mal über Remote Credential Guard: https://learn.microsoft.com/de-de/windows/security/identity-protection/r ...
Zitat von @lcer00:
Wir verwenden ein zentral gemanagetes ESET. Funktioniert. Die Deinstallation mit Passwort wäre für einen Admin, der seine Passwörter sichert, ja kein Problem. Dafür ist es ein Sicherheitsgewinn am Client.
Gedanken sollte man sich wegen der Erreichbarkeit der DCs. Wir haben an jedem Standort einen DC. RoDCs wären auch möglich.
Wir nutzen ebenfalls vorwiegend ESET Cloud Management, nützlich ist da auch die Windows Update Verwaltung für Homeoffice-Computer usw.Wir verwenden ein zentral gemanagetes ESET. Funktioniert. Die Deinstallation mit Passwort wäre für einen Admin, der seine Passwörter sichert, ja kein Problem. Dafür ist es ein Sicherheitsgewinn am Client.
Gedanken sollte man sich wegen der Erreichbarkeit der DCs. Wir haben an jedem Standort einen DC. RoDCs wären auch möglich.
Ein DC an jedem Standort wird vermutlich nicht umsetzbar sein. Macht AD Join der Clients dann überhaupt Sinn?
Zitat von @Mr-Gustav:
Ich würde alle Clients / Server entsprechend in das vorhandene? Ad aufnehmen. Zentral im AD eingebunden heißt nicht automatisch sicherer oder unsicherer. Kommt auf die Konfiguration an.
Entsprechende Sicherheitsrichtlinien für die Clients definieren ( Interaktive / RDP Anmeldung / Lokale Anmeldung / Netzwerkanmeldung / ........ ). Einen Einheitlichen AV für ALLE Clients.
Verwaltung der Grundkonfig per GPO soweit möglich. Versuchen so viel wie möglich per GPO und Scripts bzw. Powershell machen.
Danke für die Tips. Ok also auch +1 für eine einheitliche Domäne.Ich würde alle Clients / Server entsprechend in das vorhandene? Ad aufnehmen. Zentral im AD eingebunden heißt nicht automatisch sicherer oder unsicherer. Kommt auf die Konfiguration an.
Entsprechende Sicherheitsrichtlinien für die Clients definieren ( Interaktive / RDP Anmeldung / Lokale Anmeldung / Netzwerkanmeldung / ........ ). Einen Einheitlichen AV für ALLE Clients.
Verwaltung der Grundkonfig per GPO soweit möglich. Versuchen so viel wie möglich per GPO und Scripts bzw. Powershell machen.
Zitat von @em-pie:
Ich würde ebenfalls alles vereinheitlichen. Dazu am besten mal jeden Standort erstmal ho sichtlich Hard- und Software inventarisieren.
Weiß „ich“, was alles wo installiert ist und habe ich alle Lizenzschlüssel gesichert, würde ich die Clients Neu, mit einem Standard-Image aufsetzen und dann in die AD-Infrastruktur aufnehmen.
Im Vorfeld sind natürlich alle GPOs erstellt und den richtigen OUs zugeordnet worden.
Ja, macht Arbeit, die eurer Kunde zu Beginn investieren muss, aber hintenraus lohnt sich das: alles einheitlich, und deutlich pflegeleichter.
Verstehe, also auch +1 für eine einheitliche Domäne und +1 für Systeme standardisieren, danke.Ich würde ebenfalls alles vereinheitlichen. Dazu am besten mal jeden Standort erstmal ho sichtlich Hard- und Software inventarisieren.
Weiß „ich“, was alles wo installiert ist und habe ich alle Lizenzschlüssel gesichert, würde ich die Clients Neu, mit einem Standard-Image aufsetzen und dann in die AD-Infrastruktur aufnehmen.
Im Vorfeld sind natürlich alle GPOs erstellt und den richtigen OUs zugeordnet worden.
Ja, macht Arbeit, die eurer Kunde zu Beginn investieren muss, aber hintenraus lohnt sich das: alles einheitlich, und deutlich pflegeleichter.
Zitat von @simple198:
Also habe ich das richtig verstanden dass die Standorte von der Unternehmensstruktur zu euch gehören? Oder handelt es sich um eine "Bereitstellung"-Dienstleistung?
Ich verstehe nicht, warum das so unklar ist :D Mit unserer eigenen Domäne hat da nix zu tun. Es ist alles kundenspzifisch. Rechenzentrum wurde im Auftrag des Kunden bestellt und im Rechenzentrum eine neue Domäne mit Terminalserver aufgezogen.Also habe ich das richtig verstanden dass die Standorte von der Unternehmensstruktur zu euch gehören? Oder handelt es sich um eine "Bereitstellung"-Dienstleistung?
Zitat von @simple198:
Variante 2 - Dienstleistung! Dann nix mit in die Domain oder sonstiges. Dann würde ich die Administration und Verwaltung vollständig dediziert am Standort X aufbauen. Sind wir ehrlich, ein kleiner Domain-Controller ist jetzt auch nicht die Welt.
Das trifft es schon eher. Mein Gedanke war nur, für die Clients und Benutzer an den Remotestandorten standortübergreifend eine "extra" Subdomäne an zu legen. Also die Hauptdomäne des Kunden lautet z.B. ad.kundendomain.de (im Rechenzentrum). Und meine Idee oder Überlegung war jetzt einfach nur, eine zusäztliche Domäne standorte.ad.kundendomain.de anzulegen, in die ich alle User und Computer der Standorte packe und mit entsprechenden Gruppenrichtlinien und OUs versorge. Aber mehrheitlich wird ja eher davon abgeraten. Auch eigene weiterführende Recherchen diesbezüglich lassen mich eher dazu tendieren, keine Subdomain zu erstellen, sondern die Hierachie flach zu lassen.Variante 2 - Dienstleistung! Dann nix mit in die Domain oder sonstiges. Dann würde ich die Administration und Verwaltung vollständig dediziert am Standort X aufbauen. Sind wir ehrlich, ein kleiner Domain-Controller ist jetzt auch nicht die Welt.
Danke!
Ich verstehe nicht, warum das so unklar ist :D Mit unserer eigenen Domäne hat da nix zu tun. Es ist alles kundenspzifisch. Rechenzentrum wurde im Auftrag des Kunden bestellt und im Rechenzentrum eine neue Domäne mit Terminalserver aufgezogen.
Sorry! 🤠
Dreh den Gedanken doch mal um: Das Rechenzentrum würde bei denen im Büro stehen. Dann würdest du als Dienstleister ja auch nicht her gehen und die Rechner aus dem Einkauf in eine Subdomain stecken namens einkauf.ad.firma.de, oder? 😲
Aber mehrheitlich wird ja eher davon abgeraten. Auch eigene weiterführende Recherchen diesbezüglich lassen mich eher dazu tendieren, keine Subdomain zu erstellen, sondern die Hierachie flach zu lassen.
... und Punkt! 🙃
1
