{"id":1271,"date":"2024-10-09T20:14:00","date_gmt":"2024-10-09T18:14:00","guid":{"rendered":"https:\/\/www.mediamill.de\/blog\/?p=1271"},"modified":"2024-10-09T16:27:37","modified_gmt":"2024-10-09T14:27:37","slug":"tausende-logmeldungen-im-application-log-eines-adfs-servers-event-id-28005-error-15517-state-1-cannot-execute-as-the-database-principal-because-the-principal-dbo-does-not-exist","status":"publish","type":"post","link":"https:\/\/www.mediamill.de\/blog\/2024\/10\/09\/tausende-logmeldungen-im-application-log-eines-adfs-servers-event-id-28005-error-15517-state-1-cannot-execute-as-the-database-principal-because-the-principal-dbo-does-not-exist\/","title":{"rendered":"Tausende Logmeldungen im Application Log eines ADFS Servers Event ID 28005: Error: 15517, State: 1. Cannot execute as the database principal because the principal „dbo“ does not exist"},"content":{"rendered":"\n
\"\"<\/a><\/figure>\n\n\n\n

Im Rahmen der Administration eines Active Directory Federation Service (ADFS) Servers stie\u00dfen wir auf ein Problem: Tausende von Fehlermeldungen im Eventlog des Servers, die keinen direkten Einfluss auf die Funktionalit\u00e4t hatten, aber dennoch st\u00f6rend waren und die \u00dcbersicht im Log massiv beeintr\u00e4chtigten. In diesem Blogartikel m\u00f6chten wir die Ursache und L\u00f6sung des Problems im Detail erl\u00e4utern.<\/p>\n\n\n\n

Problem: Massenhaft Fehler im Application Log<\/h3>\n\n\n\n

Im Application Log eines ADFS-Servers fanden sich \u00fcber 170.000 Fehlermeldungen innerhalb von 24 Stunden, was zu einer durchschnittlichen Rate von fast zwei Logeintr\u00e4gen pro Sekunde f\u00fchrte. Der Logeintrag hatte die folgende Fehlermeldung:<\/p>\n\n\n\n

An exception occurred while enqueueing a message in the target queue. Error: 15517, State: 1. Cannot execute as the database principal because the principal \"dbo\" does not exist, this type of principal cannot be impersonated, or you do not have permission.\n<\/code><\/pre>\n\n\n\n
Obwohl diese Fehler keinen direkten Einfluss auf die Funktionalit\u00e4t des ADFS-Servers hatten, waren sie st\u00f6rend und erschwerten das Monitoring und die Diagnose anderer potenzieller Probleme.<\/p>\n\n\n\n
Ursache: Datenbank-Fehlkonfiguration<\/h3>\n\n\n\n
Nach einer eingehenden Untersuchung und einer Internetrecherche zeigte sich, dass das Problem durch eine Fehlkonfiguration in der Windows Internal Database (WID) verursacht wurde, die ADFS verwendet. Genauer gesagt war der Datenbankbesitzer (\u201eDBO\u201c, Database Owner) der relevanten ADFS-Datenbanken nicht korrekt gesetzt. Der Fehler \u201eCannot execute as the database principal because the principal ‚dbo‘ does not exist\u201c deutete darauf hin, dass der Datenbankbesitzer in den betroffenen ADFS-Datenbanken NULL war.<\/p>\n\n\n\n
L\u00f6sung: Anpassen des DBOwners der ADFS-Datenbanken<\/h3>\n\n\n\n
Um das Problem zu beheben, haben wir die folgenden Schritte durchgef\u00fchrt:<\/p>\n\n\n\n
    \n
  1. Installation von SQL Server Management Studio (SSMS)<\/strong>
    Um die Konfiguration der WID-Datenbanken zu \u00e4ndern, ist es notwendig, das SQL Server Management Studio (SSMS) zu verwenden. <\/li>\n\n\n\n
  2. Verbindung zur Windows Internal Database (WID)<\/strong>
    Als N\u00e4chstes haben wir uns mit der WID-Instanz auf dem ADFS-Server verbunden. Dies geschieht mit folgendem Verbindungsstring:<\/li>\n<\/ol>\n\n\n\n
    np:\\\\.\\pipe\\MICROSOFT##WID\\tsql\\query<\/code><\/pre>\n\n\n\n
    Wichtiger Hinweis: SSMS muss als Administrator gestartet werden, da die Verbindung zur WID-Instanz sonst fehlschl\u00e4gt.<\/mark><\/strong><\/p>\n\n\n\n
    \u00c4ndern des Datenbankbesitzers (DBOwner) f\u00fcr die ADFS-Datenbanken<\/strong>
    In der WID-Instanz haben wir dann den Datenbankbesitzer f\u00fcr die beiden ADFS-Datenbanken \u201eAdfsConfigurationV4\u201c und \u201eAdfsArtifactStore\u201c ge\u00e4ndert. Dies geschah mit den folgenden SQL-Befehlen:<\/p>\n\n\n\n
    use [AdfsConfigurationV4]\nEXEC sp_changedbowner 'sa'\n\nuse [AdfsArtifactStore]\nEXEC sp_changedbowner 'sa'<\/code><\/pre>\n\n\n\n
    Vor dieser \u00c4nderung war der Besitzer der beiden Datenbanken auf NULL<\/code> gesetzt, was die Fehlermeldungen verursachte.<\/p>\n\n\n\n
      <\/ol>\n\n\n\n
      Ergebnis: Keine weiteren Fehlermeldungen<\/h3>\n\n\n\n
      Nach der erfolgreichen \u00c4nderung des DBOwners in der WID-Instanz wurden die st\u00f6renden Logeintr\u00e4ge im Application Log vollst\u00e4ndig beseitigt. Der ADFS-Server lief weiterhin ohne Probleme, und die \u00c4nderung hatte keinerlei negative Auswirkungen auf die Funktionalit\u00e4t des Servers.<\/p>\n\n\n\n
      Hilfreichen Artikeln:<\/p>\n\n\n\n