Drei benannte Instanzen - jeweils unterschiedliche Anzahl an Fehlern 18456 (Login failed for user ... Fehler bei der Überprüfung des tokenbasierten Serverzugriffs mit einem Infrastrukturfehler ...)

Question

Hallo,

ich habe mittlerweile einige Zeit damit verbracht, eine Antwort auf mein Problem zu finden. Leider bisher vergebens, daher hier meine Situation:

Ich habe auf einem Server drei benannte Instanzen des SQL Servers 2008 R2 installiert. Jede Nacht um kurz nach 2 Uhr wird folgender Fehler protokolliert:

Fehler Fehler: 18456, Schweregrad: 14, Status: 11. Fehler Login failed for user '<Domain>\<Service Account des SQL Servers>'. Ursache: Fehler bei der Überprüfung des tokenbasierten Serverzugriffs mit einem Infrastrukturfehler. Suchen Sie nach vorherigen Fehlern. [CLIENT: ]

Das Kuriose ist, dass eine der drei benannten Instanzen diesen Fehler gar nicht meldet, eine andere diesen Fehler genau einmal meldet und die dritte benannte Instanz diesen Fehler genau zweimal hintereinander meldet!?

Der syspolicy_purge_history Job meldet keinen Fehler. Ich habe einen serverseitigen Trace mitlaufen lassen, um zu prüfen, welche Anwendung versucht sich zu verbinden. Dabei handelt es sich um SQLPS (<Service Account des SQL Servers>@<Servername>).

Wer bzw. wodurch wird die PowerShell um diese Uhrzeit gestartet? Wie lässt sich die unterschiedliche Anzahl an Fehlerereignissen auf den drei verschiedenen Instanzen erklären?

Vielen Dank im Voraus.

Answer 1

Schau mal hier, vielleicht hilft Dir das:

http://blogs.technet.com/b/the_9z_by_chris_davis/archive/2014/02/21/sql-event-id-18456-login-failed-for-user-reason-token-based-server-access-validation-failed.aspx

---

Gruß
Ben

Wenn Dir meine Antwort hilft, markiere sie bitte entsprechend als Antwort! Danke! :-)

Hinweis: Meine Posts werden "wie besehen" ohne jedwede Gewähr bereitgestellt, da menschliche, technische und andere Fehler nicht ausgeschlossen werden können.

Answer 2

Hallo Oliver,
ich könnte mir auch vorstellen, dass der Job syspolicy_purge_history  die Logins versucht.

Deaktiviere mal den Job für eine Nacht und schaue dann, ob Ruhe ist. Danach kannst Du dann gezielter anfangen zu suchen.

Einen schönen Tag noch,
Christoph
--
Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu

Answer 3

Hallo Ben,

leider gibt es bei mir keine Anzeichen von "denys" oder "revokes". Ich habe ebenso die Berechtigungen (sys.server_permissions) auf zwei Instanzen vergleichen (eine mit und eine ohne diesem Problem) und konnte keine Unterschiede feststellen.

Gruß
Oliver.

Answer 4

Hallo Christoph,

ich hatte heute bereits einen zusätzlichen Zeitplan für den syspolicy_purge_history Job eingerichtet, um genau dies zu prüfen. Der Fehler trat nicht auf. Ich habe dennoch den Job für die nächste Nacht deaktiviert und warte bis morgen.

Gruß
Oliver.

Answer 5

Hallo zusammen,

hier einige Erkenntnisse die ich zwischenzeitlich gewinnen konnte. Neben den drei benannten Instanzen existieren auf dem Server natürlich auch drei SQL Server-Agents:

SQL Server (benannte Instanz 1)
SQL Server (benannte Instanz 2)
SQL Server (benannte Instanz 3)

SQL Server-Agent (benannte Instanz 1)
SQL Server-Agent (benannte Instanz 2)
SQL Server-Agent (benannte Instanz 3)

Der Aufruf des syspolicy_purge_history Jobs im Agent der ersten Instanz verursacht den Fehler in den benannten SQL Server Instanzen 2 und 3.
Der Aufruf des syspolicy_purge_history Jobs im Agent der zweiten Instanz verursacht den Fehler in der dritten benannten SQL Server Instanz.
Der Aufruf des syspolicy_purge_history Jobs im Agent der dritten Instanz verursacht keinerlei Fehler.

