SQL Server Zugriff von Außen

[Irgendware 10]

Hallo Leute,

 

ich verwende einen Microsoft SQL Server 2000 und möchte ihn gerne so konfigurieren, dass ich auch von außen (z.B. mit Access oder einer ASP.Net Seite auf einem anderen Webserver) auf den SQL Server zugreifen kann.

 

Leider verweigert mir der Server immer den Zugriff, ich kann nur auf Ihn zugreifen, wenn die Anwendung direkt auf der Maschine läuft.

 

Was muss ich in der Konfiguration ändern, damit dies auch von außen funktioniert?

Ich verwende übrigens gemischte Authentifizierung und die Benutzer, die sich von außen einloggen sind keine AD-, sondern SQL-Benutzer.

 

Grüße,

Irgendware

[auer 10]

Als Protokoll TCP/IP zulassen, dann müßte es mit der reinen Sql-Authentifizierung eigentlich sofort gehen.

Hat ein Zugriff von außerhalb jemals funktioniert?

Mit welchem ConnectionString greift das Script en detail zu?

Wurde nach der Konfigurationsänderung Nur NT -> gemischt der MSSQL neu gestartet?

 

--------------

Gruß, Auer

[Irgendware 10]

In der SQL-Server Netzwerkkonfiguration ist TCP/IP in den Aktiven Protokollen.

 

Ein Zugriff habe ich vorher noch nie probiert, von daher gehe ich nicht davon aus, dass es schon mal funktioniert hat. Eine Konfigurationsänderung hatte ich nie durchgeführt, bei der Installation hatte ich das gleich so ausgewählt.

 

Der ConnectionString sieht in etwa so aus:

password=...;User ID=...;server=DOTNET-INFRARED.DE\SHAREPOINT;database=...

 

Ich vergaß zu erwähnen, dass es sich um eine benannte Instanz handelt, da STS2.0 diese braucht. Eine unbenannte Instanz läuft auf dem Server nicht

[auer 10]

Ungewöhnlich finde ich, daß die Variable SERVER mittendrin steht.

 

Nimm mal etwas in der Form:

 

Data Source=DOTNET-INFRARED.DE\SHAREPOINT;Trusted_Connection=YES;

 

Das ist die kürzeste Form für die integrierte Sicherheit. Dann:

 

Trusted_Connection=NO;User ID=...;PWD=...

 

kreise also das Problem ein.

 

Setze unter HKLM\Software\Microsoft\Microsoft SQL Server\Instanzname\MSSQLSERVER den Wert AuditLevel auf 3 und starte die Instanz neu -> Protokollierung aller Zugriffsversuche, um zu sehen, ob Nutzer oder PWD falsch sind.

 

------------

Gruß, Auer

[Irgendware 10]

Eigentlich ist es egal in welcher Reihenfolge die Angaben im ConnectionString stehen, aber mit dem ändern des Regsitrywertes hat es geklappt :)

 

Viel Dank :-)

[Irgendware 10]

