Testdomänen parallel betreiben

[DAUjones 10]

Hallo erstmal.

 

Hier soll in absehbarer Zeit der Testbetrieb für unsere Softwareentwickler neu organisiert werden. Es handelt sich um Backupsoftware, die auch Exchange, SQL und Sharepoint sichert und dabei natürlich auf das AD zurück greift.

Wegen der mit den jeweiligen Exchange-Versionen einhergehenden Schemaerweiterungen wird man wohl für jedes Szenario eine eigen Domäne benötigen sprich

- AD 2003 mit Ex 2003

- AD 2003 mit Ex 2007

- AD 2008 mit Ex 2003

- AD 2008 mit Ex 2007

(- AD und Ex gemischt) ?

 

Die Tester (ca. 15 Leute) sind teilweise örtlich sehr weit voneinander getrennt (Europa, Russland, Indien) und sollen über VPN-Verbindungen ihre jeweiligen Tätigkeiten erledigen können. Idealerweise werden deren Berechtigungen zentral geregelt, da die laufend geändert werden müssen. Ein Tester soll also nur auf bestimmte Szenarien zugreifen können, nicht auf alle.

Derzeit wählen die sich über den VPN-Zugang der Mutterfirma auf XP-VMs ein und von dort weiter über RDP auf die jeweiligen Testmaschinen. Jeder hat Dom-Admin-Berechtigungen. Das ist eben zu chaotisch und auch von der Performance her nicht optimal.

 

Daher mein Ausgangsüberlegung einer übergeordneten Domäne mit darunter liegenden Szenariendomänen mit Vertrauensstellungen. Tester werden über die oberste Domäne berechtigt, sprich User A soll z.B. auf Domäne 1 und 3 zugreifen können, nicht auf die restlichen.

 

Eine Hauptfrage wäre jetzt bezüglich der "Tragweite" der Schemaänderungen, die von den jeweiligen Exchangeversionen vorgenommen werden. Können die in den untergeordneten Domänen verursachten Schemaerweiterungen die Testszenarien der anderen Domäne irgendwie beeinflussen oder muss ich mir da keine Sorgen machen?

MS-SQL 2005 und 2008 sowie Sharepoint kommen auch noch mit dazu, ändern aber meines Wissen das Schema nicht weiter ab.

 

Das reicht wohl für's Erste. :)

 

Schonmal Danke im Voraus für Ideen, Anregungen, Kritik.

[NilsK 2.932]

Moin,

 

dein Szenario lässt sich innerhalb desselben Forest nicht abbilden. Zum einen gelten die Schemadefinitionen für den ganzen Forest, zum anderen ist der Forest gleich der Exchange-Organisation. Du benötigst also separate Forests.

 

Gruß, Nils

[DAUjones 10]

Das hatte ich befürchtet.

 

Ich bin auch für anders geartete Lösungsvorschläge bzw. -ansätze zu haben.

[NilsK 2.932]

Moin,

 

dazu müsstest du erst mal deine Anforderungen definieren. Aus deiner Beschreibung wird nicht ganz klar, welches Ziel du mit der Änderung verfolgst. Performancevorteile könnte ich bei deinem Modell jedenfalls nicht erkennen.

 

Gruß, Nils

[DAUjones 10]

Problem ist, die derzeitige Umgebung ist mehr oder weniger natürlich gewachsen, sprich durch diverse Adminhände undokumentiert entstanden. Es muss also so oder so was neu gemacht werden. Dazu fehlen die 2008er-Szenarien.

 

Wichtig wären die Regelung des Zugangs der Tester, dass eben nicht jeder überall alles darf und das möglichst zentral verwaltet.

 

Es soll auch der eigene Internetzugang verwendet werden und nicht wie bislang der Umweg über die Mutterfirma. Die Tester klagen regelmässig über lahme Performance der Remoteverbindungen und es wird vermutet, dass es mit einem direkteren Zugang besser wird. Desweiteren gehts auch um mehr administrative Unabhängigkeit von der Mama.

 