An der Konfiguration des Mappings Agent <-> SQL Server gibt es - wie es sich derzeit darstellt - noch Probleme!?

Die Dienste sämtlicher benannter SQL Server Instanzen und Agents laufen unter ein und demselben Domänenkonto. Die Ports der benannten Instanzen habe ich auf drei unterschiedliche statische Ports konfiguriert.

Gruß
Oliver.

Answer 6

Mit dieser neuen Erkenntnis habe ich noch etwas recherchiert. Folgenden Foreneintrag habe ich gefunden und versuche die dort beschriebenen Lösungsvorschläge bei mit anzuwenden.

http://social.msdn.microsoft.com/Forums/sqlserver/en-US/5968e421-c387-4e91-921c-7e9b1f3d1c90/syspolicypurgehistory-generates-unauthorised-connection-to-other-instances-on-a-machine?forum=sqldatabaseengine

Ich werde berichten…

Gruß
Oliver.

Answer 7

Leider hat dies noch nicht geholfen der dritte Job Step „Erase Phantom System Health Records“ verursacht den Fehler. Darin wird ein PowerShell Kommando abgesetzt. Dieses wird jeweils in der eigenen Instanz erfolgreich ausgeführt  aber, so wie es aussieht, auch jeweils in allen Instanzen die zeitlich später installiert wurden und dort jeweils den Fehler auslöst.

Answer 8

Hallo,

ich habe der 3. Instanz die Konten [NT SERVICE\SQLAgent$Instance1] und [NT SERVICE\SQLAgent$Instance2] hinzugefügt (lediglich public Serverrolle) und der 2. Instanz das Konto [NT SERVICE\SQLAgent$Instance1] (ebenfalls nur die public Serverrolle).

Der Fehler taucht nun nicht mehr auf, aber irgendwie bin ich mit dieser Lösung noch nicht zufrieden. Über andere Lösungen wäre ich weiterhin dankbar.

Gruß
Oliver.

Answer 9

Wer weiß, was da in die Hose gegangen ist...

Versuche doch mal, den Job komplett neu zu bauen:

DECLARE @jobId uniqueidentifier

-- Obtain the current job identifier that is associated with the PurgeHistory
SELECT @jobId = CAST(current_value AS uniqueidentifier)
FROM msdb.dbo.syspolicy_configuration_internal
WHERE name = N'PurgeHistoryJobGuid'

-- Delete the job identifier association in the syspolicy configuration

DELETE FROM msdb.dbo.syspolicy_configuration_internal
WHERE name = N'PurgeHistoryJobGuid'

-- Delete the offending job
EXEC msdb.dbo.sp_delete_job @job_id = @jobId

-- Re-create the job and its association in the syspolicy configuration table
EXEC msdb.dbo.sp_syspolicy_create_purge_job

---

Bodo Michael Danitz - MCT, MCITP - free consultant - performance specialist - www.sql-server.de

Answer 10

Hallo Bodo,

das hatte ich versucht - jedoch auch ohne Erfolg.

Ich habe meinen Workaround von gestern (zusätzliche SQL Server-Agent Accounts in den verschiedenen Instanzen) wieder rückgängig gemacht. Stattdessen habe ich jeweils den dritten Step des syspolicy_purge_history Jobs (Erase Phantom System Health Records) modifiziert:

Ersetzung von

if ('$(ESCAPE_SQUOTE(INST))' -eq 'MSSQLSERVER') {$a = '\DEFAULT'} ELSE {$a = ''};
(Get-Item SQLSERVER:\SQLPolicy\$(ESCAPE_NONE(SRVR))$a).EraseSystemHealthPhantomRecords()

durch

(Get-Item SQLSERVER:\SQLPolicy\<FQHN>`,<Statische Portnummer>\<Instanzname>).EraseSystemHealthPhantomRecords()

Dies hat bei mir geholfen. Der Jobstep verbindet sich nun nicht mehr mit sämtlichen Instanzen, die zeitlich nach der eigenen installiert wurden.

Gruß
Oliver.

Answer 11

Dann war es das. Ich hatte gehofft, dass er den 3. Step von selbst richtig bauen würde, tut er dann aber offensichtlich nicht. Ist natürlich so ne Sache mit hartcodierten Portnummern... aber so hast du die Lösung selbst gefunden :-)

---

Bodo Michael Danitz - MCT, MCITP - free consultant - performance specialist - www.sql-server.de