Ich habe eine .net-Webanwendung auf einem Windows Server 2003 IIS-Server installiert, die in einem Anwendungspool ausgeführt wird NETWORK SERVICEund über integrierte Sicherheit eine Verbindung zu SQL Server auf einem anderen Computer herstellt. Auf dem SQL Server-Computer läuft ebenfalls Windows Server 2003. Die Webanwendung stellt daher eine Verbindung als Identität herDOMAIN\COMPUTER$und dieses Konto verfügt über einen Login und einen Benutzer in SQL Server, sodass alles gut funktioniert.
Ich habe auch einen .net Windows-Dienst auf demselben IIS-Server installiert, der eine Verbindung zu demselben SQL Server-Rechner herstellt. Der Windows-Dienst läuft als LOCAL SYSTEMund sollte sich daher auch als Identität verbinden.DOMAIN\COMPUTER$. Ich habe dasselbe Produkt bei über einem Dutzend verschiedener Unternehmen installiert, normalerweise funktioniert alles wie erwartet, aber in einem aktuellen Fall konnte der Windows-Dienst keine Verbindung zur Datenbank herstellen, und es trat der folgende Fehler auf:
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'
Irgendwelche Ideen, warum dies bei LOCAL SYSTEM der Fall sein könnte und nicht bei NETWORK SERVICE? Um dies kurzfristig zu umgehen, musste ich auf die Verwendung einer SQL Server-Anmeldung umsteigen, würde aber, wenn es eine einfache Lösung dafür gäbe, lieber die integrierte Sicherheit verwenden. Es gab keine Fehlermeldungen im Sicherheits- oder Systemereignisprotokoll, obwohl ich nichts unternommen hatte, um zusätzliche Protokollierung zu aktivieren.
Normalerweise würde ich davon ausgehen, dass es sich um ein Kerberos/AD-Problem handelt, und nach Artikeln wieDasUndDaswürde helfen. Aber die Tatsache, dass es über NETWORK SERVICE funktioniert, lässt darauf schließen, dass die normalen Dinge, die ich überprüfen würde, bereits in Ordnung sind (z. B. wurden SPNs korrekt eingerichtet und das Computerdomänenkonto ist für die Delegierung aktiviert?). Welche Einstellung ist es also, die schief läuft?
Ich habe ohne die Unterstützung des IT-Teams meines Kunden keinen Zugriff auf die Server und auf dem Server sind andere Anwendungen installiert, die ich nicht stören darf. Beides macht die Fehlerbehebung etwas schwieriger. Ich bin für alle Vorschläge zur Fehlerbehebung sehr dankbar!
Antwort1
Möglicherweise möchten Sie bestätigen, ob es sich bei der Sicherheitsverbindung um NTLM oder Kerberos handelt. Wenn auf NTLM zurückgegriffen wird, ist die Verbindung anonym.
Es gibt eine Gruppenrichtlinie, die die Verwendung der Computeridentität bei Einsatz von NTLM ermöglicht.
Netzwerksicherheit: Lokalem System erlauben, die Computeridentität für NTLM zu verwenden
http://technet.microsoft.com/en-us/library/jj852275%28v=ws.10%29.aspx
Weitere Informationen zum Konfigurieren des SPN zur Erleichterung der Kerberos-Authentifizierung für Ihren SQL-Server:
Beachten Sie insbesondere Folgendes:
Ein SPN für SQL Server besteht aus den folgenden Elementen:
- ServiceClass: Dies identifiziert die allgemeine Dienstklasse. Für SQL Server ist dies immer MSSQLSvc.
- Host: Dies ist der vollqualifizierte Domänenname DNS des Computers, auf dem SQL Server ausgeführt wird.
Port: Dies ist die Portnummer, auf der der Dienst lauscht.
zB: MSSQLSvc/myserver.corp.mycomany.com:1433
Antwort2
Ich tippe immer noch auf ein SPN-Problem. Gehen Sie nicht einfach davon aus, dass sie da sind. Überprüfen Sie, ob die SPNs für SQL Server richtig registriert sind. Überprüfen Sie auch, ob Duplikate vorhanden sind ( setspn -x).
Network Servicefunktioniert, weil bei Nichtvorhandensein des SPN immer noch auf die NTLM-Authentifizierung zurückgegriffen werden kann.
Local Systemfunktioniert nicht, da es nur auf Netzwerkressourcen zugreift, als DOMAIN\Computer$ob es Kerberos verwenden könnte. Andernfalls fällt es auf eine Nullsitzung zurück, weshalb Sie sehen Anonymous Logon.