Nach Deiner Info zur Unumsetzbarkeit von Plan A denke ich gerade an ein Remote-Tool, das intern Berechtigungen (also wer auf welche Maschinen) regeln kann. Wollte gerade einen eigenen Thread dazu eröffnen.

[NilsK 2.932]

Moin,

 

müssen denn die Tester remote arbeiten?

 

Du könntest sie per TS-Gateway via Web auf einen Terminalserver zugreifen lassen, auf dem die verschiedenen Testmaschinen als RDP-Zugänge hinterlegt sind (nicht getestet, aber sollte gehen). Die Testmaschinen selbst könnten VMs sein, die bei Bedarf oder automatisch auf einen definierten Stand zurückgesetzt werden.

 

Welche Berechtigungen wo nötig sind, könnt ihr nur selbst definieren und einrichten. Sobald aber jemand Adminrechte hat, hat er die Sache im Griff.

 

Gruß, Nils

[DAUjones 10]

Was mir gerade einfällt...wenn wir keine übergeordnete Domäne verwenden sondern lediglich Vertrauensstellungen, sollte das doch eigentlich klappen, oder? Dann sollten sich die Szenarien nicht in die Quere kommen können, aber der RDP-Zugriff kann über Gruppenzugehörigkeit geregelt werden.

–

Moin,

 

müssen denn die Tester remote arbeiten?

Wie sonst von Indien aus? Die Hardware steht hier in D.

 

Du könntest sie per TS-Gateway via Web auf einen Terminalserver zugreifen lassen, auf dem die verschiedenen Testmaschinen als RDP-Zugänge hinterlegt sind (nicht getestet, aber sollte gehen). Die Testmaschinen selbst könnten VMs sein, die bei Bedarf oder automatisch auf einen definierten Stand zurückgesetzt werden.

Die Testmaschinen sind teils physikalisch, teils VM.

Das mit den hinterlegten RDP-Shortcuts ist zu leicht ausgehebelt. Die Leute sind u.A. Entwickler, also keine DAUs.

 

Welche Berechtigungen wo nötig sind, könnt ihr nur selbst definieren und einrichten. Sobald aber jemand Adminrechte hat, hat er die Sache im Griff.

Genau deswegen soll die Macht ja geteilt und reglementiert werden. Zur Zeit ist das nicht der Fall.

–

edit:

Kann nicht der ISA-Server den Remotezugriff regeln?

[NilsK 2.932]

Moin,

 

Wie sonst von Indien aus? Die Hardware steht hier in D.

 

ich frag ja nur. Bislang hattest du noch nicht erwähnt, dass die Testhardware in Deutschland stehen muss.

 

Das mit den hinterlegten RDP-Shortcuts ist zu leicht ausgehebelt. Die Leute sind u.A. Entwickler, also keine DAUs.

 

Erschließt sich mir nicht. Auf dem TS-Webinterface sind halt nur Applikations-Icons hinterlegt, eins pro RDP-Zugang. Das soll nur den Zugriff ohne VPN erleichtern, mehr nicht. Warum soll das weniger sicher sein als euer derzeitiger Zugang?

 

Genau deswegen soll die Macht ja geteilt und reglementiert werden. Zur Zeit ist das nicht der Fall.

 

Wie gesagt, das müsst ihr dann selbst regeln. Mir scheint, dass eure Vorstellungen da bislang noch in einem sehr rudimentären Stadium sind.

 

Kann nicht der ISA-Server den Remotezugriff regeln?

 

Natürlich kann er das.

 

Genauer kann man das nicht sagen, weil dafür einfach Details und Anforderungen fehlen. Ihr solltet euch erst mal hinsetzen, eure Anforderungen spezifizieren und ein Grundkonzept entwickeln. Für technische Details ist es eindeutig noch zu früh.

 

Gruß, Nils

[nerd 28]

Hi,

 

