Setup und Inbetriebnahme des Systems
Als Voraussetzung für das Setup muss die Firewall wie oben beschrieben eingerichtet sein und alle Appliances über das interne Netz verbunden sein und Internetverbindung haben.
-
Das Setup wird über den Befehl
linuxmuster-setupgestartet. Es können sämtliche Setup-Werte als Kommandozeilenparameter übergeben werden:
root@server:~# linuxmuster-setup -h
Usage: linuxmuster-setup [options]
[options] may be:
-n <hostname>, --servername=<hostname> : Set server hostname.
-d <domainname>, --domainname=<domainname> : Set domainname.
-r <dhcprange>, --dhcprange=<dhcprange> : Set dhcp range.
-o <opsiip>, --opsiip=<opsiip> : Set opsi ip.
-k <dockerip>, --dockerip=<dockerip> : Set docker ip.
-m <mailip>, --mailip=<mailip> : Set mailserver ip.
-a <adminpw>, --adminpw=<adminpw> : Set admin password.
-y <smtprelay>, --smtprelay=<smtprelay> : Set smtp relay.
-t <smtpuser>, --smtpuser=<smtpuser> : Set smtp user.
-p <smtppw>, --smtppw=<smtppw> : Set smtp user password.
-e <schoolname>, --schoolname=<schoolname> : Set school name.
-l <location>, --location=<location> : Set school location.
-z <country>, --country=<country> : Set school country.
-v <state>, --state=<state> : Set school state.
-c <file>, --config=<file> : path to ini file with setup values
-u, --unattended : unattended mode, do not ask questions
-s, --skip-fw : skip firewall setup per ssh
-h, --help : print this help -
Außerdem ermöglicht der Parameter --config eine Ini-Datei mit Setupwerten anzugeben. Beispiel:
[setup]
servername = server
domainname = linuxmuster.lan
opsiip = 10.0.0.2
dockerip = 10.0.0.3
mailip = 10.0.0.3
dhcprange = 10.0.0.100 10.0.0.200
smtprelay = mbox.belwue.de
smtpuser = [email protected]
smtppw = @pAssword!
adminpw = @pAssword!
schoolname = Linuxmuster
location = Schönau
country = DE
state = BW
skipfw = False -
Zusammen mit dem Parameter --unattended kann mit beiden Optionen ein automatisches Setup gestartet werden.
-
linuxmuster-setupohne Parameter aufgerufen, fragt zunächst alle benötigten Werte ab und richtet dann das System inklusive Firewall ein. -
Um die Opsi- bzw. Docker-Appliance zu konfigurieren, gibt man einfach an der entsprechende Stelle im Setup die zuvor mit linuxmuster-prepare vergebenen IP-Adressen der Appliances ein:
-
Der Docker-Mailserver wird eingerichtet, wenn man beim Setup die IP der Appliance auswählt, auf der er gehostet werden soll:
Es ist also auch möglich den Mailserver auf der Server-Appliance einzurichten. -
Nach dem das Setup durchgelaufen ist, muss der Server neu gestartet werden.
-
Die Setupwerte werden unter /var/lib/linuxmuster/setup.ini gesichert.
-
Wichtig: Das Administrator-Passwort, das beim Setup eingegeben werden muss, wird auf allen Appliances als Rootpasswort und außerdem für den Benutzer global-admin gesetzt.
- Der Zugriff auf das OPNsense-Webgui geschieht z. Bsp. über die Adresse https://firewall.linuxmuster.lan (Domäne ggf. anpassen).
- Das selbstsignierte Serverzertifikat muss akzeptiert werden.
- Zugriff von außen ist gesperrt. Portweiterleitungsregeln unter Firewall NAT für ssh, https, ldaps, smtp sind angelegt aber nicht aktiviert.
- Ebenso eine nicht aktive Regel Allow entire LAN unter Firewall | Regeln | LAN, die aus dem LAN uneingeschränkten Internetzugriff erlaubt.
- Darüberhinaus ist unter Firewall | Aliase ein NoProxy-Alias angelegt, die die ersten zehn IP-Adressen des LAN-Netzwerks und diejenigen der Server enthält. Für die Adressen dieses Aliases ist eine aktive Regel angelegt, die unbeschränkten Zugriff auf das Internet erlaubt. Eine IP-Adresse aus diesem Pool kann z.B. für einen Admin-PC verwendet werden, um die erste Einrichtung nach dem Setup durchführen zu können.
- Clients können nur über den OPNsense-Webproxy ins Internet. Dieser muss im Clientbetriebssystem an der entsprechenden Stelle eingetragen werden:
- Proxyadresse (muss mit FQDN eingetragen werden), z. Bsp. firewall.linuxmuster.lan:3128.
- Für alle Protokolle (http, https, ftp).
- Lokales Netz, localhost und Internetdomäne (z. Bsp. *.linuxmuster.net) ausnehmen.
- Die Client-Browser müssen so konfiguriert sein, dass sie die Firewalleinstellungen des Systems verwenden.
- Danach müssen sich die Nutzer für den Internetzugriff authentifizieren, falls man nicht wie unten beschrieben SSO aktiviert.
- Zusätzliche AD-Gruppen zur Beschränkung des Internet-Zugangs können im Webgui unter System | Zugang | Server | linuxmuster | Erweiterte Abfrage eingetragen werden. Per Default sind alle User in der Gruppe internet, die zum Surfen berechtigt.
- Clients, die ohne Proxy-Authentifizierung Internetzugriff haben sollen, trägt man einfach mit ihrer IP-Adresse zusätzlich in das NoProxy-Alias ein (s.o.).
Bemerkung: Dieser Schritt entfällt bei Installationen, die ab linuxmuster-base7 Version 7.0.54 (Update-Stand 12.03.2020) gemacht wurden. Der beschriebene Logintest kann selbstverständlich zur Überprüfung der Funktion weiter durchgeführt werden.
Ab OPNsense 18.1 ist Single Sign-On (SSO) in der Firewall-Appliance vorkonfiguriert. Um es zu aktivieren so vorgehen:
- Im ersten Schritt muss im OPNsense-Webinterface unter Dienste | Unbound DNS | Überbrückung der DNS-Dienst aktualisiert werden. Dazu einfach rechts oben die Aktualisierungsschaltfläche betätigen.
- Danach unter System | Zugang | Prüfer die Authentifizierung testen. Als Authentifizierungsserver linuxmuster auswählen falls noch nicht ausgewählt.
Geben Sie einfach einen gültigen Benutzernamen mit Passwort ein und betätigen Sie Test. - Ist der Test erfolgreich kann für den Web-Proxy SSO eingerichtet werden.
- Dazu zunächst unter Dienste | Web-Proxy | Verwaltung sicherstellen, dass der Proxy-Dienst läuft:
- Anschließend unter Dienste | Web-Proxy | Single Sign-On rechts oben den Reiter Kerberos Authentication auswählen.
- Weiter unten auf der Seite im Bereich Key Table Creation im Feld AD admin login den User global-admin eintragen. Darunter das Admin-Passwort eingeben, das beim Setup vergeben wurde.
- Die Schaltfläche Create Key Table bindet den Web-Proxy an das Samba-AD an.
- Ob SSO funktioniert kann man danach mit gültigen Accountdaten über die Schaltfläche Test Kerberos login prüfen.
- Nach erfolgreichem Test können die Benutzer nach erfolgter Domänenanmeldung am Client ohne weitere Authentifizierung surfen.
Auf Systemen, die mit linuxmuster-base7 >= 7.0.41 (23.07.2019) aufgesetzt wurden, ist der Radius-Dienst für das Standardnetz bereits automatisch eingerichtet. In dem Fall ist nur zu berücksichtigen, dass für weitere Subnetze gegebenenfalls entsprechende Clients definiert werden müssen (s.u. Clients definieren).
Auf vor diesem Datum aufgesetzten Systemen muss der Radius-Dienst von Hand eingerichtet werden. Wie das geht, ist im Folgenden dokumentiert.
- Die Erweiterung os-freeradius findet man im Web-UI unter System | Firmware | Erweiterungen. Die Installation startet man über die +-Schaltfläche rechts in der entsprechenden Zeile.
- Danach lädt man die Seite neu und findet unter Dienste einen neuen Menüpunkt FreeRADIUS.
- Unter Dienste: FreeRADIUS: Allgemein ist bei Aktivieren und Aktiviere LDAP ein Haken zu setzen. Anschließend sollte man nicht vergessen die Änderungen zu speichern.
- Für jeden Netzbereich, aus dem auf den Dienst zugegriffen werden soll, muss ein sogenannter Client angelegt werden.
- Die zuständige Konfigurationsseite findet man unter Dienste: FreeRADIUS: Clients. Über die +-Schaltfläche legt man einen neuen Eintrag an.
-
Name und Geheimnis sind frei wählbar. Der Netzbereich muss in CIDR-Notation eingetragen werden.
- Hier legt man für jedes zu nutzende Subnetz einen Client-Eintrag an.
- Das Betätigen der Schaltfläche Anwenden schließt diesen Konfigurationsschritt ab.
Unter dem Menüpunkt Dienste: FreeRADIUS: EAP wird das Extensible Authentication Protocol konfiguriert. Wie sieht man auf dem folgenden Screenshot:
Im letzten Schritt der Radius-Konfiguration muss die Authentifizierung gegen das AD des linuxmuster.net-Servers eingerichtet werden. Zuständig hierfür ist der Menüpunkt Dienste: FreeRADIUS: LDAP. Dazu muss man die Basis DN (BaseDN) wissen, die man auf dem Server in der Datei /var/lib/linuxmuster/setup.ini nachschauen kann. Das Passwort des Bind-Users holt man aus /etc/linuxmuster/.secret/global-binduser. Ist das System mit der Standarddomäne linuxmuster.lan aufgesetzt, lauten die entsprechenden Einträge wie folgt:
Protokolltyp LDAPS
Server server.linuxmuster.lan
Bindungsnutzer CN=global-binduser,OU=Management,OU=GLOBAL,DC=linuxmuster,DC=lan
Bind Passwort ****************
Basis DN OU=SCHOOLS,DC=linuxmuster,DC=lan
Benutzerfilter (&(objectClass=person)(sAMAccountName=%{%{Stripped-User-Name}:-%{User-Name}})(memberOf=CN=wifi*))
Gruppenfilter (objectClass=group)
Im Benutzerfilter wird sichergestellt, dass der Benutzer Mitglied der Gruppe wifi ist.
Abschließend muss noch eine Firewall-Regel angelegt werden, die Zugriffe auf den Radius-Port 1812 der Firewall aus dem LAN heraus erlaubt. Das erledigt man unter dem Menüpunkt Firewall: Regeln: LAN.
- Dazu klont man einfach die Regel 2 Allow Web-Proxy-Access.
- In der neuen Regel passt man folgende Werte an:
Protokoll UDP
Zielportbereich von 1812
Zielportbereich an 1812
Beschreibung Allow FreeRADIUS Authentication
Damit ist die Radius-Konfiguration komplett.
Zum Testen kann man auf dem Server das Paket freeradius-utils installieren. Ob die Authentifizierung gegen den Radius-Dienst der Firewall funktioniert, testet man mit dem Tool radclient (User-Passwort und Radius-Geheimnis sind anzupassen):
echo "User-Name=zell,User-Password=Muster!" | radclient -x -P udp -s 10.0.0.254:1812 auth "$(cat /etc/linuxmuster/.secret/radiussecret)"
Die erfolgreiche Rückmeldung sieht dann so aus:
Sent Access-Request Id 229 from 0.0.0.0:57233 to 10.0.0.254:1812 length 44
User-Name = "zell"
User-Password = "Muster!"
Cleartext-Password = "Muster!"
Received Access-Accept Id 229 from 10.0.0.254:1812 to 0.0.0.0:0 length 20
Packet summary:
Accepted : 1
Rejected : 0
Lost : 0
Passed filter : 1
Failed filter : 0
Nimmt man jetzt den Benutzer aus der Gruppe wifi raus
sophomorix-managementgroup --nowifi zell
und testet dann die Radius-Authentifizierung, sieht man, dass sie fehlschlägt:
echo "User-Name=zell,User-Password=Muster!" | radclient -x -P udp -s 10.0.0.254:1812 auth "Muster!"
Sent Access-Request Id 10 from 0.0.0.0:34707 to 10.0.0.254:1812 length 44
User-Name = "zell"
User-Password = "Muster!"
Cleartext-Password = "Muster!"
Received Access-Reject Id 10 from 10.0.0.254:1812 to 0.0.0.0:0 length 20
(0) -: Expected Access-Accept got Access-Reject
Packet summary:
Accepted : 0
Rejected : 1
Lost : 0
Passed filter : 0
Failed filter : 1
Das Setup erzeugt eine CA und mit deren Root-Zertifikat selbstsignierte Serverzertifikate für Server und Firewall. Das Root-Zertifikat ist unter /etc/linuxmuster/ssl/cacert.crt abgelegt und kann auf den Clients importiert werden.
Der CA-Root-Key liegt unter /etc/linuxmuster/ssl/cakey.pem und ist mit einem Passwort gesichert, das unter /etc/linuxmuster/.secret/cakey abgelegt ist.
Das Skript
/usr/share/linuxmuster/examples/create-testusers.py
legt die üblichen Verdächtigen an. Passwort ist für alle Testuser das beim Setup gesetzte Adminpasswort.
Der Domänenbeitritt kann mit dem User global-admin und dem beim Setup angegebenen Administrator-Passwort durchgeführt werden. Alternativ kann der Benutzer Administrator verwendet werden, dessen Passwort unter /etc/linuxmuster/.secret/administrator gespeichert ist.
- wird jetzt so aufgerufen:
# linuxmuster-import-devices - Die Workstationsdatei für die Default-School liegt unter /etc/linuxmuster/sophomorix/default-school/devices.csv.
- Ein Eintrag für einen Rechner muss z. Bsp so aussehen:
r100;r100-pc01;win10-efi;00:50:56:3E:A5:7C;10.0.100.1;;;;computer;;2Feld 9 enthält die Rolle des Geräts, Feld 10 ist reserviert/ungenutzt. Näheres siehe Manpage von devices.csv.
LDAP/AD können mit der Benutzer-DN
CN=global-binduser,OU=Management,OU=GLOBAL,DC=linuxmuster,DC=lan
abgefragt werden. Das Passwort ist unter /etc/linuxmuster/.secret/global-binduser abgelegt.