Jump to content

Christian81

Members
  • Gesamte Inhalte

    7
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von Christian81

  1. Nein ist sie nicht. Inwiefern kann sowas denn der Grund sein, dass es plötzlich nicht mehr funktioniert ? Es lief ja bisher
  2. Auch mit Domäne\User bekomme ich die Windows EventID 4625 "Unbekannter Benutzername oder ungültiges Kennwort." Als Kontodomäne wird weiterhin die lokale Domäne des Client Rechners aufgewiesen. Jetzt könnte ich natürlich Änderungen in der GPO betreffend der NTLM Einstellungen vornehmen, jedoch frage ich mich, warum dieses Problem plötzlich auftritt. Kann es sein, dass die Fritzbox vor dem VPN Client NTLM nicht korrekt übermittelt ?
  3. Ich stehe vor einem Rätsel. Vorerst die Daten: System 1: Server: Windows Server 2016, geschützt durch Bitdefender. Einziger DC im Netz Router: Fritzbox 7490 (IP Range 192.168.1.xxx) System 2: Windows Rechner ebenfalls hinter einer Fritzbox 7490 (IP Range 192.168.178.xxx) Das Problem: Eine VPN Verbindung wird aus dem System 2 ins System1 mittels Shrewsoft VPN-Client hergestellt. Der Tunnel steht. Möchte man nun Zugriff auf die Netzlaufwerke erhalten, erscheint die Fehlermeldung "Auf \\192.168.1.1 konnte nicht zugegriffen werden. Sie haben eventuell keine Berechtigung diese Nertzwerkressource zu verwenden...." Das merkwürdige an der Geschichte ist, dass es bis dato funktioniert hat. Stelle ich nun eine VPN Verbindung über einen mobilen Access-Point eines Smartphones her, habe ich diese Fehlermeldung nicht und kann normal arbeiten. Die Serverlogs offenbarten mir folgendes: Bei einer Verbindung aus dem Heimnetz mit gescheitertem Anmeldeversuch Bei einer Verbindung über einen mobilen Access Point, die wie gesagt erfolgreich verläuft, bekomme ich bei exakt dem gleichen Prozedere mit den gleichen Login-Daten folgende Meldung: Kann die Lösung des Rätsels so einfach sein, dass ich mich in der Anmeldemaske beim Zugriff auf das Netzlaufwerk mit "Domäne\User" anmelde ? Ich kann es leider nicht direkt jetzt testen. Wenn dem so sei, warum funktionierte es vorher ohne Probleme und wo liegt der Hund begraben ? Das Problem tritt auch auf anderen Rechnern auf, die aus dem gleichen Netz eine VPN Verbindung aufbauen. VPN Verbindungen anderer Benutzer aus anderen Netzwerken sind nicht beeinträchtigt. Dr. House übernehmen Sie. vielen Dank
  4. Die Clients haben sicherheitstechnisch keinerlei Möglichkeit, an die Registry des Servers und somit an die Passwörter der Datenbanken zu kommen. Was uns Kopfschmerzen bereitet ist viel mehr das extrem gespannte Vertrauensverhältnis unserer Firma gegenüber dem Netzadministrator des Kunden. Dieser hat zwar die Weissheit nicht mt Löffeln gefressen, sollte aber in der Lage sein, in unseren Datenbanken herumzupfuschen um unser Ansehen im dortigen Hause zu schädigen. Aber du hast schon recht, dieses Problem haben wir tatsächlich nicht bedacht. Zum damaligen Zeitpunkt fehlte uns einfach das entsprechende Hintergrundwissen. Wir werden nun versuchen, die Datenbanken direkt über die Programme ohne ODBC-Treiber anzusprechen. Gruß, Christian
  5. Hallo Auer, erstmal Danke für deine Antwort. Das Szenario sieht wie folgt aus. Auf einem Server eines Kunden sind ODBC-Verbindungen eingerichtet. Auf demselben Server laufen Programme (Coldfusion, Autodesk MapGuide Server), die auf diese ODBC-Verbindungen intern zurückgreifen. Daher kann ich leider nix am Connection-String ändern. Da die ODBC-Verbindungen auf unsere Datenbanken verweisen, die beim Kunden installiert sind, ist nun die Angst groß, das sich dort jemand an denselben vergreift. Scheint, als wären wir in den Hintern gekniffen... Gruß, Christian
  6. Hallo, mit Erschrecken musste ich heute nach einem Ausflug durch die Registry feststellen, das Passwörter für Datenbanken, die über ODBC-Verbindungen angesprochen werden, im Klartext dort abgelegt sind. [HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\ODBC-Verbindungsname] Gibt es eine Möglichkeit, dieses Verhalten zu ändern? Mfg, Christian
  7. Hallo zusammen, ich habe ein Problem mit einem Drucker (HP Dj 840C). Dieser ist an eine W2K-Workstation in unserer Windows 2000 Domäne angeschlossen und auch die Freigabe im Netz erfolgt durch diese Workstation. Nun möchte ich diesen Drucker von einer XP-Prof Workstation aus nutzen. Ich kann den Drucker ohne Probleme einrichten, der Status sagt mir "Bereit". Schicke ich jedoch eine Testseite oder beliebige andere Druckaufträge los verschwinden diese im Nirvana. Der Drucker rührt sich nicht und es werden weder auf dem XP-Rechner noch auf dem W2K-Rechner noch auf unserem Domänencontroller Fehlermeldungen ausgegeben. Der Druckauftrag verschwindet einfach. Melde ich mich am XP-Client mit einem Benutzer an, dessen Profil auf einer W2K Workstation erstellt wurde, funktioniert es. Nicht jedoch bei Benutzern, deren Profil unter XP angelegt wurden. (Wir benutzen Servergespeicherte Profile) Nachtrag: Es hängt doch nicht mit den Profilen zusammen. Es scheint, als würde es nur bei Benutzern funktionieren, die Domänen-Admin Rechte haben. Sogar bei "normalen" Administratoren kommt es zu oben beschriebenem Problem. Ich bin für jeden Tip dankbar. Vielen Dank im Voraus. Mfg, Christian
×
×
  • Neu erstellen...