SQL SQL auf dem Server für den Netzwerk verfügbar machen.

[roker002]

Ich habe ein Problem... Ich will auf meinem Heimserver MS SQL zum Laufen bringen. Das heißt, ich will dass alle Nutzer aus dem Netzwerk auf die Datenbank zugreifen können.
Bin kein Systemadmin deswegen verstehe ich nur wenig was von den ganzen Windows Konten. Zumindest habe ich den SQL Server so eingestellt dass der für den SQL Manager als sichtbare Instanz in der Liste auftaucht. Habe nur dass Problem, dass ich mit meinem Windows Konto, das nicht vom Server selbst, kein Zugriff habe. Ich habe versucht ein Konto zu erstellen aber ich finde "meine" Domain nicht. Ich sehe nur die Domain des Servers (also mit PW Konto... habe versucht auf dem Server zu konfigurieren).

Kann da jemand helfen?

 

[CalvinDeepBlue]

Erstmal was für ein Server ist das (Windows 2008, SBS, HomeServer) ??? Hast Du zuhause eine AD Domäne laufen ??? Was für Client System verwendest Du ???

 

[Rossibaer]

Mit den Windows-Konten hast du das Problem, dass jeder Benutzer eines beliebigen PC dann auch auf dem Server als Konto für SQLServer eingerichtet sein muss. Manch einer verwendet ausschließlich einen SQL-User um mit den Datenbanken auf dem Server zu kommunizieren. Das erspart ne Menge Pflegeaufwand. Evtl. wäre das für dich eine Alternative. Beabsichtigst du auch vom Client aus Stored Procedures auf dem Server zu debuggen? Befinden sich alle User des Netzwerks in einer Domäne oder ist es ein Heimnetzwerk?

 

[roker002]

Ich verwende den Win 7 Pro. Wollte den Server auf dem "Server PC" installieren aber als Heimserver hat es einfach zu viele nachteile, dass nicht alles läuft wie auf einem normalen Windows.

Ich habe noch ein anderes Problem. Sobald ich versuche MS SQL, egal welche Version zu installieren (2005 oder 2008) dann gibt der mir immer komischen Fehlern heraus. Entweder fehlen ein Paar Dateien zur komplette Installation oder die Installation selbst erfolgt nicht... aus "unbekannten" gründen.

Win 7 64 Bit hat doch wohl kein Problem mit AMD Quad Core oder?

Naja einmal hat die Installation geklappt, dann habe ich versucht Visual express 2010 zu installieren und da hat der gar nicht gut da drauf reagiert. Irgendwie waren nach der Installer von Win viele dateien korrupt!

Bin schon dran verzweifelt den SQL Server überhaupt zu installieren.

Wegen dem Login Konto habe ich anders lösen können. Gemischte Authentifizierungsform nehme. Mir reicht das komplett aus. Es werden nie irgendwelche sensiblen Daten drauf abgespeichert.
nicht mehr gewollt.

 

[CalvinDeepBlue]

@rossibaer ... verstehe Eure herangehensweise in der Firma nun wirklich nicht ?!?! Mit der integrierten Windows Authentifizierung legt man eine einfach eine Gruppe im AD an und weist diese dann im SQL Server zu - das "Sicherheitsloch" durch einen einzelnen SQL User kann man ja wohl kaum mit geringem Pflegeaufwand in einklang bringen, wenn ein Konto im AD gesperrt wird ist der Zugriff auf die DB auch abgeriegelt ...

Allerdings scheint beim TE einiges andere im argen zu sein, wenn die Installation schon mit fehlenden Dateien reagiert hat und Visual Studio den SQL Server durcheinander bringt ?!?! Korrupte Downloaddateien ??? Schon mal den Arbeitsspeicher geprüft ??? Und was meinst Du mit deinem ersten Absatz ???

 

[Rossibaer]

@CalvinDeepBlue: Das klingt so toll, wie du das schreibst, jedoch gibt es Kunden die sich - lizenzrechtlich bedenklich - nicht eine entsprechende Lizenz kaufen, wo alle konkurrierenden User der DB abgedeckt sind. Dann bleibt da trotz gutem Zureden nicht viel mehr als nur ein User zu verwenden ... Andere Firmen fahren auch schonmal mehrgleisig, d.h. der Admin fürs AD ist ein Anderer als der für die Datenbanken und wieder ein Anderer als für die Anwendungen. Mal abgesehen von dem Chaos was die Kommunikation betrifft, wirds dann schon recht spassig mal alles unter einen Hut zu bringen.

Stichwort AD, hat das wirklich jeder?! Soll ja auch Netze geben wo der Chef knausrig ist und lieber seine Mitarbeiter mit WinXP Home auf 8 Jahre alten Clients werkeln lässt ohne Domäne etc. einzurichten.

Was ist mit denen die die gesamte Rechtevergabe innerhalb der Anwendung regeln, statt sich auf AD etc. verlassen zu wollen. Was wenn dies ein Designmerkmal der Applikation ist. Kann AD auch innerhalb der Anwendung, die letzten Endes die Datenbank als Backend nutzt, alle Rechte der Anwendung klar regeln?

Und wie sieht es mit dem Löschen eines Accounts im AD aus? Bekommt dann nicht auch die Datenbank Probleme wenn plötzlich Datensätze mit einem Account verknüpft sind der nicht mehr existiert?

Das sind alles Fragen, die mir da durch den Kopf schiessen. Wäre schön wenn du ein paar davon beantworten könntest. Zugegeben mein erster Post war zu kurz geschossen und sicher nicht die beste Wahl dennoch ist es eine Alternative. Warum soll ein User mit einem Passwort eine Sicherheitslücke sein? Das erschließt sich mir nicht ganz. Im Gegenzug habe ich mehrere User mit Passwort. Oder liege ich da falsch?

