Hallo Jürgen, Am 20.03.2015 um 11:13 schrieb Juergen Engeland:
Hallo Hans-Dietrich,bei PDC und BDC denke ich noch in NT4-Domänen - was wohl für Samba 3.x auch angemessen ist.
ich denke auch in NT4-Domänen.
Was AD und Samba 4.x mehr können, weiß ich nicht.
na sicherlich die Verwaltung der Gruppenrichtlinien - aber hier uninteressant. Und sicherlich auch kerberos (Stichwort "single sign on") ist aber auch an der Stelle uninteressant.
Mit Windows NT könnte man Deine Idee vielleicht so umsetzen: Die Lehrerrechner sind Mitglieder der Domäne LEHRER. Sensible Daten befinden sich nur auf Servern der in Domäne LEHRER. Die Ressouren sollten versteckt sein.
so war das nicht gemeint. Die Daten sind weiterhin auf einem Server. Es gibt weiterhin nur ein /home und entsprechende Shares auf entsprechende Unterverzeichnisse - für was auch immer.
Die Domäne SCHULE vertraut der Domäne LEHRER, so dass die Lehrer auch auf Ressourcen der Domäne SCHULE zugreifen können, ohne dass eine doppelte Kontenführung erforderlich wird.
Es gibt 2 Domänen mit jeweils eigener Konfiguration. Aber beide Domänen greifen auf /home zu und bei beiden Domänen sind die gleichen User aus dem LDAP eingebunden. Nur welche Shares für die Domäne LEHRER sichtbar sind und wer darauf zugreifen kann, dass kann man doch konfigurieren. Das ist nichts neues. Neu ist/wäre, dass nur von den Rechnern zugegriffen werden kann, die der Admin vorher in diese Domäne LEHRER aufgenommen hat.
Bei der Domäne SCHULE gilt das analog. Aber man kann das doch (hoffentlich) so machen, das nur von den Rechnern zugegriffen werden kann, die der Admin vorher in diese Domäne aufgenommen hat. (denke bzw. hoffe ich). Aber eine doppelte Buchführung gibt es nicht, weil beide Domänen auf den gleichen LDAP zugreifen (würde m.E. sogar ohne LDAP gehen). will sagen, ich sehe keinerlei Notwendigkeit für eine Vertrauensstellung, im Gegenteil, die beiden Domänen sollen ja unabhängig sein.
Umgekehrt gibt es keine Vertrauensstellung, so dass man aus SCHULE nicht auf die versteckten Ressourcen in LEHRER zugreifen kann, d. H. sich von dort aus sich nicht einmal an der Domäne LEHRER anmelden kann.
Okay, sowas würde man sogar machen können (denke ich jetzt), aber das wäre mir zu kompliziert. Mir würde es reichen, wenn bei den (Windows-)Rechnern im Lehrernetz bei der Anmeldung eben die Domäne LEHRER voreingestellt ist und bei den Rechnern der Schüler die Domäne SCHULE. Er gibt sein Login und Passwort ein wie gewohnt und fertig.
Hier einige Ansatzpunkte zu Vertrauensstellungen in Samba: https://books.google.de/books?id=JerK9MI3zJYC&pg=PA256&lpg=PA256&dq=samba+vertrauensstellung+zwischen+dom%C3%A4nen&source=bl&ots=SmTEjuFw5V&sig=57biT9oLxxH1UiFpdqqYhx-WjpE&hl=de&sa=X&ei=ot0LVfj_MIfjUeuEgvgI&redir_esc=y http://www.administrator.de/frage/vertrauensstellung-zwischen-linux-windows-dom%C3%A4nen-31570.html
also wie schon gesagt: ich würde keine Vertrauensstellung brauchen, nichtmal haben wollen. Denn sonst ist es ja kaum vermittelbar, dass es sowas wie 2 getrennte Netze darstellen soll.
Um es nicht unnötig kompliziert zu machen (wenn es überhaupt ginge), würde ich zwei physikalische Server nehmen, allenfalls 2 virtualisierte, nicht jedoch versuchen zwei Instanzen von Samba auf einem Server zu implementieren.
Dann hast du doch auuch 2 Sambas, die zudem verschieden konfiguriert werden müssen - darum geht es ja. Aber: damit z.B. alle auf ihr Homeverzeichnis zugreifen können oder auf das Tauschlaufwerk (Lehrer von allen Rechnern!) müssen beiden Servern die Daten "untergeschoben werden. Das bedeutet, du brauchst einen weiteren Server für die Daten. Üblicherweise ein NAS. Nach meinen Vorstellungen braucht man den sowieso schon vorhandenen Samba "nur noch" einmal zu starten und natürlich entsprechend zu konfigurieren. Aber das muss man eh.
Ich sehe den Aufwand mit 2 Instanzen als deutlich geringer als 2 virtuelle Maschinen für die PDCs und dann noch eine für das NAS. Was das Problem ist (und dadurch ist es wohl deutlich schwieriger), dass es kaum einer macht und damit ist es doch neu. Aber auch der Netzbrief ist in seinen Anforderungen neu. (in meinen Bundesland wird es wohl noch ein paar Jahre dauern, eh das hier ankommt ;) )
Aber es war ja nur ein Vorschlag. Und ich wollte keineswegs hier nur meinen Senf dazu geben, sondern würde auch dabei mitarbeiten / mithelfen (auch wenn ich keine Linuxmuster-Lösung einsetze, würde das gehen).
Viele Grüße Hans-Dietrich
Gruß Jürgen P.S.: Den Ansatz die Netztrennung in der Anwendungsschicht zu sichern anstelle in TCP/IP finde ich alles andere als OT ;-) Am 20.03.2015 um 07:35 schrieb Hans-Dietrich Kirmse:Hallo Tobias, die Argumentation in deiner Mail finde ich sehr überzeugend. Wenn man den Gedanken weiterspinnt, kommt man doch zu folgender Lösung: Problem ist doch, dass sich der Computer nicht dafür authentifizieren muss, "im richtigen Netz" zu sein. Aber wenn man statt "richtigen Netz" eben in der "richtigen Domäne" verwendet, dann sollte ein Angriff über das Fälschen von MAC und IP ins Leere gehen. Will damit sagen: es müßten 2 Domänen konfiguriert werden. Die Rechner des Lehrernetzes kommen in die eine Domäne und die Rechner des pädagischen Netzes in die andere Domäne. Durch das Aufnehmen des Rechners in die Domäne durch den Administrator wird doch damit sicher gestellt, dass die Rechner im richtigen Netz sind - sonst geht die Anmeldung schief. Die Belastung der Lehrer nimmt nicht wirklich zu, weil doch bei den Rechnern die Domäne "voreingestellt" ist. Ob man mit einem Samba 2 Domänen konfigurieren kann, weiss ich nicht genau, ich denke aber ja. Aber zweifellos geht es mit 2 Instanzen von Samba. Da ist es kein Problem die entsprechenden Shares zuzuordnen und auch verschiedene Anmeldescripte zu verwenden. Alternativ kann man auch 2 Rechner (als PDCs) verwenden, muss aber dann die Shares beiden Rechnern zur Verfügung stellen, d.h. zumindest für mich, dass die auf ein NAS ausgelagert sein müssen. zusammengefasst: die Rechner müssen sich (ebenso wie die User) authentifizieren. Aber genau dafür gibt es doch die Domäne(n). Also startet man Samba zweimal und konfiguriert einen für das Lehrernetz und einen für das pädagogische Netz. m.E. braucht es dann keine VLANs, keine managebaren Switche ... Dumm ist, dass der Netzbrief von uneterschiedlichen Netzen schreibt. Hier würde aber der Zugriff aber durch die Software geregelt, die den Zugriff auf die Dateien verwaltet (also Samba). D.h. erst nach dem Netz. Das Netz wäre völlig irrelevant. Bemerkungen zur Umsetzung: so wie ich das sehe braucht man nur den Samba entsprechend zu konfigurieren (sollte einfach sein) und zweimal zu starten (das wäre ein Problem, denn man braucht ein weiteres Startscript - das kann ich aber nicht). Es reicht der eine LDAP. Um die 2. Domäne im LDAP anzulegen, dazu braucht man nichtmal einen Befehl für den LDAP, das geht mit Befehlen für Samba. Viele Grüße Hans-Dietrich Am 20.03.2015 um 05:42 schrieb "T. Küchel":Hallo Holger, ich hab noch mal nachgelesen und, wenn du nichts dagegen hast, poste ich hier mein (Un?)verständnis: Ich beziehe mich mal auf die Doku von Thomas, http://www.linuxmuster.net/wiki/dokumentation:addons:subnetting:l3switch Am 19.03.2015 um 19:14 schrieb Holger Baumhof:Also: ist das Netz richtig konfiguriert ist es nicht möglich, sich aus irgend einem anderen subnet als dem Lehrernetz dem server gegenüber als dem lehrernetz zugehörig aus zu geben.Das verstehe ich jetzt so: Hängt sich jemand an Thomas's L2-Switch 1 (Tags: 12,13,100,200) und gibt sich eine IP und MAC aus dem Lehrernetz, dann kann der L2-Switch ihn nicht taggen. Der Rechner muss aber über das Lehrernetz-Gateway 10.30.10.254 zum server, sonst kommt er gar nicht weiter. Das Gateway befindet sich aber im VLAN-50 getaggten Verkehr. Ich kann mir vorstellen, dass es von der Konfiguration der L2-Switche und des L3-Switches abhängt, was mit den nicht-getaggten Paketen des gefakten LZ-PCs passiert. Die Bilder suggerieren, dass man VLAN-50 Pakete von GE4 "ausschliessen" oder "verbieten" kann. Worin der Unterschied besteht, ... moment ... ja, so isses in etwa: http://www.cisco.com/c/dam/en/us/td/docs/switches/lan/csbms/sf30x_sg30x/administration_guide/78-19308-01.pdf S.228 " * Forbidden — The interface is not allowed to join the VLAN even from GVRP registration. [snip] * Excluded — The interface is currently not a member of the VLAN. This is the default for all the ports and LAGs. The port can join the VLAN through GVRP registration. " Ich lese weiter (S224) und vermute, dass man PVID noch setzen sollte und das nicht das Lehrer-netz-VLAN sein sollte. Möglicherweise noch "Ingress Filtering" einschalten. (S227) Ich behaupte also: mit einer gefakten MAC und IP bekomme ich am falschen Port bei richtiger Konfiguration entweder die falsche oder keine VLAN-ID im weiteren Verkehr und entsprechend der Konfiguration am L2/L3 Switch komme ich nicht weiter.. Was ist also, wenn der Spitzbube (Spitzmädel?) an der VLAN-tagging barriere vorbeikommt? (entweder Fehlkonfig: er bekommt am falschen Port trotzdem die richtige VLAN-ID 50, oder ich hab noch was falsch verstanden) Dann kommt er tatsächlich mit einer IP aus dem Lehrernetz beim Server an und der kann nicht feststellen, ob der Client an einem erlaubten Port hängt. Soweit so gut. Wenn aber die Fehlkonfig dran schuld ist, dann seh' ich für den L3-Router auch keinen Grund, warum er den Spitzbuben nicht zum NAS durchlassen sollte, ist ja im richtigen VLAN angekommen. ACL erlauben ihm das. Oder ich versteh etwas falsch: was? Nochmal anders herum: Eure Argumentation ist: Richtige IP+MAC, falsches VLAN - und bis zum Server kommt Verkehr zustande, zum LZ-NAS dagegen lässt der L3-Router aufgrund der VLAN-zugeordneten ACL keinen Verkehr zu. Dann ist der Knackpunkt doch im L3-Router: kann ich mich mit der richtigen IP+MAC (10.30.10.x) in einem falschen VLAN (100) (weiter)bewegen? Ich vermute stark: nein, denn ich sehe das falsche Gateway (10.20.100.254). Selbst wenn ich irgendwie durch Tricks als Client 10.30.10.x/12 eintrage um das gateway 10.20.100.254 in meinem netzbereich zu haben. STellt sich die Frage, ob solche Pakete im 10.30.10.x/24 Netz des Routers akzeptiert werden. Aha. Noch eine Erkenntnis! Und selbst wenn ich bis zum Server durchkomme: der bekommt durch das falsche VLAN die Anfrage auf einem falschen eth-Port (!) und kann sehr wohl erkennen, dass hier was im Argen liegt. Sprich: Samba sollte für das share-LZ-only nur auf dem Interface des richtigen VLAN (50) lauschen/empfänglich sein. ok. nach weiterer recherche: das geht wohl nur, wenn für das share-LZ-only ein extra samba mit der option "interfaces eth0.50 " gestartet wird (und beim regulären samba dort nicht lauscht). Dann haben wir, was ihr empfehlt: ein NAS im Lehrernetz, nur dass das NAS ein extra samba-Prozess auf dem server ist. Ist billiger als ein NAS :) Die Erkenntnis hat mich nur eine Nacht gekostet :)Beispiel: lehrerrechner 1 hat die MAC xx und die IP yy und ist in Subnet LZ Schüler mit Notebook ist in Subnet R155 (physikalisch, soll heißen: ihm stehen nur Dosen im R155 zur Verfügung keine im LZ), dann könnte er die MAC Adresse von lehrerrechner 1 fälschen und sich auch gleich die IP geben: trotzdem käme er nicht an das NAS, welches im Subnet LZ steht, weil weder L3 Switch noch Server ihn dort hin routen würden. Fälscht er nur die MAC, dann bekommt er in R155 eine IP vom DHCP aus dem für R155 vergebenen Lease: welches zumindest bei mir, garnichts darf: kein Serverzugriff und kein Internetzugriff.ist für mich verständlich: Er bekommt das VLAN-Tag von R155 und kommt beim Server über die Route der R155-254 IP des L3-Switch beim server an, d.h. der server kennt zwar seine MAC aus der "workstations", es entscheidet aber die Konfiguration des DHCP-Servers, welche IP er bekommt - und ich vermute, der DHCP gibt ihm nur eine aus dem R155-Netz, weil er über diese Route kam.Das habe ich so schon überprüft, da es auch ein deutlciher Nachteil ist. Beispiel: ich habe in der Schule 40 Laptops: die sind naturgemäß transportabel und genau für diesen Zweck angeschafft. "Verortet" habe ich sie im Subnet NWT. Wenn ich so ein Laptop an einen Port hänge, der in einem anderen subnet ist, so kennt der Server zwar eigentlich die MAC Adresse und kennt eigentlich auch eine IP, die er ihm geben müßte: er macht es aber nicht, weil er in einem fremden Subnet ist.obiges heißt für dich: wenn du GVRP an den entsprechend beteiligten Switches einschaltest, bekommt dein NWT-Laptop ein NWT-VLAN-ID-Tag, selbst wenn er am falschen Port hängt. DAs hatte ja schon mal jemand gepostet, dass das ("dynamic VLAN-tagging") geht. Stellt sich noch die Frage, warum man überhaupt verschiedene subnetze für Client-PCs braucht: Warum nicht *ein* "spielzimmernetz", in dem alle computerräume + nwt + medienstationen verortet sind und ein "lehrerimmernetz". Ich weiß - broadcasting vermeiden. Aber das ist halt die Abwägung wert. Warum nicht alle fest-installierten Computer-ports in so viele VLAN-Räume packen, wie man will. Alle anderen Ports in das "Spielzimmer".Bisher erscheint mir die Trennung Wasserdicht.Fazit für mich: 1. cool, wie das funktioniert. 2. cool, am ende braucht der server nur noch eine Netzwerkkarte (!) 3. Ich habe kapiert, dass der server u.U. die Herkunft der Anfrage nicht nachvollziehen kann. Ich behaupte aber, dass das NAS das dann auch nicht kann, d.h. ich sehe immer noch keinen sicherheits-vorteil eines NAS im Lehrernetz :) 4. oder der server kann die Herkunft doch nachvollziehen und dementsprechend samba konfiguriert werden. 5. ich stelle bei Durchsicht von Thomas' Beschreibung fest: jeder Server, der im "Serverraum" (VLAN 11) steht ist für Schüler-PCs zugänglich, nicht nur der Server selbst, d.h. ein Backup-NAS ist sinnvoller ins Lehrer-netz zu stellen (oder ein eigenes VLAN+subnetz aufmachen) (gilt bisher ja auch). puha, wiedermal was gelernt. Grüße, Tobias _______________________________________________ linuxmuster-user mailing list [email protected] https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user_______________________________________________ linuxmuster-user mailing list [email protected] https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user_______________________________________________ linuxmuster-user mailing list [email protected] https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
_______________________________________________ linuxmuster-user mailing list [email protected] https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
