Eine gehostete Windows-Domäne

Das codingfreaks-Team stand vor einer heftigen Aufgabe: Eine echte Windows-2008-R2-Domäne soll entstehen, aber wir wollen keinen Server dafür einkaufen, sondern ein gehostetes Angebot nutzen. Trotzdem wollen wir die gleiche Nutzer-Erfahrung erreichen, als stünden die Server in unserem lokalen Netz. Seht selbst, was passierte.

Das Ziel

codingfreaks wächst und wächst. In Wahrheit wachsen wir zusammen mit unserem Partner SAB und so stellte sich in letzter Zeit immer wieder der Wunsch ein, eine gemeinsame Infrastruktur aufzubauen. Es gibt alles, was es in anderen Firmen auch gibt: Verrieb, Consulting, Programmierung, Office usw. Auf der Systemseite brauchen wir so einiges: Visual Studio, SQL Server, Exchange, Hyper-V usw.

Das Ziel soll also sein, dass wir eine zentrale IT-Architektur aufbauen, die uns ein zentralisiertes Management der User, Apps, Ressourcen usw. ermöglicht. Aus Sicht eines Clients soll es sich so anfühlen, als ob der User in einem Intranet auf einer Infrastruktur arbeitet.

Die Probleme

Dass man für so etwas heutzutage eine AD aufsetzen wollte, wenn man im Windows-Umfeld tätig ist, war uns schon klar, das Problem war aber, dass codingfreaks und SAB komplett über das Land verteilt arbeiten und keiner der Standorte der richtige für den Aufbau von Servern ist.

Sofort kam natürlich das Thema Cloud aus der Versenkung. Wäre auch komisch gewesen, wenn nicht. Aber, genauso schnell, wie es kam, verschwand es auch wieder. Dazu muss ich ein wenig ausholen.

Was braucht man für eine Domäne? Zunächst einmal einen Domänen-Controller, der Windows Server ausführt und mit der AD-Rolle ausgestattet ist. Dafür braucht man schon mal eine Maschine. Einen Domänen-Controller zum Selbstzweck macht keinen Sinn, weil mehr als daran anmelden und Dateien ablegen wäre nicht und das können kostenlose Cloud-Dienste wirklich besser.

Ok. Das nächste, was auf die Agenda kam, war natürlich Outlook und damit Exchange. Ich werde jetzt hier nicht erläutern, dass eine Installation auf der gleichen Maschine, wie der des AD-Controllers nicht in Frage kam und wir daher – schwups – das zweite Blech geplant hatten. So ging das weiter, bis folgende Anforderung stand (jeder Anstrich eine Maschine):

  • Domänen-Controller
  • Exchange/Sharepoint
  • SQL Server 2008/TFS 2010
  • SQL Server 2012/TFS 2012 /Hyper-V

Aus Kostengründen haben wir die die meisten Maschinen mit jeweils 2 Aufgaben belegt. Damit die Dinger dann aber nicht verdursten, sollte es schon ein wenig mehr an Ausstattung sein, als die White Paper vorgeben. Wir endeten mit folgender Konfiguration für alle Systeme:

  • Core-i7-Prozessor oder vergleichbarer Xeon
  • 32 GB RAM
  • 2 x 1 TB HDD
  • Internes 1GBit-Netz

Server-Gurus werden spätestens jetzt aussteigen und die Augen verdrehen. Wir sind aber um die 50 Leute und daher ist die Ausstattung völlig in Ordnung zumal wir sie ja nicht physisch selbst betreiben wollen.

Azure: Das Hosting für Superreiche?

Mit dieser Liste bewaffnet machten wir uns natürlich erstmal auf zu Microsoft, die mit den neuen Clouding-Angeboten in Azure einiges zu bieten haben. Das Azure-Portal bietet einen Preisrechner, den man wunderbar verwendet kann, um seine Kosten grob zu schätzen. Zunächst einmal folgte eine kleine Enttäuschung. Das Maximum an Leistung für eine einzelne Maschine in der Cloud ist das Paket Server XL mit 8 x 1,6 GHz CPU, 14 GB RAM, 2.040 GB Speicher. Das relativierte sich jedoch wieder, weil wir eigentlich SQL-Server, TFS, AD usw. komplett durch MS hosten lassen könnten. Weil wir aber vergleichbar bleiben wollen, haben wir wirklich mal mit 4 XL-Systemen gerechnet.

Ich denke, jeder kann das mal selbst für sich durchrechnen. Wir landen jedenfalls bei ca. 1.500 €/Monat und haben nicht die Leistung, die auf unserer Liste steht.  Das kam nicht in die Tüte.

