Entwicklerrechner ohne Adminrechte: sicher und trotzdem produktiv

TL;DR: Am 29. Oktober 2026 scheiterte eine manipulierte Claude-Code-Erweiterung auf den meisten Rechnern an einer einzigen Hürde: Für den Zugang von außen hätte sie Administratorrechte gebraucht. Daraus folgt die wichtigste Regel für Entwicklerrechner: im Alltag kein Admin. Noch besser ist Trennung: Ein Rechner, der in keiner Domäne ist, kann keine Domäne übernehmen. Wir zeigen, wie wir selbst arbeiten, und wie sich dasselbe Prinzip in einer klassischen Domäne vor Ort, in Microsoft 365 mit Entra ID und Intune und in der hybriden Mischung umsetzen lässt, ohne dass Entwickler jeden Tag mit Rückfragen kämpfen.

Drei Regeln für Entwicklerrechner

1. Trennung vor Härtung: Wer Adminrechte braucht, bekommt einen Rechner, der nichts Wichtiges erreicht.

2. Kein Admin im Alltag: Erhöhte Rechte nur für den einen Vorgang, nicht für den ganzen Tag.

3. Zweiter Faktor überall, wo es ihn gibt: auch wenn es nervt.

Der Anlass: Ein Angriff scheitert an fehlenden Rechten

Am 29. Oktober 2026 verteilte der Marktplatz des Editors Cursor stundenlang manipulierte Versionen der Claude-Code-Erweiterung. Sie versuchten, einen fremden SSH-Schlüssel einzutragen, den SSH-Dienst einzuschalten und einen Tunnel nach außen aufzubauen. Laut Cursor scheiterte der Zugang von außen auf den meisten Rechnern, weil dafür Administratorrechte nötig waren.

Das ist die gute Nachricht. Die schlechte: Auf Entwicklerrechnern sind Administratorrechte eher die Regel als die Ausnahme. Docker, WSL, Hyper-V, Treiber für Testgeräte, das neue SDK, die Erweiterung, die nur mit erhöhten Rechten installiert: Für fast jedes Werkzeug gibt es einen Grund, warum der Entwickler „mal eben“ Admin sein muss. Und weil das Bitten um Rechte nervt, bleibt es oft beim Dauer-Admin.

Dazu kommt: Ein Entwicklerrechner ist für Angreifer besonders wertvoll. Dort liegen Quellcode, Zugangsdaten zu Git, Paketregistern und Cloud-Konten, oft auch Schlüssel für Server. Und dort laufen immer mehr KI-Werkzeuge und Erweiterungen, also fremder Code mit den Rechten des Benutzers.

Trennung vor Härtung: So arbeiten wir selbst

Bei uns gibt es zwei getrennte Anmeldewelten. Die Büro-Rechner für die tägliche Arbeit, also Mail, Teams und Dokumente, sind in Microsoft Entra ID. Unsere Produktivserver sind in einer eigenen Domäne vor Ort. Die beiden Welten teilen sich keine Konten. Wer ein Büro-Konto übernimmt, hat damit keinen Zugang zu den Servern.

Ich selbst arbeite mit zwei Windows-Rechnern:

• Der Büro-Rechner ist in Entra ID und läuft ohne lokale Adminrechte.
• Der Entwicklungsrechner ist in keiner Domäne. Dort habe ich lokale Adminrechte, weil Entwicklung sie manchmal braucht. Dafür erreicht dieser Rechner die Server nicht direkt, sondern nur über Jump Hosts, per RDP oder SSH, je nach Ziel auch beides.

Docker, WSL und Hyper-V laufen bei uns auf eigenen Systemen, nicht auf dem Alltagsrechner. KI-Agenten arbeiten nur auf Management-Rechnern außerhalb beider Domänen und außerhalb des Servernetzes, physisch getrennt. Auf einem Produktivserver läuft kein Agent. Warum, beschreiben wir in KI-Agenten an der eigenen Infrastruktur: So setzen Sie Grenzen.

flowchart LR
    B["Büro-Rechner<br/>Entra ID, kein Admin"] --> M["Microsoft 365"]
    E["Entwicklungsrechner<br/>keine Domäne, Admin"] --> J["Jump Host<br/>RDP / SSH"] --> S["Produktivserver<br/>eigene Domäne vor Ort"]
    A["Management-Rechner<br/>für Agenten, physisch getrennt"]
    style J stroke:#cc171a,stroke-width:2.5px

Die Logik dahinter: Wo Adminrechte nötig sind, wird isoliert, nicht nur gehärtet. Würde jemand meinen Entwicklungsrechner übernehmen, säße er auf einem Rechner ohne Domäne, ohne direkten Weg zu den Servern und ohne die Zugangsdaten der Büro-Welt. Der Schaden bliebe auf diesen einen Rechner begrenzt. Und den setzen wir dann neu auf, statt ihn zu putzen.

