Kommunikation zwischen Windows Systemen
und zwischen Windows und Unix (Linux)
 
Funktion und Lösungen für Problemfälle


Vorwort

Für die Kommunikation zwischen Windows-Systemen (Windows95/98NT/2000) untereinander sowie zu Unix (Linux) wird das TCP/IP-Protokoll (die "Subprotokolle" SMB und NetBIOS) benutzt, sie ist von der Kommunikation mit Novell-Systemen und von der NDS-Autorisierung völlig unabhängig.

Die Kommunikation mit UNIX setzt die Zusatzsoftware SAMBA auf den entsprechenden Unix-Maschinen voraus, damit ist der Zugriff im Netz wie auf andere Windows-Maschinen möglich. 

Windows 95/98/NT/2000 Maschinen können neben Ihrer Funktion als "normale" Arbeitsstationen auch die eigenen Ressourcen (Dateien/Verzeichnisse auf der Festplatte, Drucker usw.) zur Nutzung auf anderen PCs im Netzwerk "anbieten" (freigeben). Derart freigegebene Ressourcen heißen "Shares". 


.Wie funktioniert der Zugriff auf entferne Windows-Rechner (bzw.Unix mit SAMBA)?

Jeder Windows-PC verwendet zur Identifikation im Netzwerk einen (eindeutigen) Computernamen sowie die Windows-Arbeitsgruppe. 
Der Windows-Computername entspricht dem Hostnamen bei Unix-Systemen und ist in beiden Fällen ein "Alias" für die IP-Adresse der Maschine.
Die Arbeitsgruppe dient nur zur übersichtlicheren "Einsortierung" und leichteren Auffindung von Windows-PCs im Netzwerk. In jeder Arbeitsgruppe gibt, sofern mindestens ein PC in dieser Gruppe unter Windows 95/98 (Ressourcen freigegeben hat oder mindestens ein PC unter Windows NT betrieben, einen sogenannten Browsemaster, der die Liste der Computer dieser Arbeitsgruppe hält. 

Die Auflösung von Computernamen (das Auffinden von Computern) erfolgt unter Windows 95/98/NT4.0 über WINS. Dazu dient eine WINS-Server, der die Liste aller Namen von Windows-PCs mit zugehörigen IP-Adressen hält. Beim Hochfahren eines Windows-PCs teilt dieser dem WINS-Server seine "Existenz" mit, Analoges geschieht beim Herunterfahren. Die Computerliste des WINS-Servers wird deshalb automatisch erzeugt und upgedatet.
Eine Alternative zur Auflösung über WINS ist Broadcast (Rundspruch), diese Methode wird jedoch bei großen Netzwerken  - so auch bei uns -  in der Regel nicht unterstützt
Die Namensauflösung über WINS ist das "Windows"-Äquivalent zu Namensauflösung über DNS bei Unix.  Ab Windows 2000 ("NT 5.0") kann die Windows-Namensauflösung auch über DNS erfolgen (ohne WINS und NETBIOS).

Unter Windows 95/98/NT4.0 gibt es zwei "Namen" für die verschiedenen Dienste:

Name wird verwendet  für  wird konfiguriert über
(Windows-) 
Computername
SMB-Zugriff über IP Windows-Identifikation 
(lokal konfiguriert!)
(IP)
Hostname
andere IP-Dienste 
(http, ftp, telnet..)
TCP/IP-Konfiguration 
(automatisch über DHCP vergeben)

In unseren Netzwerk werden für "Computername" und "Hostname" sinnvollerweise dieselben Bezeichnungen verwendet, bei PCs in der Form pcxxxx (xxxx = Gerätenummer). 

Der (direkte) Zugriff auf Remote-Windows-Ressourcen (Freigaben, Shares) über SMB erfolgt über sogenannte UNC-Pfade in der Form \\computername\share. share ist die Freigabebezeichnung der remote-Ressource, computername der Windows-Computername. Statt computername kann auch das Alias, die IP-Adresse des Rechners, angegeben werden.
UNC-Pfade könne in den meisten Windows-Programmen für den Dateizugriff direkt verwendet werden, ebenso können Links (Verknüpfungen) zu derart bezeichneten Ressourcen erstellt werden.
Selbstverständlich können auch freie Laufwerksbuchstaben zu mit UNC-Pfaden bezeichneten Remote-Ressourcen zugeordnet werden. Solche Laufwerke heißen dann "Netzlaufwerke"

Das Aufsuchen von Remote-Windows-Ressourcen ist über Start -> Suchen -> Computer möglich. Diese Methode funktioniert in unserem Netzwerk aber nur verlässlich für Computer der eigene Arbeitsgruppe. Unter Windows NT werden darüber hinaus solche Computer nicht gefunden, zu denen man bereits eine Verbindung (mit Autorisierung!) hat.
Das Auflisten von
Remote-Windows-Ressourcen ist über die Netzwerkumgebung (z.B. im Explorer) möglich. Leider vermischt Windows 95 - anders als Windows NT - Windows/Unix- und Novell-Objekte! Für Windows/Unix-Objekte gilt: Die Computer der eigene Arbeitsgruppe werden in der "Wurzel" der Netzwerkumgebung angezeigt, alle andere unter "Gesamtes Netzwerk", einsortiert in die entsprechenden Windows-Arbeitsgruppen. Das korrekte Auflisten von Windows-Ressourcen einer Arbeitsgruppe setzt die korrekte Funktion des jeweiligen Browsemasters voraus, was in unserem Netzwerk wegen möglichen fehlerhaft konfigurierten PCs ebenfalls nicht 100% sicher ist.

Wichtig: Mögliche Probleme beim Auflisten oder Aufsuchen von Windows-Ressourcen beeinflussen nicht die "Verbindungsqualität". Der direkte Zugriff über UNC-Pfade oder zugeordnete Netzlaufwerke ist immer möglich!


Autorisierung, Sicherheit

Für den Zugriff auf Remote-Windows-Ressourcen kann eine Autorisierung (Name, Paßwort) verlangt werden. Dise Autorisierung hat nichts mit anderen Autorisierungen wie Novell-NDs zu tun.  Unter Windows gibt es drei Verfahren, die alte, sogenannte Lan-Manager-Technik ("LM-hash"), das neue NTLM-Verfahren und Kerberos.. Entscheidend ist, unter welchem Betriebssystem die Ressource freigegeben wird (wer der "Server" ist):

Betriebssystem Autorisierung Bemerkung Sicherheit
Windows 3.x/95/98 LM share-level, nur Passwort niedrig
Windows NT/2000/XP NTLM user-level, Name und Passwort noch
Windows 2000/XP Kerberos Name und Passwort sehr hoch

Kerberos kann nur von Windows 2000/XP zu Windows 2000/XP verwendet werden.

Unix-SAMBA verwendet je nach Version und Konfiguration LM oder NTLM-Autorisieirung. Aus Sicherheitsgründen wird dringend empfohlen, alle SABMA-Installationen auf NTLM umzustellen bzw. für neue Installationen nur diese Methode zu verwenden. Alle SAMBA-Systeme des Rechenzentrums, auch der zentrale WWW-Server verwenden NTLM-Autorisierung.

Beim LM-Verfahren erfolgt die Autorisierung nur über ein Passwort (das Freigabepasswort), dabei gibt es wiederum zwei Verfahren, die unverschlüsselte und die verschlüsselte Passwortübertragung. Nur alte SABMA-Systeme  benötigen die - gefährliche! - unverschlüsselte Passwortübertragung. 
Bei Windows NT ab SP4 und Windows 2000 ist die unverschlüsselte LM Passwortübertragung standardmäßig abgeschaltet, bei Windows 95/98 dagegen nicht. Das heißt aber nicht, dass Windows 95 grundsätzlich Passwörter unverschlüsselt über das Netzwerk schickt. Dies erfolgt nur auf "Herausforderung" des jeweiligen Servers. Man kann die LM-Klartext-Passwortübertragung  unter Windows 95 abstellen. Dazu müssen Sie ein Security-Update (vredir-security-update) installieren.
Ob das Update bereits installiert ist, sehen sie mit dem Update-Checker von Windows 95 qfecheck.exe oder an der Versionsnummer der Datei vredir.vxd (die sichere Version ist 4.00.1114, die alte, unsichere 4.00.1111)

Beim NTLM-Verfahren wird die Autorisierung grundsätzlich benutzerbezogen und mit sehr hoher Sicherheit druchgeführt. Der Client muss zum Zugriff auf "Server"-Ressourcen Name und Passwort mitgeben, die Autorisierung wird dann über die Benutzerdatenbank von NT bzw. Unix-SAMBA geprüft.

Beispiele für verschiedene Client/Server Kombinationen 
(Client = PC, welcher die Ressource "nimmt", Server = PC, welcher die Ressource "gibt")

Windows 95 Client - Windows 95 Server/ SAMBA alt(LM)

Windows 95 Client - Windows NT Server/ Samba neu (NTLM, www.uni-regensburg.de)

Windows NT Client - Windows NT Server/ Samba neu (NTLM, www.uni-regensburg.de)

Windows NT Client - Windows 95 Server/ Samba alt(LM)

Unter Windows 95 mit Security-Update werden wie unter Windows NT Passwörter für NTLM-Autorisierung grundsätzlich nicht gespeichert, auch wenn man dies im Dialog bei Verbindung herstellen "ankreuzt"


Beispiel für Zugriff auf WWW-Server der Uni Regensburg

Unser WWW-Server verwendet SAMBA mit der sicheren NTLM-Autorisierung (Benutzername und Kennwort). Hier zwei Alternativen für den Zugriff.

  1. Zugriff über Netzlaufwerk
     
    Wählen Sie im in der Menüleiste des Explorers "Extras" -> "Netzlaufwerk verbinden". Folgender Dialog erscheint:
     

     
    Wählen Sie bei "Laufwerk" einen freien Laufwerksbuchstaben (Feld Pfad ist leer), über den Sie auf die Ressource zugreifen wollen. In unserer Umgebung) sind die Laufwerke F:,G:,H: meist vergeben.
    Unter Pfad müssen Sie für Windows/Unix-Ressourcen \\server\share  in obigen Beispiel wird auf den WWW-Server zugegriffen.
    Im Feld "Verbindung beim Start..." müssen Sie ein Häkchen (wie im Bild) setzen, wenn die Laufwerkszuordnung "Permanent" sein soll.
    Nach Klick auf OK werden Sie nach dem Passwort für die Ressource \\server\share  gefragt. Bedenken Sie dabei, dass für NTLM-Autorisierung im Hintergrund der Windows-Anmeldename mitgegeben wird! Den momentanen Windows-Anmeldenamen erfahren Sie ganz einfach über das Startmenü (neue Windows 95 Shell vorausgesetzt): Oberhalb "Beenden" steht "username Abmelden". username ist der Windows-Anmeldename!
    Diese Methode ist identisch zur Kommandozeilenmethode über den Befehl NET USE.
     

  2. Zugriff über Link (z.B. auf dem Desktop)
     
    Klicken Sie mit der rechten Maustaste auf eine freie Stelle am Desktop.
    Wählen Sie "Neu" -> Verknüpfung".
    Geben Sie bei Befehlszeile  \\server\share für die Ressource ein, auf die Sie zugreifen möchten (z.B. \\www\daten), anschließend weiter und Fertigstellen. Ggfls. wird nach dem Passwort für die Ressource gefragt.
    Sie haben jetzt auf dem Desktop einen Ordner, in dem Sie alle Daten der Remote-Ressource finden.


