Dort geht es ja um den Abschnitt Setup und Inbetriebnahme des Systems · linuxmuster/linuxmuster-base7 Wiki · GitHub - richtig?
Und eben der darin beschriebene Schritt (Zugangsdaten global-admin eintragen, Schlüsseltabelle erzeugen) bringt oben genannten Fehler…
Habe jetzt noch mal den Zugangs-Tester verwendet und jetzt kriege ich die Fehlermeldung:
ldap_error: Can’t contact LDAP server
Da ist jetzt irgendwie zu viel kaputt gegangen. Ich setze noch mal auf das BackUp der VM zurück und starte von da neu. Da gab es immerhin noch eine keytab ;-)…
Kannst Du mir zu der Frage der externen IPs noch mal helfen: Samba-Proxy-Anmeldung "zurücksetzen" - #17 von Guntram
Danke,
Guntram
Update:
opnSense-VM zurückgesetzt.
Beim Schlüssel-Erzeugen mit global-admin kommt jetzt wieder diese Meldung:
Error: another computer account (CN=FIREWALL,OU=server,OU=Devices,OU=default-school,OU=SCHOOLS,DC=linuxmuster,DC=lan) has the principal host/firewall
Error: ldap_add_principal failed
Das verstehe ich nicht…wieso „hat“ ein Account den „principal host/firewall“ (<- was soll das sein?) ?
Hallo,
das Thema IPv6 führt nur weg vom eigentlichen Problem. Es ist normal, dass auch für IPv6 ein Gateway angelegt wird, wenn DHCP aktiv ist. Solange dort keine IP dahinter steht, passiert da auch erstmal nichts. Die Firewall hat zeitweise DNS-Problem (mal geht es, mal nicht). Da aber nur IPv4-Adressen für DNS-Server eingetragen sind, spielt IPv6 keine Rolle, aber eine zweite DNS-Server-IP-Adresse hingegen schon.
Damit die Firewall linuxmuster.lan auflösen kann, darf sie auch nur den DNS-Server befragen, der weiß, welche IP linuxmuster.lan hat. Hast du wie im Abschnitt Single Sign-On aktivieren deine interne Schuldomain als Domainüberschreibung eingerichtet? Im Screenshot dort steht schule.lan, was bei dir linuxmuster.lan sein muss.
Du hast zwei Nameserver genannt. Welches Gerät steckt hinter 192.168.11.10? Nach meinem Verständnis dürfte dort nur die eine IP des LMN-Servers stehen. Falls eine der IPs ein externer Router/Firewall oder DNS-Server ist, sollte diese IP entfernt werden.
Dann gibt es ein weiteres Problem, dass in dem Fall, wo der LMS-Server kontaktiert werden kann, dieser sagt, es gibt schon ein Computerobjekt, welche den selben Principal erhalten soll. Hier kann ich gerade nicht beurteilen, ob CN=FIREWALL,OU=server,OU=Devices,OU=default-school,OU=SCHOOLS,DC=linuxmuster,DC=lan der vorgesehene Ort ist oder ob es sich um einen weiteren Eintrag an falscher Stelle handelt. Gibt es die Firewall zweimal in deiner Geräteliste in der LMN-Weboberfläche?
MfG Buster
Hallo Buster,
danke für die ausführliche Nachricht!
Bgzl. Domainüberschreibung:
Da habe ich diese beiden Einträge:
Das scheint also zu passen?
Ich vermute, die 192.168.11.10 war die alte IP (DHCP vom roten Netz ausgehend) des Servers vor Umzug. Ich habe den Eintrag jetzt in der GUI gelöscht.
In der /etc/resolv.conf auf der opnSense steht sie auch nach reboot noch drin:
root@firewall:~ # cat /etc/resolv.conf
domain linuxmuster.lan
nameserver 127.0.0.1
nameserver 192.168.11.10
nameserver 10.0.0.1
search linuxmuster.lan
Soll die da raus? Und die 127.0.0.1 vielleicht auch noch?
Bzgl. firewall in der Geräteliste: definitiv nur einmal drin.
Hallo,
Dann gibt es ein weiteres Problem, dass in dem Fall, wo der LMS-Server
kontaktiert werden kann, dieser sagt, es gibt schon ein Computerobjekt,
welche den selben Principal erhalten soll. Hier kann ich gerade nicht
beurteilen, obCN=FIREWALL,OU=server,OU=Devices,OU=default-school,OU=SCHOOLS,DC=linuxmuster,DC=lan| der vorgesehene Ort ist oder ob es sich um einen weiteren Eintrag an falscher Stelle handelt. Gibt es die Firewall zweimal in deiner Geräteliste in der LMN-Weboberfläche?
das Problem ist, dass die alte Firewall in die Domäne aufgenommen wurde
und dann immer mal wieder (vermute ich) ein neues Passwort für das
workstationaccount ausgehandelt hat.
Das Zurücksetzen der Firewall auf einen älteren Stand hat nun bewirkt,
dass der server die neuen credentials erinnert: die Firewall aber nicht
(ihr wurde ja ein Teil der Erinnerung gelöscht).
Die Firewall muss also neu in die Domäne aufgenommen werden, damit man
wieder keytabs erstellen kann… irgend wie hab ich ein Deja Vu: hab
ich das nciht schon vor ein paar Tagen geschrieben?
LG
Holger
Ich kann nichts finden :-(.
Das hat wahrscheinlich damals das Setup-Skript gemacht?
Oder ist das der Vorgang, welcher beim Importieren der devices.csv in der WebGUI ausgelöst wird?
Ich habe jetzt devices.csv neu importiert - die Fehlermeldung bleibt.
Wo finde ich Infos, wie ich die Firewall wieder in die Domäne aufnehme?
Danke,
Guntram
Hallo,
ich würde die Firewall aus der Geräteliste entfernen und die Liste importieren. Dadurch sollte das alte Objekt an falscher Stelle entfernt werden. Dann die Firewall wieder in die Geräteliste aufnehmen und diese importieren. Danach weiter wie in den Beiträgen zuvor erwähnt, um die keytab-Datei bzw. den Service-Principal zu erzeugen
VG Buster
Hallo Buster,
das war der richtige Tip(p) - danke!
Aber es hakte wohl noch immer an meiner DNS-Konfiguration.
Nach dem „säubern“ der Domäne konnte ich „Schlüsseltabelle erstellen“ ohne Fehler durchlaufen lassen. Der SSO-Tester funktionierte (hat aber ja auch schon vorher funktioniert), der Internetzugriff im Firefox fragt aber immer noch ununterbrochen nach den Zugangsdaten.
Anschließend habe ich „Schlüsseltabelle löschen“ gewählt und dann „Schlüsseltabelle erstellen“ und bin wieder bei diesem Fehler gelandet:
Password for global-admin@LINUXMUSTER.LAN:
-- init_password: Wiping the computer password structure
-- generate_new_password: Generating a new, random password for the computer account
-- generate_new_password: Characters read from /dev/urandom: 90
-- get_dc_host: Attempting to find domain controller to use via DNS SRV record in domain LINUXMUSTER.LAN for procotol tcp
-- DnsSrvQuery: Running DNS SRV query for _kerberos._tcp.dc._msdcs.LINUXMUSTER.LAN
-- get_dc_host: Attempting to find domain controller to use via DNS SRV record in domain LINUXMUSTER.LAN for procotol udp
-- DnsSrvQuery: Running DNS SRV query for _kerberos._udp.dc._msdcs.LINUXMUSTER.LAN
-- get_dc_host: Attempting to find a domain controller to use (DNS domain)
-- validate: Error: gethostbyname failed for LINUXMUSTER.LAN: Address family for hostname not supported
-- get_dc_host: Found preferred domain controller:
Error: get_dc_host failed
Ich habe dann noch mal die /etc/resolv.conf auf der OPNsense angeschaut und dort standen:
root@firewall:~ # cat /etc/resolv.conf
domain linuxmuster.lan
nameserver 127.0.0.1
nameserver 192.168.11.10
nameserver 10.0.0.1
search linuxmuster.lan
Ich habe dann die 127.0.0.1 und die 192.168.11.10 gelöscht, neu gestartet und jetzt ging die Erstellung der Schlüsseltabelle sowie das SSO im Browser 
!
Danke euch allen für die Geduld! Ich habe jetzt wieder ein kleines bisschen mehr von der Architektur verstanden!
Hallo,
ich glaube man sollte im OpnSense keine Konfigurationsdateien per Hand anpassen, da diese im Zweifel beim nächsten Update und/oder der nächsten Konfigurationsänderung, die über die Weboberfläche durchgeführt wird, überschrieben werden. Trage lieber die richtigen Werte an der richtigen Stelle in der Weboberfläche ein. Welche Stellen das sind, kann ich dir mangels OpnSense bei mir nicht sagen.
VG Buster
Hallo Buster,
das ist ein guter Hinweis. Das könnte der Grund gewesen sein, dass nach dem Update etwas schief gelaufen ist…
Falls jemand noch eine Idee hat, wo diese Werte in der Weboberfläche zu finden sind - ich habe sie nicht gefunden :-(…
Hallo,
ein bisschen mehr Mühe solltest du dir schon geben. Mindestens beim Durchklicken aller Konfigurationsseiten der Firewall solltest du diese Seiten finden:
- Settings - General - DNS-Server: Settings — OPNsense documentation
- Servives - DNS-Server Unbound: Unbound DNS — OPNsense documentation
- Services - DNS-Forwarder DSNmasq: Dnsmasq DNS — OPNsense documentation
Schau nach, ob dort die alte/falsche IP vorkommt und entferne sie.
VG Buster
Hallo Buster,
danke nochmals für Deine Hilfe! Diese Seiten hatte ich mir vorher schon durchgeklickt und nirgends war die alte IP zu finden - deswegen hatte ich ja auch nachgefragt, ob da vielleicht irgendwo etwas an unerwarteter Stelle zu finden sein könnte…
LG,
Guntram
Hallo,
dank dem Hinweis konnte ich mein Problem auch beheben. Allerdings hat es nicht gereicht, die Firewall aus der Geräteliste zu entfernen, das hat bei mir genau gar nichts bewirkt. Übrigens konnte ich bei einem späteren Test auch weiter die Keytab erstellen, obwohl das Gerät entfernt war.
Man möge mich wegen meines Leichtsinns steinigen, aber ich habe (nach vorherigem Snapshot) dann das Device „FIREWALL-K“ direkt aus dem AD gelöscht. Dann die Firewall wieder eine neue Keytab erstellen lassen und siehe da, ein neues FIREWALL-K-Device war im AD und die Anmeldung funktionierte wieder.
Meine Erfahrungen mit dem Firewall-Update:
- Niemals im laufenden Betrieb machen (so doof ist wohl außer mir auch keiner), denn dann bleiben von allen angemeldeten Nutzern die Kerberos-Tickets in Windows drin (Windows-Anmeldeinformationen, kann man dann da theoretisch auch löschen), und diese Nutzer können an diesen PCs nach dem Update nicht mehr ins Internet. Und
- wenn die Firewall und der Server auf unterschiedlichen Ständen sind (dieser Thread), dann aus der AD den FIREWALL-K rauslöschen, die Keytab löschen und neu anlegen. Es sei denn, dass hier jemand, der sich auskennt, da noch ein Veto einlegt…
Dank eurer Hilfe kann ich wieder ruhig schlafen, danke!
Hallo ringline,
doch, ich war auch so blöd
Bin genau wie du vorgegangen, und hab mich dann auch gewundert warum trotz Neuaufnahme der Firewall in der Geräteliste und Neuerstellung der squid-Keytab die Benutzer nicht ins Internet kamen (Proxy-Authentifizerungsdaten-Abfrage erschien). Hatte dann die Proxy-Authentifizierung abgeschaltet. Ca. 6 Stunden später am Tag wo schon Schule aus war hab ich die Authentifizierung wieder eingeschaltet und die Proxy-Abfrage erscheinte nicht mehr.
Greets
Chris
Tja, ich hatte mich auch zu früh gefreut, jetzt habe ich doch wieder die Probleme wie direkt nach dem Update der Firewall:
- Mitten während des Unterrichts kommt niemand mehr ins Internet. Während ich versucht habe, zu debuggen, ging es plötzlich wieder. Überlastungserscheinungen??
- Ich komme mit meinem Lehrer-Konto nicht mehr ins Internet. Grund: Mir fehlt plötzlich die Gruppe „Internet“ im AD. Wie kann ich mir die wieder zuweisen?
LG
Lars
Update: Bisher ist es ruhig und der Proxy scheint sich „gefangen“ zu haben.
Ich habe mich
samba-tool group addmembers internet username
wieder der Gruppe hinzugefügt und kann auch wieder ins Internet.
Außerdem habe ich zum Zeitpunkt des Proxy-Aussetzers noch Fehlermeldungen gefunden, die besagen, dass der LDAP-Server nicht kontaktiert werden konnte sowie zeitgleich, dass SSL von der ldap-library nicht supportet ist. Aber vorher und nachher und von allen anderen Systemen macht LDAP/LDAPS keine Probleme - also doch eine Überlastung durch die Kerberos-Abfragen?
Also es bleibt rätselhaft, auch warum bei meinem Lehreruser plötzlich die Internet-Gruppe fehlte, weil ich ja die ganzen Arbeiten logischerweise mit dem global-admin gemacht habe.
LG
Lars