SQL Server 2012 mit dem Konto NT Service \ MSSQLSERVER-Zugriff wird in der Domäne verweigert

7

Vor einigen Monaten haben wir SQL Server 2012 in Windows 2008 R2 unter dem virtuellen Konto " NT Service \ MSSQLSERVER " installiert .

Vor einigen Tagen hat einer der Administratoren der IT-Abteilung die Volltextsuchkomponente auf dem SQL Server 2012 installiert (das Problem ist, dass er sich nicht erinnern konnte, welche Einstellungen er während des Setups genau gewählt hat), und danach treten einige Probleme auf ::

A. Wir haben die Windows-Protokolle überprüft. In der Anwendung stellen wir fest, dass MSSQLServer viele anormale Protokolle enthält, z.

Die SQL Server-Netzwerkschnittstellenbibliothek konnte den Dienstprinzipalnamen (SPN) [MSSQLSvc / FooComputer.FooDomain.com: 1433] für den SQL Server-Dienst nicht registrieren. Windows-Rückkehrcode: 0xffffffff, Status: 63. Wenn ein SPN nicht registriert wird, kann die integrierte Authentifizierung NTLM anstelle von Kerberos verwenden. Dies ist eine Informationsnachricht. Weitere Maßnahmen sind nur erforderlich, wenn die Kerberos-Authentifizierung gemäß den Authentifizierungsrichtlinien erforderlich ist und der SPN nicht manuell registriert wurde.

Es scheint die Ursache zu sein, aber keine Ahnung, warum und wie man es löst.

B. SQL-Jobs mit Eigentümern, die Domänenbenutzer wie "MyDomain \ FooUser" sind, schlagen mit der folgenden Meldung fehl:

Der Job ist fehlgeschlagen. Es kann nicht festgestellt werden, ob der Eigentümer (MyDomain \ FooUser) des Jobs JOBNAME Serverzugriff hat (Grund: Es konnten keine Informationen über die Windows NT-Gruppe / den Benutzer 'MyDomain \ FooUser', Fehlercode 0x6e. [SQLSTATE 42000] (Fehler 15404) abgerufen werden.)

Wir haben intensiv gesucht und schließlich den Besitzer durch "sa" ersetzt und das Problem gelöst, obwohl es nicht so anständig ist. Trotzdem möchten wir herausfinden, warum.

C. Sie können nicht auf Netzwerkressourcen wie einen Ordner auf anderen Computern zugreifen. Die folgende SQL gibt beispielsweise "Zugriff verweigert" zurück:

DECLARE @CopyCommand nvarchar(1000)
set @CopyCommand = 'dir ' + Char(34) + '\\FooComputer\FooFolder\' + Char(34)
EXEC master..xp_cmdshell @CopyCommand

Für Problem C haben wir laut MSDN ( http://technet.microsoft.com/en-us/library/ms143504.aspx ) versucht, dem Ordner den vollständigen Kontrollzugriff für das Konto "MyDomain \ SQLServerComputerName $" zu gewähren Ergebnis.

— ungeregelter Junge
quelle

7

Diese drei Probleme sind alle darauf zurückzuführen, dass das Konto, auf dem der SQL-Dienst ausgeführt wird, kein Domänenkonto ist, und sie werden alle behoben, indem SQL so geändert wird, dass es unter einem Domänenkonto ausgeführt wird. Speziell:

A - Ein SPN ist eine Kerberos-Sicherheitsfunktion, für die ein Domänenkonto erforderlich ist und die nicht mit lokalen Konten funktioniert

B - Zum Lesen aus Active Directory benötigt der Dienst die Anmeldeinformationen eines Domänenkontos

C - Lokale Konten werden von Remotecomputern nicht erkannt und verweigern daher den Verbindungsversuch.

Hier ist eine Anleitung zum Ändern des Dienstkontos:

http://technet.microsoft.com/en-us/library/ms345578.aspx

— SqlRyan
quelle

Was mich jedoch verwirrt hat, ist, dass seit dem ersten Tag unter dem virtuellen Konto "NT Service \ MSSQLSERVER" 2 Monate lang alles gut funktioniert hat. Warum plötzlich nicht mehr arbeiten? Und wir haben das gleiche für SQL Server 2008 in Windows 2008 jahrelang noch kein Problem gemacht.

— unruledboy

1

Sie sagen, es wurde festgelegt, dass das Dienstkonto zuvor verwendet wurde, und es hat ohne Probleme funktioniert? Soweit ich weiß, ist dies nicht möglich. Das Dienstkonto ist lokal auf dem Computer und authentifiziert sich nicht auf anderen Servern / Arbeitsstationen (außer möglicherweise als Gastkonto, das normalerweise deaktiviert ist). Das Wechseln zu einem Proxy-Domänenkonto ist in jedem Fall der richtige Weg und die empfohlene Methode, wenn Ihr SQL-Dienst mit anderen Computern in der Domäne kommunizieren muss.

— SqlRyan

Perfekt. Dies hat mir geholfen, die Arbeit im Handumdrehen zu erledigen.

— miCRoSCoPiCeaRthLinG

1

Als wir auf dieses Problem stießen, bestand unsere Lösung darin, den Ordner zu suchen und die Berechtigungen hinzuzufügen, die für das virtuelle Konto erforderlich sind, das dies benötigt. Nachdem wir das Konto einfach durch Eingabe hinzugefügt hatten, überwachten wir die Protokolldateien und stellten fest, dass wir das Problem mit diesem Ordner / dieser Datei nicht mehr hatten.

— user250187
quelle

1

Alte Frage, scheint aber keine richtige Antwort zu haben. NT Service \ MSSQLSERVER ist ein lokales virtuelles Konto und greift als Computerkonto auf das Netzwerk zu. Und solange das Computerkonto Zugriff auf Freigaben und Dateisysteme hat, sollten Sie beispielsweise in der Lage sein, auf UNC-Pfaden im Netzwerk zu sichern. Siehe Konfigurieren von Windows-Dienstkonten und -Berechtigungen .

— StiffBoard
quelle