Zwei Grundsätze gehören dazu: Wo ein zweiter Faktor verfügbar ist, nutzen wir ihn, auch wenn es bei jeder Anmeldung nervt. Und unsere Backups liegen auf Bändern, die jeden Montag gewechselt werden. Ein Band, das nicht im Laufwerk steckt, erreicht kein Prozess im Netz. Nur deshalb ist „neu aufsetzen“ eine echte Option.

Diese Trennung ist kein Luxus für große Firmen. Ein zweiter Rechner oder eine eigene VM für die Entwicklung kostet weniger als ein einziger Sicherheitsvorfall. Wo sie nicht möglich ist, und das ist im Mittelstand der Normalfall, kommt die zweite Linie: Härtung.

Kein Admin im Alltag: was das konkret heißt

Die Grundidee ist einfach: Das Konto, mit dem jemand mailt, surft, chattet und programmiert, hat keine Administratorrechte. Erhöhte Rechte gibt es nur für den einen Vorgang, der sie braucht.

Windows bietet dafür inzwischen mehrere Wege:

• Ein getrenntes Admin-Konto: der klassische Weg. Installationen laufen über „Als anderer Benutzer ausführen“ mit einem eigenen Konto, das für nichts anderes verwendet wird. Kein Browser, keine Mail, kein Editor unter diesem Konto.
• Windows LAPS: Jedes Gerät bekommt ein eigenes lokales Admin-Kennwort, das automatisch gewechselt und zentral gesichert wird, entweder im Active Directory oder in Entra ID. Damit gibt es kein gemeinsames Admin-Kennwort mehr, mit dem ein Angreifer von einem Rechner zum nächsten kommt. Windows LAPS ist in Windows enthalten und kostet nichts extra. Das ältere Produkt „Microsoft LAPS“ ist ab Windows 11 23H2 abgekündigt.
• Administratorschutz (Administrator protection): seit August 2026 für Windows 11 24H2 und 25H2 allgemein verfügbar, standardmäßig ausgeschaltet. Auch ein Admin arbeitet damit ohne erhöhte Rechte und bestätigt jede Erhöhung mit Windows Hello, die erhöhte Sitzung läuft in einem getrennten, versteckten Konto. Wichtig für Entwickler: Microsoft rät davon ab, ihn auf Geräten mit LAPS oder mit Bedarf an Hyper-V einzuschalten, und WSL sowie Visual Studio müssen im erhöhten Profil getrennt eingerichtet werden. Das ist ein weiterer Grund, Hyper-V und WSL auf eigene Systeme zu legen.
• sudo für Windows: ab Windows 11 24H2. Ein einzelner Befehl läuft erhöht, ohne dass man eine ganze Admin-Konsole öffnet.
• Endpoint Privilege Management in Intune: Statt das Konto zum Admin zu machen, werden einzelne, freigegebene Programme mit erhöhten Rechten gestartet, automatisch, nach Bestätigung durch den Benutzer oder nach Freigabe durch den Support. Seit dem Lizenz-Update 2026 ist das in Microsoft 365 E5 enthalten, in E3 nicht, dort braucht es eine Zusatzlizenz.

Damit es nicht nervt

Die meisten Dauer-Admins entstehen nicht aus Bequemlichkeit, sondern weil der Alltag ohne Adminrechte zu viele Unterbrechungen hat. Diese lassen sich deutlich reduzieren:

• Werkzeuge im Benutzerkontext installieren. Viele Entwicklerwerkzeuge gibt es als Installation pro Benutzer. Docker Desktop lässt sich zum Beispiel pro Benutzer ohne Adminrechte installieren und aktualisieren.
• Software aus einer eigenen Quelle. Der Paketmanager winget kann eine firmeneigene Quelle nutzen, und per Richtlinie („Enable App Installer Allowed Sources“, ab Windows 11 22H2) lässt sich festlegen, welche Quellen überhaupt erlaubt sind.
• Erweiterungen und Plugins aus dem eigenen Katalog. Für Plugins von Claude Code geht das mit einem eigenen Marketplace als Git-Repository, wie in Claude-Code-Plugins vom eigenen Azure DevOps Server verteilen. Warum das zählt, steht in Agent Plugins und Sicherheit.
• Die Ausnahmen offen benennen und bündeln. WSL lässt sich laut Microsoft weiterhin nur mit Adminrechten installieren, ein Dev Drive ebenfalls. Statt dafür Dauer-Admin zu vergeben, lieber einmal sauber einrichten lassen, oder gleich auf ein eigenes System auslagern.

Kennwörter: lang statt ständig neu