Hab mich leider zu früh gefreut :-(

 

Hatte eine falsche web.config hochgeladen, die noch die Zugangsdaten zum alten SQL Server enthielt.

Es funktioniert weiterhin nicht...

[auer 10]

Hatte mich auch schon gewundert, der Reg-Wert definiert lediglich eine erweiterte Protokollierung: Jedes Logon (erfolgreich und gescheitert) wird nun im Anwendungsprotokoll aufgezeichnet. Sieh nun also nach, ob das Server-Anwendungsprotokoll Einträge enthält. Falls nein, dann kommt der Client bsp. aufgrund einer Firewall nicht an den Server heran.

 

-----------

Gruß, Auer

[Irgendware 10]

In dem Anwendungungsprotokoll sammeln sich Meldungen für erfolgreiche Logins von lokal abgelegten ASP.Net Seiten und den Sharepoint Team Services.

 

Ich habe gerade mal den SQL Server auch auf meinen Rechner hier installiert, ich bin mit T-Online drin und der Server steht in der Uni. Wenn ich nun von hier aus Versuche mit dem Enterprise Manager auf den Server in der Uni eine Verbindung aufzubauen schlägt dieses auch fehl und es gibt keinen Eintrag ins Protokoll!

 

Ich kann aber mit Telnet auf Port 1433 Verbindungen öffnen, wenn ich das tue gibt es aber auch keinen Protokolleintrag. Da auf dem Server und hier keine Firewall läuft, kann es nicht das Problem sein, dass er keine Verbindung aufbauen kann.

 

Meine Vermutung ist, dass der Server die Verbindung entweder verweigert oder die SQL-Benutzer nur Rechte haben von localhost aus Verbindungen aufzubauen und nicht von außen (wüsste aber auch nicht, wo man sowas einstellen könnte, kenne ich nur von MySQL).

 

Für letzeres Spricht auch, dass mir die Verbindung verweigert wird, wenn ich bei den lokalen ASP.Net Anwendungen anstatt localhost die Domain eintrage.

[auer 10]

Wenn ich nun von hier aus Versuche mit dem Enterprise Manager auf den Server in der Uni eine Verbindung aufzubauen schlägt dieses auch fehl und es gibt keinen Eintrag ins Protokoll!

 

Wenn es keinen Eintrag ins Protokoll gibt, dann wurde die laufende Instanz aufgrund der Netzwerktopologie nicht gefunden. Da genügt ein Router dazwischen, der die Ports sperrt, dies müssen Client und Server nicht selbst leisten.

 

Ich kann aber mit Telnet auf Port 1433 Verbindungen öffnen, wenn ich das tue gibt es aber auch keinen Protokolleintrag.

 

Wie soll ein Anmeldeversuch protokolliert werden, wenn über Telnet zugegriffen wird? Telnet ist doch kein gültiger Sql-Client, sondern spricht den Port bloß auf TCP-Ebene an? Mache denselben Versuch mit OSQL.Exe aus einer DosBox.

 

Meine Vermutung ist, dass der Server die Verbindung entweder verweigert oder die SQL-Benutzer nur Rechte haben von localhost aus Verbindungen aufzubauen und nicht von außen.

 

Dies ist definitiv falsch. Die Sql-Authentifizierung ermöglicht es ja gerade, unabhängig von der NT-Umgebung bsp. von den USA auf einen Rechner in Australien zuzugreifen.

 

Für letzeres Spricht auch, dass mir die Verbindung verweigert wird, wenn ich bei den lokalen ASP.Net Anwendungen anstatt localhost die Domain eintrage.

Gibt es für diese Fälle einen Eintrag im Anwendungsprotokoll?

 

Bei benannten Instanzen wird die Angelegenheit noch komplizierter, da man für diese den UDP 1434 und einen weiteren TCP-Port benötigt.

 

[Edit] Welche Fehlermeldung erhälst Du en detail beim Versuch, per OSQL auf den Server zuzugreifen?

 

------------------

Gruß, Auer

[Irgendware 10]

OK, ich habe jetzt fest gestellt, dass ich einen Fehler in der Clientconfiguration auf dem Server hatte, beim rumprobieren woran es denn nun liegen könnte hatte ich ein Alias für Named Pipes eingerichtet, das ist nun weg.

 

oSQL -S dotnet-infrared.de\Sharepoint -U ... -P ...

funktioniert nun local (vorher ging nur localhost\Sharepoint), das Ereginisprotokoll meldet dann auch den Erfolg

 

Von außen gehts aber weiterhin nicht. (Kein Eintrag im Ereignisprotokoll)

 

Könnte es damit zusammenhängen, dass ich bei der Einrichtung des Servers zuerst die MSDE2000 installiert habe (wegen Sharepoint) und dann auf den SQL Server upgedated habe? War vielleicht die abgespeckte MSDE für externe Zugriffe nicht vorgesehen und die Einstellung ist nach dem Update nicht geändert worden?

 

Edit: Die oSQL Fehlermeldung lauet

[DBNETLIB]SQL Server existiert nicht oder Zugriff verweigert.

[DBNETLIB]ConnectionOpen (Connect()).

 

Fehlgeschlagene Logins tauchen im Ereignisprotokoll übrigens auf, wenn ich sie lokal vom Server ausführe (z.B. mit falschem Passwort), von außen aber nicht

[auer 10]

Von außen gehts aber weiterhin nicht. (Kein Eintrag im Ereignisprotokoll)

Dies ist das, was ich nicht verstehe. Offenbar erreichst Du von außen die Instanz nicht, denn würdest Du sie erreichen und wären bsp. Nutzer und / oder PWD falsch, so würde dies protokolliert werden.

 

Ob MSDE oder die große Engine - dies dürfte keine Rolle spielen.

 

Die Fehlermeldung kommt nicht vom Sql-Server, sondern von der vorgeschalteten Netzbibliothek. Sql-Fehlermeldungen wären bsp. 'Fehler bei der Anmeldung von ...', soweit kommst Du aber gar nicht.

 

Probier mal noch folgendes: Rufe svrnetcn.exe auf, das Tool für die serverseitige Netzwerkkommunikation. Da bei dir keine unbenannte Instanz läuft, setze die benannte Instanz auf 1433 und starte den Server neu. Klar ist, daß die Option 'Server ausblenden' nicht gesetzt sein darf.

 

-------------

Gruß, Auer

[Irgendware 10]

Ich habe die Änderungen durchgeführt, allerdings hat sich nicht geändert. Jetzt habe ich aber die Möglichkeit ohne Angabe einer Instanz immerhin eine andere Fehlermeldung zu bekommen:

 

[DBNETLIB]Ungültige Verbindung.

[DBNETLIB]ConnectionOpen (Invalid Instance()).

 

Das Ereignisprotokoll meldet dann:

18454 :

Login succeeded for user 'Irgendware'. Connection: Non-Trusted.

 

Mit Instanz erhalte ich aber weiterhin die alte Fehlermeldung.

 

Ich schreibe auch mal in die MS Newsgroups, vielleicht hat jemand anders dort das Problem auch schon mal gehabt.

[auer 10]

Bei Microsoft habe ich einen Hinweis gefunden, daß die Fehlermeldung '[DBNETLIB]SQL Server existiert nicht oder Zugriff verweigert.' auch dann auftritt, falls nur die NT-Authentifizierung erlaubt ist. Sieh 'sicherheitshalber' nach, ob unter HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server\Instance Name\MSSQLServer\ der Schlüssel LoginMode den Wert 2 hat - 1 steht für den reinen NT-Modus.

 

Den 'Fehler' 18454 kapiere ich überhaupt nicht. Denn dieser besagt, daß Du dich erfolgreich über eine SQL-Authentifizierung angemeldet hast. Es handelt sich um 'Fehler', denen einfach Einträge in der sysmessages-Tabelle zugrunde liegen, Connection: Non-Trusted heißt gerade eine nicht vertraute Verbindung, 18454 ist die eigentlich erhoffte Erfolgsmeldung.

 

Meldest Du dich mit OSQL an einem SQL-Server an und schickst eine Sql-Anweisung Select description from master.dbo.sysmessages where error = 18454 ab, so erhälst Du den obigen Ausgabetext.

 

Versuch: Definiere dir über Systemsteuerung - ODBC-Datenquellen eine Systemdatenquelle, die den Sql-Server verwendet. Lass bei den Optionen möglichst viel weg, insbesondere darf Sprache nicht auf Deutsch sein, falls bloß Englisch installiert ist. Und auch dort gibt es nochmals einen Punkt 'strong encryption'.

 

Oder versuche, von einem direkt auf dem Server liegenden Script auf den Sql-Server zuzugreifen, das TRUSTED_CONNECTION=NO;User ID=...;PWD=...; enthält, das also explizit den Sql-Modus nutzt.

 

-------------

Gruß, Auer

[Irgendware 10]

Hallo, da das auch nicht geklappt hat, habe ich jetzt einfach eine weitere Instanz erstellt, mit der es super funktioniert.

 

Trotzdem vielen Dank für die Hilfe und deine Zeit für die zahlreichen Überlegungen. Ich werde mir den Thread auf jeden Fall für zukünftiges Troubleshooting abspeichern.

[auer 10]

Stimmt - da läuft jetzt eine Instanz. Hoffe nur, daß Dir die niemand hackt - habe mich grade im Log eingetragen - per 'korrekter Fehlermeldung 18456'.

 

------------

Gruß, Auer