Ein Active Directory, mehrere Remotedesktopdienste (Server 2012-Lösung)

Was ich versuche zu tun, ist ziemlich komplex, also dachte ich mir, ich würde es einem breiteren Publikum zugänglich machen, um zu sehen, ob jemand einen Fehler finden kann. Was ich versuche (als MSP / VAR), ist das Entwerfen einer Lösung, die mehreren Unternehmen einen sitzungsbasierten Remotedesktop (Unternehmen, die vollständig getrennt gehalten werden müssen) mit nur einer Handvoll Servern bietet. So stelle ich es mir im Moment vor:

• KERN-SERVER - Server 2012-Rechenzentrum (Alle unten aufgeführten sind HyperV-Server)
  Server1: Cloud-DC01 (Active Directory-Domänendienste für mycloud.local)
  Server2: Cloud-EX01 (Exchange Server 2010 im Mandantenmodus)
  Server3: Cloud-SG01 (Remotedesktop) Tor)
• KERN-SERVER 2 - Server 2012-Rechenzentrum (Alle unten aufgeführten sind HyperV-Server)
  Server1: Cloud-DC02 (Active Directory-Domänendienste für mycloud.local)
  Server2: Cloud-TS01 (Remotedesktop-Sitzungshost für Unternehmen A)
  Server3: Cloud-TS02 (Remote) Desktop-Sitzungshost für Unternehmen B)
  Server4: Cloud-TS03 (Remotedesktop-Sitzungshost für Unternehmen C)

Ich dachte darüber nach, jede Organisation in einer eigenen Organisationseinheit einzurichten (möglicherweise wurde ihre Organisationseinheitsstruktur basierend auf der OU-Struktur der Excahnge 2010-Mandanten erstellt, damit die Konten verknüpft sind). Jedes Unternehmen würde einen Remotedesktop-Sitzungshostserver erhalten, der auch als Dateiserver dienen würde. Dieser Server würde in seinem eigenen Bereich vom Rest getrennt sein. Der Server Cloud-SG01 hat Zugriff auf alle diese Netzwerke und leitet den Datenverkehr an das entsprechende Netzwerk weiter, wenn ein Client eine Verbindung herstellt und sich authentifiziert, sodass diese auf den richtigen Server übertragen werden (basierend auf Sitzungssammlungen im Jahr 2012).

Ich werde nicht lügen, das ist etwas, das ich mir ziemlich schnell ausgedacht habe, also kann es durchaus etwas geben, das mir offensichtlich fehlt. Jedes Feedback wäre dankbar.

Dies ist sehr ähnlich zu dem, was wir tun. Wir haben ein einziges TS-Gateway, über das alle unsere Kunden eintreten. Dies hat Verbindungs- und Ressourcenrichtlinien, die steuern, welche Benutzergruppen sich an welchen Servern anmelden können.

Jedes Unternehmen verfügt über einen eigenen Terminalserver. Die meisten Unternehmen können sich nur bei einem TS anmelden, für einen besonders großen Kunden haben sie jedoch zwei. Wir machen kein Clustering von ihnen, nur die Hälfte der Benutzer stellt eine Verbindung zu TS1 und die andere Hälfte eine Verbindung zu TS2 her.

Alle Server befinden sich im selben Netzwerksegment, und wir haben sehr strenge ACLs, um zu definieren, wer wohin im Netzwerk gehen kann (dh niemand kann wirklich irgendwohin gehen). Unser Gruppenrichtlinienobjekt für die RDS-Server schränkt auch stark ein, wo sie auf dem Server selbst gespeichert werden können.

Das größte Problem bei diesem Setup ist die automatisierte Bereitstellung von Servern für neue Clients. Der größte Teil des Prozesses kann automatisiert werden (wir verwenden ESXi und vSphere, die über eine Powershell-Integration verfügen. Genau wie Hyper-V), aber ich habe noch nicht herausgefunden, wie die Änderung von TS Gateway-Richtlinien automatisiert werden kann.

Wir haben auch einen sehr großen Client, der unsere gehosteten Terminalserver verwendet. Da ich mich nicht darum kümmern wollte, alle Kennwortrücksetzungen und neuen Konten selbst zu verwalten, haben wir ihnen Delegierungsrechte für ihre eigene Organisationseinheit in der Domäne eingeräumt. Als sie herauswuchsen, gaben wir ihnen aus politischen Gründen ihre eigene Domäne unter unserem Wald. Das hat bisher auch ganz gut funktioniert, außer dass Sie das nicht verwenden können, User must change their password on next logonda dies nicht mit TS Gateway kompatibel ist. Gleiches gilt, wenn ihr Passwort abläuft, sie sich nicht anmelden können und jemand sein Passwort manuell zurücksetzen muss.