Zugriffsprobleme, Ursachen und Lösungen

Generell sollten Sie versuchen, über den Explorer (Netzlaufwerk verbinden) direkt auf die gewünschte Ressource zuzugreifen und nicht den Computer zu suchen, gleich wie.

  1. Haben Sie überhaupt eine Berechtigung für die Remote-Ressource? Für den zentralen WWW-Server z.B. brauchen Sie eine spezielle Berechtigung. Für andere Windows-Ressourcen müssen Sie sich an die jeweiligen Betreiber wenden (keine zentrale Betreuung!)
     

  2. Haben sie die Remote-Ressource richtig bezeichnet? Sie hat immer die Form \\computername\share oder \\ip-adresse\share. An die Share dürfen keine weiteren Verzeichnispfade angehängt werden!
    Beispiel: \\www\daten (Der Server heißt www, die share daten)
      

  3. Ist das Passwort für die Remote-Ressource richtig? Dieses Passwort hat nichts mit dem NDS-Passwort zu tun, für den Zugang zum zentralen Webserver können Sie es über die Seite https://unixcip.uni-regensburg.de/cgi-bin/passwd.pl neu setzen bzw. ändern.
     

  4. Wenn Punkt 1 -3 sichergestellt ist, liegt wahrscheinlich ein Konfigurationsfehler an Ihrem PC vor, den sie wie im folgenden beschrieben meistens selbst beheben können.

