In vielen Unternehmen arbeiten Administratoren und Analysten mit getrennten Benutzerkonten:
- Ein „normaler“ User für tägliche Arbeit
- Ein „Admin-Konto“ für SQL- oder Serverzugriffe
Doch SSMS meldet sich standardmäßig mit deinem aktuellen Windows-Konto an – auch wenn du eigentlich mit einem anderen Domain-User arbeiten möchtest.
Genau hier kommt der Befehl runas /netonly ins Spiel.
Damit kannst du:
- SSMS lokal unter deinem normalen Benutzer starten
- dich aber gegenüber dem SQL Server mit einem anderen Domain-Account authentifizieren
- ohne wirklich den Benutzer zu wechseln
- ohne Ausloggen
- ohne RDP
- ohne Kennwörter zu speichern
Was genau macht /netonly?
/netonly bedeutet:
- Das Programm läuft lokal mit deinem aktuellen Benutzer
- Netzwerkverbindungen zu Servern erfolgen jedoch mit dem angegebenen Benutzerkonto
Perfekt für:
- externe Netzwerke
- Domänen, auf denen du lokal nicht angemeldet bist
- Privates Notebook → SQL Server in Firmendomäne
- Entwickler, die mit mehreren Test-/Admin-Accounts arbeiten
SSMS mit runas /netonly starten – Schritt für Schritt
1. Eingabeaufforderung als Benutzer öffnen
Es reicht eine normale CMD oder PowerShell – kein Administrator nötig.
2. Den runas-Befehl ausführen
Beispiel:
runas /netonly /user:DOMAIN\username "C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe"
oder kürzer, wenn ssms im PATH liegt:
runas /netonly /user:DOMAIN\username ssms.exe
Windows fragt dann nach dem Passwort für diesen Domain-User.
3. SSMS öffnet sich – aber mit deinem lokalen Benutzer
In SSMS erscheint weiterhin dein lokales Windows-Konto.
Doch sobald du dich an einen SQL Server anmeldest, verwendet SSMS den Domain-User aus dem runas-Befehl.
Wie erkenne ich, dass es funktioniert hat?
- Verbinde dich im SSMS mit Windows Auth.
- Öffne eine neue Abfrage:
SELECT SYSTEM_USER;
Wenn hier DOMAIN\username steht → alles korrekt.
Wenn hier dein lokaler Benutzer steht → runas wurde nicht angewendet.
Typische Anwendungsfälle
✔ Zugriff auf SQL Server in anderer Domäne
z. B. du bist in DOMAIN_A, SQL Server aber in DOMAIN_B.
✔ Arbeiten mit Admin-Konten
Dein Admin-Konto hat SQL-Serverrechte, dein normaler User nicht.
✔ Zugriff aus nicht-domänengebundenen Geräten
Privates Notebook → SQL Server in Firmendomäne: /netonly ist der Standardweg.
Häufige Fehler und Lösungen
❌ Fehler: SSMS verbindet sich weiterhin mit dem lokalen User
→ SSMS wurde ohne vollständigen Pfad gestartet.
Lösung: Vollständigen Pfad angeben:
runas /netonly /user:DOMAIN\username "C:\Program Files (x86)\Microsoft SQL Server Management Studio 19\Common7\IDE\Ssms.exe"
❌ Netzwerkname konnte nicht gefunden werden
→ Firewall, DNS oder Portproblem → teste vorher mit Telnet:
telnet sqlserver01 1433
❌ SSPI-Fehler („Cannot generate SSPI context“)
→ SPN fehlen oder Kerberos-Problem.
Workaround: Fallback auf NTLM erzwingen durch IP-Adresse statt Hostnamen:
Servername: 192.168.0.10
Sicherheitshinweis
runas /netonly speichert kein Passwort – du musst es jedes Mal erneut eingeben.
Das ist sicherer als Credential Manager oder gespeicherte SSMS-Logins.
Interne Links – Weitere relevante Beiträge
- Verbindungstest mit Telnet am SQL Server
- SQL Server Error 53 beheben
- Excel: Runden vs Kürzen – hilfreiche Praxisbeispiele
YouTube-Tipp
Weitere technische Schritt-für-Schritt-Anleitungen findest du auf meinem Kanal:
👉 https://www.youtube.com/@datenanalyst