SQL-Server 2019 Wartungsplan sperrt Benutzeraccount

[Knut.Wuchtig 11]

Hallo Gemeinde,
habe beim SQL Server 2019 mehrere Wartungspläne am Laufen. Ganz plötzlich kommt der Server auf die Idee, die neuen, die ich in den letzten Tagen erstellt habe, beim Ausführen mit dem Sperren des Benutzers zu beantworten, unter dessen Account der Wartungsplan erstellt wurde. Der Wartungsplan selbst hat dann auch keinen Eintrag mehr unter "Verbindung". Ich kann dort in diesem Fall auch nichts mehr auswählen. Normalerweise steht dort "Lokaler Server". Ich muss den Wartungsplan löschen und neu erstellen. Manchmal dann aber leider mit demselben Ergebnis.

 

Hat das schon mal jemand erlebt, oder besser, weiß jemand den Grund und einen Ausweg?

 

VG, Knut

[NilsK 2.939]

Moin,

 

wenn der Account gesperrt wird, dann ist die Anmeldung fehlerhaft.

 

Gruß, Nils

 

[Knut.Wuchtig 11]

Nein, kann nicht sein, die Sitzung ist sogar noch offen. Also konkret: Ich öffne das Managementstudio mit Verbindung zur Instanz Nr. 1 als z.B. "sa" der Instanz 1.

Nun erstelle ich einen Wartungsplan mit der Verbindung "Lokaler Server". Dann teste ich den Wartungsplan und es geht sofort schief. Nachgeschaut bin ich jetzt als der Benutzer "sa" gesperrt bei noch offenem Managementstudio und der Wartungsplan hat keine Verbindung mehr und kann auch den Lokalen Server nicht mehr auswählen. Selbst nach Reaktivierung des sa ist der Wartungsplan beschädigt.

 

VG, Knut

[Gulp 256]

Ein gesperrter Account ist immer eine fehlerhafte Anmeldung, es gibt schlicht keine andere Aktion, die eine Kontosperrung auslöst.

 

Grüsse

 

Gulp

[Knut.Wuchtig 11]

Ich kann angemeldet zusehen, wie mein Account gesperrt wird. Und der Wartungsplan zerstört wird. Das alles soll an einer fehlerhaften Anmeldung liegen? Wie konnte ich mich denn gerade noch anmelden, wenn die Anmeldung fehlerhaft ist, und warum zerstört dieser Prozess den Wartungsplan, bzw. die Wartungspläne aller Instanzen? Und übrigens, alle Instanzen haben andere Anmeldungen. Alle fehlerhaft? Plötzlich? Wo sie doch über mehrere Jahre schon so liefen,

Seltsam. Glaub ich nicht. Das einzige was sich ändert ist das/der Patchlevel von Window und SQL-Server.

[NilsK 2.939]

Moin,

 

ja und? Was sollen wir dazu jetzt sagen?

 

Gruß, Nils

 

[Knut.Wuchtig 11]

Naja, hätte ja sein können, dass das schon mal jemand so erlebt hat.

Wenn ich das gleiche Spiel erneut mache, funktioniert es manchmal. Meist aber nicht. Keine Logik dahinter, Für mich jedenfalls.
Ich hänge mal einen Screenshot an, wie der Wartungsplan dann aussieht. Im Feld "Verbindung" steht üblicherweise "lokaler Server". Hier steht dann nichts mehr, und lokaler Server ist auch nicht auswälbar.

[NilsK 2.939]

Moin,

 

ein SQL-Login wird durch SQL Server gesperrt, wenn zu häufig versucht wurde, sich mit falschem Kennwort anzumelden. Es gibt keine andere Ursache dafür. Wie viele Versuche das sind, kannst du in der zugehörigen Policy nachsehen.

 

Das Verhalten, das du beschreibst, passt dazu: Du hast eine Session mit dem Account offen, der dann später gesperrt wird. Daher funktioniert deine Session nicht mehr, weswegen du keine Daten - wie z.B. die Serververbindung - mehr abrufen kannst.

 

Wo da bei dir falsche Anmeldedaten hinterlegt sind, müsstest du selbst prüfen. Vielleicht ist es ja auch gar nicht der Wartungsplan selbst, sondern eine andere Stelle, und du siehst des nur zufällig, wenn du im SSMS arbeitest.

 

Gruß, Nils

 

[Gulp 256]

Da kann ich Nils nur beipflichten und Dir nur weiterhin versichern, dass der einzige Grund für eine Kontosperrung in der Tat eine mehrfache fehlerhafte Eingabe (egal, ob per gespeicherten Anmeldedaten oder manuell) des Kennworts des dann gesperrten Accounts ist, es gibt wie gesagt keine andere Ursache dafür.

 

Da dürftest Du auch im passenden Ereignis-Log zum Accounttyp etwas entweder auf dem SQL Server oder einem DC herausfinden können.

 

Grüsse

 

Gulp

 

 

bearbeitet 7. Februar 2023 von Gulp
Typo

[daabm 1.356]

Wenn ich das richtig interpretiere, arbeitet er mit dem sa, das ist ein SQL-interner User (über Für und Wider wollen wir hier nicht diskutieren ). Da wird im AD nichts zu finden sein.

Wenn das so richtig ist, bin ich ab jetzt still, weil ich von SQL-Auth keine Ahnung habe (und von Wartungsplänen und SMSS auch nur oberflächlichst).

[NilsK 2.939]

Moin,

 

Das ist korrekt, ändert am Prinzip aber nichts, sondern reduziert nur die Anzahl der Stellen, an denen man nachsehen kann. 

 

Gruß, Nils