bin mir jetzt nicht sicher, ob ich alles vollständig richtig vestanden habe - wie Nils schon gesagt hat fehlen ein paar Details. Ich würde aber Grundsätzlich seinen Vorschlägen folgen und diese noch minimal erweitern:

 

1. Umgebung vollständig virtualisieren und für jede deiner Umgebungen ein eigenes virtuelles Netz aufbauen (Entwickler gehören eh nicht in Produktion).

2. Zugang zu den Testnetzen NUR über einen Terminalserver der die Zugriffsrechte auf die VMs regelt in dem er die Verknüpfungen anzeigt oder eben nicht.

 

Vorteile dieses Aufbaus:

1. Du kannst die Umgebung jederzeit zurück setzen und damit auf einen definierten Punkt zurück kommen.

2. Die Dev's können in Ihren Domänen weiterhin Admin sein und jammern dir nicht die Ohren voll mit Dingen die nicht mehr gehen...

3. Die Umgebungen sind nicht nur untereinander abgesichert, sie sind zudem auch aus eurem Netz raus.

4. Hat jemand via Terminalserver keinen Zugriff auf eine VM, dann hat er den Zugang auch nicht, da die einzelnen Netze untereinander nicht kommunizieren können und somit RDP Verbindungen nicht möglich sind.

[DAUjones 10]

Erschließt sich mir nicht. Auf dem TS-Webinterface sind halt nur Applikations-Icons hinterlegt, eins pro RDP-Zugang. Das soll nur den Zugriff ohne VPN erleichtern, mehr nicht. Warum soll das weniger sicher sein als euer derzeitiger Zugang?

Jetzt ist das Ganze reichlich unsicher. Jeder Tester ist quasi Domänen-Admin und kann überall alles. Das soll ja geändert werden.

 

Mir scheint, dass eure Vorstellungen da bislang noch in einem sehr rudimentären Stadium sind.

Ähem...ja. Natürlich. Ich suche ja nach einem brauchbaren Ansatz.

 

Natürlich kann er das.

 

Genauer kann man das nicht sagen, weil dafür einfach Details und Anforderungen fehlen. Ihr solltet euch erst mal hinsetzen, eure Anforderungen spezifizieren und ein Grundkonzept entwickeln. Für technische Details ist es eindeutig noch zu früh.

Naja, ich muss wissen, was technisch machbar/sinnvoll ist. Sonst wird das Grundkonzept nix.

 

Die Tester sollen eine sichere Verbindung zum (zu den) Testnetzwerk(en) bekommen, wo sie ihre jeweiligen Aufgaben erledigen können. Wer auf welche Testdomäne zugreifen darf soll relativ flexibel aber zentral geregelt werden können. Innerhalb der jeweiligen Testdomäne wird der Tester wohl oder übel Dom-Admin-Rechte haben müssen.

 

Ich habe leider keine Erfahrungen mit dem ISA-Server. Kann der einem User bzw. einer Gruppe RDP-Zugriff auf nur einige bestimmte Server geben? Falls ja, können diese Server in einer eigenen Domäne sein, die nichts mit der Domäne, in der sich der ISA befindet, zu tun hat ausser am gleichen Switch zu hängen bzw. im gleichen IP-Netzwerk?

–

wie Nils schon gesagt hat fehlen ein paar Details.

Mal anders rum: Welche Details fehlen Euch denn?

 

1. Umgebung vollständig virtualisieren und für jede deiner Umgebungen ein eigenes virtuelles Netz aufbauen (Entwickler gehören eh nicht in Produktion).

Hier am Standort ist quasi nur Entwicklung. Eine vollständige Virtualisierung wird nicht möglich sein. Die Software ist für Appliances...plus halt die Client-Agents. Auch sind derzeit mehr als nur ein physikalischer Server mit VMware ESX im Einsatz + einige physikalische XP-Clients. Letztere sind absichtlich alte Kisten mit "wilder" Hardware, weil nur so reale Bedingungen simuliert werden können. Reine VMs sind zu "glatt".

 