Im übrigen bin ich wahrscheinlich überfordert, jedoch bekomme ich den SQLServer nicht zum Remotedebuggen von Stored Procedures, wenn mein Windows-Account nicht sysadmin auf dem SQLServer ist. Da reicht es auch nicht aus "nur" einer Gruppe anzugehören die sysadmin ist.

 

[CalvinDeepBlue]

Die lizenzrechtliche Frage diskutiere ich nicht, wenn sich ein Kunde ein entsprechendes Produkt nicht leisten kann und/oder will und dort eine Lösung braucht wird es der Dienstleister/die IT schon hinbiegen oder die lizenztechnisch "unbedenkliche" Variante wählen (soll mir auch nicht soooo fremd sein) ... die Frage mit der mehrgleisigen Administration sehe ich nicht unbedingt als Problem, es sei denn - wie Du schon richtig anmerkst, es an der Kommunikation und ggf. der Rollenverteilung mangelt.

Das mit dem Argument AD in kleinen Netzen sehe ich auch noch ein, jedoch lehne ich solche wie von Dir beschriebene Konstruktionen in Betrieben auch kleinerer größenordnung (XP Home oder Vista Home only im peer betrieb und am besten noch mit Win 98 gemischt) ab, ein SBS z.B. kostet nicht mehr die Welt, und wer solche Systeme in einem Betrieb fährt, spart auch an anderen wirklich kritischen Stellen (z. B. Backup, zentrales Update usw. - ich denke ich weiß ganz gut wovon du sprichst), aber darum ging es mir nicht ...

Die Rechtevergabe stellt in der Tat ein Problem dar und kann sicherlich nicht in allen Kleinigkeiten bis aufs letzte geregelt werden, allerdings ergänzt es die Möglichkeiten und schafft bei einigen Anwendungen (MSBS CRM, NAV usw.) eine erhebliche einfachere Implementierung in den laufenden Betrieb, da dort das Modell im weiteren Verlauf über Rollen innerhalb der Anwendung (und dadurch der DB) geregelt wird. Wenn die Applikation wie von Dir beschrieben ist, liegt es am Design - nicht mehr und nicht weniger.

Ein Löschen oder sperren, des Accounts im AD sollte wohl kaum ohne weiteres auf die DB und die dort hinterlegten Daten "durchschlagen" ... das Design an der Stelle wäre mir auch etwas sagen wir mal "abstrakt" (... löschen mit referentieller Integrität, Account weg - Daten gelöscht) ?!?!

Ich habe auch garnichts gegen deinen Post sagen wollen, sonder nur meine Verwunderung über die "ein DB-User" Variante geäußert ...

Und das einige Funktionen nur für bestimmte Accounts vorgesehen sind und sein sollten spricht nicht gegen meinen Post. Wenn Du als Entwickler stored procedures debuggen musst, solltest du einen Account mit entsprechenden Rechten in der DB haben, für den Regelbetrieb ist der wohl auch nicht zwingend nötig.

Leider erschloß sich aus dem Post des TE nicht wirklich was er dort in seinem Netzwerk installiert hat, was er wie mit dem SQL vorhat und vorher die Probleme kommen könnten, das hat er in seinem zweiten Post ja nachgeholt ...

 

[Rossibaer]

@CalvinDeepBlue:
Vielen Dank für deine ausführliche Antwort. Eins vorweg ich stimme mit Dir überein ... im Grunde freut es mich dass ich mit meiner persönlichen Meinung nicht so ganz falsch liege, da du eben genau das schreibst, was ich mir so denke, wie es sein sollte. Jedoch sieht leider die Realität anders aus und es gibt immer wieder diese "krummen" Praktiken von diversen Kunden, die einem echt das Leben sehr schwer machen und wo man dennoch zum Erfolg verdammt ist. Eine ideale Welt ist nun mal nicht alles bunt zu mixen und mal bißchen hier und bißchen da zu "basteln", sondern statt dessen solide Vorraussetzungen zu schaffen. Aber wie gesagt - in einer idealen Welt.

Allgemein: Deine Antwort habe ich nicht als "Kritik" oder ähnliches wahrgenommen. Erstmal sehe ich das Forum als eine Möglichkeit seine Gedanken mit Gleichgesinnten auszutauschen und zum zweiten sehe ich jeden Post als Grundlage einer Diskussion. Also ist für mich alles "cremig".
______________________________________

@Roker:
Sorry das ich jetzt deinen Thread mal missbraucht hatte um hier abseits von deiner Frage zu antworten. Aber um nochmal auf dein Problem zurückzukommen. Wenn du in deinem Heimnetz an den SQLServer willst, dann würde ich als "Bastellösung" einfach nur ein SQLServer Konto (1 User) verwenden. Wenn es jedoch professionell werden soll, Domäne einrichten, am Client als Domänen-User anmelden und dessen Gruppe zum SQLServer hinzufügen.

Desweiteren kann ich mich erinnern, dass es mit "einfach nur User einrichten" nicht so ohne weiteres getan ist. Zum einen gibt es da noch die Einstellungen welche Protokolle SQLServer verwenden soll/darf (siehe SQL Server Configuration). Da sollte nun TCP/IP aktiviert sein. Ebenso kann eine Firewall auf dem Server oder Client Probleme machen. Hab aber leider den genauen Port nicht parat. Evtl. stört auch nur die windowseigene Firewall. Du könntest aber mal Tcpview.exe von Sysinternals (installationsfrei) auf dem Server ausführen und dann sehen, welcher Port von SQLServer verwendet wird. Das war irgendwas bei 15xx oder 16xx, wenn ich mich noch recht entsinne.

Also viel Erfolg
Rossibaer