MS SQL Server und keine Netzlaufwerke

[T. Wilhelm]

Bei der Arbeit mit MS-SQL 7.0 fällt mir häufig auf das mir die Netzlaufwerke nicht zur Verfügung stehen. Das beginnt bei der Datenbank-Sicherung, bis hin zum Import von Daten.
Beispiel:
CREATE PROCEDURE LTBGemTxtImport
@xFile nVarChar(50)
AS
DECLARE
@SQLString nVarCHAR(200)
SET @SQLString = "BULK INSERT LTBGem FROM " + @xFile+ " WITH ( CODEPAGE = "+'"OEM"'+", FIELDTERMINATOR = "+'";"'+" )"
EXEC sp_executesql @SQLString
->bringt den Fehler Zugriff (Fehler 5) verweigert.
Wer kann helfen ?

[Andreas Kosch]

Unter welchen Betriebssystem und unter welchem Benutzerkonto läuft der SQL Server? Unter NT 4 hat zum Beispiel das SYSTEM-Konto per Default keine Verbindungsmöglichkeit auf fremde Rechner

[T. Wilhelm]

Erst mal vielen Dank für die schnelle Antwort auf meine Frage. Ich arbeite unter NT 4.0 SP 5.0, wie schon vermutet war das Systemkonto daran schuld, dass ich von einem Netzlaufwerk nicht importieren konnte. Nach einer kurzen Änderung des Dienstes auf mein Konto, mit dem ich auch lokale Administrator-Rechte besitze war alles i.O.
Wie kann man das SYSTEM-Konto ändern, damit man diese Probleme umgehen kann?
Trotzdem habe ich immer noch das Problem, das ich eine Sicherung, die auf einem Netzlaufwerk liegt, nicht angezeigt wird. Es werden mir nur meine lokalen Platten angezeigt.
Vielen Dank im voraus ...........

[Andreas Kosch]

Hallo,

es gibt zwar einen von Microsoft offiziell dokumentierten Weg, über einen Registry-Eintrag das SYSTEM-Konto auch für Netzzugriffe freizuschalten, aber im Sinne der Erfinder (NT-Sicherheitssystem) ist das nicht.

Das <b>LocalSystem</b>-Benutzerkonto (.\System) wird für die System-Prozesse verwendet. Es hat kein Passwort - jedes beim Aufruf einer API-Funktion übergebenes Passwort wird ignoriert. Ein Service, der unter dem LocalSystem-Benutzerkonto läuft, erbt die Sicherheits-Konfiguration des SCM (Service Control Manager). Somit kann LocalSystem keinem echten Benutzer zugeordnet werden und auch die Verifizierung dieses Kontos ist nicht möglich. Daraus ergeben sich einige Einschränkungen: <br>
- Der Service kann den Registry-Zweig HKEY_CURRENT_USER nicht öffnen.
Im Gegensatz dazu kann der Service den Registry-Zweig HKEY_LOCAL_MACHINE\SECURITY öffnen. <br>
- Der Service hat nur sehr eingeschränkten Zugriff auf Netzwerk-Ressourcen (wie zum Beispiel freigegebene Verzeichnisse oder Pipes). Konkret bedeutet dies, das jeder erlaubte Zugriff in der Registry über die Werte <b>NullSessionPipes</b> und <b>NullSessionShares</b> eingetragen werden muss (Registry-Zweig unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\LanmanServer\Parameters). Wenn der Eintrag RestrictNullSessAccess mit dem DWORD-Wert 0 gesetzt wird, kann der Service auf alle freigegebenen Verzeichnisse und Pipes zugreifen. <br>
- Der Service kann bestimmte Objekte nur dann mit anderen Prozessen teilen, wenn auch dafür spezielle Sicherheitseinstellungen (DACL) gesetzt werden.

P.S: Bei Windows 2000 gibt es diese Einschränkung für SYSTEM nicht mehr