die nachfolgende Diskussion scheint mir zwar noch nicht zu einem abschließenden Ergebnis gekommen zu sein, aber es ist gut, dass sie geführt wird: Eine Schullösung braucht natürlich eine Möglichkeit der Webfilterung.-
Noch eine Frage zu deinem augenblicklichen Stand: Was steht bei deinen Clients in den Einstellungen für den Netzwerkproxy?
super: vielen Dank, jetzt hab ich es kapiert.
… allerdings bleibt eine Frage offen. Ich weiß jetzt wo der externe DNS hin muss: in den unbound auf der OPNsense… nun steht da aber keiner.
Wie löst mein Netz den nun externe domains auf? … wenn nirgendwo ein externer DNS eingetragen ist?
Bei den Einstellungen des unbound hab ich auch kein Feld gesehen wo man einen DNS eintragen könnte …
Das müsstest Du mit dem dig-Befehl sehen können … sowas wie: dig @10.16.1.1 firewall fragt den lml7-Server nach dem Namen …
dabei kannst du natürlich das @ … auch weglassen und eine externe domain nehmen, sowas wie: dig (mit/ohne @firewall) heise.de
hth,
Michael
Bei den allgemeinen DNS-Einstellungen den LMN-Server rausnehmen und dort nur den vorgelagerten DNS eintragen
Bei den Unbound-Einstellungen unter Allgemeines den Forwarding-Mode aktivieren
Bei den Unbound-Einstellungen unter Overrides ein Domain-Override für linuxmuster.lan auf die 10.0.0.1 anlegen, damit die Schulnetz-Adressen wieder aufgelöst werden
Das habe ich aber nicht getestet.
Den vorgelagerten DNS bei Samba einzutragen ist aus meiner Sicht durchaus auch eine gute Option.
In der Tat wäre es gut, wenn hier ein offiziell unterstütztes bzw. empfohlenes Vorgehen dokumentiert werden könnte.
Im UnboundDNS kann man auch keinen DNS Forwarder eintragen. Dieser nutzt die Root Nameserver:
Würde man statt dem UnboundDNS den Dnsmasq verwenden, welchen die OPNsense ebenfalls anbietet, so könnte man dort mit einer eigenen Konfigurationsdatei den DNS Forwarder eintragen z.B.:
Wenn man dnsmasq verwendet, müsste man auch noch die Domain und Host Overrides konfigurieren, so wie das Linuxmuster Setup das schon mit dem UnboundDNS vornimmt.
Man kann Webfilterung statt auf DNS Ebene auch auf URL Ebene betreiben. Diese Möglichkeit bietet der Squid Proxy bereits mit der Möglichkeit externe Filterlisten, wie z.B. die Shallalist zu integrieren. Der Vorteil gegenüber einer globalen DNS Sperrliste ist, daß man dann je nach Gruppenzugehörigkeit filtern kann. Also zum Beispiel für „teachers“ kein Filter, für „students“ der Filter. Wenn man den Aufwand der Unterscheidung nicht betreiben möchte, geht das ziemlich einfach.
der Unbound kann schon mit Forwardern umgehen. Man kann das bei der OPNSense auch im Webfrontend konfigurieren. In den Konfigurationsdateien kann man das sehr detailliert feintunen (verschiedene Forwarder für verschiedene Domains), dass sollte eigentlich die „Domain Override“ Einstellung im Webfrontend sein.
Zum SSO kann ich nichts sagen, das habe ich nicht getestet. Wenn dafür nur die internen Hosts aufgelöst werden müssen, dann sollte das so gehen (es muss dazu natürlich in der resolv.conv die 127.0.0.1 stehen). Wenn mehr erforderlich ist, dann vielleicht auch nicht. Vielleicht probiere ich es einfach mal aus. Einfacher erscheint mir aber in der Tat, einen Forwarder in Samba einzutragen.
Wie gesagt wäre es toll, wenn ein offizieller Weg dokumentiert würde, das wäre die beste Lösung.
… also ich blicke durch die hier zu treffenden Einstellungen nun auch nicht mehr durch. Bin gerade nochmal an den Anfang dieses Threads gesprungen und da gibt es bei uns einige Abweichungen. Allerdings habe ich bei Webproxy → SSO → Kerberos leider genauso viele rote wie grüne „Punkte“:
Wir haben die Webfilterung per SSO bisher nicht verwendet … ist es dennoch möglich, dass mein Anmeldeproblem unter Linux mit diesen Settings zusammenhängen könnte??
wahrscheinlich brauchen wir 2 dokumentierte Lösungswege. Einmal für einen DNS-Eintrag, z. B. für Belwue, wobei offen ist, ob der noch lange funktioniert. Dazu hat Dominik schon einmal eine Lösung vorgeschlagen:
Und außerdem die Möglichkeit der Filterung mit Listen, z. B. der shallalist.
Hi.
Ich frische diesen Thread aus aktuellem Anlass nochmal auf …
Wir nutzen im Moment kein SSO – dafür aber diverse Netze, die auch unabhängig vom „grünen“ Servernetz laufen. Also z.B. eine DMZ sowie das WLAN. Nun ist es ja eigentlich so, dass man auf der OPNSense als DNS-Server den v7-Server eintragen soll (und zwar NUR den).
Daher nochmal zu den OPNSense-Einstellungen unter
System: Einstellungen: Allgemein
Ich habe dort im Moment diese Einstellungen, frage mich aber, ob der Server 10.16.1.1 nicht an erster Stelle stehen sollte …
(Das Problem sind nicht die Clients, die der v7-Server aufgrund der devices.csv kennt – sondern alle anderen.)
Ich hole diesen Thread nochmal nach oben … ich bin gerade nochmal alles von vorne bis hinten durchgegangen.
Hier ist es genauso wie von Klaus (@garblixa ) beschrieben: Nur wenn ich auf der OPNSense unter System → Einstellungen → Allgemein bei den DNS-Servern NUR noch die 10.16.1.1 eintrage, liefert die Kerberos-Authentifizierung sofort überall grüne Häkchen.
Trage ich hingegen einen anderen DNS-Server wie z.B. 9.9.9.9 mit ein, sind einige der Haken rot.
Andererseits funktioniert aber die DNS-Auflösung vom Server aus nicht mehr, wenn dort nur die 10.16.1.1 steht (wie das ja hier mehrfach vorgeschlagen wurde).
Also konkret:
Auf dem Server liefert dig linuxmuster.net @10.16.1.1 nichts mehr, wenn auf der OPNSense kein weiterer DNS-Server neben der 10.16.1.1 eingetragen wurde.
Daher nochmal die Frage in die Runde: Welche Einstellungen für den DNS-Server im Zusammenspiel mit dem Unbound sind richtig?
[etwas später…]
Ich glaube jetzt hab ich’s!
Im Moment ist es so: Unter System → Einstellungen → Allgemein bei den DNS-Servern steht NUR die 10.16.1.1
aber unter Dienste → Unbound → Unbound DNS → Query Forwarding ist der Haken bei [ ] Use System Nameservers NICHT mehr gesetzt. Stattdessen sind die DNS-Server darunter als Custom forwarding eingetragen, damit die 10.16.1.1 in dieser Liste nun nicht mehr mit auftaucht!!
Mit diesen Einstellungen wird auf dem Server dig irgendein.server.im.inter.net richtig aufgelöst.
Auf der Firewall geht auch drill ein.server
Außerdem zeigt die Kerberos-Authentifizierung jetzt überall grüne Häkchen.
Scheint also zu passen?!
Hallo Alois … vielleicht ist das wieder so ein Fall, wo unser Setup „intern wie extern der gleiche FQDN“ zuschlägt?
Ich hatte jedenfalls bisher noch nie alle Häkchen grün bei der Kerberos-Authentifizierung – erst seitdem ich diese Einstellung gewählt habe!