Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- invis_server_wiki:client [2016/11/16 08:18]
flacco [sssd-Konfiguration invis-Server Classic]
+++ invis_server_wiki:client [2018/03/09 07:50]
flacco [openSUSE Leap]
@@ Zeile 24: / Zeile 24: @@
 Domänenbeitritte können nicht mit den Personal-Versionen von Windows durchgeführt werden (OK -- Heise hat gezeigt, dass es mit XP Home mit ein bisschen getrickse doch geht.).
-  - Ist der PDC ein Samba-PDC mit NTLM Domäne (**invis Classic**) müssen zunächst zwei Einträge in der Win7 Registry geändert werden. Einen fertigen Patch gibt es [[https://bugzilla.samba.org/attachment.cgi?id=4988&action=view|hier]]. (Zusätzliche Infos [[http://wiki.samba.org/index.php/Windows7|hier]]). Ein Windows Neustart ist nach Einspielen des Patches nicht nötig.
+  - Ist der PDC ein Samba-PDC mit NTLM Domäne (**invis Classic**) müssen zunächst zwei Einträge in der Win7 Registry geändert werden. Einen fertigen Patch gibt es [[https://bugzilla.samba.org/attachment.cgi?id=4988&action=view|hier]]. (Zusätzliche Infos [[http://wiki.samba.org/index.php/Windows7|hier]]). Ein Windows Neustart ist nach Einspielen des Patches nicht nötig. In Verbindung mit Active-Directory Domänen entfällt dieser Schritt.
   - Unter Windows 7 lässt sich die Funktion "Einer Domäne Beitreten" am besten über die Desktop-Suche finden. Einfach //Domäne// in der Suchleiste eingeben und dann auf den entsprechenden Menüeintrag klicken.
   - Als nächstes auf die Schaltfläche "Ändern" klicken und dann das Feld "Domäne" aktivieren, den Domänennamen eintragen und mit OK bestätigen.
@@ Zeile 74: / Zeile 74: @@
 ===== Linux Clients mit SSSD integrieren =====
-Anbindung von Linux-Clients an einen invis-Server. Die folgende Beschreibung orientiert sich an **Ubuntu 12.04 LTS** und **Linux Mint 17 "Qiana"** (Getestet auch mit Linux Mint 13 "Maya"), gilt aber prinzipiell auch für andere Linux-Distributionen. Unter **openSUSE** kann der Vorgang bezogen auf den invis-Classic vollständig mit **YaST** vorgenommen werden. Die Anbindung an die Active-Directory Variante erfordert etwas mehr Handarbeit.
+Anbindung von Linux-Clients an einen invis-Server. Die folgende Beschreibung orientiert sich an **Ubuntu 12.04 LTS** und **Linux Mint 17 "Qiana"** (Getestet auch mit Linux Mint 13 "Maya"), gilt aber prinzipiell auch für andere Linux-Distributionen.
+==== openSUSE Leap ====
+Für openSUSE Leap basierte Clients stellen wir ein eigenes Setup-Paktet über unsere Repositories zur Verfügung, mit dem sich der ganze Vorgang der Client-Anbindung automatisieren lässt. Unter der aktuellen openSUSE Leap 42.3 lässt sich das entsprechende Repository wie folgt einrichten:
+<code>
+invis-client:~ # zypper ar https://download.opensuse.org/repositories/spins:/invis:/unstable/openSUSE_Leap_42.3/spins:invis:unstable.repo
+</code>
+Danach kann das Setup-Paket dann installiert werden:
+<code>
+invis-client:~ # zypper ref
+invis-client:~ # zypper in invisAD-client
+</code>
-Kern der Beschreibung ist die Anbindung eines Linux-Clients an eine LDAP-gestützte Benutzerverwaltung mit Hilfe des noch recht jungen System Security Services Daemon (SSSD). Nicht alle Distributionen haben den SSSD bereits vollständig integriert, daher muss in vielen Fällen wie beim hier gezeigten Ubuntu die Einrichtung vollständig manuell durchgeführt werden.
-SSSD erschließt der Linux-Welt einen Vorteil, der bisher nur Windows-Nutzern zugänglich war. Er bietet die Möglichkeit einer Offline-Anmeldung. D.h. Ein Benutzerkonto steht auf einem Client auch dann zur Verfügung, wenn keine Verbindung zum Server besteht. Spannend vor allem für die Nutzung auf Notebooks.
-Um das zu erreichen baut und pflegt SSSD lokal einen Cache der Benutzerverwaltung. Nachteilig daran ist bisher, dass es nicht möglich ist ein Aktualisieren des Caches zu triggern. Daraus resultiert oft eine zeitliche Verzögerung, bis Änderungen, die an der Benutzerdatenbank des Servers vorgenommen wurden auf dem Client zur Verfügung stehen. Wird beispielsweise auf dem Server eine neuer Benutzer angelegt, können einige Minuten vergehen, bis sich der Benutzer tatsächlich anmelden kann.
 ==== 1. Freigaben einbinden ====
 Zur Anbindung eines Linux-Clients an den Server müssen zunächst die Server-Freigaben **home** und **shares** per NFSv4 ins lokale Verzeichnissystem eingehängt werden. Dazu sind in der Datei <file>/etc/fstab</file> folgende Einträge vorzunehmen:
@@ Zeile 100: / Zeile 113: @@
 ==== 2. Benutzerverwaltung ====
-Die folgenden Erläuterungen beschreiben die Anbindung eines Linux-Clients an einen invis-Server, sowohl AD, als auch Classic. Für die Anbindung von openSUSE Leap (42.1) an einen invis AD Server steht in unserem Github-Repository inzwischen ein Client-Setup-Script zur Verfügung, welches die Anbindung vollständig automatisch durchführt.
+Die folgenden Erläuterungen beschreiben die Anbindung eines Linux-Clients an einen invis-Server, sowohl AD, als auch Classic. Für die Anbindung von openSUSE Leap (42.x) an einen invis AD Server steht in unserem Github-Repository inzwischen ein Client-Setup-Script zur Verfügung, welches die Anbindung vollständig automatisch durchführt.
 **[[https://github.com/invisserver/invisAD-client]]**
@@ Zeile 259: / Zeile 272: @@
 </code>
+Grundsätzlich ist der SSSD relativ sparsam mit dem Schreiben von Fehlerprotokollen, was natürlich dei Fehlersuche nicht gerade erleichtert. Um den Loglevel auf ein brauchbares Niveau anzuheben hat sich in den einzelnen Sektionen der Konfigurationsdatei folgende Einstellung bewährt:
+<code>
+debug_level = 0x0370
+</code>
+Der Debug-Level kann für die einzelnen Sektionen "[sssd]", "[nss]", "[pam]" und "[domain/...]" auch individuell gesetzt werden. Weitere Infos zum Debug-Level sind in der Manpage des Dienstes zu finden (https://jhrozek.fedorapeople.org/sssd/1.13.1/man/sssd.conf.5.html)
 === Name-Service-Switch anpassen ===
@@ Zeile 274: / Zeile 294: @@
 === PAM konfigurieren ===
-Auch die PAM Module für die Benutzeranmeldung am System müssen an den **sssd** angepasst werden. Dies kann mit Hilfe des Tools //**pam-config**// vorgenommen werden:
+Auch die PAM Module für die Benutzeranmeldung am System müssen an den **sssd** angepasst werden. Dies kann im einfachsten Fall mit Hilfe des Tools //**pam-config**// vorgenommen werden:
 <code>
@@ Zeile 280: / Zeile 300: @@
 </code>
+Linux Mint (und daher vermutlich auch Ubuntu, man entschuldige hier meine Unwissenheit...) verfügen alternativ über das Programm //**pam-auth-update**// mit dem die PAM-Konfiguration recht komfortabel generiert bzw. aktualisiert werden kann. Bei dessen Verwendung ist (so nicht bereits geschehen, einfach der Punkt "SSS authentication" im Auswahlmenü zu aktivieren.
+Leider haben nicht alle Linux-Distributionen entsprechende Tools im Gepäck. Ist dies der Fall und PAM wird nicht beim Installieren neuer PAM-Module automatisch von der verwendeten Linux-Distribution angepasst, müssen die relevanten PAM-Konfigurationen händisch angepasst werden. Dies sind in aller Regel 4 Dateien im Verzeichnis: <file>/etc/pam.d</file>
+Hier Beispielhaft die Dateien aus Linux Mint 17.3, relevant sind immer die Zeilen in denen auf **pam_sss.so** Bezug genommen wird:
+**common-account**
+<code>
+...
+# here are the per-package modules (the "Primary" block)
+account [success=1 new_authtok_reqd=done default=ignore]        pam_unix.so
+# here's the fallback if no module succeeds
+account requisite                       pam_deny.so
+# prime the stack with a positive return value if there isn't one already;
+# this avoids us returning an error just because nothing sets a success code
+# since the modules above will each just jump around
+account required                        pam_permit.so
+# and here are more per-package modules (the "Additional" block)
+account sufficient                      pam_localuser.so
+account [default=bad success=ok user_unknown=ignore]    pam_sss.so
+# end of pam-auth-update config
+</code>
+**common-auth**
+<code>
+...
+# here are the per-package modules (the "Primary" block)
+auth    [success=2 default=ignore]      pam_unix.so nullok_secure
+auth    [success=1 default=ignore]      pam_sss.so use_first_pass
+# here's the fallback if no module succeeds
+auth    requisite                       pam_deny.so
+# prime the stack with a positive return value if there isn't one already;
+# this avoids us returning an error just because nothing sets a success code
+# since the modules above will each just jump around
+auth    required                        pam_permit.so
+# and here are more per-package modules (the "Additional" block)
+auth    optional        pam_ecryptfs.so unwrap
+auth    optional                        pam_cap.so
+# end of pam-auth-update config
+</code>
+**common-password**
+<code>
+...
+# here are the per-package modules (the "Primary" block)
+password        requisite                       pam_pwquality.so retry=3
+password        [success=2 default=ignore]      pam_unix.so obscure use_authtok try_first_pass sha512
+password        sufficient                      pam_sss.so use_authtok
+# here's the fallback if no module succeeds
+password        requisite                       pam_deny.so
+# prime the stack with a positive return value if there isn't one already;
+# this avoids us returning an error just because nothing sets a success code
+# since the modules above will each just jump around
+password        required                        pam_permit.so
+# and here are more per-package modules (the "Additional" block)
+password        optional        pam_gnome_keyring.so
+password        optional        pam_ecryptfs.so
+# end of pam-auth-update config
+</code>
+**common-session**
+<code>
+...
+# here are the per-package modules (the "Primary" block)
+session [default=1]                     pam_permit.so
+# here's the fallback if no module succeeds
+session requisite                       pam_deny.so
+# prime the stack with a positive return value if there isn't one already;
+# this avoids us returning an error just because nothing sets a success code
+# since the modules above will each just jump around
+session required                        pam_permit.so
+# The pam_umask module will set the umask according to the system default in
+# /etc/login.defs and user settings, solving the problem of different
+# umask settings with different shells, display managers, remote sessions etc.
+# See "man pam_umask".
+session optional                        pam_umask.so
+# and here are more per-package modules (the "Additional" block)
+session required        pam_unix.so
+session optional                        pam_sss.so
+session optional        pam_systemd.so
+session optional        pam_ecryptfs.so unwrap
+session optional                        pam_ck_connector.so nox11
+# end of pam-auth-update config
+</code>
+Alle gezeigten Beispiele stammen aus einer Anbindung an einen invis-Classic Server.
 === Kerberos Konfiguration für Client-Anbindung an invis-Server ActiveDirectory ===
@@ Zeile 350: / Zeile 460: @@
 Geeignet ist das folgende Setup für Notebooks die unterwegs genutzt werden sollen oder den PC im Home-Office.
-Ziel des Setups ist es von Ferne via OpenVPN und NFS vollständigen Zugriff auf den Datenbestand und die Webapplikationen des invis-Servers zuzugreifen. Für diesen Zweck wird lokal ein Benutzerkonto genutzt werden, welches zum Zeitpunkt des Logins noch nicht zur Verfügung steht. D.h. es wird vor allem ein lokales Home-Verzeichnis benötigt, da ohne ein solches ein Login an einer graphischen Oberfläche unter Linux nicht möglich ist.
+Ziel des Setups ist es von Ferne via OpenVPN und NFS vollständigen Zugriff auf den Datenbestand und die Webapplikationen des invis-Servers zu erhalten. Für diesen Zweck wird lokal ein Benutzerkonto benötigt, da zum Zeitpunkt des Logins die Verbindung zum Server noch nicht zur Verfügung steht. D.h. es wird vor allem ein lokales Home-Verzeichnis benötigt, da ohne ein Solches, ein Login an einer graphischen Oberfläche unter Linux nicht möglich ist.
-Geht man wie oben von einer Ubuntu- oder Mint-Installation aus, wird zum Anlegen dieses Home-Verzeichnisses wie auch zur Konfiguration des SSSD zunächst ein Systemverwalter-Konto benötigt, da ein Root-Zugang unter Ubuntu normalerweise nicht zur Verfügung steht.
+Geht man wie oben beschrieben von einer Ubuntu- oder Mint-Installation aus, wird zum Anlegen dieses Home-Verzeichnisses wie auch zur Konfiguration des SSSD zunächst ein Systemverwalter-Konto benötigt, da ein Root-Zugang unter Ubuntu normalerweise nicht zur Verfügung steht.
-Mit diesem Konto kann der Zugriff auf die Benutzerverwaltung des invis-Servers eingerichtet werden. Für ein Notbook kann das der Einfachheit halber direkt im Netzwerk des invis-Servers erfolgen, der PC im Home-Office wiederum benötigt zunächst eine OpenVPN-Verbindung zum invis-Netzwerk. Das Konto wir später nicht mehr benötigt.
+Mit diesem Konto kann der Zugriff auf die Benutzerverwaltung des invis-Servers eingerichtet werden. Für ein Notbook kann das der Einfachheit halber direkt im Netzwerk des invis-Servers erfolgen, der PC im Home-Office wiederum benötigt zunächst eine OpenVPN-Verbindung zum invis-Netzwerk. Das Konto wird später nicht mehr benötigt.
 Ziel ist unter Anderem auch der Zugriff auf das eigene Home-Verzeichnis auf dem invis-Server. Da dieses zum Zeitpunkt der lokalen Anmeldung aber noch nicht zur Verfügung steht, kann es nicht wie bei lokalen PCs nach "/home" gemountet werden.
@@ Zeile 406: / Zeile 516: @@
 # Authentifizierung und Verschluesselung
 tls-client
-auth SHA1
+auth SHA512
-tls-remote server.ihredomain.de
+cipher AES-256-CBC
 ....
 # The hostname/IP and port of the server.
@@ Zeile 522: / Zeile 632: @@
 //**Achtung:** Das gilt nur für Ubuntu und nicht für openSUSE. Dort genügt es eine fehlerhafte "resolv.conf" zu löschen und die Netzwerkverbindung kurz zu unterbrechen. Danach wird automatisch eine neue "resolv.conf" erzeugt.//
+Hier noch der Vollständigkeit halber das //**invisconnect**// Script:
+<code>
+#!/bin/bash
+# (c) 2015 Stefan Schaefer - invis-server.org
+# License: GPLv3
+ovpnconf="/etc/openvpn/vpn-client.ovpn"
+mntpathbase="/mnt/invis"
+domain="invis-net.loc"
+invisip="192.168.220.10"
+delay=20
+usage() {
+    echo -e "Geben Sie an, ob Sie die Verbindung zum Server aufbauen oder trennen möchten."
+    echo -e "Verbinden:\tinvisconnect c"
+    echo -e "Trennen:\tinvisconnect d"
+}
+case "$1" in
+    "c")
+            # OpenVPN Verbindung aufbauen
+            sudo /usr/sbin/openvpn --config $ovpnconf --daemon -log ovpnsession.log
+            # invis Server Freigaben einhaengen
+            echo "$delay Sekunden Wartezeit, bevor das Script fortgesetzt wird."
+            sleep $delay
+            # invis DNS Server nutzen
+            # resolv.conf sichern
+            sudo mv /etc/resolv.conf /etc/resolv.conf.ori
+            # temporaere resolv.conf erzeugen
+            sudo echo -e "search $domain" > /tmp/resolv.conf
+            sudo echo -e "nameserver $invisip" >> /tmp/resolv.conf
+            sudo mv /tmp/resolv.conf /etc/resolv.conf
+            # Testen, ob Zielverzeichnisse vorhanden, wenn nicht anlegen.
+            if [[ ! -d $mntpathbase ]]; then
+                sudo mkdir -p $mntpathbase/shares
+                sudo mkdir -p $mntpathbase/home
+            fi
+            # Freigaben einhaengen
+            sudo mount -t nfs $invisip:/srv/nfs4_base/shares $mntpathbase/shares
+            sudo mount -t nfs $invisip:/srv/nfs4_base/home $mntpathbase/home
+            ;;
+        "d")
+            # Freigaben aushaengen
+            sudo umount $mntpathbase/shares
+            sudo umount $mntpathbase/home
+            # OpenVPN beenden
+            openvpnpid=$(pgrep openvpn)
+            sudo kill $openvpnpid
+            # Urspruengliche resolv.conf wiederherstellen
+            sudo mv /etc/resolv.conf.ori /etc/resolv.conf
+            ;;
+        *)
+            usage
+            ;;
+esac
+</code>