mwiederkehr 373 Geschrieben 17. April 2020 Melden Teilen Geschrieben 17. April 2020 Hallo zusammen Ein Kunde bietet seine Software (Branchenlösung) gehostet an. Da die Software nicht mandantenfähig ist und einige Kunden zusätzlich noch andere Anwendungen gehostet haben wollen, haben wir bisher pro Kunde einen Terminalserver betrieben. Dieser war nicht in einer Domäne (da zu aufwändig/teuer für nur zwei bis zehn Benutzer) und auch nicht DC (weil TS auf DC bekanntlich nicht so toll ist). Das hat wunderbar funktioniert seit Windows 2008 R2. Windows 2019 will aber eine Domäne, sonst läuft die Terminalserver-Lizenzierung nicht. Meine Idee war, eine Domäne für alle Mandanten aufzubauen. Die einzelnen Server wären immer noch per Firewall getrennt. Pro Mandant gäbe es eine OU. Damit die Benutzer einander nicht sehen, hätte ich ihnen im AD die Leserechte auf jeweils alle anderen OU entzogen. Oder könnte man ihnen sogar die Leserechte auf das gesamte AD entziehen? Also können tut man, aber gäbe es dann Probleme? Es ist noch anzumerken, dass es keine Katastrophe wäre, wenn sich die Kunden untereinander einmal sehen würden. (Wer Anwender der Branchenlösung ist, ist kein Geheimnis, die Daten der Kunden natürlich schon.) Habe ich etwas übersehen, das gegen meine Idee spricht? Hattet ihr schon ähnliche Anforderungen und habt es eleganter gelöst? Vielen Dank für eure Erfahrungen! Zitieren Link zu diesem Kommentar
testperson 1.674 Geschrieben 17. April 2020 Melden Teilen Geschrieben 17. April 2020 Hi, im Prinzip "Ja". Beim AD hast du einerseits die Möglich den List Object Mode zu aktivieren. Anderseits kannst du das auch über entsprechend "Inhalt Auflisten" und "Eigenschaften Lesen" per Deny lösen. Das wird hier grob beschrieben: https://social.technet.microsoft.com/wiki/contents/articles/29558.active-directory-controlling-object-visibility-list-object-mode.aspx Wir selber betreiben ein AD per "Deny" beim Upgrade der DCs von 2008 R2 auf 2016 habe ich mich mehrfach eingenä*t obwohl es bei Tests funktioniert hat. ;) Die "Verwaltung" und alles was so dran hängt ist Unmengen an PowerShell Code. "Den Rest" hosten wir derzeit noch in dedizierten AD-Gesamtstrukturen. Gruß Jan Zitieren Link zu diesem Kommentar
NilsK 2.930 Geschrieben 17. April 2020 Melden Teilen Geschrieben 17. April 2020 (bearbeitet) Moin, Radio Eriwan: Im Prinzip schon ... Ich rate von solchen Konstrukten entschieden ab. Wenn du wirklich eine einigermaßen saubere Trennung der Mandanten erreichen willst - Kunde A sieht nichts (überhaupt nichts!) von Kunde B - dann wirst du sehr tief in die Berechtigungen des AD eingreifen müssen. Das ist richtig Arbeit. Und du verlierst faktisch den Support durch Microsoft für das AD. Lustig wird es dann, wenn noch Exchange dazukommt, weil sich das seit 2013 nicht mehr an die AD-Berechtigungen hält. Da darf man alles dann noch mal dicht machen. Die meisten Hosting-Umgebungen arbeiten daher auch für Kleinkunden mit separaten Forests pro Mandant. Gruß, Nils bearbeitet 17. April 2020 von NilsK 1 Zitieren Link zu diesem Kommentar
testperson 1.674 Geschrieben 17. April 2020 Melden Teilen Geschrieben 17. April 2020 vor 42 Minuten schrieb NilsK: Die meisten Hosting-Umgebungen arbeiten daher auch für Kleinkunden mit separaten Forests pro Mandant. Am Ende des Tages ist man sind wir da aber auch schnell in einer Situation angekommen, wo man wir "bescheide Dinge" gegeneinander aufwiegen kann konnten. Ich wäre ja schon froh, wenn die Mehrheit unserer Kunden _einen_ dedizierten DC betreiben (lassen) würde. Daher wiegen wir schon länger "DC + Exchange ( + im "Worst Case" SQL)" gegen "Mandanten AD (mit MS Exchange Online) " auf... P.S.: Natürlich trifft "uns" eine erhebliche Mitschuld an solchen Konstrukten (die aber dennoch vernünftig laufen, auch wenn man sich hier und da ins Knie schießt und sich verbiegen muss)... Zitieren Link zu diesem Kommentar
mwiederkehr 373 Geschrieben 17. April 2020 Autor Melden Teilen Geschrieben 17. April 2020 Danke für eure Antworten! Werde mir die Doku zum List Object Mode durchlesen. Kannte bisher nur die Deny-Methode. Und die ist gefährlich, wenn man nicht alles gescriptet hat und der Supporter mal die Checkliste nicht zu Ende liest... vor 32 Minuten schrieb testperson: P.S.: Natürlich trifft "uns" eine erhebliche Mitschuld an solchen Konstrukten (die aber dennoch vernünftig laufen, auch wenn man sich hier und da ins Knie schießt und sich verbiegen muss)... Von "Schuld" würde ich nicht sprechen, aber ich finde, Microsoft könnte da flexibler sein. Einerseits benötigen immer mehr ihrer Anwendungen eine Domäne, andererseits benötigt man für einen DC immer noch eine komplette VM, auch wenn dann nur drei Benutzer im AD stehen. (Etwas überspitzt gesagt natürlich, ein DC macht ja schon noch etwas mehr als LDAP-Anfragen zu beantworten.) Wäre schön, wenn es etwas wie das Azure AD auch für Hoster gäbe. Windows 10 Multisession gibt es ja leider auch nur auf Azure. Zitieren Link zu diesem Kommentar
testperson 1.674 Geschrieben 17. April 2020 Melden Teilen Geschrieben 17. April 2020 vor 1 Minute schrieb mwiederkehr: Von "Schuld" würde ich nicht sprechen, Naja doch, wenn der Kunde "einfach nur billig" will kann man auch "einfach nur nein" sagen. ;) (In unserem Fall jetzt) vor 7 Minuten schrieb mwiederkehr: Windows 10 Multisession gibt es ja leider auch nur auf Azure. Ist / Wird doch für Azure Stack Hub freigegeben. ;) Zitieren Link zu diesem Kommentar
NilsK 2.930 Geschrieben 17. April 2020 Melden Teilen Geschrieben 17. April 2020 Moin, man behalte im Auge, dass Active Directory über 20 Jahre alt ist und eine ganze Reihe weiterer Einschränkungen nie losgeworden ist, die teils noch deutlich gravierender sind. Seit mindestens zehn Jahren muss man das AD als "Legacy"-Technik ansehen, die eben da ist, an der sich aber auch nichts Großes mehr ändern wird. Kunden, die ernsthaft Bedarf an Spezialitäten haben, haben längst ihre Workarounds gefunden, sodass ein neuer großer Wurf vielleicht überhaupt nicht genutzt würde. Und am Ende - ja, ich verstehe das Abwägen, von dem Jan spricht. Aber eine zusätzliche VM ist dann eben auch nur eine zusätzliche VM, die nur sehr überschaubare Kosten verursacht. Rechnet man das spitz, wird man den Multi-Mandanten-Ansatz kaum jemals ernsthaft verfolgen wollen. Gruß, Nils 3 Zitieren Link zu diesem Kommentar
MrCocktail 192 Geschrieben 22. April 2020 Melden Teilen Geschrieben 22. April 2020 Moin, ich werfe jetzt einfach mal Server 2016 in Raum ... Wenn man es denn weiterhin einfach betreiben will. Server 2019 hat in meinen Augen als RDS Host kaum Vorteile und die Support Zeit ist doch auch nur bis 2025 ... Ansonsten haben die anderen hier eigentlich schon alles gesagt. Gruß J Zitieren Link zu diesem Kommentar
Dukel 451 Geschrieben 22. April 2020 Melden Teilen Geschrieben 22. April 2020 Wie kommst du auf 2025? Windows Server 2016 hat Support bis 2022 (Extended bis 2027) und Server 2019 bis 2024 (Extended bis 2029). Zitieren Link zu diesem Kommentar
NilsK 2.930 Geschrieben 22. April 2020 Melden Teilen Geschrieben 22. April 2020 Moin, ich verstehe gerade nicht, wie dieses Thema hier reinpasst ...? Gruß, Nils Zitieren Link zu diesem Kommentar
testperson 1.674 Geschrieben 22. April 2020 Melden Teilen Geschrieben 22. April 2020 vor 6 Minuten schrieb NilsK: ich verstehe gerade nicht, wie dieses Thema hier reinpasst ...? Die RDS Rolle unter Windows Server 2019 braucht laut TO einen Domain Controller und der Windows Server 2016 wohl nicht. Damit wäre das Thema Domäne ad acta gelegt, sofern es nicht zwingend Windows Server 2019 sein muss. Zitieren Link zu diesem Kommentar
MrCocktail 192 Geschrieben 22. April 2020 Melden Teilen Geschrieben 22. April 2020 vor 2 Stunden schrieb Dukel: Wie kommst du auf 2025? Windows Server 2016 hat Support bis 2022 (Extended bis 2027) und Server 2019 bis 2024 (Extended bis 2029). Hups... Da bin ich wie immer von Exchange ausgegangen, sorry... Und ja, das war für mich aufgrund von DC benötigt 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.