2. Zugang zu den Testnetzen NUR über einen Terminalserver der die Zugriffsrechte auf die VMs regelt in dem er die Verknüpfungen anzeigt oder eben nicht.

DAS habe ich jetzt noch nicht so ganz verstanden. Der TS soll ausserhalb der Testdomänen/-netze liegen? Jede Testdomäne in einem eigene IP-Bereich?

Was hindert den Tester am Öffnen einer RDP-Verbindung auf einen beliebigen Rechner im Netz? Oder meint ihr einen TS für jede Testdomäne?

 

Vorteile dieses Aufbaus:

1. Du kannst die Umgebung jederzeit zurück setzen und damit auf einen definierten Punkt zurück kommen.

2. Die Dev's können in Ihren Domänen weiterhin Admin sein und jammern dir nicht die Ohren voll mit Dingen die nicht mehr gehen...

3. Die Umgebungen sind nicht nur untereinander abgesichert, sie sind zudem auch aus eurem Netz raus.

4. Hat jemand via Terminalserver keinen Zugriff auf eine VM, dann hat er den Zugang auch nicht, da die einzelnen Netze untereinander nicht kommunizieren können und somit RDP Verbindungen nicht möglich sind.

Schwierig so zu realisieren wegen der oben geschilderten Problematik. Die Anschaffung eines Blade-Systems wurde schon mal erwogen...bis man die Kosten sah.

[NilsK 2.932]

Moin,

 

Jetzt ist das Ganze reichlich unsicher. Jeder Tester ist quasi Domänen-Admin und kann überall alles. Das soll ja geändert werden.

 

Moment. Einerseits willst du das ändern, andererseits sagst du:

 

Innerhalb der jeweiligen Testdomäne wird der Tester wohl oder übel Dom-Admin-Rechte haben müssen.

 

Muss ich das verstehen?

 

Mal anders rum: Welche Details fehlen Euch denn?

 

Kann man so nicht sagen. Dein Problem liegt nicht auf einer technischen, sondern auf einer konzeptuellen Ebene. Dafür ist ein Forum nicht besonders geeignet.

 

Der TS soll ausserhalb der Testdomänen/-netze liegen?

 

Ja. Natürlich. Der TS ist Standalone oder meinethalben Mitglied der Produktionsdomäne. Die Testserver sind eigene Forests. Müssen sie ja sowieso, wegen Exchange. Vertrauensbeziehungen zwischen Produktion und Test gibt es nicht.

 

Jede Testdomäne in einem eigene IP-Bereich?

 

Kann, braucht aber nicht.

 

Was hindert den Tester am Öffnen einer RDP-Verbindung auf einen beliebigen Rechner im Netz?

 

Dass ihm der TS-Gateway nur die Icons gibt, die er sehen darf. Und dass er zu den anderen Maschinen ja nicht die Kennwörter kennen muss.

 

Schwierig so zu realisieren wegen der oben geschilderten Problematik. Die Anschaffung eines Blade-Systems wurde schon mal erwogen...bis man die Kosten sah.

 

Was soll die Frage Blade oder nicht Blade mit dem Problem zu tun haben? Ein Blade ist nur ein Formfaktor für Server.

 

Wir haben dir schon ein paar Ansatzpunkte geliefert. Mein Favorit wäre, die gesamte Umgebung als VMs aufzubauen, vielleicht auch skriptgesteuert. Zu bestimmten Intervallen (oder wie auch immer) wird die Umgebung auf einen definierten Stand zurückgesetzt. Dabei ändert man dann die Kennwörter und teilt sie nur den Berechtigten mit. Dürfte schon ziemlich weit kommen.

 

Gruß, Nils

[nerd 28]

Hi,

 

also ich stimme Nils in allen Punkten vollständig zu. Plus:

 

Ich habe leider keine Erfahrungen mit dem ISA-Server. Kann der einem User bzw. einer Gruppe RDP-Zugriff auf nur einige bestimmte Server geben? Falls ja, können diese Server in einer eigenen Domäne sein, die nichts mit der Domäne, in der sich der ISA befindet, zu tun hat ausser am gleichen Switch zu hängen bzw. im gleichen IP-Netzwerk?

 

