Event-ID 10154: SPNs konnten vom WinRM-Dienst nicht erstellt werden
Da es immer wieder einmal vorkommt, dass ich beim Empfang der protokollierten, unterschiedlichen Warn- und Fehlermeldungen verschiedener Kundensysteme auf Fehler stoße, die laut Microsoft als unbedenklich einzustufen sind und ignoriert werden können, neige ich manchmal dazu, häufig auftretende – eher unkritische – Warnungen oder Fehler einfach herauszufiltern bzw. auszublenden. Doch die Lösung durch Beseitigung der Ursache ist oftmals die bessere Variante.
Problem
Da der folgende Fehler doch häufiger auftaucht, hier nun die Dokumentation zu Behebung. Im Anwendungsereignisprotokoll taucht unter der Quelle Windows Remote Management (WinRM) mit der Event-ID 10154 gelegentlich die folgende Warnung auf:
Die folgenden SPNs konnten vom WinRM-Dienst nicht erstellt werden:
WSMAN/FQDN; WSMAN/Servername.
Zusätzliche Daten Empfangener Fehler: 8344: %%8344.
Benutzeraktion Die SPNs können von einem Administrator mithilfe des Hilfsprogramms „setspn.exe“ erstellt werden.
Ursache
Die sogenannten SPNs stehen für Service Principal Names und identifizieren eindeutig Dienstinstanzen in einer Active Directory Domäne. Jede Instanz eines Dienstes hat dabei einen eindeutigen SPN und wird nach dem Schema [Dienstklasse]/[Host]:[Port]/[Dienstname] gebildet. Im beschriebenen Fehlerfall soll somit die Dienstklasse Web Services-Management (WSMAN) auf einem (in meinem Falle) Domänencontroller eindeutig identifiziert werden.
Microsoft hat das WS-Management eingeführt, um einen einheitlichen Zugriff auf Informationen innerhalb einer IT-Infrastruktur zu ermöglichen (ähnlich WBEM und SNMP). Implementiert wurde der Zugriff des Windows Remote Management (WinRM), welches – wie der Name bereits verdeutlicht – der entfernten Verwaltung von Systemen im Netzwerk dient.
Lösung
Da der Dienst Windows-Remoteverwaltung (WS-Verwaltung) unter dem Benutzer Netzwerkdienst gestartet wird, benötigt dieser auch das Recht entsprechende SPNs zu ändern. Um die Berechtigung zu erteilen, öffnet man auf einem Domänencontroller den ADSI-Editor und verbindet sich mit dem Standardmäßigen Namenskontext.
Im Anschluss navigiert man zum Common Name (CN) des betroffenen Domänencontrollers (CN=<Name>,OU=Domain Controllers, DC=<Domain>,DC=<TLD>). Nach dem Aufruf der Eigenschaften und des Reiters Sicherheit muss für den Benutzer NETZWERKDIENST nun die Berechtigung Bestätigtes Schreiben an Dienstprinzipal zugelassen werden:
Im Anschluss taucht der beschriebene Fehler nicht mehr auf.
Fazit
Obwohl mittlerweile einige Beschreibungen zur Fehlerbehebung existieren, so fehlt bei den meisten eine Erklärung. Da ich Fehler und deren Ursache gern verstehen möchte, dient dieser Artikel – wie so oft – als Gedankenstütze oder Nachschlagewerk.
Für Verbesserungsvorschläge, Kritik oder Fragen bin ich immer offen und freue mich über jederzeit über einen Kommentar.
Einen Blog am Leben zu erhalten kostet Zeit und Geld. Da ich auf meiner Seite weder Werbung einbinde, noch andersweitige Zuwendungen erhalte, freue ich mich über jede kleine Spende. Einfach und unkompliziert geht das über PayPalMe. Du unterstützt damit diesen Blog. Vielen Dank.
Auf Grund der am 25. Mai 2018 in Kraft tretenden europäischen Datenschutz-Grundverordnung wurden alle Kommentare abgeschaltet und gelöscht. Damit wird die Erhebung personenbezogener Daten vermieden. Das DSGVO wurde von Professor Thomas Hoeren zu "einem der schlechtesten Gesetze des 21. Jahrhunderts" gekürt, mit der Bemerkung, dass überbordene Werk sei "hirnlos". Ich bedaure sehr, das damit die Möglichkeit zum Austausch von Informationen von Gleichgesinnten verhindert wird.