Ein zweiter Faktor ändert auch, wie man mit Kennwörtern umgehen sollte. Der erzwungene Wechsel alle paar Wochen sorgt in der Praxis nicht für sicherere Kennwörter, sondern für vorhersehbare: Wir haben in der Praxis schon Reihen gesehen wie „Snickers“, dann „Sn!ckers“, dann „Snickers2002“: ein Lieblingsriegel, bei jedem Wechsel ein Zeichen anders. Genauso beliebt sind Geburtstage mit wechselnder Endziffer. Microsoft beschreibt genau diesen Effekt: Vorgaben zum Kennwortwechsel führen zu einer Normalisierung der Kennwörter, die sie leichter zu erraten macht. Für Cloud-Konten rät Microsoft deshalb, Kennwörter nicht mehr ablaufen zu lassen. Auch die Sicherheitsbaseline von Microsoft für Windows enthält keinen Kennwortablauf mehr, mit einer wichtigen Bedingung: Wer keinen zweiten Faktor und keinen Schutz gegen leicht zu erratende Kennwörter hat, soll den Ablauf beibehalten.

Unsere Regel daher:

• Zweiter Faktor aktiv, dann ein langes Kennwort ohne Ablauf. Microsoft empfiehlt mindestens 14 Zeichen.
• Wechsel nur mit Anlass: bei Verdacht auf Abfluss, nach einem Vorfall wie am 29. Oktober, nach einer Weitergabe.
• Leicht zu erratende Kennwörter sperren, etwa mit dem Kennwortschutz von Entra ID.
• Den alten Standard prüfen: In der Standard-Domänenrichtlinie einer klassischen Domäne steht ein Ablauf nach 42 Tagen. Wer den zweiten Faktor eingeführt hat, sollte diese Einstellung bewusst überprüfen, statt sie aus Gewohnheit stehen zu lassen.

Je nach Umgebung anders umgesetzt

Das Prinzip ist überall gleich, die Werkzeuge sind es nicht. Die drei typischen Umgebungen im Mittelstand:

Klassische Domäne vor Ort

Active Directory mit Gruppenrichtlinien, wie sie viele Unternehmen seit Jahren betreiben.

• Die lokale Admingruppe zentral festschreiben. Die Gruppenrichtlinie „Eingeschränkte Gruppen“ ersetzt die Mitgliederliste vollständig: Wer nicht auf der Liste steht, fliegt raus, auch wenn er sich selbst eingetragen hat. Für Geräte, die zusätzlich per MDM verwaltet werden, empfiehlt Microsoft ab Windows 10 20H2 die neuere Richtlinie „LocalUsersAndGroups“. Beide gleichzeitig zu verwenden führt zu Konflikten.
• Windows LAPS mit Sicherung im Active Directory.
• Admin-Konten nach Ebenen trennen. Ein Konto, das Domänen-Admin ist, meldet sich nie an einem Arbeitsplatz an. Microsoft beschreibt das heute als Enterprise Access Model, den Nachfolger des früheren Stufenmodells. Für privilegierte Konten gibt es die Gruppe „Protected Users“, die unter anderem verhindert, dass Anmeldedaten zwischengespeichert werden.
• Software über eine eigene Quelle, freigegeben per Gruppenrichtlinie.

Microsoft 365 mit Entra ID und Intune

Immer mehr Unternehmen verwalten ihre Rechner ganz aus der Cloud, ohne Domäne vor Ort. Hier lauert eine Falle, die viele nicht kennen:

• Wer ein Gerät mit Entra ID verbindet, ist dort standardmäßig lokaler Admin. So steht es in der Microsoft-Dokumentation. Abhilfe schafft die Geräteeinstellung in Entra ID, die den registrierenden Benutzer beim Join zum lokalen Admin macht („Registering user is added as local administrator on the device during Microsoft Entra join“): ausschalten. Bei Windows Autopilot gehört die Profileinstellung „User account type“ auf „Standard“.
• Die lokale Admingruppe per Intune festlegen. Unter Endpunktsicherheit gibt es dafür ein Profil zur Mitgliedschaft in lokalen Gruppen, das Mitglieder hinzufügen, entfernen oder die Liste ersetzen kann.
• Windows LAPS mit Sicherung in Entra ID.
• Endpoint Privilege Management für die Programme, die wirklich erhöhte Rechte brauchen.

Wie so eine Umstellung in der Praxis aussieht, zeigt unser Praxisfall vom defekten Rechner zu Microsoft 365 mit Intune.

Hybrid: Domäne vor Ort plus Microsoft 365 und Intune

Der häufigste Fall im Mittelstand: Die Domäne vor Ort gibt es noch, dazu kommen Microsoft 365, Entra ID und Intune. Hier ist die wichtigste Frage: Wer gewinnt?