Ich denke ein ISA ist hier eher fehl am Platz. Man könnte damit vielleicht etwas basteln aber das wäre dann auf jeden Fall eine Sandkastenlösung...

 

Da du keine vollständig virtuelle Umgebung haben möchtest würde ich meinen Ansatz der virtuellen Netze durch vLans umsetzen. Jede der Teststellungen bekommt also eine eigene VLan ID und der einzige Zugang zu dem Netz geht über den TS (dieser steht in allen VLans). Damit ist sicher gestellt, dass die Entwickler nicht aus den vorgegebenen Umgebungen raus kommen.

 

DAS habe ich jetzt noch nicht so ganz verstanden. Der TS soll ausserhalb der Testdomänen/-netze liegen? Jede Testdomäne in einem eigene IP-Bereich?

Was hindert den Tester am Öffnen einer RDP-Verbindung auf einen beliebigen Rechner im Netz? Oder meint ihr einen TS für jede Testdomäne?

Jup vollständig ausserhalb an einem so genannten Trunk-Port des Switches welches deine Teststellungen verwaltet. Wie Nils schon gesagt hat könnte man sich überlegen den TS in die Prod Domäne aufzunehmen um die Rechteverwaltung über euer AD machen zu können. In den jeweiligen Domänen brauchen die Tester jedoch weiterhin eigene Accounts. Da die Jungs aber eh DomAdmin Rechte bekommen sollen kann das auch ein generischer account sein...

[DAUjones 10]

Muss ich das verstehen?

Es wäre wahrscheinlich hilfreich für diese Diskussion. ;)

 

Derzeit gibt es nur zwei Domänen, wovon eine für Performancetests relativ isoliert ist. Die andere ist quasi "produktiv" wobei die Produktion der Testbetrieb ist. AD und Exchange auf 2003.

Jetzt wird es an der Zeit das Ganze zu erweitern. Ex07 und Server08 müssen mit in die Gleichung in allen sinnvollen Varianten. Gleichzeitig soll das derzeitige "Jeder darf alles"-System geordnet werden.

Hardwaremässig stehen hier einige Server, Clients und Backup-Appliances, teils mit VMware. Damit muss ich erstmal arbeiten. Neuanschaffungen sind in begrenztem Umfang möglich. Die Anschaffung eines leistungsfähigen Blade-Centers (für virtuelle Testdomänen) war mal im Gespräch, ist aber an den Kosten gescheitert. Vielleicht nächstes Jahr. So ist eine vollständige Virtualisierung der Umgebung nicht machbar, wobei das eh nicht 100%ig realisierbar ist.

 

Kann man so nicht sagen. Dein Problem liegt nicht auf einer technischen, sondern auf einer konzeptuellen Ebene. Dafür ist ein Forum nicht besonders geeignet.

Muss ich das jetzt verstehen?

Ihr habt mir ja schon einigen Input gegeben, der mir aber jetzt noch nicht reicht um das Problem zu lösen. Liegt vielleicht an noch mangelndem Verständnis von dem, was Du/Ihr mir sagen wollte.

 

Ja. Natürlich. Der TS ist Standalone oder meinethalben Mitglied der Produktionsdomäne. Die Testserver sind eigene Forests. Müssen sie ja sowieso, wegen Exchange. Vertrauensbeziehungen zwischen Produktion und Test gibt es nicht.

Das ist solch verwertbarer Input. Danke.

 

Dass ihm der TS-Gateway nur die Icons gibt, die er sehen darf. Und dass er zu den anderen Maschinen ja nicht die Kennwörter kennen muss.

Hier war ein Verständnisproblem.

Ich kann den TS also so konfigurieren, dass ein bestimmter User nur bestimmte Icons (etc.) zur Verfügung und auch sonst keine weitere Macht innerhalb seiner Session hat? Geht das schon mit einem 2003er TS oder brauch ich den 2008 bzw. Zusatzprodukte?

 

