cbka 0 Geschrieben 11. Oktober 2017 Melden Teilen Geschrieben 11. Oktober 2017 Hallo Zusammen und guten Abend, wir planen die umstellung einer "historisch gewachsenen IT-Landschaft" in etwas mehr strukturiertes... Folgende Situation: MaxMustermann hat mehrere Firmen. contosoA contosoB contosoC contosoD A-D sollen sich nun einen gemeinsamen Exchange 2016 teilen. Als Infrastruktur steht ein 2 node Hyper-v 2016 Cluster mit zentralem Storage via 10G-iSCSI zur verfügung + 1 Server 2012R2 Hyper-V außerhalb vom Clusterverbund für die virtuellen secondary DCs. A-D sollen aber "komplett voneinander getrennt" sein. D.h. Keine Einträge von contosoA in der GAL von contosoB Um den Aufwand aber möglichst gering zu halten, sollen die Anmeldekonton von contosoA-D dem Exchange bekannt sein und zur Authentifizierung benutzt werden können. Da dies der erste Kunde mit so einer Landschaft ist, habe ich so meine Zweifel an meinem Domain-Design und komme nun nach mehreren Tagen HOwTos und Technet auf euch zurück... Hat jemand einen Tipp für mich, wie das am sinnvollsten und einfachsten (geringer verwaltungsoverhead) zu lösen ist ? Cheers, Chris Zitieren Link zu diesem Kommentar
NorbertFe 2.027 Geschrieben 11. Oktober 2017 Melden Teilen Geschrieben 11. Oktober 2017 (bearbeitet) Nabend, vorsichtig formuliert widersprechen sich die dort oben stehenden Anforderungen: A-D sollen sich nun einen gemeinsamen Exchange 2016 teilen. A-D sollen aber "komplett voneinander getrennt" sein. D.h. Keine Einträge von contosoA in der GAL von contosoB Wie groß ist der Kunde? Die "wahrscheinlich sinnvollste" Lösung dürfte eine Single Domain Umgebung sein und die Trennung der User in entsprechende OUs (nach Firmen). Die Trennung im Exchange läßt sich "rudimentär" mittels Adressbuchpolicies abbilden, aber auch das würde ich pauschal erstmal hinterfragen. Für mich klar ein Fall von Beratung des Kunden und Anforderungsdefinitionen, welche sich danach auch basierend auf technischen Notwendigkeiten abbilden lassen. Im Zweifel auch mit allen folgenden Konsequenzen wie das nicht Erfüllen von _geringem_ administrativen Overhead oder "einfacher Implementierung". ;) Bye Norbert bearbeitet 11. Oktober 2017 von NorbertFe Zitieren Link zu diesem Kommentar
NilsK 2.930 Geschrieben 12. Oktober 2017 Melden Teilen Geschrieben 12. Oktober 2017 Moin, wie Norbert schon sagt - so ohne Weiteres ist das technisch nicht möglich. Um das "Weitere" passend einschätzen zu können, sollte man einen ausführlichen Design-Workshop machen. Die Pole der Designvarianten sind (auch hier stimme ich Norbert zu): Single-Domain für alle Firmen, Aufteilung per OU, AD-Berechtigungen, Exchange-Berechtigungen und Adressbuch-Richtliniendas ist der administrativ einfachste Aufbau, der aber auf "komplette Trennung" verzichtet und in der Einrichtung einiges an Aufwand und Sorgfalt erfordert Je ein Forest (jeweils als Single-Domain) und je eine Exchange-Umgebung pro Firmadas ist die einzige "vollständige Trennung", aber die Anmeldekonten sind dann eben auch getrennt Ohne genau zu erörtern, welche Anforderungen hinter den Wünschen stehen, kann man das nicht entwerfen. Gruß, Nils Zitieren Link zu diesem Kommentar
cbka 0 Geschrieben 12. Oktober 2017 Autor Melden Teilen Geschrieben 12. Oktober 2017 Hallo und guten Morgen, zuerst - vielen dank für die Antworten. Ich versuche mal etwas Licht ins Dunkle meiner Formulierung zu bekommen... vorsichtig formuliert widersprechen sich die dort oben stehenden Anforderungen:Wie groß ist der Kunde? Der Kunde hat in keiner contoso mehr als 50 MA (bis jetzt) Jede Contoso hat mind. einen RDS-Server. Eigentlich arbeiten alle Mitarbeiter ausschließlich auf den Terminalservern. Die "wahrscheinlich sinnvollste" Lösung dürfte eine Single Domain Umgebung sein und die Trennung der User in entsprechende OUs (nach Firmen). wie würdest du das dann mit der anmeldedomain handhaben? wenn ich das in OUs auftrenne, dann habe ich doch lediglich unterschiedliche Nutzernamen, oder ? Hier kommt die lustige Sache: Mitarbeiter1 arbeitet in contosoA - ist aber gleichzeitig auch in contosoB tätig. Demnach müsste es ja dann Mitarbeiter1.contosA@domain.local und Mitarbeiter1.contosoB@domain.local geben. Je ein Forest (jeweils als Single-Domain) und je eine Exchange-Umgebung pro Firmadas ist die einzige "vollständige Trennung", aber die Anmeldekonten sind dann eben auch getrennt Das war irgendwie mein Plan... je ein Forest pro Contoso und dann einen Resourceforest oben drüber. Trusts zwischen den Contosos und dem Resourceforest. Quasi wie ein tree, nur eben als einzelne Forests. Dann hätte man ja auch die Porblematik mit den Anmeldekonton am Exchange im Griff, oder ? stichwort LinkedMailbox? Besten Dank für eure Gedanken und Kritik, Cheers, Chris Zitieren Link zu diesem Kommentar
Dukel 451 Geschrieben 12. Oktober 2017 Melden Teilen Geschrieben 12. Oktober 2017 (bearbeitet) https://de.wikipedia.org/wiki/User_Principal_Name Du erstellst für jeden Contoso einen Realm und der Beispiel Benutzer hat einen Account Mitarbeiter1@ContosoA.de und Mitarbeiter1@ContosoB.de. Das war irgendwie mein Plan... je ein Forest pro Contoso und dann einen Resourceforest oben drüber. Trusts zwischen den Contosos und dem Resourceforest. Quasi wie ein tree, nur eben als einzelne Forests. Bei vier Contosos und einer Ressourcendomäne sind das fünf Domänen, sprich 10 DC's für 200 Mitarbeiter? Das würde ich vermeiden wollen. bearbeitet 12. Oktober 2017 von Dukel Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 12. Oktober 2017 Melden Teilen Geschrieben 12. Oktober 2017 (bearbeitet) Moin A-D sollen sich nun einen gemeinsamen Exchange 2016 teilen. Ist das denn zwingend, einen eigenen Exchange inhouse zu betreiben (wollen)? Ich denke, für jede Firma wird wohl eine eigene Maildomäne benötigt. https://products.office.com/de-at/exchange/exchange-online Und, google nach Hosted Exchange Der Rest könnte wohl in einer AD-Domäne(2xDC) mit neutralem Namen für alle gebildet werden. bearbeitet 12. Oktober 2017 von lefg Zitieren Link zu diesem Kommentar
NilsK 2.930 Geschrieben 12. Oktober 2017 Melden Teilen Geschrieben 12. Oktober 2017 Moin, ihr braucht Beratung. In Form eines Workshops. Designfragen dieser Art sind nichts für ein Forum. Gruß, Nils Zitieren Link zu diesem Kommentar
NorbertFe 2.027 Geschrieben 12. Oktober 2017 Melden Teilen Geschrieben 12. Oktober 2017 Quasi: Für mich klar ein Fall von Beratung des Kunden und Anforderungsdefinitionen ;) Zitieren Link zu diesem Kommentar
Squire 260 Geschrieben 13. Oktober 2017 Melden Teilen Geschrieben 13. Oktober 2017 Der TO ist nicht der Kunde sondern der Dienstleister! Zitieren Link zu diesem Kommentar
NorbertFe 2.027 Geschrieben 13. Oktober 2017 Melden Teilen Geschrieben 13. Oktober 2017 Und der Dienstleister kann nicht darauf hingewiesen werden, dass der Kunde fachkundige Beratung benötigt? Alternativ kann der Dienstleister sich natürlich auch zum Kunden machen und Dienstleistung beauftragen. ;) Zitieren Link zu diesem Kommentar
Dr.Melzer 191 Geschrieben 14. Oktober 2017 Melden Teilen Geschrieben 14. Oktober 2017 Könnt ihr bitte Diskussionen die nicht der Problemlösung des TO dienen bleiben lassen! Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.