• Eine Quelle pro Einstellung. Legen Gruppenrichtlinie und Intune dieselbe Einstellung fest, kann es Widersprüche geben, etwa bei der Admingruppe. Mit der Einstellung „MDMWinsOverGP“ blockiert Windows Gruppenrichtlinien, für die es eine gleichwertige Intune-Richtlinie gibt. Wichtig ist aber vor allem, bewusst zu entscheiden, welche Einstellung woher kommt.
• LAPS sichert entweder ins Active Directory oder nach Entra ID, nie in beides. Für hybrid eingebundene Geräte muss man sich entscheiden.
• Admin-Konten nicht synchronisieren. Konten mit Adminrechten in der Domäne gehören nicht in die Cloud und haben kein Postfach.

Was wir bewusst nicht machen

• Entwickler als Domänen-Admins. Nie, auch nicht „nur kurz für das Projekt“.
• Server-Administration aus derselben Sitzung wie Mail, Chat oder KI-Agent. Wer im selben Fenster eine Mail öffnet und einen Server verwaltet, hat keine Trennung.
• Zugangsdaten für Produktivserver auf dem Rechner, auf dem Erweiterungen und Agenten laufen. Was ein Werkzeug nicht erreicht, kann es nicht verlieren.
• Lokaler Admin plus Hoffnung auf den Virenscanner. Die manipulierte Erweiterung vom 29. Oktober kam aus einem offiziellen Marktplatz, unter dem richtigen Namen. Was den Zugang von außen auf den meisten Rechnern verhindert hat, waren laut Cursor die fehlenden Rechte.

Häufige Fragen

Müssen Entwickler die Domäne verlassen? Nein. Für die meisten Entwickler reicht ein Konto ohne Adminrechte, LAPS und eine Lösung für die wenigen Programme, die erhöhte Rechte brauchen. Die Trennung in eigene Rechner oder VMs ist die stärkere Variante, vor allem für Experimente mit Agenten und für Werkzeuge, die dauerhaft Adminrechte brauchen.

Reicht es, wenn niemand Domänen-Admin ist? Das ist die wichtigste Grundlage, aber nicht genug. Mit lokalen Adminrechten kann Schadcode sich auf dem Rechner einnisten, Dienste einschalten und Anmeldedaten auslesen, auch ohne Domänen-Admin zu sein.

Brauche ich für Docker Adminrechte? Für Docker Desktop nicht zwingend: Die Installation pro Benutzer kommt ohne aus. Für WSL und Hyper-V schon. Wir haben diese Werkzeuge deshalb auf eigene Systeme gelegt.

Lohnt sich ein eigener Rechner oder eine VM nur für KI-Agenten? Ja. KI-Agenten führen Befehle aus, installieren Pakete und lesen Dateien. Was sie nicht erreichen, können sie weder beschädigen noch verlieren. Mehr dazu in Warum KI-Agenten im Unternehmen echte Sandboxes brauchen.

Fazit

Die manipulierte Erweiterung vom 29. Oktober ist nicht an einer besonders klugen Abwehr gescheitert, sondern an fehlenden Administratorrechten. Das ist die günstigste Sicherheitsmaßnahme, die es gibt, und gleichzeitig die, die im Entwickleralltag am schnellsten aufgeweicht wird.

Wer die Wahl hat, trennt: Ein Rechner mit Adminrechten bekommt keinen Zugang zu Domäne und Servern. Wer nicht trennen kann, härtet: kein Admin im Alltag, LAPS, ein zweiter Faktor und erhöhte Rechte nur für den einen Vorgang. Mit den heutigen Werkzeugen in Windows und Intune ist das für Entwickler kein Dauerärgernis mehr.

Wie wir mit KI-Werkzeugen und Agenten insgesamt umgehen, beschreiben wir in So arbeiten wir mit KI. Sie möchten Ihre Entwicklerrechner so einrichten, dass sie produktiv bleiben und trotzdem kein Sprungbrett sind? Mehr zu unserer IT-Sicherheit, oder sprechen Sie uns direkt an.

Quellen: Microsoft Learn – Manage the local administrators on Microsoft Entra joined devices · Microsoft Learn – Windows Autopilot profiles · Microsoft Learn – Intune Account protection · Microsoft Learn – Windows LAPS overview · Microsoft Learn – Endpoint Privilege Management · Microsoft – 2026 Microsoft 365 packaging and pricing updates · Microsoft Learn – Administrator protection · Microsoft Learn – Sudo for Windows · Microsoft Learn – ControlPolicyConflict (MDMWinsOverGP) · Microsoft Learn – Enterprise access model · Microsoft Learn – Protected Users · Microsoft Learn – RestrictedGroups · Microsoft Learn – Password policy recommendations · Microsoft Learn – Maximum password age · Docker Docs – Install Docker Desktop on Windows · Microsoft Learn – Install WSL · Microsoft Learn – DesktopAppInstaller Policy CSP · Microsoft Learn – Dev Drive