12
Terminalserver Anmeldung Herunterfahren verhindern
Durch eine "schrottige" Softare versuche ich folgenden Schritt:
Hallo zusammen, ich habe ein kleines Dilemma oder bin einfach zu unwissend.
Deshalb möchte ich dir Frage an Euch stellen:
FAKTEN:
- Eine Software mit MS SQL 2000 Datenbank läuft auf einem virtualisierten Windows XP.
Das OS ist nur aufgrund dieser Software aufgesetzt worden.
- Mitarbeiter der Firma sitzen mehrere 100Km verteilt in Deutschland.
- Wir lassen sie mittels MSTSC auf einem Terminalserver arbeiten.
- Zugriff auf die Datenbank haben die Nutzer nur unter zwei Bedingungen:
a) Sie haben Domänen-Admin Rechte, oder
b) Ich richte die User über SQL Server Management Studio Express auf dem SQL-Server ein
Komischerweise haben alle Anwender, die im lokalen Netzwerk arbeiten Zugriff auf die Software, sprich der DB-Connect funktioniert.
Wenn ich mich via Terminalanmeldung einlogge, bekomme ich eine Zugriffsverweigerungsmeldung. Ich darf nicht auf den SQL-Server connecten.
Die User habe ich alle im SQL-Studio eingetragen und auch alle Rechte vergeben.
Der Connect kommt dennoch nicht zustande. Gebe ich ihnen Domänen-Admin Rechte, funktioniert der Connect.
Meine Lösung wäre den Usern Domänen-Admin Rechte zu vergeben und mittels einer von mir erstellten GPO das Herunterfahren des Server zu verhindern. Immerhin könnten die User dann ja den Server herunterfahren. Das wäre nicht gut =)
Ich habe hier unter administrator.de einige Lösungsvorschläge gefunden (siehe Loopback etc...).
ABER: Kann es sein, dass keinerlei Policy anzieht, sprich der Herunterfahren Knopf immer da ist, weil die Anwender über Domänen-Admin Rechte verfügen?
Habt ihr sonst eine Lösung?
Ich bedanke mich im Voraus fürs Lesen und für evtl. Hilfe!
Grüße
Vince
Hallo zusammen, ich habe ein kleines Dilemma oder bin einfach zu unwissend.
Deshalb möchte ich dir Frage an Euch stellen:
FAKTEN:
- Eine Software mit MS SQL 2000 Datenbank läuft auf einem virtualisierten Windows XP.
Das OS ist nur aufgrund dieser Software aufgesetzt worden.
- Mitarbeiter der Firma sitzen mehrere 100Km verteilt in Deutschland.
- Wir lassen sie mittels MSTSC auf einem Terminalserver arbeiten.
- Zugriff auf die Datenbank haben die Nutzer nur unter zwei Bedingungen:
a) Sie haben Domänen-Admin Rechte, oder
b) Ich richte die User über SQL Server Management Studio Express auf dem SQL-Server ein
Komischerweise haben alle Anwender, die im lokalen Netzwerk arbeiten Zugriff auf die Software, sprich der DB-Connect funktioniert.
Wenn ich mich via Terminalanmeldung einlogge, bekomme ich eine Zugriffsverweigerungsmeldung. Ich darf nicht auf den SQL-Server connecten.
Die User habe ich alle im SQL-Studio eingetragen und auch alle Rechte vergeben.
Der Connect kommt dennoch nicht zustande. Gebe ich ihnen Domänen-Admin Rechte, funktioniert der Connect.
Meine Lösung wäre den Usern Domänen-Admin Rechte zu vergeben und mittels einer von mir erstellten GPO das Herunterfahren des Server zu verhindern. Immerhin könnten die User dann ja den Server herunterfahren. Das wäre nicht gut =)
Ich habe hier unter administrator.de einige Lösungsvorschläge gefunden (siehe Loopback etc...).
ABER: Kann es sein, dass keinerlei Policy anzieht, sprich der Herunterfahren Knopf immer da ist, weil die Anwender über Domänen-Admin Rechte verfügen?
Habt ihr sonst eine Lösung?
Ich bedanke mich im Voraus fürs Lesen und für evtl. Hilfe!
Grüße
Vince
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 127120
Url: https://administrator.de/contentid/127120
Ausgedruckt am: 22.11.2024 um 12:11 Uhr
12 Kommentare
Neuester Kommentar
Hallo,
das mit den Domänenadmin-Rechten würde ich nicht machen. Besser wäre wohl den Fehler der fehlgeschlagenen Anmeldung beim SQL-Server zu suchen.
Was steht den in den SQL-Server Protokollen wenn die Anmeldung fehlschlägt?
Gruß
Tom
das mit den Domänenadmin-Rechten würde ich nicht machen. Besser wäre wohl den Fehler der fehlgeschlagenen Anmeldung beim SQL-Server zu suchen.
Was steht den in den SQL-Server Protokollen wenn die Anmeldung fehlschlägt?
Gruß
Tom
Servus Tommy,
meinst du die Logs im Ordner "C:\Programme\Microsoft SQL Server\MSSQL\LOG"?
Übrigens steht im MS SQL Server Management Studio Express: "NAMEDERDATENBANK (SQL Server 8.0.760) Falls das noch was hilft...
Fehlermeldung beim Aufruf der Software: "[DBNETLIB][ConnectionOpen (Connect()).]SQL Server existiert nicht oder Zugriff verweigert."
Danke für deine Antwort!
meinst du die Logs im Ordner "C:\Programme\Microsoft SQL Server\MSSQL\LOG"?
Übrigens steht im MS SQL Server Management Studio Express: "NAMEDERDATENBANK (SQL Server 8.0.760) Falls das noch was hilft...
Fehlermeldung beim Aufruf der Software: "[DBNETLIB][ConnectionOpen (Connect()).]SQL Server existiert nicht oder Zugriff verweigert."
Danke für deine Antwort!
Habs LOG gefunden, stht glaub nichts wildes drin, oder?
Hier mal das letzte:
2009-10-14 03:37:11.51 server Microsoft SQL Server 2000 - 8.00.760 (Intel X86)
Dec 17 2002 14:22:05
Copyright (c) 1988-2003 Microsoft Corporation
Desktop Engine on Windows NT 5.1 (Build 2600: Service Pack 3)
2009-10-14 03:37:11.54 server Copyright (C) 1988-2002 Microsoft Corporation.
2009-10-14 03:37:11.54 server Alle Rechte vorbehalten.
2009-10-14 03:37:11.54 server Serverprozess-ID ist 1676.
2009-10-14 03:37:11.54 server Protokolliert SQL Server-Meldungen in Datei 'C:\Programme\Microsoft SQL Server\MSSQL\LOG\ERRORLOG'.
2009-10-14 03:37:11.57 server SQL Server startet mit Prioritätsklasse 'normal' (1 CPU vorgefunden).
2009-10-14 03:37:12.46 server SQL Server wurde für die Verarbeitung im thread-Modus konfiguriert.
2009-10-14 03:37:12.48 server Die dynamic-Sperrenreservierung wird verwendet. [500] Sperrenblöcke, [1000] Sperrenbesitzerblöcke.
2009-10-14 03:37:12.67 spid3 Startet Datenbank 'master'.
2009-10-14 03:37:13.09 server Verwendet 'SSNETLIB.DLL', Version '8.0.766'.
2009-10-14 03:37:13.13 spid5 Startet Datenbank 'model'.
2009-10-14 03:37:13.17 spid3 Servername ist 'XxXx'.
2009-10-14 03:37:13.17 spid3 Skipping startup of clean database id 4
2009-10-14 03:37:13.17 spid3 Skipping startup of clean database id 5
2009-10-14 03:37:13.20 server SQL Server überwacht 192.168.0.5: 1433.
2009-10-14 03:37:13.20 server SQL Server überwacht 127.0.0.1: 1433.
2009-10-14 03:37:13.29 server SQL Server überwacht TCP, Shared Memory, Named Pipes.
2009-10-14 03:37:13.29 server SQL Server ist bereit für Clientverbindungen
2009-10-14 03:37:13.29 spid5 Löscht tempdb-Datenbank.
2009-10-14 03:37:13.98 spid5 Startet Datenbank 'tempdb'.
2009-10-14 03:37:14.10 spid3 Wiederherstellung abgeschlossen.
2009-10-14 03:37:14.10 spid3 SQL global counter collection task is created.
2009-10-14 10:03:44.69 spid51 'xpstar.dll', Version '2000.80.760', wird verwendet, um die erweiterte gespeicherte Prozedur 'sp_MSgetversion' auszuführen.
2009-10-14 10:03:45.12 spid51 Startet Datenbank 'XxXx'.
2009-10-14 10:03:45.30 spid51 Startet Datenbank 'msdb'.
2009-10-14 10:14:28.31 spid51 Startet Datenbank 'XxXx'.
2009-10-14 10:14:47.90 spid51 Startet Datenbank 'XxXx'.
2009-10-14 10:14:48.73 spid51 Startet Datenbank 'XxXx'.
2009-10-14 10:14:48.85 spid51 Startet Datenbank 'XxXx'.
2009-10-14 10:14:49.08 spid51 Startet Datenbank 'XxXx'.
2009-10-14 10:15:19.19 spid52 Startet Datenbank 'XxXx'.
2009-10-14 10:15:38.59 spid52 Startet Datenbank 'XxXx'.
2009-10-14 10:15:38.68 spid52 Startet Datenbank 'XxXx'.
2009-10-14 10:15:38.82 spid52 Startet Datenbank 'XxXx'.
2009-10-14 10:16:18.24 spid52 'xplog70.dll', Version '2000.80.760', wird verwendet, um die erweiterte gespeicherte Prozedur 'xp_msver' auszuführen.
2009-10-14 10:17:38.99 spid51 Startet Datenbank 'XxXx'.
2009-10-14 10:17:43.04 spid51 Startet Datenbank 'XxXx'.
2009-10-14 10:17:43.24 spid51 Startet Datenbank 'XxXx'.
2009-10-14 10:17:43.38 spid51 Startet Datenbank 'XxXx'.
2009-10-14 10:18:02.03 spid52 Startet Datenbank 'XxXx'.
2009-10-14 10:29:28.94 spid52 Startet Datenbank 'XxXx'.
2009-10-14 10:56:01.16 spid52 Startet Datenbank 'XxXx'.
2009-10-14 17:08:51.81 spid3 Aufgrund der Stop-Anforderung des Dienstkontroll-Managers wird SQL Server beendet.
Hier mal das letzte:
2009-10-14 03:37:11.51 server Microsoft SQL Server 2000 - 8.00.760 (Intel X86)
Dec 17 2002 14:22:05
Copyright (c) 1988-2003 Microsoft Corporation
Desktop Engine on Windows NT 5.1 (Build 2600: Service Pack 3)
2009-10-14 03:37:11.54 server Copyright (C) 1988-2002 Microsoft Corporation.
2009-10-14 03:37:11.54 server Alle Rechte vorbehalten.
2009-10-14 03:37:11.54 server Serverprozess-ID ist 1676.
2009-10-14 03:37:11.54 server Protokolliert SQL Server-Meldungen in Datei 'C:\Programme\Microsoft SQL Server\MSSQL\LOG\ERRORLOG'.
2009-10-14 03:37:11.57 server SQL Server startet mit Prioritätsklasse 'normal' (1 CPU vorgefunden).
2009-10-14 03:37:12.46 server SQL Server wurde für die Verarbeitung im thread-Modus konfiguriert.
2009-10-14 03:37:12.48 server Die dynamic-Sperrenreservierung wird verwendet. [500] Sperrenblöcke, [1000] Sperrenbesitzerblöcke.
2009-10-14 03:37:12.67 spid3 Startet Datenbank 'master'.
2009-10-14 03:37:13.09 server Verwendet 'SSNETLIB.DLL', Version '8.0.766'.
2009-10-14 03:37:13.13 spid5 Startet Datenbank 'model'.
2009-10-14 03:37:13.17 spid3 Servername ist 'XxXx'.
2009-10-14 03:37:13.17 spid3 Skipping startup of clean database id 4
2009-10-14 03:37:13.17 spid3 Skipping startup of clean database id 5
2009-10-14 03:37:13.20 server SQL Server überwacht 192.168.0.5: 1433.
2009-10-14 03:37:13.20 server SQL Server überwacht 127.0.0.1: 1433.
2009-10-14 03:37:13.29 server SQL Server überwacht TCP, Shared Memory, Named Pipes.
2009-10-14 03:37:13.29 server SQL Server ist bereit für Clientverbindungen
2009-10-14 03:37:13.29 spid5 Löscht tempdb-Datenbank.
2009-10-14 03:37:13.98 spid5 Startet Datenbank 'tempdb'.
2009-10-14 03:37:14.10 spid3 Wiederherstellung abgeschlossen.
2009-10-14 03:37:14.10 spid3 SQL global counter collection task is created.
2009-10-14 10:03:44.69 spid51 'xpstar.dll', Version '2000.80.760', wird verwendet, um die erweiterte gespeicherte Prozedur 'sp_MSgetversion' auszuführen.
2009-10-14 10:03:45.12 spid51 Startet Datenbank 'XxXx'.
2009-10-14 10:03:45.30 spid51 Startet Datenbank 'msdb'.
2009-10-14 10:14:28.31 spid51 Startet Datenbank 'XxXx'.
2009-10-14 10:14:47.90 spid51 Startet Datenbank 'XxXx'.
2009-10-14 10:14:48.73 spid51 Startet Datenbank 'XxXx'.
2009-10-14 10:14:48.85 spid51 Startet Datenbank 'XxXx'.
2009-10-14 10:14:49.08 spid51 Startet Datenbank 'XxXx'.
2009-10-14 10:15:19.19 spid52 Startet Datenbank 'XxXx'.
2009-10-14 10:15:38.59 spid52 Startet Datenbank 'XxXx'.
2009-10-14 10:15:38.68 spid52 Startet Datenbank 'XxXx'.
2009-10-14 10:15:38.82 spid52 Startet Datenbank 'XxXx'.
2009-10-14 10:16:18.24 spid52 'xplog70.dll', Version '2000.80.760', wird verwendet, um die erweiterte gespeicherte Prozedur 'xp_msver' auszuführen.
2009-10-14 10:17:38.99 spid51 Startet Datenbank 'XxXx'.
2009-10-14 10:17:43.04 spid51 Startet Datenbank 'XxXx'.
2009-10-14 10:17:43.24 spid51 Startet Datenbank 'XxXx'.
2009-10-14 10:17:43.38 spid51 Startet Datenbank 'XxXx'.
2009-10-14 10:18:02.03 spid52 Startet Datenbank 'XxXx'.
2009-10-14 10:29:28.94 spid52 Startet Datenbank 'XxXx'.
2009-10-14 10:56:01.16 spid52 Startet Datenbank 'XxXx'.
2009-10-14 17:08:51.81 spid3 Aufgrund der Stop-Anforderung des Dienstkontroll-Managers wird SQL Server beendet.
Moin,
Dir ist aber bekannt, das XP nur 10 gleichzeitige Zugriffe zulässt, hast Du da mal gezählt?
Gruß
24
Dir ist aber bekannt, das XP nur 10 gleichzeitige Zugriffe zulässt, hast Du da mal gezählt?
Gruß
24
Guten Morgen
Wurde in diesem Zeitraum mal eine Anmeldung versucht die fehlschlug?
Gruß
Tom
Moin:
FAKTEN:
[Quote]
Meine Lösung wäre den Usern Domänen-Admin Rechte zu vergeben und mittels einer von mir erstellten GPO das Herunterfahren des Server zu verhindern. Immerhin könnten die User dann ja den Server herunterfahren. Das wäre nicht gut =)
[/quote]
Und wie fährt der Domänen-Admin den Server dann runter? (Z.B. Reboot wg. Win-Updates,...)
[quote]
Eine Software mit MS SQL 2000 Datenbank läuft auf einem virtualisierten Windows XP.
Das OS ist nur aufgrund dieser Software aufgesetzt worden.
[/quote]
Wie kommt man eigentlich auf die Idee einen SQL-Server auf nem XP zu installieren? Sorry, aber ich fahre nen Mopped mit 98 PS - würdest du auf die Idee kommen diesen Motor in ne Mofa zu bauen? (bzw. umgekehrt - nen Mofa-Motor in nen Motorrad wo nen 1000ccm-Motor reingehört?)
Hier würde ich den SQL-Server schnell wieder runternehmen und den auf nem richtigen Server-OS installieren... Dieses auch nicht virtuell - sondern dem DB-Server schon ne eigene Maschine geben. Ist nicht sooo prickelnd wenn du ne grössere Abfrage machst o.ä. -> und die Festplatte grade vom User auf dem TS belastet wird weil der meint er möchte mal seine 200 GB-Porno-Filme von einen Ordner in nen anderen kopieren...
[quote]
Zugriff auf die Datenbank haben die Nutzer nur unter zwei Bedingungen:
a) Sie haben Domänen-Admin Rechte, oder
b) Ich richte die User über SQL Server Management Studio Express auf dem SQL-Server ein
[/quote]
Haben die User bei dir einen DIREKTEN Zugriff auf den DB-Server? Ohne Front-End - notfalls auch MS-Access mit entsprechend vorbereiteten Formularen? D.h. die können da praktisch jeden Müll reinpacken -> Fatal Error...
Meine Lösung: Du holst dir nen kleinen Server für den SQL-Server und überträgst die DB dahin. Dann holst du dir nen paar Lizenzen für Access (oder nen anderes Front-End, du kannst es wahlweise natürlich auch selbst schreiben!) und haust das auf deinen Terminal-Server. Die USER bekommen da auch keine Admin-Rechte (super - du hast nicht nur 200 GB Porno-Filme sondern auch den passenden Codec und nen FTP-Server weil der Mitarbeiter X gerne von zuhause darauf zugreiffen will und der Nachbarsjunge das eben schnell eingerichtetet hat...) - der User hat nur Benutzerrechte. Er kann also nur die vorhandenen Programme - inkl. deines Frontends - nutzen. Spendirst du jetzt deiner DB noch nen User-Feld dann kannst du über den Front-End-Anmeldenamen des Users auch immer schön mitspeichern wer welche Einträge gemacht/modifiziert hat -> ohne das der User da irgendwas dran machen kann...
Danach lehnst du dich entspannt zurück und genießt die ruhe und die entspannung weil du keine Angst haben muss das irgendwer der User das Admin-PW weitergibt bzw. sich da mit User Hans, PW Hans anmeldet...
FAKTEN:
[Quote]
Meine Lösung wäre den Usern Domänen-Admin Rechte zu vergeben und mittels einer von mir erstellten GPO das Herunterfahren des Server zu verhindern. Immerhin könnten die User dann ja den Server herunterfahren. Das wäre nicht gut =)
[/quote]
Und wie fährt der Domänen-Admin den Server dann runter? (Z.B. Reboot wg. Win-Updates,...)
[quote]
Eine Software mit MS SQL 2000 Datenbank läuft auf einem virtualisierten Windows XP.
Das OS ist nur aufgrund dieser Software aufgesetzt worden.
[/quote]
Wie kommt man eigentlich auf die Idee einen SQL-Server auf nem XP zu installieren? Sorry, aber ich fahre nen Mopped mit 98 PS - würdest du auf die Idee kommen diesen Motor in ne Mofa zu bauen? (bzw. umgekehrt - nen Mofa-Motor in nen Motorrad wo nen 1000ccm-Motor reingehört?)
Hier würde ich den SQL-Server schnell wieder runternehmen und den auf nem richtigen Server-OS installieren... Dieses auch nicht virtuell - sondern dem DB-Server schon ne eigene Maschine geben. Ist nicht sooo prickelnd wenn du ne grössere Abfrage machst o.ä. -> und die Festplatte grade vom User auf dem TS belastet wird weil der meint er möchte mal seine 200 GB-Porno-Filme von einen Ordner in nen anderen kopieren...
[quote]
Zugriff auf die Datenbank haben die Nutzer nur unter zwei Bedingungen:
a) Sie haben Domänen-Admin Rechte, oder
b) Ich richte die User über SQL Server Management Studio Express auf dem SQL-Server ein
[/quote]
Haben die User bei dir einen DIREKTEN Zugriff auf den DB-Server? Ohne Front-End - notfalls auch MS-Access mit entsprechend vorbereiteten Formularen? D.h. die können da praktisch jeden Müll reinpacken -> Fatal Error...
Meine Lösung: Du holst dir nen kleinen Server für den SQL-Server und überträgst die DB dahin. Dann holst du dir nen paar Lizenzen für Access (oder nen anderes Front-End, du kannst es wahlweise natürlich auch selbst schreiben!) und haust das auf deinen Terminal-Server. Die USER bekommen da auch keine Admin-Rechte (super - du hast nicht nur 200 GB Porno-Filme sondern auch den passenden Codec und nen FTP-Server weil der Mitarbeiter X gerne von zuhause darauf zugreiffen will und der Nachbarsjunge das eben schnell eingerichtetet hat...) - der User hat nur Benutzerrechte. Er kann also nur die vorhandenen Programme - inkl. deines Frontends - nutzen. Spendirst du jetzt deiner DB noch nen User-Feld dann kannst du über den Front-End-Anmeldenamen des Users auch immer schön mitspeichern wer welche Einträge gemacht/modifiziert hat -> ohne das der User da irgendwas dran machen kann...
Danach lehnst du dich entspannt zurück und genießt die ruhe und die entspannung weil du keine Angst haben muss das irgendwer der User das Admin-PW weitergibt bzw. sich da mit User Hans, PW Hans anmeldet...
Servus zusammen... Hm... mal der Reihe nach:
1.) 2hard4you: Wie meinst du das mit 10 Connections gleichzeitig? Die Software ist noch nicht im produktiven Einsatz, ich teste gerade noch. Also können sich 10 User bisher nicht connectet haben. Wenn überhaupt warens max 3 gleichzeitig. Oder wie meinst du das genau?
2.) Tommy70: Ja, das Log ist aus einem Zeitraum, indem ich versucht habe das Programm zu starten
3.) maretz: Das ist nicht so einfach. Die Software ist nicht nur deshalb von mir als "schrottig" bezeichnet worden, weil mir danach stand. Sie ist es definitiv. Sie läuft max auf einem Server 2003 (Und die SW ist NEU!!!). Da wir einen Server 2008 laufen haben, hab ich ne XP Maschine virtualisiert (war das kostengünstigste, da Lizenz vorhanden). Das Programm ist kein Access oder dergleichen, sondern eine Bauträgersoftware, die eben MS SQL als Datenbank nutzt. Am Programm kann ich nichts rumschrauben, es wurde mir auf den Tisch geknallt und die wird auch definitiv benutzt. Ich muss also so zurecht kommen.
Ich sehs ein, keine Dom-Admin-Rechte zu vergeben (war mir eh nicht wohl). Also müssen wir, wie Tommy ganz oben schon schrieb, dem Problem auf die Schliche kommen.
Das Programm ist auf der XP-Maschine ganz normal installiert. Die Installation selbst hat dann auch den SQL-Server installiert. Ich selbst habe lediglich das Microsoft tool nachinstalliert um die DB verwalten zu können. Alle Anwender greifen auf die Start EXE-Datei zu, die auf dem Server liegt. Das Programm läuft also auf dem Server. Man kann es auch lokal installieren, das hab ich bei ein paar Usern der Performace wegen gemacht. Zugriff haben sie ob so oder so.
Jetzt kommen meine in Deutschland verteilten Mitarbeiter, die sich per Terminal an dem Server anmelden. Diese bekommen den Zugriff-Verweigert Status auf dem SQL-Server.
Ich hab was gelesen, dass man ind er registry den SQL-Log auf "verbose" stellen kann. Der Regeintrag war bei mir aber nicht vorhanden.
Sonst noch Tipps und Fragen an mich?
Wäre lieb... ich weiß echt nimmer weiter...
Grüße vom
Vince
1.) 2hard4you: Wie meinst du das mit 10 Connections gleichzeitig? Die Software ist noch nicht im produktiven Einsatz, ich teste gerade noch. Also können sich 10 User bisher nicht connectet haben. Wenn überhaupt warens max 3 gleichzeitig. Oder wie meinst du das genau?
2.) Tommy70: Ja, das Log ist aus einem Zeitraum, indem ich versucht habe das Programm zu starten
3.) maretz: Das ist nicht so einfach. Die Software ist nicht nur deshalb von mir als "schrottig" bezeichnet worden, weil mir danach stand. Sie ist es definitiv. Sie läuft max auf einem Server 2003 (Und die SW ist NEU!!!). Da wir einen Server 2008 laufen haben, hab ich ne XP Maschine virtualisiert (war das kostengünstigste, da Lizenz vorhanden). Das Programm ist kein Access oder dergleichen, sondern eine Bauträgersoftware, die eben MS SQL als Datenbank nutzt. Am Programm kann ich nichts rumschrauben, es wurde mir auf den Tisch geknallt und die wird auch definitiv benutzt. Ich muss also so zurecht kommen.
Ich sehs ein, keine Dom-Admin-Rechte zu vergeben (war mir eh nicht wohl). Also müssen wir, wie Tommy ganz oben schon schrieb, dem Problem auf die Schliche kommen.
Das Programm ist auf der XP-Maschine ganz normal installiert. Die Installation selbst hat dann auch den SQL-Server installiert. Ich selbst habe lediglich das Microsoft tool nachinstalliert um die DB verwalten zu können. Alle Anwender greifen auf die Start EXE-Datei zu, die auf dem Server liegt. Das Programm läuft also auf dem Server. Man kann es auch lokal installieren, das hab ich bei ein paar Usern der Performace wegen gemacht. Zugriff haben sie ob so oder so.
Jetzt kommen meine in Deutschland verteilten Mitarbeiter, die sich per Terminal an dem Server anmelden. Diese bekommen den Zugriff-Verweigert Status auf dem SQL-Server.
Ich hab was gelesen, dass man ind er registry den SQL-Log auf "verbose" stellen kann. Der Regeintrag war bei mir aber nicht vorhanden.
Sonst noch Tipps und Fragen an mich?
Wäre lieb... ich weiß echt nimmer weiter...
Grüße vom
Vince
Hallo,
da du oben schreibst
Gruß
Tom
da du oben schreibst
Fehlermeldung beim Aufruf der Software: "[DBNETLIB][ConnectionOpen (Connect()).]SQL Server existiert nicht oder Zugriff verweigert."
aber im Log nicht steht von wegen Login failed for user 'test'. [CLIENT: 10.1.0.10] oder ähnliches nehme ich mal an, dass SQL Server existiert nicht das ist wo du weitersuchen musst. Eventuell ein Problem mit der Namensauflösung oder ähnliches.Gruß
Tom
Jo es muss in die Richtung gehen.
Ich habe einen User, nennen wir ihn Herr Müller.
Dieser arbeitet im lokalen Netzwerk (normale Domänenanmeldung), ist also in den Räumlichkeiten vor Ort, in denen auch der Server steht. Sein Programm funktioniert dort.
Wenn ich mich mit ihm in der Terminalsitzung anmelde, funktioniert der Zugriff nicht. Gebe ich ihm domänen Adminrechte gehts.
Im Log ist weiterhin nichts zu sehen (auch nicht der erfolgreiche Connect mit den domänen Adminrechten übrigens...).
Es muss also definitiv an der Berechtigung in der AD liegen, oder? Aber was hat das mit dem lokalen Netz zu tun? Der einzige Unterschied ist, dass ich von einem Terminalserver auf die DB zugreifen will.
Der Terminalserver ist übrigens auch virtualisiert. Und die AD liegt auf einem weiteren Server, der auch virtualisiert ist... falls das wichtig sein sollte...
Anbei nochmals das Log mit meinen Anmeldeversuchen in der Zeit mit und ohne Domänenadmin.
2009-10-14 17:44:28.70 server Microsoft SQL Server 2000 - 8.00.760 (Intel X86)
Dec 17 2002 14:22:05
Copyright (c) 1988-2003 Microsoft Corporation
Desktop Engine on Windows NT 5.1 (Build 2600: Service Pack 3)
2009-10-14 17:44:28.93 server Copyright (C) 1988-2002 Microsoft Corporation.
2009-10-14 17:44:28.93 server Alle Rechte vorbehalten.
2009-10-14 17:44:28.93 server Serverprozess-ID ist 1652.
2009-10-14 17:44:28.95 server Protokolliert SQL Server-Meldungen in Datei 'C:\Programme\Microsoft SQL Server\MSSQL\LOG\ERRORLOG'.
2009-10-14 17:44:28.98 server SQL Server startet mit Prioritätsklasse 'normal' (1 CPU vorgefunden).
2009-10-14 17:44:29.98 server SQL Server wurde für die Verarbeitung im thread-Modus konfiguriert.
2009-10-14 17:44:30.00 server Die dynamic-Sperrenreservierung wird verwendet. [500] Sperrenblöcke, [1000] Sperrenbesitzerblöcke.
2009-10-14 17:44:30.09 spid3 Startet Datenbank 'master'.
2009-10-14 17:44:30.65 server Verwendet 'SSNETLIB.DLL', Version '8.0.766'.
2009-10-14 17:44:30.65 spid5 Startet Datenbank 'model'.
2009-10-14 17:44:30.65 spid3 Servername ist 'XxXxX'.
2009-10-14 17:44:30.65 spid3 Skipping startup of clean database id 4
2009-10-14 17:44:30.70 spid3 Skipping startup of clean database id 5
2009-10-14 17:44:30.76 server SQL Server überwacht 192.168.0.5: 1433.
2009-10-14 17:44:30.76 server SQL Server überwacht 127.0.0.1: 1433.
2009-10-14 17:44:30.84 server SQL Server überwacht TCP, Shared Memory, Named Pipes.
2009-10-14 17:44:30.84 server SQL Server ist bereit für Clientverbindungen
2009-10-14 17:44:30.84 spid5 Löscht tempdb-Datenbank.
2009-10-14 17:44:32.06 spid5 Startet Datenbank 'tempdb'.
2009-10-14 17:44:32.18 spid3 Wiederherstellung abgeschlossen.
2009-10-14 17:44:32.22 spid3 SQL global counter collection task is created.
2009-10-14 17:47:35.39 spid51 Startet Datenbank 'XxXxX'.
2009-10-14 17:48:10.62 spid52 'xpstar.dll', Version '2000.80.760', wird verwendet, um die erweiterte gespeicherte Prozedur 'sp_MSgetversion' auszuführen.
2009-10-14 17:48:10.67 spid52 Startet Datenbank 'XxXxX'.
2009-10-14 17:48:10.72 spid52 Startet Datenbank 'msdb'.
2009-10-14 17:49:20.16 spid51 Startet Datenbank 'XxXxX'.
2009-10-14 17:49:50.99 spid51 Startet Datenbank 'XxXxX'.
2009-10-14 17:57:32.89 spid52 Startet Datenbank 'XxXxX'.
2009-10-15 15:39:09.02 spid51 Startet Datenbank 'XxXxX'.
2009-10-15 15:46:53.52 spid52 Startet Datenbank 'XxXxX'.
2009-10-15 15:48:47.64 spid51 Startet Datenbank 'XxXxX'.
2009-10-15 15:48:47.66 spid51 Startet Datenbank 'XxXxX'.
2009-10-15 15:48:47.67 spid51 Startet Datenbank 'XxXxX'.
2009-10-15 15:48:58.38 spid51 Startet Datenbank 'XxXxX'.
2009-10-15 15:54:31.09 spid51 Startet Datenbank 'XxXxX'.
Ich habe einen User, nennen wir ihn Herr Müller.
Dieser arbeitet im lokalen Netzwerk (normale Domänenanmeldung), ist also in den Räumlichkeiten vor Ort, in denen auch der Server steht. Sein Programm funktioniert dort.
Wenn ich mich mit ihm in der Terminalsitzung anmelde, funktioniert der Zugriff nicht. Gebe ich ihm domänen Adminrechte gehts.
Im Log ist weiterhin nichts zu sehen (auch nicht der erfolgreiche Connect mit den domänen Adminrechten übrigens...).
Es muss also definitiv an der Berechtigung in der AD liegen, oder? Aber was hat das mit dem lokalen Netz zu tun? Der einzige Unterschied ist, dass ich von einem Terminalserver auf die DB zugreifen will.
Der Terminalserver ist übrigens auch virtualisiert. Und die AD liegt auf einem weiteren Server, der auch virtualisiert ist... falls das wichtig sein sollte...
Anbei nochmals das Log mit meinen Anmeldeversuchen in der Zeit mit und ohne Domänenadmin.
2009-10-14 17:44:28.70 server Microsoft SQL Server 2000 - 8.00.760 (Intel X86)
Dec 17 2002 14:22:05
Copyright (c) 1988-2003 Microsoft Corporation
Desktop Engine on Windows NT 5.1 (Build 2600: Service Pack 3)
2009-10-14 17:44:28.93 server Copyright (C) 1988-2002 Microsoft Corporation.
2009-10-14 17:44:28.93 server Alle Rechte vorbehalten.
2009-10-14 17:44:28.93 server Serverprozess-ID ist 1652.
2009-10-14 17:44:28.95 server Protokolliert SQL Server-Meldungen in Datei 'C:\Programme\Microsoft SQL Server\MSSQL\LOG\ERRORLOG'.
2009-10-14 17:44:28.98 server SQL Server startet mit Prioritätsklasse 'normal' (1 CPU vorgefunden).
2009-10-14 17:44:29.98 server SQL Server wurde für die Verarbeitung im thread-Modus konfiguriert.
2009-10-14 17:44:30.00 server Die dynamic-Sperrenreservierung wird verwendet. [500] Sperrenblöcke, [1000] Sperrenbesitzerblöcke.
2009-10-14 17:44:30.09 spid3 Startet Datenbank 'master'.
2009-10-14 17:44:30.65 server Verwendet 'SSNETLIB.DLL', Version '8.0.766'.
2009-10-14 17:44:30.65 spid5 Startet Datenbank 'model'.
2009-10-14 17:44:30.65 spid3 Servername ist 'XxXxX'.
2009-10-14 17:44:30.65 spid3 Skipping startup of clean database id 4
2009-10-14 17:44:30.70 spid3 Skipping startup of clean database id 5
2009-10-14 17:44:30.76 server SQL Server überwacht 192.168.0.5: 1433.
2009-10-14 17:44:30.76 server SQL Server überwacht 127.0.0.1: 1433.
2009-10-14 17:44:30.84 server SQL Server überwacht TCP, Shared Memory, Named Pipes.
2009-10-14 17:44:30.84 server SQL Server ist bereit für Clientverbindungen
2009-10-14 17:44:30.84 spid5 Löscht tempdb-Datenbank.
2009-10-14 17:44:32.06 spid5 Startet Datenbank 'tempdb'.
2009-10-14 17:44:32.18 spid3 Wiederherstellung abgeschlossen.
2009-10-14 17:44:32.22 spid3 SQL global counter collection task is created.
2009-10-14 17:47:35.39 spid51 Startet Datenbank 'XxXxX'.
2009-10-14 17:48:10.62 spid52 'xpstar.dll', Version '2000.80.760', wird verwendet, um die erweiterte gespeicherte Prozedur 'sp_MSgetversion' auszuführen.
2009-10-14 17:48:10.67 spid52 Startet Datenbank 'XxXxX'.
2009-10-14 17:48:10.72 spid52 Startet Datenbank 'msdb'.
2009-10-14 17:49:20.16 spid51 Startet Datenbank 'XxXxX'.
2009-10-14 17:49:50.99 spid51 Startet Datenbank 'XxXxX'.
2009-10-14 17:57:32.89 spid52 Startet Datenbank 'XxXxX'.
2009-10-15 15:39:09.02 spid51 Startet Datenbank 'XxXxX'.
2009-10-15 15:46:53.52 spid52 Startet Datenbank 'XxXxX'.
2009-10-15 15:48:47.64 spid51 Startet Datenbank 'XxXxX'.
2009-10-15 15:48:47.66 spid51 Startet Datenbank 'XxXxX'.
2009-10-15 15:48:47.67 spid51 Startet Datenbank 'XxXxX'.
2009-10-15 15:48:58.38 spid51 Startet Datenbank 'XxXxX'.
2009-10-15 15:54:31.09 spid51 Startet Datenbank 'XxXxX'.
Die Bauträger Software hat nur eine MSDE installiert. Nicht einen richtigen, dicken SQL Server. Falls das auch noch nützlich ist.
Diese MSDE steuere ich via der Management Console Studio Express von Microsoft.
Den User der vom Terminal aus auf die XP Maschine zugreift, habe ich auch schon auf dem XP Rechner als User angelegt... keine Besserung...
Grüße
Diese MSDE steuere ich via der Management Console Studio Express von Microsoft.
Den User der vom Terminal aus auf die XP Maschine zugreift, habe ich auch schon auf dem XP Rechner als User angelegt... keine Besserung...
Grüße
Ichhabe eine test.udl auf der Terminalserveranmeldung "kreiert" und die Verbindung zum SQL-Server probiert.
Die Verbindung klappt. Demnach gehe ich davon aus, dass es an den Berechtigungseinstellungen (irgendwas in den GPOs?) vom virtualisierten Terminalserver zum virtualisierten XP-Rechner liegt.
Hat da jemand schon nähere Erfahrungen gemacht?
Vince
Die Verbindung klappt. Demnach gehe ich davon aus, dass es an den Berechtigungseinstellungen (irgendwas in den GPOs?) vom virtualisierten Terminalserver zum virtualisierten XP-Rechner liegt.
Hat da jemand schon nähere Erfahrungen gemacht?
Vince
Für alle dies noch interessiert.
Der Programmierer der Software hat feststellen können, dass bei einer TS-Anmeldung, nicht die richtigen Registryinformationen zum Connect auf die SQL-DB ausgelesen werden.
(Ich vermute, er wusste nicht, dass bei einer TS-Anmeldung jeder User seinen eigenen Registrybereich hat HKCU etc...).
Er hat das Problem umgangen, indem er eine Textdatei erstellt hat, die ins Installationsverzeichnis kopiert werden muss.
Die Textdatei beinhaltet die IP-Adresse des SQL-Server. Somit wird nicht mehr die Registry für den DB-Connect benötigt.
Problem nicht gelöst, aber umgangen.... seeeeehr "elegant" ;)
Thema als "gelöst".
Grüße
Vince
Der Programmierer der Software hat feststellen können, dass bei einer TS-Anmeldung, nicht die richtigen Registryinformationen zum Connect auf die SQL-DB ausgelesen werden.
(Ich vermute, er wusste nicht, dass bei einer TS-Anmeldung jeder User seinen eigenen Registrybereich hat HKCU etc...).
Er hat das Problem umgangen, indem er eine Textdatei erstellt hat, die ins Installationsverzeichnis kopiert werden muss.
Die Textdatei beinhaltet die IP-Adresse des SQL-Server. Somit wird nicht mehr die Registry für den DB-Connect benötigt.
Problem nicht gelöst, aber umgangen.... seeeeehr "elegant" ;)
Thema als "gelöst".
Grüße
Vince