Ein Blick in die Hoster-Ecke beruhigte uns dann schnell wieder und wir fanden unser Angebot letztlich bei Hetzner Root Server EX 4S war genau, was wir gesucht haben und kosten 59 €/ Monat, also in Summe 236 €/ Monat. Das ist schon eher, wonach wir suchten. Nach ein paar Telefonaten war klar, dass die Hetzner-Jungs auch noch super flexibel sind: Sie stellten uns einfach alle 4 Systeme in ein Rack und haben die Dinger per GBit-Switch miteinander verbunden, sodass unsere Server eine kleine Enklave im Hetzner-RZ bilden. Das kostet ein paar Euro extra, ist aber kaum der Rede wert.

Im Hetzner-Paket enthalten war je eine feste öffentliche IP-Adresse pro Server. Wichtig!

Vorsicht: Man kann jetzt natürlich nicht Azure mit Hetzner vergleichen! Azure bedient eine ganz andere Zielgruppe und andere Einsatzszenarien. Ich habe das hier nur erwähnt, weil wir ein wenig naiv AD, SQL Server usw. nutzen wollten und ein wenig verwundert über die hohen Kosten waren. Themen, wie Redundanz, Sicherheit usw. müssen wir bei Hetzner noch dazu kaufen.

Aber egal mal wie, der Hoster war gefunden. Also hoch mit der Domäne!

Die Domäne entsteht

So ungefähr eine Woche lang haben wir nun unsere Server eingerichtet. Begonnen haben wir natürlich mit dem DC und dann gings weiter mit SQL Server, Sharepoint, TFS, SQL Server 2012 (in der Reihenfolge). Die ganze Zeit über waren wir dabei per RDP auf den Maschinen unterwegs. Natürlich hinterließ das kein gutes Gefühl, weil die Dinger da offen im Netz standen. Also ran an das Thema VPN.

VPN her

Jetzt ging das Theater los! Zunächst einmal die Frage: Wie richtet man einen VPN-Server unter Windows ein? Antwort: Der entsprechende Server, der das anbieten soll, muss die Rolle „Routing und RAS“ einnehmen. Hier wurde schnell klar, dass wir etwas nicht bedacht hatten: Wir brauchten natürlich einen Gateway-Server. Zuerst gab es Ansätze, den DC damit zu betrauen, aber schnell wurden empörte Rufe laut, dass das nicht geht, weil der DC ja gerade einer der schützenswerten Rechner ist.

Also Anruf bei Hetzner und eine kleine Maschine Dual Core, 2 GB RAM und wenig Festplatte gehlt. Auch dort haben wir einen Windows Server aufgesetzt und ihm die Rolle (s.o.) verpasst. Hier der Baum des Server-Managers mit der aufgeklappten RAS-Rolle:

Abb. 1: Routing und RAS im Server Manager

und hier der Eigenschaften-Dialog:

Abb. 2: Routing und RAS Eigenschaften

Sobald das konfiguriert wird, sollte man dem Gateway-System auch noch die DHCP-Rolle geben, damit bei Einwahl eines Clients in die Domäne eine entsprechende IP-Adresse aus dem internen Netz vergeben wird. Interessant an Abb. 2 ist vor allem der „Vorinstallierte Schlüssel“. Das ist ein Notnagel, den wir verwendet haben, weil die zertifikats-basierte Authentifizierung bei uns einfach nicht klappen wollte (ja, wir hatten einen intenern Zertifikats-Server). Das hinterließ gleich mal ein flaues Gefühl im Magen, funktionierte aber.

Die Verbindung konnte nun per Windows-VPN aufgebaut werden, aber das Problem ist ja, dass man das erst machen kann, nachdem man sich am System angemeldet hat. Wir wollten aber „richtig“ in die Domäne einsteigen und dazu muss die VPN bereits beim Anmelden am Rechner vorhanden sein.

Alles neu

Sowas riecht immer nach Hardware. Und so war es auch bei uns. Die Geschichte war aber etwas hakelig. Zunächst befragten wir einige Admins in unserem Umkreis. Die einhellige Meinung war, dass man dedizierte Profi-Hardware in Regionen um 600 € und mehr benöätigt, um sowas auzubauen. Dazu ein kleines Schaubild:

Abb. 3: Das soll erreicht werden

Abb. 3 zeigt quasi unseren naiven Wunsch. Wir haben links (also irgendwo auf der Welt) ein privates Subnetz mit PCs, Druckern usw. Eine Fritzbox sorgt für den Zugriff auf das Internet. Am liebsten hätten wir nun die Möglichkeit, der Fritzbox beizubringen, dass sie einen VPN-Tunnel (rote Linie) zu unserem Einwahl-Server aufbauen soll. Das aber kann die Fritzbox nicht.

Also ein anderes Gerät her, aber bitte nicht für 600 €, denn wir haben mehrere Standorte, die alle auf die eine Domäne müssen. Pro Standort wären dann ja 600 € fällig. Auf keinen Fall!

Die Lösung

Die Suche begann und dauerte eine Weile. Das Problem bei solchen Recherchen ist, dass man eigentlich nie genau weiß, ob ein Gerät die gestellten Anforderungen umsetzen kann, weil die Beschreibungen allesamt Schrott sind. Wir fanden schließlich das pfSense Komplettsystem im Varia-Store. Kostenpunkt 171 €. Für optionale 26,19 € bekommt man sogar ein englischsprachiges Handbuch dazu (das sehr hilfreich war).

