Ein eigener Forest für zwei Proxys?
Ein Partner fragte uns, ob man für den Backup-Server eines Kunden eine zweite Domäne aufbauen sollte. Eigener Forest, eigene Domänencontroller, Vertrauensstellung zur Produktion. Sauber, wie es im Leitfaden steht.
Die Umgebung: ein Backup-Server, zwei Proxys. Unsere Antwort war kurz. Bei dieser Größe ist es am einfachsten, den Backup-Server gar nicht erst in eine Domäne zu nehmen.
Das ist der zweite Teil unserer Reihe zum Backup-Server und der Domäne. Im ersten ging es darum, warum er nicht in die Produktivdomäne gehört. Hier geht es um die Frage danach: wohin dann?
Drei Wege, nach Sicherheit geordnet
Veeam nennt im Sicherheitsleitfaden drei Möglichkeiten, vom sichersten zum unsichersten Weg:
- Management-Domäne in einem eigenen Forest, die Admin-Konten mit zweitem Faktor.
- Eigene Arbeitsgruppe, die Veeam-Komponenten nach Möglichkeit in einem eigenen Netz.
- Produktivdomäne, aber die Admin-Konten mit zweitem Faktor.
Wer nur die Reihenfolge liest, landet beim ersten Weg. Wer weiterliest, findet bei Veeam auch die Einordnung nach Größe. Zur Arbeitsgruppe: „A Workgroup setup is a good solution for small environments.“ Zur Management-Domäne: eine gute Lösung „for large(r) environments“. Die offizielle Dokumentation sagt es genauso, die Arbeitsgruppe ist dort der Weg für kleine und mittlere Umgebungen.
Und im Abschnitt „Best Practice“ steht die Arbeitsgruppe sogar mit drin: „a management workgroup or a management domain“.
Was der Management-Forest bringt und was er kostet
Der eigene Forest hat echte Vorteile. Veeam zählt sie auf: zentrale Konten und Gruppenrichtlinien, ein Konto mit einem Klick sperren, Kerberos zwischen den Komponenten, MFA auf Domänenebene. Die Vertrauensstellung läuft nur in eine Richtung: Die Produktion vertraut der Management-Domäne, umgekehrt nicht. Wer in der Produktion sitzt, kommt damit nicht in die Verwaltung.
Die Nachteile stehen bei Veeam gleich daneben: zusätzliche Infrastruktur und mehr Wissen, um sie richtig aufzubauen. Im Alltag heißt das:
- Mindestens zwei weitere Domänencontroller, die gepatcht, überwacht und gesichert werden. Und zwar nicht vom Backup-Server, den sie schützen sollen.
- Jemand, der Forests und Trusts versteht. Ein falsch gesetzter Trust in die andere Richtung macht die ganze Trennung wertlos, ohne dass es auffällt.
- Eigene Admin-Arbeitsplätze, sonst meldet man sich vom selben Rechner an der Management-Domäne an, auf dem man auch Mails liest.
Für ein Unternehmen mit eigenem AD-Team und gestuftem Admin-Modell ist das machbar und richtig. Für ein KMU mit 20 Servern ist es eine zweite Baustelle neben der ersten. Wer die Produktivdomäne schon nicht sauber gepflegt bekommt, bekommt eine zweite nicht besser hin.
Microsoft ist vom Admin-Forest selbst abgerückt
Die Idee eines gehärteten Admin-Forests stammt von Microsoft. Unter dem Namen ESAE, oft „Red Forest“ genannt, war das jahrelang die Empfehlung, um Domänen-Admins zu schützen.
Heute führt Microsoft ESAE als Altlast. Das Modell gilt nur noch als Sonderkonfiguration, „suitable only for exception cases“. Die Begründung: hohe technische Komplexität und Betriebskosten. Wer es schon betreibt, muss es nicht abreißen. Neu aufbauen soll man es aber in den meisten Fällen nicht mehr.
Das ist nicht eins zu eins dasselbe: ESAE sollte alle AD-Admins schützen, die Management-Domäne für Veeam schützt nur das Backup. Der Grund für den Rückzug trifft aber beide. Ein zusätzlicher Forest ist dauerhafter Betrieb, kein einmaliges Projekt.
Was Microsoft ausdrücklich behält: eigene Admin-Arbeitsplätze, MFA für Admin-Konten und wenige Admins mit wenig Rechten. Das passt alles auch zur Arbeitsgruppe.
Die Arbeitsgruppe: die Nachteile ehrlich
Veeam verschweigt die Schwächen der Arbeitsgruppe nicht, und wir tun es auch nicht:
- Nur NTLM, kein Kerberos bei der Anmeldung am Server.
- Kein gMSA für die Anmeldung in den gesicherten Systemen.
- Keine zentrale Sperre. Geht ein Admin im Streit, muss sein lokales Konto auf jedem Veeam-Server einzeln weg.
- Compliance ist schwerer nachzuweisen, weil es keine Gruppenrichtlinien gibt.
In einer Umgebung mit einem Backup-Server und ein paar Proxys wiegt das wenig. Drei Admins, drei persönliche Konten, MFA an der Konsole, ein Notfallkonto mit langem Passwort im Tresor. Das bleibt überschaubar. Was im Betrieb sonst noch anders ist, vom Zeitdienst bis zur Firewall, ist Thema im nächsten Teil .
Domäne mit MFA: der letzte Weg
Der dritte Weg steht bei Veeam in der Liste, aber an letzter Stelle. MFA schützt die Anmeldung an der Veeam-Konsole. Wer Domänen-Admin ist, ist aber auch Administrator auf dem Windows-Server darunter. Er kann Dienste stoppen, Dateien löschen und an die Datenbank, ohne die Konsole je zu öffnen. Dort hilft die MFA nicht.
Diesen Weg gehen wir nur, wenn der Kunde trotz Rat darauf besteht. Warum das trotzdem vorkommt, steht bei den Einwänden, die immer kommen . Dann wird er dokumentiert, mit MFA umgesetzt und das Speicherziel unveränderbar gemacht. Eine Empfehlung ist er nicht.
Unsere Faustregel
| Umgebung | Weg |
|---|---|
| Kein eigenes AD-Team, ein Backup-Server, wenige Proxys | Arbeitsgruppe im eigenen Netz |
| Eigenes AD-Team, gestuftes Admin-Modell, eigene Admin-Arbeitsplätze | Management-Domäne im eigenen Forest |
| Kunde besteht auf der Produktivdomäne | MFA, unveränderbares Speicherziel, Risiko schriftlich |
Die Frage ist nicht, welcher Weg auf dem Papier am sichersten ist. Die Frage ist, welchen ihr in drei Jahren noch sauber betreibt.
Quellen
- Veeam Security Best Practices, „Workgroup or Domain?“, Abschnitte Workgroup or Domain , Best Practice , Windows Workgroup , Management Domain und What type of trust?
- Veeam Help Center, Securing Backup Infrastructure (Stand 05.06.2026)
- Microsoft Learn, Enhanced Security Admin Environment
- Microsoft Learn, Enterprise access model (Stand 07.05.2026)