Das Tool von Helge Klein stellt der Autor mittlerweile nicht mehr bereit. Während Klassiker wie SetACL weiterhin präsent sind, wurde das kleine Werkzeug SID2UserName (eine grafische Oberfläche für die Win32-API-Funktion "LookupAccountSid") von seiner Website entfernt. 

Das Tool, einst entwickelt für Windows Server 2003/2008 ist mit moderneren Server-Version aber auch nicht mehr notwendig. Microsoft hat die Auflösung von Sicherheitsbezeichnern (SIDs, Security Identifiers) in lesbare Kontonamen längst vollständig in die Bordmittel integriert – vor allem via PowerShell und über die Windows-Management-Instrumentierung (WMI). Dafür sind keine externen Binärdateien mehr erforderlich.

Native SID-Auflösung

Je nachdem, der Admin lokal, im Active Directory oder auf Dateiebene arbeitet, stehen folgende native Wege zur Verfügung:

• Der .NET-Übersetzer: Über die .NET-Klasse "SecurityIdentifier" lässt sich jede SID direkt im Terminal übersetzen. Das funktioniert sowohl für lokale Konten als auch für Domänen-SIDs, solange der Rechner die SID auflösen kann.
• Über das Active-Directory-Modul: In einer AD-Umgebung bringen die Standard-Cmdlets die Übersetzung nativ mit.
• Wenn es um lokale Instanzen auf einem Server oder Client geht, kommt das CIM-Modell (Common Information Model) zur Namensauflösung zum Einsatz. Dies klappt in der PowerShell mit dem Get-CimInstace-Cmdlet. 

Das Tool füllte früher eine echte Lücke, wenn Admins mal eben eine verwaiste SID in den NTFS-Berechtigungen auflösen mussten. Heute ist der Griff zu Drittanbieter-Tools für diese Aufgabe aus Sicherheits- und Governance-Sichten unnötig geworden – die PowerShell erledigt das sauber und skriptbar.

Die Umwandlung einer Security Identifier (SID) in einen lesbaren Kontonamen gehört zu den Standardaufgaben in der Windows-Administration – etwa beim Auswerten von Ereignisprotokollen, NTFS-Berechtigungen oder Registry-Einträgen, in denen Konten oft nur als SID auftauchen. Klassische Drittanbieter-Tools sind dafür nicht mehr nötig: Windows bringt alle notwendigen Bordmittel mit. Allerdings hat sich die empfohlene Vorgehensweise zuletzt verschoben.

WMIC fällt weg

Der Befehl

wmic useraccount where sid="S-1-5-21-..." get Name

war lange die naheliegende Lösung direkt aus der Eingabeaufforderung heraus. Microsoft hat WMIC jedoch bereits 2016 als veraltet eingestuft und die Ablösung seither konsequent vorangetrieben: Seit Windows 10 21H2 gilt das Tool offiziell als deprecated, in Windows 11 23H2 und 24H2 ist es standardmäßig deaktiviert und muss bei Bedarf manuell als Feature on Demand nachinstalliert werden.

Wer auf Windows 11, Version 25H2, aktualisiert, verliert ein bereits installiertes WMIC ersatzlos – ein Nachrüsten ist auf diesem Stand nicht mehr möglich. Mit dem für 2026 angekündigten Windows-11-Feature-Update soll WMIC schließlich komplett aus dem Betriebssystem verschwinden.

Für Skripte und Dokumentationen, die auch in Zukunft funktionieren sollen, führt an PowerShell daher kein Weg vorbei.

PowerShell-Standardmethode

Der zuverlässigste Weg zur SID-Auflösung – lokal wie in der Domäne – nutzt die .NET-Klasse SecurityIdentifier:

$sid = New-Object System.Security.Principal.SecurityIdentifier("S-1-5-21-...") $sid.Translate([System.Security.Principal.NTAccount]).Value

Der Befehl funktioniert ohne zusätzliche Module und liefert den Kontonamen im Format DOMÄNE\Benutzername beziehungsweise COMPUTERNAME\Benutzername zurück.

WMIC-Ersatz per Get-CimInstance

Wer eine WMIC-ähnliche Abfrage bevorzugt, findet in Get-CimInstance den von Microsoft empfohlenen Nachfolger:

Get-CimInstance -ClassName Win32_UserAccount -Filter "SID='S-1-5-21-...'" | Select-Object Name, Domain

Dieser Befehl lässt sich bei Bedarf auch direkt aus der Eingabeaufforderung heraus starten:

powershell -NoProfile -Command "Get-CimInstance -ClassName Win32_UserAccount -Filter \"SID='S-1-5-21-...'\" | Select-Object Name, Domain"

Damit bleibt die Funktionalität einer klassischen CMD-Abfrage erhalten, ohne von WMIC abhängig zu sein.

Active-Directory-Konten und gelöschte Objekte

In Domänenumgebungen mit installiertem ActiveDirectory-Modul lässt sich die Auflösung auch über Get-ADObject realisieren – inklusive Konten, die sich bereits im AD-Papierkorb befinden:

Get-ADObject -IncludeDeletedObjects -Filter "objectSid -eq '$sid'" | Select-Object Name, ObjectClass

Steht das AD-Modul nicht zur Verfügung, aber die RSAT-Basistools sind installiert, funktioniert alternativ:

dsquery * -filter "(objectSid=S-1-5-21-...)" -attr name objectClass

Standard-SIDs auflösen

Die genannten Methoden funktionieren nicht nur für Benutzerkonten, sondern auch für bekannte System-SIDs wie S-1-5-11 ("Authentifizierte Benutzer") oder S-1-5-18 (SYSTEM-Konto). Diese lassen sich mit derselben PowerShell-Syntax in lesbare Namen übersetzen.

Fazit

Der Wegfall von SID2UserName schmerzt in der Praxis kaum, denn Windows deckt die frühere Funktionalität des Tools heute vollständig über Bordmittel ab. Für lokale und Domänenkonten führt an PowerShell mit SecurityIdentifier.Translate() kein Weg vorbei; wer eine WMIC-ähnliche Abfrage bevorzugt, findet in Get-CimInstance den offiziell empfohlenen Ersatz.

In Active-Directory-Umgebungen liefert Get-ADObject sogar einen Mehrwert gegenüber dem alten Tool, da sich damit auch bereits gelöschte Konten aus dem AD-Papierkorb auflösen lassen. Administratoren, die bislang auf Drittanbieter-Tools oder WMIC gesetzt haben, sollten ihre Skripte und Dokumentationen entsprechend anpassen – spätestens mit der für 2026 angekündigten vollständigen Entfernung von WMIC führt ohnehin kein Weg mehr an PowerShell vorbei.