# Was entscheidet, wer sich an Domäne anmelden darf? **URL:** \ **Category:** Windowsclient\ **Created:** [14. Januar 2026 um 13:30 UTC](https://ask.linuxmuster.net/t/was-entscheidet-wer-sich-an-domaene-anmelden-darf/12021 "2026-01-14T13:30:43Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![Michael](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/michael/32/59_2.png) [@Michael](https://ask.linuxmuster.net/u/Michael)\ **Post date:** [14. Januar 2026 um 13:30 UTC](https://ask.linuxmuster.net/t/was-entscheidet-wer-sich-an-domaene-anmelden-darf/12021/1 "2026-01-14T13:30:43Z")
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: ![image-20260114-120147-992](https://ask.linuxmuster.net/uploads/default/original/2X/b/bf1ff41d0f188a26b4ed5069fa14b8b0c41b2623.jpeg) 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 ---
**Author:** ![mcteefax](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/mcteefax/32/2185_2.png) [@mcteefax](https://ask.linuxmuster.net/u/mcteefax)\ **Post date:** [14. Januar 2026 um 17:14 UTC](https://ask.linuxmuster.net/t/was-entscheidet-wer-sich-an-domaene-anmelden-darf/12021/2 "2026-01-14T17:14:52Z")
Hallo Michael, nur, um auf Nummer sicher zu gehen: Könnte dies die Ursache sein: [Unterricht: WLAN freischalten](https://docs.linuxmuster.net/en/latest/classroom/use-wifi/) Viele Grüße McTeefax ---
**Author:** ![Michael](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/michael/32/59_2.png) [@Michael](https://ask.linuxmuster.net/u/Michael)\ **Post date:** [14. Januar 2026 um 17:29 UTC](https://ask.linuxmuster.net/t/was-entscheidet-wer-sich-an-domaene-anmelden-darf/12021/3 "2026-01-14T17:29:14Z")
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 ---
**Author:** ![sucher](https://ask.linuxmuster.net/letter_avatar_proxy/v4/letter/s/50afbb/32.png) [@sucher](https://ask.linuxmuster.net/u/sucher)\ **Post date:** [14. Januar 2026 um 18:10 UTC](https://ask.linuxmuster.net/t/was-entscheidet-wer-sich-an-domaene-anmelden-darf/12021/4 "2026-01-14T18:10:58Z")
auch nur ne idee. unterschiedliche MAC Adressen WLAN Netzwerkkarte und LAN Netzwerkkarte/ Dockingstation? ---
**Author:** ![Buster](https://ask.linuxmuster.net/letter_avatar_proxy/v4/letter/b/41988e/32.png) [@Buster](https://ask.linuxmuster.net/u/Buster)\ **Post date:** [14. Januar 2026 um 18:41 UTC](https://ask.linuxmuster.net/t/was-entscheidet-wer-sich-an-domaene-anmelden-darf/12021/5 "2026-01-14T18:41:41Z")
Hi, 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](https://learn.microsoft.com/de-de/troubleshoot/windows-server/user-profiles-and-logon/cached-domain-logon-information) 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)** > > 1. Systemstart / Resume: Windows startet, Netzwerkstack ist noch nicht (vollständig) initialisiert > 2. 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 > > 3. Winlogon.exe startet, Credential Provider werden geladen, Domänenanmeldung wird als eine mögliche Option angeboten > 4. 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) > > 5. Benutzer gibt Domänenanmeldedaten ein > 6. LSASS (Local Security Authority Subsystem Service) übernimmt die Anmeldung und entscheidet, ob Online- oder Cached-Logon durchgeführt wird > 7. 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 > > 8. 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 > > 9. 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 > > 10. 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 > > 11. 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 > > 12. Benutzer-Authentifizierung: Validierung der Anmeldedaten gegen Anmeldeserver > 13. Erstellung des Benutzer-Tokens mit SID (Security Identifier), Gruppenmitgliedschaften > 14. Laden des Benutzerprofils (lokal oder servergespeicherte) > 15. 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](https://support.microsoft.com/de-de/topic/beschreibung-des-features-windows-optimierung-f%C3%BCr-schnelles-anmelden-9ca41d24-0210-edd8-08b0-21b772c534b7) ist so kaputt übersetzt, dass ich empfehle [EN](https://support.microsoft.com/en-us/topic/description-of-the-windows-fast-logon-optimization-feature-9ca41d24-0210-edd8-08b0-21b772c534b7) 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](https://www.thewindowsclub.com/what-is-fast-logon-optimization) 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. VG Buster ---
**Author:** ![Michael](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/michael/32/59_2.png) [@Michael](https://ask.linuxmuster.net/u/Michael)\ **Post date:** [14. Januar 2026 um 19:11 UTC](https://ask.linuxmuster.net/t/was-entscheidet-wer-sich-an-domaene-anmelden-darf/12021/6 "2026-01-14T19:11:42Z")
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? Viele Grüße, Michael ---
**Author:** ![Buster](https://ask.linuxmuster.net/letter_avatar_proxy/v4/letter/b/41988e/32.png) [@Buster](https://ask.linuxmuster.net/u/Buster)\ **Post date:** [14. Januar 2026 um 21:46 UTC](https://ask.linuxmuster.net/t/was-entscheidet-wer-sich-an-domaene-anmelden-darf/12021/7 "2026-01-14T21:46:17Z")
Hi, 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 😉 VG Buster ---
**Author:** ![Michael](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/michael/32/59_2.png) [@Michael](https://ask.linuxmuster.net/u/Michael)\ **Post date:** [15. Januar 2026 um 09:35 UTC](https://ask.linuxmuster.net/t/was-entscheidet-wer-sich-an-domaene-anmelden-darf/12021/8 "2026-01-15T09:35:08Z")
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. Viele Grüße, Michael ---
**Author:** ![Michael](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/michael/32/59_2.png) [@Michael](https://ask.linuxmuster.net/u/Michael)\ **Post date:** [15. Januar 2026 um 14:09 UTC](https://ask.linuxmuster.net/t/was-entscheidet-wer-sich-an-domaene-anmelden-darf/12021/9 "2026-01-15T14:09:19Z")
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: ```auto (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 ---
**Author:** ![Buster](https://ask.linuxmuster.net/letter_avatar_proxy/v4/letter/b/41988e/32.png) [@Buster](https://ask.linuxmuster.net/u/Buster)\ **Post date:** [16. Januar 2026 um 22:02 UTC](https://ask.linuxmuster.net/t/was-entscheidet-wer-sich-an-domaene-anmelden-darf/12021/10 "2026-01-16T22:02:29Z")
Hi, 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. VG Buster ---
**Author:** ![Michael](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/michael/32/59_2.png) [@Michael](https://ask.linuxmuster.net/u/Michael)\ **Post date:** [17. Januar 2026 um 18:18 UTC](https://ask.linuxmuster.net/t/was-entscheidet-wer-sich-an-domaene-anmelden-darf/12021/11 "2026-01-17T18:18:32Z")
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.) Viele Grüße, Michael ---
**Author:** ![mcteefax](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/mcteefax/32/2185_2.png) [@mcteefax](https://ask.linuxmuster.net/u/mcteefax)\ **Post date:** [31. Januar 2026 um 17:18 UTC](https://ask.linuxmuster.net/t/was-entscheidet-wer-sich-an-domaene-anmelden-darf/12021/12 "2026-01-31T17:18:04Z")
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