LOGINventory Helpdesk

Kurzfassung

Wenn das LOGINventory Webinterface auf einem anderen Server läuft als der SQL Server, ist SQL Server Authentication für die Datenbankverbindung die einfachste und empfohlene Variante.

Windows Authentication ist grundsätzlich möglich, kann bei getrennten Servern aber deutlich aufwendiger sein, da dann häufig Kerberos/Delegation korrekt eingerichtet werden muss.

Typische Fehlermeldung:

Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'

oder:

Fehler beim zugrunde liegenden Anbieter auf Open.
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'

Ursache

Bei Windows Authentication muss die Windows-Anmeldung vom Browser über den IIS-Webserver bis zum SQL Server weitergereicht werden.

Wenn Webinterface und SQL Server auf demselben Server laufen, ist das meist unproblematisch.

Wenn das Webinterface jedoch auf Server A läuft und der SQL Server auf Server B, entsteht ein sogenanntes Double-Hop-Szenario:

Benutzer / Browser → IIS Webinterface → SQL Server

Ohne korrekt konfigurierte Kerberos-Delegation kann die Windows-Anmeldung des Benutzers nicht bis zum SQL Server weitergereicht werden. Beim SQL Server kommt dann häufig nur noch an:

NT AUTHORITY\ANONYMOUS LOGON

Mögliche Varianten

Empfehlung

Für die meisten Installationen mit getrenntem Webserver und SQL Server empfehlen wir:

SQL Server Authentication für die Verbindung vom Webinterface zur Datenbank

Diese Variante vermeidet das Double-Hop-Problem vollständig und ist in der Praxis am stabilsten.

Wenn Windows Authentication zwingend vorgeschrieben ist, sollte das Webinterface nicht unter ApplicationPoolIdentity betrieben werden, sondern unter einem dedizierten Domänen-Dienstkonto, z. B.:

DOMAIN\svc_loginventory_web

Dieses Konto kann dann auf dem SQL Server für die LOGINventory-Datenbank berechtigt werden.

Wichtig: Dienstkonto ist nicht dasselbe wie Benutzerdelegation

Es gibt bei Windows Authentication zwei unterschiedliche Modelle:

1. Zugriff über ein festes Dienstkonto

Das Webinterface verbindet sich mit SQL unter der Identität des IIS-Dienstkontos.

Beispiel:

DOMAIN\svc_loginventory_web

In diesem Fall muss dieses Konto auf dem SQL Server berechtigt werden.

Vorteil: einfacher als echte Benutzerdelegation.
Nachteil: Der SQL Server sieht nicht den aktuell angemeldeten Web-Benutzer, sondern nur das Dienstkonto.

2. Zugriff im Kontext des angemeldeten Benutzers

Der Benutzer, der das Webinterface im Browser öffnet, soll auch gegenüber dem SQL Server verwendet werden.

Beispiel:

DOMAIN\max.mustermann → IIS → SQL Server

Dafür reicht ein Dienstkonto allein nicht aus. In diesem Fall muss zusätzlich Kerberos Delegation korrekt eingerichtet werden.

Typischerweise erforderlich:

• korrekte SPNs
• Kerberos statt NTLM
• Constrained Delegation für das IIS-/AppPool-Konto
• passende SQL-Rechte für die Benutzer oder AD-Gruppen

Diese Variante sollte nur verwendet werden, wenn sie wirklich benötigt wird.

Grundprüfung im IIS

Für das LOGINventory Webinterface sollte im IIS geprüft werden:

Diese Einstellungen allein lösen das Double-Hop-Problem bei getrenntem Web- und SQL-Server jedoch nicht automatisch.

Details: Dienstkonto für das Webinterface verwenden

Wenn Windows Authentication verwendet werden muss, ist ein dediziertes Domänen-Dienstkonto meist die sauberste Grundlage.

1. Dienstkonto in Active Directory anlegen

Beispiel:

DOMAIN\svc_loginventory_web

Empfehlungen:

• kein persönlicher Benutzeraccount
• kein Domain-Admin
• kein lokaler Administrator, sofern nicht ausdrücklich nötig
• starkes Passwort oder gMSA verwenden
• Konto eindeutig als Dienstkonto dokumentieren

2. Application Pool im IIS umstellen

Im IIS:

1. Anwendungspools öffnen
2. Application Pool des LOGINventory Webinterface auswählen
3. Erweiterte Einstellungen öffnen
4. Identität ändern
5. Benutzerdefiniertes Konto auswählen
6. Domänen-Dienstkonto eintragen

Beispiel:

DOMAIN\svc_loginventory_web

Danach den Application Pool neu starten.

3. SQL Server berechtigen

Auf dem SQL Server muss das verwendete Konto als Login angelegt und für die LOGINventory-Datenbank berechtigt werden.

Beispiel:

DOMAIN\svc_loginventory_web

Welche Datenbankrollen erforderlich sind, hängt vom jeweiligen LOGINventory-Setup ab.

Details: Wenn der echte Benutzer bis SQL delegiert werden soll

Wenn nicht das Dienstkonto, sondern der aktuell angemeldete Benutzer bis zum SQL Server weitergereicht werden soll, ist zusätzlich eine Kerberos-Konfiguration erforderlich.

Dazu gehören typischerweise:

• SPNs für das Webinterface bzw. das AppPool-Konto
• SPNs für den SQL Server
• Constrained Delegation im Active Directory
• Prüfung, dass tatsächlich Kerberos verwendet wird und nicht NTLM

Zur Diagnose kann auf dem SQL Server geprüft werden, mit welchem Verfahren die Verbindung aufgebaut wurde:

SELECT
    session_id,
    net_transport,
    client_net_address,
    auth_scheme
FROM sys.dm_exec_connections;

Für funktionierende Kerberos-Delegation sollte bei der betroffenen Verbindung stehen:

KERBEROS

Steht dort NTLM, funktioniert die Delegation zum SQL Server in diesem Szenario nicht korrekt.

Zusammenfassung

Für getrennte Web- und SQL-Server ist SQL Server Authentication die empfohlene und einfachste Variante.

Windows Authentication ist möglich, muss aber bewusst geplant werden:

• Dienstkonto-Modell: einfacher, SQL sieht das Dienstkonto
• Benutzerdelegation: aufwendiger, benötigt Kerberos/SPNs/Delegation

Die Fehlermeldung NT AUTHORITY\ANONYMOUS LOGON ist in diesem Zusammenhang meist ein Hinweis darauf, dass die Windows-Identität nicht korrekt bis zum SQL Server weitergegeben werden konnte.