Fehlereingrenzung bei SMB-Zugriffsproblemen (mit Beispielen für WWW-Server)

  1. Verifizieren Sie mit dem Befehl winipcfg /all  (bei NT statt dessen Iipconfig /all in Kommandozeileneingabe), ob Ihr PC richtig konfiguriert ist. Entscheidend für die Namensauflösung ist der richtige node-type (peer-peer oder hybrid) und die Existenz eines WINS-Servers. Folgendes Bild erscheint:
     

    In der Listbox unterhalb von "Ethernet-Adapter-Information" müssen Sie zunächst, falls Ihr PC mehr als eine Netzwerkkarte enthält (auch DFÜ-PPP-Adapter sind Netzwerkkarten) denjenigen Adapter auswählen, über den Sie die Verbindung tätigen wollen. Innerhalb des Uni-Netzes ist dies immer ein  Netzwerkadapter (Ethernet), zu Hause in der Regel ein PPP-Adapter (DFÜ).
    Im Feld "Node Type" muss entweder Peer-Peer oder Hybrid stehen, Broadcast funktioniert nicht!
    Im Feld "Primary WINS Server" muss ein nicht leerer Eintrag, für das Uninetz obiger Wert stehen.
    Natürlich muss Ihr Computer auch eine gültige IP-Adresse haben (Feld IP Address ungleich 255.255.255.255)
    Stimmen diese Werte nicht, kann die SMB-Namensauflösung nicht funktionieren. Sie finden dann den Remote- Computer nicht mit seine Namen. Zur Behebung diese Fehlers lesen Sie hier weiter.
     

  2. Verifizieren Sie mit dem Befehl ping hostname (in einer "DOS-Box"), ob die gewünschte Maschine über das TCP/IP-Protokoll elementar erreichbar ist. Bei Remote-Windows-Maschinen ist hostname wirklich der Hostname, nicht der Windows-Computername (mit WINIPCFG bzw. IPCONFIG lesbar).
    Geht dies nicht, probieren Sie ping zu einem anderen Host (in der Uni z.B. dns), damit können Sie unterscheiden, on Ihr PC nicht mit dem Netzwerk verbunden ist oder der Remote-Host nicht verfügbar ist.
    Beispiel: ping www 
      

  3. Verifizieren Sie mit dem Befehl nbtstat -a computername (in einer "DOS-Box"), ob die gewünschte Maschine über das SMB/NetBIOS Protokoll erreichbar ist. Nbtstat gibt bei Erfolg einige Parameter über die Zielmaschine aus.
    Beispiel: nbtstat -a www    gibt folgende Werte aus:
     
    NetBIOS-Namentabelle des Remote-Computers

    Name     Typ    Status
    ---------------------------------------------
    WWW <00> UNIQUE Registriert 
    WWW <03> UNIQUE Registriert 
    WWW <20> UNIQUE Registriert 
    RZ  <00> GROUP  Registriert 
    RZ  <1E> GROUP  Registriert 

    MAC-Adresse = 00-00-00-00-00-00

     
    Windows-Maschinen liefern hier auch Ihre Ethernet-(MAC-) Adresse, UNIX/SAMBA dagegen nicht. Die Zahlen in spitzen Klammern sind die NetBIOS-Subtypen, aufgelistet werden Computername, Arbeitsgruppe sowie evtl. weitere installierte Dienste. Im Normalfall werden genau obige fünf Werte angezeigt.
    Erhalten Sie hier eine Fehlermeldung, ist der Remote-Computer nicht über dessen Computernamen auffindbar (Problem Nr.1). Sie könne dann versuchen, den Remote-Computer über dessen IP-Adresse anzusprechen, um festzustellen, ob dort alles "ok" ist. Geben Sie dazu den Befehl 
    nbtsstat -A ipaddress. Die IP-Adresse des Computer erfahren Sie mit dem Befehl ping (siehe 2).
    Beispiel: ping www liefert (derzeit) 132.199.3.217, nbtstat -A 132.199.3.217 liefert obige NetBIOS-Namenstabelle.
    Wenn der Zugriff über die IP-Adresse funktioniert, nicht aber über den Namen, liegt Problem Nr.1 vor. Sie können dann notfalls über die IP-Adresse in der Form \\ip-adresse\share auf Ressourcen des Zielcomputers zugreifen. Andernfalls liegt ein Problem am Remote-Computer vor oder aber Ihre Autorisierung stimmt nicht.


