Hallo.
Wir haben hier ein merkwürdiges Problem: Unsere Ausleihstation für Windows-Laptops lief bisher problemlos so, dass alle User einen beliebigen Laptop starten konnten und sich an der Domäne anmelden konnten. Es war dabei egal, ob der Laptop an der Dockingstation hing (LAN) oder zuerst in einen anderen Raum transportiert wurde (WLAN).
Neuerdings (?) können sich die Schüler nicht mehr über das WLAN anmelden. Es erscheint stattdessen diese Meldung:
Das kann natürlich eine falsche Meldung von Windows sein, denn wenn ich es mit einem anderen Benutzer (in der Regel mein eigener) versuche, klappt der Login sofort. Mein Kollege hat das gleiche beobachtet – auch bei ihm funktioniert der Login sofort per WLAN. Nun könnte man ja meinen, dass in diesen beiden Fällen eben ein lokales, bereits vorhandenes Profil verwendet wurde aber das stimmt nicht, da das auch geschieht, wenn der Laptop ganz neu und nur mit dem lokal vorhandenen Admin-Account mit Hilfe von LINBO (roter Button) neu aufgesetzt wurde.
Die gleiche Beobachtung gibt es auch unter Ubuntu: Mit gewissen Logins funktioniert die Anmeldung aber bei anderen erscheint, dass das Passwort angeblich falsch sei (was aber nicht stimmt).
Meine Fragen sind daher:
Wie / wo wird in diesem Fall festgelegt, wer sich an der Domäne anmelden darf und wer nicht?
Hat sich hier in letzter Zeit (alles noch v7.2 produktiv!) etwas geändert, denn wir sind sicher, dass das vor kurzem noch kein Problem war.
Per LAN scheint es immer zu funktionieren; nur über die WLAN-Verbindung taucht das Problem auf. Aber über die WLAN-Verbindung ist der Server dennoch die ganze Zeit erreichbar.
Wer hat eine gute Idee, woran das liegen könnte?
Viele Grüße,
Michael
Hi.
Das haben wir anfangs auch vermutet – aber die Rechner der Ausleihe sind immer im Internet (MAC-Adressen sind erfasst) und werden nicht blockiert. Die Anmeldung hat bisher für alle auch funktioniert, ohne vorher eine Freigabe für das Internet machen zu müssen.
Und: Der Login an die Domäne erfordert ja keinen Internetzugriff – oder?!
Viele Grüße,
Michael
die Meldung sagt erstmal, dass der Anmeldeserver nicht erreicht werden kann, um die Nutzeranmeldung zu überprüfen. Habt ihr mal überprüft, ob der DNS-Name für den Anmeldeserver auch auf die richtige IP auflöst und diese IP bzw. die Ports für Kerberos und LDAP aus dem IP-Netz des WLANs erreichbar sind? Dass der Laptop Internetzugang hat, sagt ja nichts darüber aus, dass er Zugang zum Anmeldeserver im benachbarten lokalen Netz hat.
Sind die Zugangsdaten von dir und dem Kollegen vielleicht im Credential Cache gelandet und mit dem Image aufgezeichnet worden? Das würde erklären warum es mit euren Konten geht. Um das zu überprüfen, könntest du den CachedLogonsCount auf 0 setzen.
Fallstricke sind:
WLAN-Verbindung noch nicht bereit
IP-Konfiguration
DNS-Konfiguration im Client
DNS-Auflösung (DNS-Server)
Routing kaputt
Firewall blockiert
Zeitabweichung (Kerberos)
detaillierterer Ablauf des Anmeldeprozesses (KI-unterstützt erstellt)
Systemstart / Resume: Windows startet, Netzwerkstack ist noch nicht (vollständig) initialisiert
Netzwerktreiber werden geladen und Verbindung wird aufgebaut (SSID, WPA2/3, ggf. 802.1X)
mögliche Probleme:
WLAN noch nicht verbunden
802.1X-Authentifizierung noch läuft
Captive Portal aktiv
Winlogon.exe startet, Credential Provider werden geladen, Domänenanmeldung wird als eine mögliche Option angeboten
Netzwerkstatus-Abfrage: Windows prüft, ob ein Netzwerkkarte Konnektivität (Link up) meldet
mögliche Probleme:
Laden des Treibers dauert länger (Timing-Problem)
WLAN verbunden, aber keine IP-Konfiguration (Timing-Problem, ggf. DHCP-Server oder DHCP-Relay zu langsam)
Benutzer gibt Domänenanmeldedaten ein
LSASS (Local Security Authority Subsystem Service) übernimmt die Anmeldung und entscheidet, ob Online- oder Cached-Logon durchgeführt wird
Prüfung auf vorhandene Cached Credentials
Letzte erfolgreiche Domänenanmeldungen werden lokal gespeichert (Standard: bis zu 10 Benutzer)
wenn vorhanden, kann Anmeldung ohne Kontakt zum Anmeldeserver erfolgen
Domänen-Erreichbarkeitsprüfung (kritisch) durch DNS-Auflösung der Domäne durch DNS-Abfrage von _ldap._tcp.dc._msdcs.DOMÄNE und Domain Controller SRV-Records
mögliche Probleme:
Domain Controller SRV Records fehlen
DNS zeigt auf falschen Server
Split-DNS wird genutzt und der DNS-Server die falsche View aus, so dass der Client nur öffentliche DNS-Einträge sieht
DNS-Suffix fehlt in Konfiguration der WLAN-Verbindung im Client oder er weicht vom DNS-Suffix der LAN-Verbindung ab
Auswahl eines Domain Controllers
mögliche Probleme:
Standortermittlung (AD Sites) über DNS schlägt fehl
Anmeldeserver zwar auflösbar, aber Server oder Dienste darauf nicht erreichbar
Aufbau der LDAP / Kerberos-Verbindung
Kerberos (UDP/TCP 88)
LDAP (TCP 389 / 636)
SMB (TCP 445, u. a. für GPO)
mögliche Probleme:
Firewall blockiert IP/Ports
WLAN-ACLs greifen
MTU-Probleme
Kerberos-Authentifizierung
Client fordert TGT (Ticket Granting Ticket) beim Anmeldeserver an
Zeitstempelprüfung (±5 Minuten!)
mögliche Probleme:
Uhrzeitabweichung
NTP nicht erreichbar
BIOS-Zeit falsch
Benutzer-Authentifizierung: Validierung der Anmeldedaten gegen Anmeldeserver
Erstellung des Benutzer-Tokens mit SID (Security Identifier), Gruppenmitgliedschaften
Laden des Benutzerprofils (lokal oder servergespeicherte)
Gruppenrichtlinien-Verarbeitung
Deine Fehlermeldung im Screenshot ordne ich Schritt 6-8 zu, wobei Schritt 8 nicht funktionieren kann, wenn Schritt 2 oder 4 noch Probleme haben.
Microsoft hat seit Windows XP ein Feature namens „Fast Logon Optimization“ (Beschreibung in DE ist so kaputt übersetzt, dass ich empfehle EN zu lesen), dass dafür sorgen kann, dass die Anmeldung bereits probiert wird, wenn noch kein Netzwerk verfügbar ist. Das Feature kann per Gruppenrichtlinie abgeschaltet werden, was bei Rechnern im Offline-Betrieb zu einer Verzögerung im Anmeldebildschirm von wenigen bis zu 30 Sekunden führen kann (warten auf Netzwerk-Timeout), aber zu zuverlässigeren Anmeldevorgängen bei online betriebenen Geräten führt.
Hi.
Danke! Gute Tipps …
DNS usw schaue ich mir nochmal an.
Da das Problem ja auch unter Ubuntu auftritt, spricht ja einiges dafür, dass es daran liegen kann. Ob die Logins auf dem Ubuntu-Client bereits drauf waren oder wirklich neu angelegt wurden, kann ich gerade nicht nachsehen. Aber auch bei Ubuntu gilt: Sobald der Client am LAN hängt, geht’s!
Ach ja: Die Ports 137, 139, 445 und 636 sind für den Zugriff vom WLAN → Server aus offen. Da fehlt keiner, oder?
LDAP Port 389 sollte mit dabei sein für LDAP-Verbindungen, die StartTLS nutzen, also wo nach TCP-Verbindungsaufbau Client und Server sich aushandeln, dass sie innerhalb der Verbindung TLS nutzen wollen. Port 636 ist (nur) LDAPS, d. h. Client und Server sprechen von Anfang an TLS (ähnlich wie bei HTTPS). Beides sollte im Zweifel möglich sein.
Port 137/138 NetBIOS Name Service braucht keiner mehr, der DNS Port 53 mit UDP und(!) TCP (für größere Antworten) nutzt
Port 139 SMB über NetBIOS braucht keiner, der SMB direkt über TCP auf Port 445 nutzt.
Das veraltete NetBIOS-Protokoll sollte niemand mehr nutzen (wollen), weil die Verwendung heutzutage sicherheitstechnisches Harakiri ist und es seit ca. dem Jahr 2000 durch o.g. Alternativen ersetzt werden kann. Auf den Clients und Servern sollte NetBIOS ausgeschaltet sein, sonst bring ich mal einen alten Drucker mit, der so heißt wie irgendein Server und klemm den mal an und wir schauen was passiert, wenn der Drucker anfängt seinen Nachbarn per Broadcast (NetBIOS) zu erzählen, dass er doch diesen Hostnamen hat
Hi.
Heute haben wir das nochmal geprüft und auf der Firewall die Protokollierung in der Live-Ansicht mitlaufen lassen. Zugriffe von Win10 auf Port 137 und seltsamerweise auch auf Port 80 gibt es haufenweise bei einer Anmeldung an die Domäne.
Die oben übersehenen Porftreigaben für 389, 636, 53 usw waren alle bei den globalen Regeln auf der OPNSense vorhanden – es funktionierte ja bisher auch.
DNS und „tracert“ haben wir ebenfalls überprüft. Das stimmte und zeigt alles direkt auf den Server.
Seltsam ist nach wie vor, dass sowohl Linux als auch Windows neuerdings davon betroffen sind. Kann da vielleicht irgendein Update der OPNSense reingefunkt haben?
Es wäre natürlich mögich, dass man die Laptops der Ausleihstation mit einer Auto-Anmeldung (dann halt ohne Domäne) fertig macht. Aber elegant ist das natürlich nicht.
Hallo.
Noch eine Beobachtung unter Linux:
Ich habe eine VM von einem VLAN („grün“) in ein anderes VLAN („blau“) gepackt und zunächst auf der Firewall nachgeschaut, was der Client macht. Dazu habe ich eine neue Regel erstellt, dass dieser Client mit dieser IP-Adresse alles darf und alles protokolliert werden soll.
Ergebnis: Die Anfragen gingen auf die üblichen Ports (s.o.) aber ein Anmeldung war trotzdem nicht möglich. Daher kann es ja kein Problem mit blockierten Ports sein, denke ich.
Dann ein Blick in die Datei /var/log/sssd/sssd_linuxmuster.meine-domain.de.log
und siehe da:
(2026-01-15 14:25:52): [be[linuxmuster.meine-domain.de]]
[sbus_issue_request_done] (0x0040): sssd.dataprovider.getAccountInfo: Error
[1432158212]: SSSD is offline
aber:
ping server
und
tracepath server
kommen an und liefern den richtigen Namen
Wenn ich das VLAN wieder zurück auf die ursprüngliche Einstellung wechsel, ist der Domain-Controller nach kurzer Zeit wieder online / erreichbar und die Anmeldung klappt auch wieder.
Nun bleibt die Frage, was den Effekt verursacht, wenn es nicht die Firewall ist?
Wie gesagt: Vor einiger Zeit lief das noch; mir ist nicht ganz klar, was sich da geändert haben könnte.
Viele Grüße,
Michael
sind die Firewallregeln, die schon existieren und Anmeldung im LAN ermöglichen, auch für das Interface gültig über das die Datenpakete aus dem WLAN reinkommen?
Sind das Dualbootgeräte oder läuft da nur Windows? Bei Dualboot könnte es ja das Problem geben, dass Linux und Windows beim Herunterfahren die aktuelle Zeit mit abweichender Zeitzonen speichern. Da würde für das jeweils andere OS die Zeit um eine Stunde falsch laufen, was die 5-Minuten-Grenze von Kerberos verletzt.
Ich habe nutze in meiner Umgebung vom LMN-Server nur die LInbo-Funktionalitäten und habe ansonsten ein pfSense als Firewall und ein (externes) Active Directory mit Windows-Server als DC, daher kann ich wenig zu spezifischen Einstellungen und Fehlerquellen bei OPNsense und Samba-Server beisteuern.
Habt ihr Layer3-Switche im Einsatz? Asymmetrisches Routing, d.h. Datenpakete nehmen auf Hin- und Rückweg andere Routen, könnte auch noch ein Problem sein, da Firewalls dann gerne mal Verbindungen verwerfen, weil sie die bspw. den initialen Verbindungsaufbau nicht gesehen haben, weil der gar nicht bei ihnen vorbei kam.
Hallo Buster,
danke für die Tipps, ich habe in der OPNSense die Regel für die IP-Adresse des Clients vor alle anderen gesetzt, also an Position 1 („first match“-Prinzip). Aber es kann natürlich trotzdem noch sein, dass eine globale Regel weiterhin Vorrang hat. Dennoch glaube ich eigentlich nicht, dass das ein Firewall-Problem ist. In Sachen DNS kann das schon eher sein, denn wenn der Client im LAN („grün“) hängt, bekommt er direkt den v7-Server als DNS-Server verpasst. Hängt der Client hingegen im WLAN („blau“), wird ihm zunächst die OPNSense als DNS-Server mitgegeben, die dann aber mit Unbound weitermacht.
Es sind aber (im Moment) alles keine Dual-Boot-Geräte. Wir haben in der Laptop-Ausleihstation 30 Clients, die wir entweder mit Win oder mit Linux austatten können. Im Moment läuft auf 29 davon Win10 und auf einem Ubuntu. Es kann aber sein, dass wir in Kürze vollständig umstellen.
Ein L3-Switch (Cisco) ist im LAN („grün“) für die VLANs vorhanden. Dass es evtl ein Problem mit asymmetrischen Routing sein könnte, kann ich nicht völlig ausschließen, aber ich frage mich, wie man das testen geschweige denn herausfinden könnte? Geändert haben wir allerdings an diesem Setting seit längere Zeit nichts und wir sind sicher, dass die Ausleihstation vor kurzem noch funktioniert hat. (Für den Moment haben wir als Workaround übrigens einen Auto-Login für einen default-User eingerichtet. Das bringt auf den Clients nicht die gleiche Funktionalität wie vorher aber immerhin kann am sie überhaupt verwenden.)
Mir fällt noch ein:
Wir hatten mal vereinzelt Windows-Geräte, mit denen man nach dem Image sich mit dem privaten WLAN (zu Hause) verbinden konnte, aber kein Internetzugriff möglich war.
Der Grund dafür war, dass die IP-Einstellungen zwar auf DHCP konfiguriert war, aber bei manchen PCs (eher selten) trotzdem ein „vorrangiger“ DNS-Server eingetragen war. Den musste man löschen, dann gings wieder.
Ich konnte nie herausfinden, was die Ursache dafür war, weil stets das gleiche Image verwendet wird.
=> funktioniert die DNS-Auflösung zum LDAP-Server usw.?
Viele Grüße McTeefax