Passwörter...wir reden von insgesamt ca. 15 Leuten, die wechselnde Tests durchführen. Es würden also recht schnell einige Leute mehrere Passwörter wissen. Die sollen aber auch wieder nicht alle 3 Tage geändert werden müssen. Ich bin mir jetzt aber nicht sicher, ob das tatsächlich so relevant ist.

 

Wir haben dir schon ein paar Ansatzpunkte geliefert. Mein Favorit wäre, die gesamte Umgebung als VMs aufzubauen, vielleicht auch skriptgesteuert. Zu bestimmten Intervallen (oder wie auch immer) wird die Umgebung auf einen definierten Stand zurückgesetzt. Dabei ändert man dann die Kennwörter und teilt sie nur den Berechtigten mit. Dürfte schon ziemlich weit kommen.

Schonmal ein guter Ansatz. Genau deswegen habe ich ja den Thread eröffnet. Danke schonmal.

–

Da du keine vollständig virtuelle Umgebung haben möchtest...

Das hat recht wenig mit meinen Wünschen zu tun. :)

 

...würde ich meinen Ansatz der virtuellen Netze durch vLans umsetzen. Jede der Teststellungen bekommt also eine eigene VLan ID und der einzige Zugang zu dem Netz geht über den TS (dieser steht in allen VLans). Damit ist sicher gestellt, dass die Entwickler nicht aus den vorgegebenen Umgebungen raus kommen.

Klingt gut.

 

Jup vollständig ausserhalb an einem so genannten Trunk-Port des Switches welches deine Teststellungen verwaltet.

Dieser Trunk-Port ist ein physikalischer Port der in beliebigen vLans gleichzeitig ist?

 

Wie Nils schon gesagt hat könnte man sich überlegen den TS in die Prod Domäne aufzunehmen um die Rechteverwaltung über euer AD machen zu können. In den jeweiligen Domänen brauchen die Tester jedoch weiterhin eigene Accounts. Da die Jungs aber eh DomAdmin Rechte bekommen sollen kann das auch ein generischer account sein...

So klingt das sinnvoll.

[nerd 28]

Hi,

 

jup ein Trunkport ist ein Hardwareport an einem Switch welcher auf alle Vlans kommt. Man kann das aber auch manuel einrichten... Im ESX kannst du dann auch noch hin gehen und virtuelle Netze bauen die mit einer VLan ID ausgestattet werden - damit wäre auch der Übergang virtuel zu phyisch gesichert.

 

Anmerkung zur Sicherheit: VLans sind im allgemeinen keine hoch- sichere Sache um Umgebungen vollständig zu trennen. Es gibt durchaus Ansätze sich über die damit erstellten Sicherheitszonen hinweg zu setzen. Da es sich bei dir jedoch nur um ein Testnetz handelt und schützenswerte sensible Daten dort nicht vorhanden sein sollten dürfte das kein Problem sein...

[NilsK 2.932]

Moin,

 

Muss ich das jetzt verstehen?

Ihr habt mir ja schon einigen Input gegeben, der mir aber jetzt noch nicht reicht um das Problem zu lösen. Liegt vielleicht an noch mangelndem Verständnis von dem, was Du/Ihr mir sagen wollte.

 

was ich versuche dir klarzumachen ist, dass ihr erst mal konzeptuell eine genauere Vorstellung entwickeln müsst, was ihr eigentlich vorhabt. Dies hier ist ein technisches Forum, in dem wir relativ gut technische Detailfragen klären können. Zum Entwickeln von Konzepten taugt ein Forum aber nicht besonders. Zudem ist das eben eure Aufgabe, denn ihr habt ja Anforderungen, die ihr erfüllen müsst.

 

Es ist ein typisches IT-Phänomen, dass man viel zu schnell anfängt, in technischen Details zu denken. So weit seid ihr aber offensichtlich noch nicht.

 

Gruß, Nils