Geplante Aufgaben können unter Windows Server 2022 oder höher nicht mehr auf entferne SQL Server zugreifen

Das Problem

Zeitplan-Jobs, die unter einem Domänenkonto laufend auf einen entfernten SQL Server mit Windows-integrierter Authentifizierung zugreifen müssen, werden vom SQL Server abgewiesen werden, weil der sie anonym anstatt mit dem Domänenkonto ankommend sieht. Die Fehlermeldung lautet:

Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'

oder auf einem deutschsprachigen System

Fehler bei der Anmeldung für den Benutzer "NT-AUTORITÄT\ANONYMOUS-ANMELDUNG"

Die Ursache

Windows Server 2022 und 2025 machen Ernst mit dem Abschalten der betagten und nicht mehr als sicher geltenden NTLM-Authentifizierung (vom "Windows NT LAN Manager"). Windows versucht (schon lange) zunächst die Kerberos-Authentifizierung am SQL Server durchzuführen. Wenn das nicht klappt, versuchten Windows Server 2019 und früher es standardmäßig auch mit der einfacheren, aber eben unsicheren NTLM-Authentifizierung.

Aktuelle Windows-Server-Editionen versuchen NTLM nicht mehr. Da Kerberos noch nicht konfiguriert wurde, klappt die Authentifizierung als das Ausführungskonto des geplanten Tasks nicht mehr - und Windows meldet sich als der "anonyme" Benutzer beim SQL Server. Den lässt der SQL Server nicht rein, und die Sache endet mit der o.g. Fehlermeldung.

Die Lösung

SQL Server muss per Kerberos-Authentifizierung angesprochen werden können. Das ist kein großer Aufwand, wir müssen nur wenige Bedingungen erfüllen:

• SQL Server muss auf einen festen TCP-Port hören.
• Sein Dienstkonto muss ein Domänenkonto sein.
• Für das Domänenkonto müssen die korrekten Service Principal Names (SPNs) konfiguriert worden sein.

Wie macht man das?

Ein Beispiel:

SQL Server-Port und -Dienstkonto einstellen

• Falls das Dienstkonto des SQL Servers ein lokales Konto ist, legen Sie in der Active Directory ein ganz normales Benutzerkonto oder auch ein verwaltetes Dienstkonto dafür an. In diesem Beispiel verwenden wir ein normales Benutzerkonto namens Sys-SQLServer und es bekommt ein starkes Kennwort.
• Bei einem normalen Benutzerkonto sollte das Kennwort nicht ablaufen und der Benutzer selbst sollte es nicht ändern können.
• Zusätzlich können Sie konfigurieren, dass sich das Konto nur von dem Computer mit dem SQL Server-Dienst aus anmelden kann.
• Sicherheitshalber können Sie im Benutzer Remotedesktop-Profil auch verbieten, dass dieses Konto für eine Anmeldung per RDP verwendet werden kann.
• Falls SQL Server noch auf einem dynamischen TCP-Port hört, stellen Sie im Sql Server Configuration Manager in Protokolle für '(Instanzname)', TCP/IP, Eigenschaften bei IPAll den dynamischen Port auf 0 und den TCP-Port auf einen festen Port (der Standardport für SQL Server ist 1433) ein. Auf denselben Port darf natürlich nichts anderes auf der Maschine hören. Das wirkt nach einem Neustart des SQL Server-Datenbankdienstes.
• Falls SQL Server noch nicht unter dem Domänenkonto läuft, stellen Sie im Sql Server Configuration Manager in SQL Server-Dienste, SQL Server (Instanzname), Eigenschaften, Anmelden das Dienstkonto auf das Domänenkonto (in unserem Beispiel also (Domänenname)\Sys-SQLServer) mit dem entsprechenden Kennwort ein. Spätestens jetzt müssen Sie die Datenbankdienste neu starten.
• Vergessen Sie nicht, den ggf. automatisch beendeten Dienst SQL Server Agent auch wieder zu starten.
• Testen Sie, ob alle existierenden Anwendungen sich noch problemlos mit SQL Server verbinden können.

Service Principle Names (SPNs) konfigurieren

In der Active Directory müssen für das Dienstkonto (hier also Sys-SQLServer) noch die SPNs registriert werden. Das kann von einem beliebigen Computer in der Domäne aus geschehen (es muss weder der SQL Server noch ein Domänencontroller sein), aber Sie müssen das Recht haben, das zu tun (ein Domänen-Administrator hat das).

Der SPN ist nichts anderes als ein Stück Text, ein String. Er ist so aufgebaut:

MSSQLSVC/Computername:Port

Wenn der Computername also SQL1 und die Domäne meinefirma.zone heißt, brauchen wir zwei SPNs, einen für den FQDN:

MSSQLSVC/sql1.meinefirma.zone:1433

Und einen für den NetBIOS-Namen des Computers:

MSSQLSVC/SQL1:1433

Diese Namen fügen wir dem Dienstkonto per setspn.exe hinzu (die Eingaben sind unterstrichen):

PS> setspn.exe -s 'MSSQLSVC/sql1.meinefirma.zone:1433' 'Sys-SQLServer'

Die Domäne "DC=meinefirma,DC=zone" wird überprüft.

Dienstprinzipalnamen (SPN) für CN=Sys-SQLServer,CN=Users,DC=meinefirma,DC=zone werden registriert.

MSSQLSVC/sql1.meinefirma.zone:1433

Aktualisiertes Objekt

PS> setspn.exe -s 'MSSQLSVC/SQL1:1433' 'Sys-SQLServer'

Die Domäne "DC=meinefirma,DC=zone" wird überprüft.

Dienstprinzipalnamen (SPN) für CN=Sys-SQLServer,CN=Users,DC=meinefirma,DC=zone werden registriert.

MSSQLSVC/SQL1:1433

Aktualisiertes Objekt

Ob das geklappt hat, können wir uns anzeigen lassen:

PS> setspn.exe -l 'Sys-SQLServer'

Registrierte Dienstprinzipalnamen (SPN) für CN=Sys-SQLServer,CN=Users,DC=meinefirma,DC=zone:

MSSQLSVC/SQL1:1433

MSSQLSVC/sql1.meinefirma.zone:1433

Jetzt sollte der Zeitplan-Job wieder Windows-integriert auf den SQL Server zugreifen können.

Voilà.