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 ;-)…
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?) ?
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?
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:
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?
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?
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
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:
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!
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.
ein bisschen mehr Mühe solltest du dir schon geben. Mindestens beim Durchklicken aller Konfigurationsseiten der Firewall solltest du diese Seiten finden:
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…
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!
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.
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?
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.