Hallo.
Wir haben ein paar „Verleihlaptops“ mit LINBO und Win10 aufgesetzt – die Anmeldung an die Domäne funktioniert prima; aber leider nur, solange man im LAN ist.
Der Witz bei „Verleihlaptops“ ist natürlich, dass man die zum Großteil im WLAN betreiben will. Nun kann sich ja Windows 10 vor der Anmeldung mit einem WLAN verbinden. Die Anmeldung an die Domäne kommt hier allerdings trotzdem nicht zustande (lange Fehlermeldung; leider keinen Screenshot gemacht).
Ich habe auf der OPNSense bereits den Zugriff für das WLAN auf den Server freigeschaltet (auch bereits um ganz sicher zu gehen: alle Ports, TCP & UDP). Es kommt aber scheinbar nichts an.
Verwendet das von Euch jemand so? Sollte doch eigentlich problemlos möglich sein? Meine Vermutung ist, dass die Clients im WLAN den AD/Samba-Server evtl unter falscher IP suchen??
Danke jedenfalls für Tipps…
nicht so.
Ich würde nie die sambaports (oder gar alles) ins Blaue netz öffnen …
Sollte doch eigentlich problemlos
möglich sein?
nee, überhaupt nicht.
Meine Vermutung ist, dass die Clients im WLAN den
AD/Samba-Server evtl unter falscher IP suchen??
die wollen sich in der Domäne anmelden aus einem anderen IP Netz.
Wäre ich samba, würde ich das auch ablehnen.
In Blau hast du ja eine 172.er IP oder 198.er? …
Hallo Holger,
das wundert mich aber, dass so ein „gängiges Problem“ nicht ohne weiteres lösbar ist??
Die Samba-Ports sind nur zum Testen offen – es erscheint aber erst gar keine Meldung in der Firewall.
Ich kenne mich mit dem ganzen Autorisierungszeug nicht gut genug aus - aber es sollte meiner Meinung nach als letztes an der IP des Clients liegen, ob der Server dessen Auth. zulässt oder abweist?!?? Dazu gibt es doch schließlich das ganze Kryptozeug?
das wundert mich aber, dass so ein „gängiges Problem“ nicht ohne
weiteres lösbar ist??
ich halte es nicht für Gängig mein grünes Netz ins WLAN zu erweitern,
ich halte das für gefährlich.
Ich kenne mich mit dem ganzen Autorisierungszeug nicht gut genug aus -
aber es sollte meiner Meinung nach als /letztes/ an der IP des Clients
liegen, ob der Server dessen Auth. zulässt oder abweist?!?? Dazu gibt es
doch schließlich das ganze Kryptozeug?
unter Windows geht das sogar noch weiter: an eine Domäne bekommst du es
erst gar nicht, wenn nicht das Domaincontroller auch der DNS ist…
Warum machst du kein WLAN in Grün auf: dann hast du diese „roaming
Clients“ vom normalen „Besucherverkehr“ getrennt.
So machen das mehrere seit langem hier.
Soe wie du es machen willst hab ich keinen im Kopf, der das auch so macht.
Ok, das ginge – aber das WLAN (ehemals blau) sollte ja eigentlich für Leihgeräte das richtige Netz sein. Wenn ich daraus ein grünes Netz mache ist die Frage, was dramatischer ist: Zugriff auf das AD aus blau oder ggf „Wildwuchs“ in grün (Laptops in Schülerhänden)?
Ach ja übrigens – mit „gängiges Problem“ meinte ich: „Anmeldung an das AD vor WLAN“ – also ganz allgemein. Das betrifft doch viele Win-Clients (auch völlig ohne linuxmuster-Server)?
Ok, das ginge – aber das WLAN (ehemals blau) sollte ja eigentlich für
Leihgeräte das richtige Netz sein. Wenn ich daraus ein grünes Netz mache
ist die Frage, was dramatischer ist: Zugriff auf den AD aus blau oder
ggf „Wildwuchs“ in grün?
ich würde nicht das ganze WLAN nach Grün verlegen: die BYOD Geräte
sollen ja extra nicht in Grün sein.
Andere hier in der Liste haben ein eigenes WLAN in Grün für
„einrichtungseigene“ Geräte.
Auch ich habe das: für Tablets.
In Blau hab ich WPA2 Enterprise und in Grün WPA2 Personal
Ach ja übrigens – mit „gängiges Problem“ meinte ich: „Anmeldung an das
AD vor WLAN“ – also ganz allgemein. Das betrifft doch viele Win-Clients
(auch völlig ohne linuxmuster-Server)?
… ich glaube nicht dass es ein „normales“ Vorgehen ist in Firmen eine
AD Anmeldung über WLAN zu zu lassen.
Wenn die an die Laufwerke in Grün wollen, dann machen die VPN … egal
von wo aus: auch aus dem Firmeneigenen WLAN.
Ne, so hatte ich Dich auch nicht verstanden. Es müsste aber ein weiteres WLAN in einem grünen Subnetz her. Ich habe noch ein VLAN frei – daran soll es nicht scheitern. Dachte bisher nur, dass ich mit zwei SSIDs hinkommen würde … dann werden es jetzt vermutlich doch drei …
Es ist ja auch gut möglich, dass Firmen das Problem in dieser Form überhaupt nicht haben. An einer Schule bekommt irgendein Schüler irgendein Laptop in die Hände gedrückt und soll sich anmelden können. Das kann er bei Domänenbetrieb nur, wenn die Kiste zuerst im richtigen (W)LAN ist und erst dadurch das AD erreichbar wird … in einer Firma wird einem Mitarbeiter vermutlich ein entsprechend ausgestattetes Notebook mitgegeben; er meldet sich erstmals direkt in der Firma an und hat später dieses Problem gar nicht mehr, weil es mittlerweile auch ein lokales Profil gibt, auf das im Notfall ja immer zurückgegriffen werden kann, falls das AD nicht erreichbar ist … Man sieht also mal wieder: Schule != Firma
Wir machen das mit unseren Leihgeräten so, dass sie mit einem generischen Auto-Login ausgestattet sind.
Zugriff auf die Dateien der Schülerinnen und Schüler geht ja über Nextcloud (und ohnehin liegt viel bei Moodle).
Wir arbeiten daran, das Drucken mit einer interaktiven Abfrage des Benutzernamens auszustatten (für die Quotierung). Evtl. könnte man die Homes auch dynamisch einbinden (muss ja nicht mal SMB sein - geht ja z.B. auch über WebDAV, wenn auch nicht besonders performant). Das liefe dann alles nach der Anmeldung über einen Knopf auf dem Desktop.
Und bei den nur kurz ausgeliehenen Geräten kann man das dann alles mit Linbo oder über ein Skript zurücksetzen für den Datenschutz.
Noch sehe ich die Vorteile einer AD-Anmeldung in der Schule nicht. Wir sind aber auch noch mit der 6.2 unterwegs…
gute Idee …
dann könnten die Geräte auch in BLAU bleiben – denn mir fiel noch ein, dass man auf Leihgeräten in grün natürlich sofort den super geheimen WPA2-PSK ermitteln kann. Damit wäre das ganze Konzept, die Schüler mit ihren Geräten aus grün heraus zu halten, für die Tonne…
Dann seid ihr aber auch in grün, oder?
na ja. … unser Master-Client ist so eingerichtet, dass der sich an der Domäne anmeldet. Da war es relativ naheliend, das mit einem Schüler-Login vom WLAN aus zu versuchen… sonst steckte bisher nicht viel dahinter. Ich könnte mir auch einen default-User vorstellen. Gibt es einen Weg, dessen Anmeldung auch nachträglich noch ins System zu bekommen? Nur deshalb würde nicht natürlich nur ungerne ein zweites Windows-Image haben wollen…
Nein, in grün gibt es bei uns kein WLAN. Man kommt aus blau auf Moodle/Nextcloud. Damit kann man dann auch z.B. die User-Homes über WebDAV einbinden (macht der Nextcloud-Client sogar automatisch). Das ist halt nicht das schnellste, aber man kann damit gut arbeiten. SMB einbinden/Drucken hieße, die Ports aufzubohren. Da bin ich noch zurückhaltend. Dann vielleicht doch eher ein Web-Druck-Portal, von dem aus man ebenfalls über HTTP(S) drucken kann.
Wir haben tatsächlich 4 Images: Windows/Linux Domäne und Windows/Linux für nicht-vernetzte Geräte (Ausleihe/Schülerendgeräte). Da wir in der Domäne vieles auf Netzwerklaufwerken speichern und bei den „Offline-Geräten“ alles lokal ist (auch die Daten, Einstellungen, etc. auf einer Datenpartition), scheint mir das am Ende weniger Aufwand (ich mache Updates, etc. immer parallel), als wenn ich mir überlege, wie ich H: am Offline-Rechner umbiege, etc. Ich habe das mal versucht, aber am Ende war es viel Kleinarbeit, die kaum einer gewürdigt hat, weil die Rechner oft nur für Recherchen oder Präsentationen genutzt wurden.
Die Leihgeräte schaltet man jetzt halt ein und sie sind sofort und ohne Anmeldung nutzbar. Das hat sich bei uns so bewährt. Und die Nutzerinnen und Nutzer dürfen gerne „üben“, wie man per Nextcloud//Moodle arbeitet
Kurze Rückmeldung zu Holgers Idee: Wir haben heute ein zusätzliches WLAN in grün eingerichtet. Daraufhin funktionierte die Domänenanmeldung. Da die Problematik mit dem verbrannten WPA2-PSK aber bleibt, wenn man Leihgeräte in Schülerhände gibt, haben wir die Anmeldung daraufhin auf WPA2-Enterprise & freeRadius umgestellt.
Das funktionierte ebenfalls. Zuerst die Anmeldung an’s WLAN mit den eigenen Credentials (die zudem vorher noch in der WebUI freigeschaltet sein müssen) und anschließend die Anmeldung an Windows bzw dem Domaincontroller mit eigenem Profil; also die gleichen Credentials ein zweites Mal.
Ob das nun als umständlich oder zumutbar empfunden wird, muss jeder selbst entscheiden. Einfacher ist ganz sicher der Weg, den Thomas oben beschrieben hat…
Eine Sache fiel aber noch auf: Das neue WLAN hatten wir zuerst „Test WLAN grün“ genannt. Eine Anmeldung war nicht möglich; es wurde auch ein kleines Schloss bei den verfügbaren Netzen gezeigt. Und wo war der Fehler? Unglaublicherweise bei dem „ü“ … da dürfen offenbar keine Umlaute in den Namen stehen; ohne ging es sofort. Nur falls von Euch auch jemand darüber stolpert …
Hallo Thomas,
ich hab ähnliches vor. Möchte gern ein paar Laptops(Windows 10) nur im WLAN(blau) nutzen. Mein Plan ist es, erstmal ein Image mit lokalem Benutzer im Lan zu erstellen und anschließend im WLAN nutzen. Den WPA2-PSK würde ich ins Image einbinden. Selbst wenn die Schüler diesen auslesen könnten, müsste ein Client erst auf der Firewall(noch iPfire) den Zugriff auf blau gestattet werden.
Dann bräuchten die Laptops von der HD starten und alles wäre gut. Wenn das Image angepasst werden soll, müsste wieder PXE boot eingestellt werden und im LAN sein. Das solltze doch klappen?!
Du musst da nicht mal etwas ändern. Lass sie lokal zu Linbo booten - FALLS sie am Netz sind und FALLS es Änderungen gibt, merkt Linbo das. Man kann sogar nach einer Image-Veränderung für die betroffenen Rechner einen Sync-Befehl vorbereiten (linbo-remove … -p …). Dann wird der Rechner automatisch beim nächsten Boot am Netz synchronisiert (oder was auch immer). Man muss also gar nichts ändern/umstellen.
danke für die rasche Antwort. Ich hab aber gelegentlich das Problem, dass Rechner, die nicht im LAN sind, beim booten hängen bleiben. SIe finden kein Bootmedium.
So richtig hab ich noch nicht herausgefunden, welche Einstellung in der start.conf und bootreihenfolge dafür verantwortlich sind.
danke für die rasche Antwort. Ich hab aber gelegentlich das Problem,
dass Rechner, die nicht im LAN sind, beim booten hängen bleiben. SIe
finden kein Bootmedium.
So richtig hab ich noch nicht herausgefunden, welche Einstellung in der
start.conf und bootreihenfolge dafür verantwortlich sind.
das hat mit der start.conf nichts zu tun: es ist Sache des BIOS (UEFI)
zu entscheiden, von wo gebootet wird.
Normalerweise stellt man da diese Reihenfolge ein
PXE IPv4
lokaler Massenspeicher (bzw. in UEFI „grub“)
Das BIOS sollte schlau genug sein zu erkennen, dass kein Netzwerkkabel
steckt und gleich zu Punkt 2 springen.
Aber … heut zutage wird ja alles so schlau, dass es Doof wird. Und so
beobachte ich immer mal wieder, wie Betriebsysteme oder das UEFI an der
Bootreihenfolge rumschraubt.
Das nur als Hinweis wenn du denkst "Hä? spinn ich jetzt? da hab ich doch
vorhin was anderes eingestellt gehabt !! "
… es liegt (nicht zwingend) an dir