pfSense selbst ist ein OpenSource-Projekt. Die Jungs haben im Prinzip ein angepasstes Linux erstellt, das einige Hersteller auf geeignete Hardware bringen. Zum Projekt gehört auch eine Web-basierte Konfiguration sowie ein Menu, mit dem man per serieller Schnittstelle eine pfSense administrieren kann.

Eine Detailbeschreibung der Einstellungen wird dasgunn vielleicht noch nachliefern. Ich konzentriere mich hier auf die Änderungen an unserer Installation.

Anpassungen an Servern

Schnell stellte sich heraus, dass die pfSense nicht viel von den Windows-VPN-Mitteln hält bzw. diese nicht versteht. Die gängigste Lösung hier ist OpenVPN. Also haben wir alle Windows-VPN-Einstellungen rausgeworfen und dann OpenVPN auf dem Einwahlserver installiert. Hier muss man nun diverse Zertifikate erstellen und herunterladen, damit man diese dann später in die pfSense importieren kann. Das löst auch gleich das hässliche Problem mit dem vorinstallierten Schlüssel unter Windows.

Auf der lokalen Seite wurde es etwas kniffliger. Zunächst das Schaubild:

Abb. 4: pfSense im LAN

In Abb. 4 erkennt man, dass es nun im 2 Subnetze im internen LAN gibt. Das ist Bedingung für den Einsatz der pfSense. Diese stellt 2 Ports zur Verfügung (LAN und WAN). An den LAN-Port schließt man seinen internen Switch an. An den WAN-Port kommt die Fritzbox. Beide Ports dürfen nicht im selben Subnetz liegen. Das hat Folgen!

Da vorher meine Fritzbox der DHCP-Server war, darf sie das nun nicht mehr sein. Diese Aufgabe muss die pfSense übernehmen. Die Fritzbox hat ein eigenes Subnetz, in dem sie auch wieder DHCP sein darf. Die Folge ist nun aber, dass die Geräte, die per WLAN ins Netz gehen (iPhone, Notebook usw.) die anderen nicht mehr „sehen“. Das kann man ändern, aber dazu wird dasgunn noch weitere Details bringen.

Sieht man mal von den Subnetzproblemen ab, funktioniert nun alles, wie erwartet. Greift man auf IP-Adressen des Domänen-Netzwerks zu (egal, ob per IP oder per DNS-Namen), erkennt die pfSense dies und baut transparent einen VPN-Tunnel über OpenVPN auf.

Resumé

Dieser Beitrag hat lediglich an der Oberfläche der Probleme gekrazt. Wir haben insgesamt über 6 Wochen an dem Problem gebrütet. Gleich ein Tipp: Vergesst die ganzen Seiten, wei administrator.de usw. Erstens ist deren Stand grotten-alt und zweitens gehen sie fast immer davon aus, dass man schön gemütlich zum Serverraum spazieren kann, um Probleme zu lösen.

Die pfSense funktioniert einwandfrei. Wir haben mittlerweile 5 von den Dingern nachgeordert. Das WLAN-Problem kann man umgehen, wenn man ein wenig an der Firtbox rumfummelt oder man sich einfach eine WLAN-fähige pfSense-Version holt. Der nächste Schritt ist jetzt, die gesamte Infrastruktur bei Hetzner zu sichern (Backups und Spiegelung) und dann gehts los.

3 Antworten auf „Eine gehostete Windows-Domäne“

  1. Hallo Alexander,
    ich stehe gerade vor einer ähnlichen Überlegung.
    4 Filialen in 3 Städten miteinander in einer Domäne zu verknüpfen.
    Hetzner ist der 1.DC und in den einzelnen Häusern stehen dann wieder separate DCs rum.
    Soweit war Deine Anleitung erstmal klar.
    VPN … warum hast Du es denn nicht einfacher gemacht.
    Lass doch den Hetzner Server die VPN Verbindung zu den einzelnen Filialen aufbauen.
    ShrewSoft bietet diese Möglichkeit und spielt auch mit der FritzBox hervorragend zusammen.
    ShrewSoft kann auch per Batch-Script gestartet werden, also einfach nach dem Start des Hetzner-Servers das Script ausführen und fertig.

    Nur mal so als Idee …

    1. Hi Martin, die Idee ist nicht schlecht. Wir werden sie aber wohl doch nicht umsetzen, weil wir nun doch in Richtung Azure AD denken. Das liegt vor allem daran, dass es Hetzner nicht schafft, uns vernünftigen Hardware-Support zu bieten. Nach all den Jahren fliegen uns nun regelmäßig die Platten um die Ohren und wir sind ca. alle 2 Monate mit Restores beschäftigt. Wir werden das ganze Ding migrieren und auch darüber hier berichten. Trotzdem danke für den Tipp.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden .