Christian81

Nein ist sie nicht.

Inwiefern kann sowas denn der Grund sein, dass es plötzlich nicht mehr funktioniert ?

Es lief ja bisher 

vor 22 Stunden schrieb Christian81:

 

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.

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 ?

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

Zitat

Fehler beim Anmelden eines Kontos.

Antragsteller:
    Sicherheits-ID:        NULL SID
    Kontoname:        -
    Kontodomäne:        -
    Anmelde-ID:        0x0

Anmeldetyp:            3

Konto, für das die Anmeldung fehlgeschlagen ist:
    Sicherheits-ID:        NULL SID
    Kontoname:        *Benutzer*
    Kontodomäne:        *Lokale Domäne des Rechners*

Fehlerinformationen:
    Fehlerursache:        Unbekannter Benutzername oder ungültiges Kennwort.
    Status:            0xC000006D
    Unterstatus::        0xC000006A

Prozessinformationen:
    Aufrufprozess-ID:    0x0
    Aufrufprozessname:    -

Netzwerkinformationen:
    Arbeitsstationsname:    *Lokaler Rechner*
    Quellnetzwerkadresse:    192.168.1.132
    Quellport:        52154

Detaillierte Authentifizierungsinformationen:
    Anmeldeprozess:        NtLmSsp 
    Authentifizierungspaket:    NTLM
    Übertragene Dienste:    -
    Paketname (nur NTLM):    -
    Schlüssellänge:        0
 

 

 

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: 

 

Zitat

Ein Konto wurde erfolgreich angemeldet.

Antragsteller:
    Sicherheits-ID:        NULL SID
    Kontoname:        -
    Kontodomäne:        -
    Anmelde-ID:        0x0

Anmeldeinformationen:
    Anmeldetyp:        3
    Eingeschränkter Administratormodus:    -
    Virtuelles Konto:        Nein
    Token mit erhöhten Rechten:        Ja

Identitätswechselebene:        Identitätswechsel

Neue Anmeldung:
    Sicherheits-ID:        *Zieldomäne\Benutzer*
    Kontoname:        *Benutzer*
    Kontodomäne:        *Zieldomäne*
    Anmelde-ID:        0x2E6472393
    Verknüpfte Anmelde-ID:        0x0
    Netzwerk-Kontoname:    -
    Netzwerk-Kontodomäne:    -
    Anmelde-GUID:        {00000000-0000-0000-0000-000000000000}

Prozessinformationen:
    Prozess-ID:        0x0
    Prozessname:        -

Netzwerkinformationen:
    Arbeitsstationsname:   *Lokaler Rechner*
    Quellnetzwerkadresse:    192.168.1.132
    Quellport:        52157

Detaillierte Authentifizierungsinformationen:
    Anmeldeprozess:        NtLmSsp 
    Authentifizierungspaket:    NTLM
    Übertragene Dienste:    -
    Paketname (nur NTLM):    NTLM V2
    Schlüssellänge:        128
 

 

 

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

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

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

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

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