38
Replizieren von Active Directory Benutzer und Gruppen auf anderen AD Server
Hallo zusammen,
ich plane für den Notfall eine extern gehostete IT-Infrastruktur mit wenigen Basisdiensten, u. a. Active Directory. Im Notfall verbinden sich die Benutzer mit der Notfallumgebung und arbeiten dort weiter.
Wie kann ich die Benutzer und Gruppen aus dem produktiven AD in das Notfall AD replizieren? Im Normalfall sind Produktiv- und Notfallumgebung per VPN verbunden. Im Notfall muss ich auf das AD in der Notfallumgebung auch schreiben können, also Benutzer und Gruppen bearbeiten etc. Read Only DC fällt somit weg, oder?
Danke und viele Grüße,
tonabnehmer
ich plane für den Notfall eine extern gehostete IT-Infrastruktur mit wenigen Basisdiensten, u. a. Active Directory. Im Notfall verbinden sich die Benutzer mit der Notfallumgebung und arbeiten dort weiter.
Wie kann ich die Benutzer und Gruppen aus dem produktiven AD in das Notfall AD replizieren? Im Normalfall sind Produktiv- und Notfallumgebung per VPN verbunden. Im Notfall muss ich auf das AD in der Notfallumgebung auch schreiben können, also Benutzer und Gruppen bearbeiten etc. Read Only DC fällt somit weg, oder?
Danke und viele Grüße,
tonabnehmer
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: 193428
Url: https://administrator.de/contentid/193428
Ausgedruckt am: 21.11.2024 um 23:11 Uhr
38 Kommentare
Neuester Kommentar
Moin tonabnehmer,
vor was willst du dich bzw. dein AD schützen? Hardwareausfall? Defekte AD-Datenbank?
Grüße,
Dani
vor was willst du dich bzw. dein AD schützen? Hardwareausfall? Defekte AD-Datenbank?
Grüße,
Dani
Hi Dani,
ich will eine Notfallumgebung schaffen, in der unsere Entwickler bei Totalausfall unserer IT-Infrastruktur durch Brand, Wasser, Diebstahl etc. weiterarbeiten können. Dort sollen sie sich mit ihren normalen Benutzerdaten anmelden und über die Gruppenzugehörigkeit die Rechte auf Files, Repositories etc. bekommen. Die Benutzer und Gruppen möchte ich im Notfall nicht erst händisch anlegen und dachte man könnte diese auch täglich replizieren.
Danke und Grüße,
tonabnehmer
ich will eine Notfallumgebung schaffen, in der unsere Entwickler bei Totalausfall unserer IT-Infrastruktur durch Brand, Wasser, Diebstahl etc. weiterarbeiten können. Dort sollen sie sich mit ihren normalen Benutzerdaten anmelden und über die Gruppenzugehörigkeit die Rechte auf Files, Repositories etc. bekommen. Die Benutzer und Gruppen möchte ich im Notfall nicht erst händisch anlegen und dachte man könnte diese auch täglich replizieren.
Danke und Grüße,
tonabnehmer
Hallo,
an Sich können sich deine Entwickler an den PC's ja anmelden wenn mal der DC nicht da ist.
an Sich können sich deine Entwickler an den PC's ja anmelden wenn mal der DC nicht da ist.
Hallo wiesi200
nein, können sie nicht, da im Notfallszenario auch die Arbeitsplätze nicht mehr zur Verfügung stehen und im nächst gelegenen Elektronikmarkt neu gekauft bzw. private Home Office Rechner benutzt werden. Zudem erfordert die VPN Verbindung zur Notfallumgebung eine Anmeldung am dortigen AD.
Grüße,
tonabnehmer
nein, können sie nicht, da im Notfallszenario auch die Arbeitsplätze nicht mehr zur Verfügung stehen und im nächst gelegenen Elektronikmarkt neu gekauft bzw. private Home Office Rechner benutzt werden. Zudem erfordert die VPN Verbindung zur Notfallumgebung eine Anmeldung am dortigen AD.
Grüße,
tonabnehmer
Moin,
also grundsätzlich baut man eine Site-to-Site VPN-Verbindung mit zwei Router und nicht mit dem Windows Server. DAmit bist du AD - und Server unabhängig.
Den 2. DC kannst du einfach in die Domäne als weiteren DC aufnehmen. Heutzutage wird dieser DNS-Server und Global Catalog. Somit brauchst du nur noch die FSMO-Rollen umziehen.
Grüße,
Dani
also grundsätzlich baut man eine Site-to-Site VPN-Verbindung mit zwei Router und nicht mit dem Windows Server. DAmit bist du AD - und Server unabhängig.
Den 2. DC kannst du einfach in die Domäne als weiteren DC aufnehmen. Heutzutage wird dieser DNS-Server und Global Catalog. Somit brauchst du nur noch die FSMO-Rollen umziehen.
Grüße,
Dani
Hi Dani,
Site-to-Site VPN werden wir mit OpenVPN realisieren. Allerdings wird die Firewall nur die Richtung Produktiv nach Notfall erlauben, da Notfall public Cloud basiert sein wird. Ich würde auch lieber eine separate AD Domain in der Notfallumgebung haben wollen und dann nur die Benutzer und Gruppen von Domain produktiv.local nach Domain notfall.local replizieren. Geht das?
Danke und Grüße,
tonabnehmer
Site-to-Site VPN werden wir mit OpenVPN realisieren. Allerdings wird die Firewall nur die Richtung Produktiv nach Notfall erlauben, da Notfall public Cloud basiert sein wird. Ich würde auch lieber eine separate AD Domain in der Notfallumgebung haben wollen und dann nur die Benutzer und Gruppen von Domain produktiv.local nach Domain notfall.local replizieren. Geht das?
Danke und Grüße,
tonabnehmer
Hallo.
Du gehst von falschen Voraussetzungen aus. Du kannst nicht einfach ein AD von produktiv.local nach notfall.local replizieren.
Wenn, dann ist das ein AD bei dem ein 2. DC eben an einem anderen Standort steht. Verabschiede dich also von deiner Idee, das wird nie klappen.
Und wenn du das sinnvoll zu Ende denkst, dann ist es ja nicht damit getan das das AD zur Verfügung steht, es fehlen ja auch noch die Daten mit den gearbeitet werden soll.
Ich würde an deiner Stelle anders an die Aufgabe herangehen. Wie lange dauert es im Disaster Fall aus den Backups wieder ein funktionierenden System herzustellen. Welche Daten gehen aufgrund der derzeitigen Backupstrategie verloren. Was kostet es dem Unternehmen bis das System wieder lauffähig ist.
Mit diesen Daten hast du dann einen Kostenfaktor, mit dem du planen kannst.
LG Günther
Du gehst von falschen Voraussetzungen aus. Du kannst nicht einfach ein AD von produktiv.local nach notfall.local replizieren.
Wenn, dann ist das ein AD bei dem ein 2. DC eben an einem anderen Standort steht. Verabschiede dich also von deiner Idee, das wird nie klappen.
Und wenn du das sinnvoll zu Ende denkst, dann ist es ja nicht damit getan das das AD zur Verfügung steht, es fehlen ja auch noch die Daten mit den gearbeitet werden soll.
Ich würde an deiner Stelle anders an die Aufgabe herangehen. Wie lange dauert es im Disaster Fall aus den Backups wieder ein funktionierenden System herzustellen. Welche Daten gehen aufgrund der derzeitigen Backupstrategie verloren. Was kostet es dem Unternehmen bis das System wieder lauffähig ist.
Mit diesen Daten hast du dann einen Kostenfaktor, mit dem du planen kannst.
LG Günther
Hallo Günther,
das Replizieren der Daten in die Notfallumgebung ist weniger das Problem. Das geht über Skripte mit rsync und robocopy ganz gut und ist für uns ausreichend. Für das Desaster Recovery haben wir außerhalb der Firma gelagerte Bänder. Im Notfall muss aber neue Hardware beschafft, Virtualisierungs- und Backup-Infrastruktur eingerichtet und dann die virtuellen Maschinen und ggf. Bewegungsdaten wiederhergestellt werden. Wir sind Small Business und können das nicht vorhalten. Das kann schon 1-2 Wochen oder länger dauern. In der Zeit wird in der Notfallumgebung gearbeitet - zumindest die Projekte, bei denen wir SLAs mit unseren Kunden einhalten müssen. Der Rest steht halt still.
Zurück zum AD:
Dani und Du Ihr meint also es geht nur wenn ich die Domain produktiv.local auf den entfernten Standord ausweite und dort einen zweiten DC aufsetze? Die Dienste in der Notfallumgebung (VPN, Wiki, Chat, SVN, Tomcats) würde ich dann so einrichten, dass diese gegen den dortigen DC authentifizieren? Fällt dann die Produktivumgebung aus, tut der zweite DC in der Notfallumgebung ganz normal seinen Dienst und ich kann dort auch Gruppen und Benutzer bearbeiten?
Danke und Grüße,
tonabnehmer
das Replizieren der Daten in die Notfallumgebung ist weniger das Problem. Das geht über Skripte mit rsync und robocopy ganz gut und ist für uns ausreichend. Für das Desaster Recovery haben wir außerhalb der Firma gelagerte Bänder. Im Notfall muss aber neue Hardware beschafft, Virtualisierungs- und Backup-Infrastruktur eingerichtet und dann die virtuellen Maschinen und ggf. Bewegungsdaten wiederhergestellt werden. Wir sind Small Business und können das nicht vorhalten. Das kann schon 1-2 Wochen oder länger dauern. In der Zeit wird in der Notfallumgebung gearbeitet - zumindest die Projekte, bei denen wir SLAs mit unseren Kunden einhalten müssen. Der Rest steht halt still.
Zurück zum AD:
Dani und Du Ihr meint also es geht nur wenn ich die Domain produktiv.local auf den entfernten Standord ausweite und dort einen zweiten DC aufsetze? Die Dienste in der Notfallumgebung (VPN, Wiki, Chat, SVN, Tomcats) würde ich dann so einrichten, dass diese gegen den dortigen DC authentifizieren? Fällt dann die Produktivumgebung aus, tut der zweite DC in der Notfallumgebung ganz normal seinen Dienst und ich kann dort auch Gruppen und Benutzer bearbeiten?
Danke und Grüße,
tonabnehmer
Zitat von @tonabnehmer:
Zurück zum AD:
Dani und Du Ihr meint also es geht nur wenn ich die Domain produktiv.local auf den entfernten Standord ausweite und dort einen
zweiten DC aufsetze? Die Dienste in der Notfallumgebung (VPN, Wiki, Chat, SVN, Tomcats) würde ich dann so einrichten, dass
diese gegen den dortigen DC authentifizieren? Fällt dann die Produktivumgebung aus, tut der zweite DC in der Notfallumgebung
ganz normal seinen Dienst und ich kann dort auch Gruppen und Benutzer bearbeiten?
Zurück zum AD:
Dani und Du Ihr meint also es geht nur wenn ich die Domain produktiv.local auf den entfernten Standord ausweite und dort einen
zweiten DC aufsetze? Die Dienste in der Notfallumgebung (VPN, Wiki, Chat, SVN, Tomcats) würde ich dann so einrichten, dass
diese gegen den dortigen DC authentifizieren? Fällt dann die Produktivumgebung aus, tut der zweite DC in der Notfallumgebung
ganz normal seinen Dienst und ich kann dort auch Gruppen und Benutzer bearbeiten?
wenn du das ganze in eine andere Domain replizieren würdest, abgesehen davon das es nicht geht, haettest du ja dann andere Benutzer und somit berechtigungsprobleme.
Du kannst auf dem Reserve DC ohne Probleme AD Inhalte bearbeiten. Wobei es auch Read only DC's geben würde fall's du das bevorzugst.
Ach weil du von Small Buissines redest. Du kannst so keine 2 SBS Server koppeln. Das Mögen die nicht.
Moin,
ich hab mir mal den ganzen Thread kopfschüttelnd durchgelesen - was haste nun?
SBS? - dann kannste nen weiteren DC wie auch ne Vertrauenstellung vergessen.
richtiges AD - setz nen 2. DC auf und gut ist, die Rechte werden repliziert, die Daten hast Du hoffentlich im Backup, auch wieder jutt iss
Gruß
24
ich hab mir mal den ganzen Thread kopfschüttelnd durchgelesen - was haste nun?
SBS? - dann kannste nen weiteren DC wie auch ne Vertrauenstellung vergessen.
richtiges AD - setz nen 2. DC auf und gut ist, die Rechte werden repliziert, die Daten hast Du hoffentlich im Backup, auch wieder jutt iss
Gruß
24
Hi.
Das geht schon. Nur muss auch der externe DC zur Domäne produktiv.local gehören.
LG Günther
Dani und Du Ihr meint also es geht nur wenn ich die Domain produktiv.local auf den entfernten Standord ausweite und dort einen zweiten DC aufsetze?
Das geht schon. Nur muss auch der externe DC zur Domäne produktiv.local gehören.
LG Günther
Hi,
unser AD läuft unter SBS 2008. Heißt das jetzt ich kann keinen 2. DC am entfernten Standort aufsetzen (Windows Server 2008 R2 mit AD Rolle)?
Danke und Grüße,
tonabnehmer
unser AD läuft unter SBS 2008. Heißt das jetzt ich kann keinen 2. DC am entfernten Standort aufsetzen (Windows Server 2008 R2 mit AD Rolle)?
Danke und Grüße,
tonabnehmer
unser AD läuft unter SBS 2008. Heißt das jetzt ich kann keinen 2. DC am entfernten Standort aufsetzen (Windows Server 2008 R2 mit AD Rolle)?
Das geht problemlos. Wenn es nochmal ein SBS gewesen wäre, hättest du ein Problem.Grüße,
Dani
Zitat von @Dani:
> unser AD läuft unter SBS 2008. Heißt das jetzt ich kann keinen 2. DC am entfernten Standort aufsetzen (Windows
Server 2008 R2 mit AD Rolle)?
Das geht problemlos. Wenn es nochmal ein SBS gewesen wäre, hättest du ein Problem.
> unser AD läuft unter SBS 2008. Heißt das jetzt ich kann keinen 2. DC am entfernten Standort aufsetzen (Windows
Server 2008 R2 mit AD Rolle)?
Das geht problemlos. Wenn es nochmal ein SBS gewesen wäre, hättest du ein Problem.
Da bin ich ja beruhigt
In dem Zusammenhang noch eine Frage bzgl. DMZ. Aktuell haben wir den SBS 2008 als DC für domain.local. In der DMZ haben wir einen Windows Server 2003 mit AD Rolle als DC für die Domain dmz.local. Macht es Sinn die Domain dmz.local abzuschaffen und statt dessen die Domain domain.local auf die Rechner in der DMZ auszudehnen? Dann könnte in der DMZ entweder ein zweiter DC stehen oder die Firewall für alle Rechner in der DMZ hin zum DC im internen Netz geöffnet werden. Internes Netz und DMZ sind physisch gleich, logisch per VLAN und Firewall getrennt. Wie realisiert man Domain und AD in der DMZ heutzutage am besten in Small Business Netzen?
Danke und Grüße,
tonabnehmer
Hallo.
Welche Aufgaben hat dieser Rechner (DC)
LG Günther
In der DMZ haben wir einen Windows Server 2003 mit AD Rolle als DC für die Domain dmz.local
Welche Aufgaben hat dieser Rechner (DC)
LG Günther
Hi Günther,
der Rechner dient nur als DC, also AD Computerkonten für die Rechner in der DMZ, AD Benutzerkonten und Gruppen für den Zugriff auf die Rechner in der DMZ und DNS für die DMZ. Ich finde es sehr ungünstig, da unsere Mitarbeiter somit einen AD Account im internen und einen in der DMZ haben (habe mein Passwort vergessen, bitte zurücksetzen). Das wurde vor meiner Zeit eingerichtet.
Viele Grüße,
tonabnehmer
der Rechner dient nur als DC, also AD Computerkonten für die Rechner in der DMZ, AD Benutzerkonten und Gruppen für den Zugriff auf die Rechner in der DMZ und DNS für die DMZ. Ich finde es sehr ungünstig, da unsere Mitarbeiter somit einen AD Account im internen und einen in der DMZ haben (habe mein Passwort vergessen, bitte zurücksetzen). Das wurde vor meiner Zeit eingerichtet.
Viele Grüße,
tonabnehmer
Den DC in der DMZ wuerd ich schnell rausschmeißen.
Hi.
Wie wiesi200 schon schrieb, weg damit. Anscheinend muss da bei euch das komplette Konzept überarbeitet werden.
LG Günther
Ich finde es sehr ungünstig, da unsere Mitarbeiter somit einen AD Account im internen und einen in der DMZ haben
Wie wiesi200 schon schrieb, weg damit. Anscheinend muss da bei euch das komplette Konzept überarbeitet werden.
LG Günther
Hi,
d.h. wir sollten künftig nur noch eine AD Domain betreiben und diese über das interne Netz, die DMZ und den entfernten Standort mit der Notfallumgebung "aufspannen". Korrekt?
In der Notfallumgebung würde in jedem Fall ein zweiter writable DC stehen, damit ich dort im Desaster Fall auch Benutzer und Gruppen bearbeiten kann bzw. neue Rechner aufsetzen und in die Domäne hiefen. Mit einem read only DC geht das nicht. Richtig?
Was mache ich mit der DMZ? Gebe ich a) in der Firewall den Zugriff aus der DMZ auf den DC im internen Netz frei oder stelle ich b) einen writable DC in die DMZ und gebe in der Firewall nur diesem den Zugriff auf dem Master DC im internen Netz oder stelle ich b) einen read only DC in die DMZ? Ich möchte das möglichst einfach halten und nur so komplex gestalten, wie es die IT-Sicherheit erfordert.
Danke und viele Grüße,
tonabnehmer
d.h. wir sollten künftig nur noch eine AD Domain betreiben und diese über das interne Netz, die DMZ und den entfernten Standort mit der Notfallumgebung "aufspannen". Korrekt?
In der Notfallumgebung würde in jedem Fall ein zweiter writable DC stehen, damit ich dort im Desaster Fall auch Benutzer und Gruppen bearbeiten kann bzw. neue Rechner aufsetzen und in die Domäne hiefen. Mit einem read only DC geht das nicht. Richtig?
Was mache ich mit der DMZ? Gebe ich a) in der Firewall den Zugriff aus der DMZ auf den DC im internen Netz frei oder stelle ich b) einen writable DC in die DMZ und gebe in der Firewall nur diesem den Zugriff auf dem Master DC im internen Netz oder stelle ich b) einen read only DC in die DMZ? Ich möchte das möglichst einfach halten und nur so komplex gestalten, wie es die IT-Sicherheit erfordert.
Danke und viele Grüße,
tonabnehmer
Warum brauchst du ueberhaupt in der DMZ einen DC?
Zentrale Benutzer- und Gruppenverwaltung, Password-Policies, GPOs.
Ja toll, mir ist schon klar was man mit einem AD macht. Aber was soll das Ding in einer DMZ?
Da hat es doch überhaupt nichts zu suchen da der Server ja angreifbar ist.
Sicherheitstechnisch ein Problem.
Genau daher hatte ich weiter oben danach gefragt, wie ich externe Notfallumgebung und die DMZ ins AD integriere
In der Notfallumgebung würde in jedem Fall ein zweiter writable DC stehen, damit ich dort im Desaster Fall auch Benutzer und
Gruppen bearbeiten kann bzw. neue Rechner aufsetzen und in die Domäne hiefen. Mit einem read only DC geht das nicht.
Richtig?
Was mache ich mit der DMZ? Gebe ich a) in der Firewall den Zugriff aus der DMZ auf den DC im internen Netz frei oder stelle ich b)
einen writable DC in die DMZ und gebe in der Firewall nur diesem den Zugriff auf dem Master DC im internen Netz oder stelle ich b)
einen read only DC in die DMZ? Ich möchte das möglichst einfach halten und nur so komplex gestalten, wie es die
IT-Sicherheit erfordert.
Gruppen bearbeiten kann bzw. neue Rechner aufsetzen und in die Domäne hiefen. Mit einem read only DC geht das nicht.
Richtig?
Was mache ich mit der DMZ? Gebe ich a) in der Firewall den Zugriff aus der DMZ auf den DC im internen Netz frei oder stelle ich b)
einen writable DC in die DMZ und gebe in der Firewall nur diesem den Zugriff auf dem Master DC im internen Netz oder stelle ich b)
einen read only DC in die DMZ? Ich möchte das möglichst einfach halten und nur so komplex gestalten, wie es die
IT-Sicherheit erfordert.
Ok, wenn du nicht's sagen willst, wir wird's zu blöd zum fragen.
Ich klink mich aus.
Meiner Meinung ein DC hat überhaupt nichts in einer DMZ zu suchen. Somit weder read only noch einen normalen.
Ich klink mich aus.
Meiner Meinung ein DC hat überhaupt nichts in einer DMZ zu suchen. Somit weder read only noch einen normalen.
Hi.
So kommen wir nicht weiter. Beantworte bitte die Frage: "Welche Dienste stellt der DC in der DMZ zur Verfügung"
LG Günther
So kommen wir nicht weiter. Beantworte bitte die Frage: "Welche Dienste stellt der DC in der DMZ zur Verfügung"
LG Günther
Hallo zusammen,
ich bin grad etwas verwirrt und dachte die Frage hätte ich beantwortet. Also der DC in der DMZ stellt das Active Directory und DNS für die Rechner in der DMZ zur Verfügung.
Viele Grüße,
tonabnehmer
ich bin grad etwas verwirrt und dachte die Frage hätte ich beantwortet. Also der DC in der DMZ stellt das Active Directory und DNS für die Rechner in der DMZ zur Verfügung.
Viele Grüße,
tonabnehmer
Also der DC in der DMZ stellt das Active Directory und DNS für die Rechner in der DMZ zur Verfügung.
Was sind das für Rechner? In der DMZ werden doch nur Dienste wie FTP, Proxy, Webdienste zur Verfügung gestellt. Und diese sind eigentlich so zu konfigurieren, dass kein Zugriff auf ein AD notwendig ist.
Was sind das also für Rechner, die da herumschwirren?
LG Günther
In der DMZ befinden sich jede Menge Rechner, auf denen die von uns entwickelten Anwendungen unseren Kunden als Demo oder Prototypen zur Verfügung gestellt wird. Die Anwendungen werden von den Entwicklungsteams eigenständig auf diesen Rechnern deployed, ich richte lediglich in Forefront TMG die Veröffentlichungen ein. Die Entwickler haben mit ihren Accounts im DMZ AD dann auf den jeweiligen Rechnern lokale Admin Rechte um dort Tomcats und Datenbanken selbst zu verwalten.
Viele Grüße,
tonabnehmer
Viele Grüße,
tonabnehmer
Hi.
Ok, dann ist aber der Begriff DMZ falsch bzw. unglücklich gewählt. Die Frage stellt sich jetzt, muss dafür ein AD vorhanden sein, bzw. wie greifen die Kunden auf diese Rechner zu?
LG Günther
In der DMZ befinden sich jede Menge Rechner
Ok, dann ist aber der Begriff DMZ falsch bzw. unglücklich gewählt. Die Frage stellt sich jetzt, muss dafür ein AD vorhanden sein, bzw. wie greifen die Kunden auf diese Rechner zu?
LG Günther
Hi Günther,
DMZ ist schon richtig. Das sind alles Webanwendungen, die dort laufen. Die Kunden greifen via Browser über https://www.domain.de/application zu und /application läuft dann auf einem der Rechner in der DMZ.
AD benötigen wir für die GPOs, die auch für die Rechner in der DMZ gelten sollen, sowie für die Benutzerkonten der Entwickler, die auf den Rechnern ihren Kram installieren sollen.
Die Frage ist aus meiner Sicht eher: Brauchen wir in der DMZ eine separate AD Domain oder können wir nicht die interne AD Domain mitnutzen?
Viele Grüße,
tonabnehmer
DMZ ist schon richtig. Das sind alles Webanwendungen, die dort laufen. Die Kunden greifen via Browser über https://www.domain.de/application zu und /application läuft dann auf einem der Rechner in der DMZ.
AD benötigen wir für die GPOs, die auch für die Rechner in der DMZ gelten sollen, sowie für die Benutzerkonten der Entwickler, die auf den Rechnern ihren Kram installieren sollen.
Die Frage ist aus meiner Sicht eher: Brauchen wir in der DMZ eine separate AD Domain oder können wir nicht die interne AD Domain mitnutzen?
Viele Grüße,
tonabnehmer
Hallo
und für was brauchst du ein AD im DMZ?
Okay DNS kann praktisch sein aber brauchst du in der DMZ auch nich oder verwaltest du eure Domains selbst?
Grußnä
und für was brauchst du ein AD im DMZ?
Okay DNS kann praktisch sein aber brauchst du in der DMZ auch nich oder verwaltest du eure Domains selbst?
Grußnä
Na Gut einen hab ich noch,
Aber nur wegen der Zeitumstellung.
Dir schon klar das man auch jede Menge Webanwendungen auf einen Server platzieren kann?
Und das andere, du könntest auch einen kleinen Reverseproxy in die DMZ stellen und den Webserver in's Hausnetz. Haette auchVorteile für die Bedienbarkeit für die Programmierer aber auch wenn sich die Anwendungen selbst gegen ein AD anmelden sollten.
Aber nur wegen der Zeitumstellung.
Dir schon klar das man auch jede Menge Webanwendungen auf einen Server platzieren kann?
Und das andere, du könntest auch einen kleinen Reverseproxy in die DMZ stellen und den Webserver in's Hausnetz. Haette auchVorteile für die Bedienbarkeit für die Programmierer aber auch wenn sich die Anwendungen selbst gegen ein AD anmelden sollten.
Hi,
Ja klar, aber hier geht es nicht um 2-3 Anwendungen, sondern um dutzende. Die Anforderung lautet ganz klar: Die Projekte bekommen voneinander getrennte Rechner in der DMZ, um dort ihre Demos und Prototypen zu hosten. Die brauchen unterschiedliche OS, DBMS und Applikation/Web-Server.
Nein, denn dann werden Angreifer via Proxy in unser internes Netz geleitet!
Also: Wir benötigen in der DMZ Active Directory, daran führt kein Weg vorbei! Ich habe inzwischen in dem Dokument unter http://www.microsoft.com/en-us/download/details.aspx?id=3957 nachlesen können, dass unsere IST-Lösung einem sogenannten "Isolated forest model" entspricht. Dort werden aber auch "Forest trust" und "Extended corporate forest model" besprochen, letzteres mit writable oder read only DC.
Grüße,
tonabnehmer
Zitat von @wiesi200:
Dir schon klar das man auch jede Menge Webanwendungen auf einen Server platzieren kann?
Dir schon klar das man auch jede Menge Webanwendungen auf einen Server platzieren kann?
Ja klar, aber hier geht es nicht um 2-3 Anwendungen, sondern um dutzende. Die Anforderung lautet ganz klar: Die Projekte bekommen voneinander getrennte Rechner in der DMZ, um dort ihre Demos und Prototypen zu hosten. Die brauchen unterschiedliche OS, DBMS und Applikation/Web-Server.
Und das andere, du könntest auch einen kleinen Reverseproxy in die DMZ stellen und den Webserver in's Hausnetz. Haette
auchVorteile für die Bedienbarkeit für die Programmierer aber auch wenn sich die Anwendungen selbst gegen ein AD
anmelden sollten.
auchVorteile für die Bedienbarkeit für die Programmierer aber auch wenn sich die Anwendungen selbst gegen ein AD
anmelden sollten.
Nein, denn dann werden Angreifer via Proxy in unser internes Netz geleitet!
Also: Wir benötigen in der DMZ Active Directory, daran führt kein Weg vorbei! Ich habe inzwischen in dem Dokument unter http://www.microsoft.com/en-us/download/details.aspx?id=3957 nachlesen können, dass unsere IST-Lösung einem sogenannten "Isolated forest model" entspricht. Dort werden aber auch "Forest trust" und "Extended corporate forest model" besprochen, letzteres mit writable oder read only DC.
Grüße,
tonabnehmer
NaJa, man kann auch ohne Probleme 20-30 Webanwendungen auf einem Server laufen lassen.
Bei unterschiedlichen OS? Ein AD bringt dir nur bei Windows etwas und ob's jetzt auf XP läuft oder Windows xxxx Server sollte eigentlich egal sein, aber gut.
Ein Reverse Proxy leitet ja nicht direkt den Angreifer in dein internes Netz.
Die Frage ist nur, ist dir von einem Reverse Proxy eine HTTP Anfrage auf einen Webserver, oder von einem PC in der DMZ eine LDAP Anfrage auf eine AD wo alle deine Benutzer drinnen sind, lieber? Meine Meinung HTTP.
Bei unterschiedlichen OS? Ein AD bringt dir nur bei Windows etwas und ob's jetzt auf XP läuft oder Windows xxxx Server sollte eigentlich egal sein, aber gut.
Ein Reverse Proxy leitet ja nicht direkt den Angreifer in dein internes Netz.
Die Frage ist nur, ist dir von einem Reverse Proxy eine HTTP Anfrage auf einen Webserver, oder von einem PC in der DMZ eine LDAP Anfrage auf eine AD wo alle deine Benutzer drinnen sind, lieber? Meine Meinung HTTP.
Hallo,
Gruß
Zitat von @wiesi200:
Bei unterschiedlichen OS? Ein AD bringt dir nur bei Windows etwas und ob's jetzt auf XP läuft oder Windows xxxx Server
sollte eigentlich egal sein, aber gut.
Ich kann mich ohne Probleme über ein Linux Server am AD authentifizieren falls du das meinst.Bei unterschiedlichen OS? Ein AD bringt dir nur bei Windows etwas und ob's jetzt auf XP läuft oder Windows xxxx Server
sollte eigentlich egal sein, aber gut.
Gruß
Aber das war's dann schon. AD hat nicht nur was mit der Anmeldung zu tun.
Das Gruppenrichtlinien etc. unter Linux nicht funktionieren ist mir klar.
Aber ich kann auch meine Rechte Struktur unter Linux aus dem AD beziehen.
Das einige Funktionen nicht funktionieren weiß ich, ist allerdings mit Samba 4 geplant.
Gruß
Aber ich kann auch meine Rechte Struktur unter Linux aus dem AD beziehen.
Das einige Funktionen nicht funktionieren weiß ich, ist allerdings mit Samba 4 geplant.
Gruß
Hallo zusammen,
bitte redet mir doch nicht ein, dass wir in der DMZ 20-30 Anwendungen auf einem Rechner laufen lassen können oder Linux verwenden. Wir haben dort ganz klare Anforderungen aus den Softwareentwicklungsprojekten, die strikt voneinander getrennte Rechner pro Projekt und diverse Betriebssysteme, Datenbanken, Application Server etc. vorsieht. Active Directory ist dort ebenfalls ein Muss für GPOs, Password Policies, Benutzerauthentifizierung von interen Mitarbeiter auf den Windows Rechnern. Eure Einwände verstehe ich, aber die Projekte brauchen es und so bekommen sie es
Ich würde gern zum eigentlichen Thema zurückkommen, wegen dem ich den Thread gestartet habe: Notfallumgebung am entfernten Standort.
Hauptstandort und entfernter Notfallstandort sind per Site-to-Site VPN miteinander verbunden. Am Hauptstandort betreiben wir die Active Directory Domäne domain.local auf einem DC (DC1). Tritt das Disaster ein, ist der Hauptstandort vollständig nicht mehr verfügbar und es wird am Notfallstandort weiter gearbeitet. Sind dann folgende Annahmen richtig?
1) Die domain.local wird auf den entfernten Notfallstandort ausgedehnt.
2) Am Notfallstandort gibt es dazu einen zweiten DC (DC2), auf den domain.local repliziert wird.
3) DC2 darf kein RODC sein, da im Normalfall dort keine Anmeldedaten gecached sind und man auf einem RODC keine Gruppen oder Benutzer bearbeiten kann.
Vielen Dank und beste Grüße,
tonabnehmer
bitte redet mir doch nicht ein, dass wir in der DMZ 20-30 Anwendungen auf einem Rechner laufen lassen können oder Linux verwenden. Wir haben dort ganz klare Anforderungen aus den Softwareentwicklungsprojekten, die strikt voneinander getrennte Rechner pro Projekt und diverse Betriebssysteme, Datenbanken, Application Server etc. vorsieht. Active Directory ist dort ebenfalls ein Muss für GPOs, Password Policies, Benutzerauthentifizierung von interen Mitarbeiter auf den Windows Rechnern. Eure Einwände verstehe ich, aber die Projekte brauchen es und so bekommen sie es
Ich würde gern zum eigentlichen Thema zurückkommen, wegen dem ich den Thread gestartet habe: Notfallumgebung am entfernten Standort.
Hauptstandort und entfernter Notfallstandort sind per Site-to-Site VPN miteinander verbunden. Am Hauptstandort betreiben wir die Active Directory Domäne domain.local auf einem DC (DC1). Tritt das Disaster ein, ist der Hauptstandort vollständig nicht mehr verfügbar und es wird am Notfallstandort weiter gearbeitet. Sind dann folgende Annahmen richtig?
1) Die domain.local wird auf den entfernten Notfallstandort ausgedehnt.
2) Am Notfallstandort gibt es dazu einen zweiten DC (DC2), auf den domain.local repliziert wird.
3) DC2 darf kein RODC sein, da im Normalfall dort keine Anmeldedaten gecached sind und man auf einem RODC keine Gruppen oder Benutzer bearbeiten kann.
Vielen Dank und beste Grüße,
tonabnehmer