Behebung der häufigsten Fehler in Zusammenhang mit SMB-Kommunkation

Wie vorher beschrieben, liefert das Kommando winipcfg /all  Informationen, ob Probleme vorliegen.

Der kritische Node-Typ und die WINS-Adresse ergeben sich bei richtiger Netzwerkkonfiguration (Auslieferungszustand von PCs) von selbst! Die Adresse des  WINS-Server wird über DHCP bezogen, der node-Typ ergibt sich aus der gewählten Netzwerkkonfiguration.

node-Type-Fehler

Falls bei node-Typ der Wert "Broadcast", ist häufig  ein (oder mehrere)  unvollständig oder fehlerhaft konfigurierter DFÜ-Adapter schuld. Wenn Sie im Uni-Netz arbeiten und keine DFÜ-Adapter benötigen (z.B. für Fax installiert), entfernen Sie diese restlos aus der Netzwerkkonfiguration!
Klicken Sie dazu mit der rechten Maustaste auf das Symbol "Netzwerkumgebung" am Desktop und wählen Sie im Kontextmenü "Eigenschaften". Es wird ein Liste vorhandener Netzwerkkomponenten angezeigt. Löschen Sie dort, wenn Sie im Uni-Netz arbeiten (nicht zu Hause!) alle DFÜ-Adpater. Möglicherweise stürzt Ihr PC dabei ab (Rundll Fehler), das stört nicht. Testen Sie nach dem Neustart, ob alle DFÜ-Adapter entfernt sind und wiederholen Sie ggfl. die Schritte. Sehen Sie anschließend mit winipcfg /all nach, ob alles in Ordnung ist.

In selteneren Fällen ist das TCP/IP-Protokoll falsch konfiguriert Sämtliche "Standardwerte" (IP-Adresse über DHCP beziehen!) sind richtig. Beim WINS-Eintrag muss WINS über DHCP aktiviert sein. 
Haben Sie das aktuelle TCP/IP-Update für Win95 installiert? Sie können es jederzeit wiederholen, es ist auf den Windows 95 Update Seiten zu finden. 
Weitere Fehlerbehebungen sollten Sie Ihrem PC-Betreuer überlasen.

WINS-Fehler

Wenn bei WINS-Server kein Werte angegeben ist, können sie wie oben bei node-type-Fehler vorgehen. Möglicherweise ist auch das TCP/IP-Protokoll falsch konfiguriert (WINS muß aktiviert sein, Bezug über DHCP). Sie sollten Den WINS-Server nicht statisch eintragen, bei richtiger Netzwerkkonfiguration wird die Adresse  automatisch über DHCP geliefert. Weitere Fehlerbehebungen sollten Sie Ihrem PC-Betreuer überlasen.


Wolfram Oestreicher, 9.3.2000, korrigiert 1.7.2001