Warum der Aufwand?

Linux auf dem Desktop erfreut sich steigender Beliebtheit, wenn dies zugegeben auch nur ein langsames Wachstum ist. Die Gründe dafür sind vielfältig, hauptsächlich dürfte es an der Abhängigkeit und den damit verbundenen Problemen zu Microsoft-Produkten liegen (z.B. seltsame UI-Erscheinungen wie die aufgeteilte Systemsteuerung, Datenschutz- und Updateprobleme in Windows 10, sowie die allgemeine Abhängigkeit von einem Anbieter sind ein nicht zu unterschätzendes Problem). Der Linux-Desktop ist im Jahr 2020 auch von Laien benutzbar und daher sollte man seine Vorteile auch im Unternehmensumfeld wahrnehmen.

Digitale Souveränität ist mit proprietärer (closed source) Software meiner Meinung nach nicht möglich, vor allem, wenn es sich um eine derartig grundlegende Komponente wie das Betriebssystem handelt. Das heißt nicht, dass ich gegen die Monetarisierung von Software bin, ganz im Gegenteil. Softwareentwickler zu bezahlen Open Source-Projekte zu entwickeln bzw. weiterzuentwickeln und/oder Support dafür einzukaufen ist eine großartige Idee um die Projekte zu unterstützen - vor allem in öffentlichen Einrichtungen muss gelten: Public Money, Public Code!

Nun gibt es im Unternehmensumfeld einige Besonderheiten, welche den großflächigen Einsatz erschweren. Auf dieser Seite möchte ich auf die wichtigsten Sachen eingehen und meine Lösungen dazu vorstellen.

1. Einbindung in eine Active Directory-Domäne (AD)

Benutzer sollen sich am Linux-Client genau so anmelden können, wie man es vom Windows-Client gewohnt ist. In den meisten Unternehmen besteht bereits ein Microsoft AD-Server mit einer Windows-Domäne. Diesen wollen wir an dieser Stelle (noch) nicht ersetzen, sondern für die Authentifizierung verwenden. Für die Linux-AD-Authentifizierung gibt es mehrere Lösungen, nennenswert sind Samba Windbind, RedHats SSSD und PBIS. Mit dem Winbind hatte ich Probleme bei der erstmaligen Anmeldung nach Neustart des Linux-Rechners (dies funktionierte immer erst nach etwa 20 Sekunden), daher beschreibe ich hier die Verfahrensweise mit dem moderneren SSSD.

Für den Domainjoin wird entweder Sambas net ads join-Kommando, adcli oder PBIS' domainjoin-cli join benötigt; außerdem das Kerberos-Paket. Ich arbeite mit der Linux-Distribution Linux Mint, alle angegebenen Schritte sind aber ohne Probleme auf Ubuntu, Debian etc. übertragbar.

Ebenso kann diese Anleitung für Linux-Server (ohne GUI) verwendet werden. Dann sollte man nur zusätzlich eine Anmeldebeschränkung auf bestimmte Accounts einrichten, nicht dass sich jeder Domänenbenutzer auf dem Server anmelden kann.

Wir beginnen mit der Installation der benötigten Pakete. Ich verwende im Folgenden adcli für den Domainjoin. Je nach Präferenz kann aber auch wie oben erwähnt statt adcli das Samba-Paket installiert werden, um mittels net ads join beizutreten.

apt install krb5-user adcli sssd-ad libnss-sss libpam-sss

Als nächstes wird eine SSSD-Konfiguration erstellt (/etc/sssd/sssd.conf). Hierbei aktivieren wir auch das "Credential Caching", welches die Benutzer-Passwörter (in gehaster Form) zwischenspeichert, sodass die Anmeldung an Notebooks auch offline (sprich unterwegs) möglich ist.

[sssd] config_file_version = 2 services = nss, pam domains = MYDOMAIN.TLD [pam] # cache credentials for offline login offline_credentials_expiration = 365 offline_failed_login_attempts = 5 offline_failed_login_delay = 10 [domain/MYDOMAIN.TLD] id_provider = ad access_provider = simple sudo_provider = none ldap_id_mapping = true # cache account information for offline usage account_cache_expiration = 365 entry_cache_timeout = 5400 # cache credentials for offline login cache_credentials = true # if logged in offline: query kerberos ticket as soon as we are online again krb5_store_password_if_offline = true krb5_ccname_template = FILE:/run/krb5cc/krb5cc_%U_XXXXXX fallback_homedir = /home/%u default_shell = /bin/bash skel_dir = /etc/skel

Dann wird Kerberos konfiguriert (/etc/krb5.conf). Hier sind die zusätzlich Adressen zu den AD-Servern (ad1-3.mydomain.tld) entsprechend anzupassen.

[libdefaults] default_realm = MYDOMAIN.TLD dns_lookup_realm = false dns_lookup_kdc = false # The following krb5.conf variables are only for MIT Kerberos. kdc_timesync = 1 ccache_type = 4 forwardable = true proxiable = true # The following libdefaults parameters are only for Heimdal Kerberos. fcc-mit-ticketflags = true [realms] MYDOMAIN.TLD = { kdc = ad1.mydomain.tld kdc = ad2.mydomain.tld kdc = ad3.mydomain.tld admin_server = ad3.mydomain.tld default_domain = mydomain.tld } [domain_realm] .mydomain.tld = MYDOMAIN.TLD mydomain.tld = MYDOMAIN.TLD

Nun wird die PAM-Konfiguration dahingehend erweitert, dass bei der ersten Anmeldung eines Domänenbenutzers ein Home-Verzeichnis angelegt wird. In die Datei /usr/share/pam-configs/my-ad wird folgender Inhalt geschrieben.

Name: AD user home management Default: yes Priority: 127 Session-Type: Additional Session-Interactive-Only: yes Session: required pam_mkhomedir.so skel=/etc/skel umask=0077

Zum Schluss muss noch der Login-Manager angepasst werden, damit dieser auch nach dem Benutzernamen fragt und nicht nur eine Liste der lokalen Konten anzeigt. In meinem Fall des LightDMs unter Ubuntu/Mint muss die Datei /usr/share/lightdm/lightdm.conf.d/50-domainlogin.conf mit folgendem Inhalt erstellt werden. Falls es sich um einen Server ohne GUI handelt kann dieser Schritt übersprungen werden.

[SeatDefaults] greeter-session=unity-greeter allow-guest=false greeter-show-remote-login=false greeter-show-manual-login=true greeter-hide-users=true

Damit ist die Konfiguration abgeschlossen. Mit folgenden Kommandos treten wir nun der Domäne bei.

adcli join -U <ADMIN-USERNAME> mydomain.tld pam-auth-update --package systemctl daemon-reload && systemctl enable sssd && systemctl start sssd

Nach einem Neustart können wir uns nun mit Domänen-Logins am Anmeldebildschirm anmelden. Damit ist die Einrichtung des Domänenlogins abgeschlossen. Um diese Einstellungen einfacher auf viele Clients auszurollen kann z.B. ein eigenes .deb-Paket erstellt werden.

Als nächstes kann in /etc/sudoers.d/domainadmins eine sudo-Regel definiert werden, welche den Domänen-Administratoren automatisch sudo-Rechte auf den Maschinen einräumt.

%Domänen-Admins ALL=(ALL:ALL) ALL

Das war die Pflicht, nun kommt die Kür. Für den Cinnamon-Desktop habe ich das LDAP-Passwort-Desklet entwickelt, welches dem Nutzer anzeigt, wann sein Domänenkennwort abläuft. Darüber kann das Kennwort auch mit einem Klick geändert werden.

2. Festplattenverschlüsselung mit automatischer Entsperrung via TPM-Chip

Unternehmensrechner mit wichtigen Dateien sollten eine verschlüsselte Festplatte besitzen, damit Angreifer die Festplatte nicht einfach ausbauen und an anderen Rechnern auslesen bzw. Schadsoftware (z.B. Keylogger) installieren können.

Voraussetzung ist, dass das Linux-System bereits in einer LUKS-verschlüsselten Partition installiert wurde. Der Ubuntu/Linux Mint Installer bietet dies optional an unter Verwendung einer statischen Passphrase, welche bei der Installation festgelegt wird und dann bei jedem Bootvorgang eingegeben werden muss.

Ein "Convenience-Kompromiss", bei welchem keine Passworteingabe beim Bootvorgang notwendig ist, ist mit dem TPM-Chip möglich: dieser prüft beim Bootvorgang, ob die Umgebung vertrauenswürdig ist (ob die Hardware und EFI-Einstellungen unverändert vorliegen) und gibt dann automatisch den Schlüssel zu Entschlüsselung der Festplatte frei. Somit kann man tatsächlich jede Festplatte im Unternehmen vollständig verschlüsseln, ohne auf Widerstand der Nutzer zu treffen ("jetzt müssen wir uns noch ein Passwort merken"). Bei diesem BitLocker-ähnlichen Vorgehen merkt der Nutzer gar keinen Unterschied zu einer unverschlüsselten Festplatte. Die Umsetzung ist mit der Software "Clevis" möglich.

apt install clevis-initramfs clevis-tpm2 clevis-luks sudo clevis luks bind -d /dev/nvme0n1p3 tpm2 '{"pcr_ids":"0,1,2,3,4,5"}'

Beim nächsten Neustart wird die Festplatte nun automatisch entsperrt - solange keine EFI-Einstellungen des Rechners geändert werden (dann muss der TPM erneut eingemessen werden). Die zuvor vergebene Passphrase kann weiterhin zur Entsperrung genutzt und sollte sicher aufbewahrt werden. Im TPM-Fehlerfall kann dieser dem Nutzer übermittelt werden, damit er kurzfristig wieder arbeitsfähig ist (Beispiel: Batterie auf dem Mainboard ist leer und die Uhrzeit/EFI-Einstellungen wurden zurückgesetzt).

3. Programme mit "Gruppenrichtlinien" systemweit konfigurieren

Im Unternehmensumfeld ist es oft notwendig Software vorzukonfigurieren (nicht nur im Benutzerkontext) und einige (Sicherheits-)Einstellungen zu erzwingen, sodass die Nutzer sie nicht verändern/überschreiben können. Einige Programme bieten eine solche Konfiguration über systemweite Konfigurationsdateien an, wie man es von Gruppenrichtlinien aus der Windows-Domäne kennt.

Bei allen folgenden Beispielen ist darauf zu achten, dass die Dateirechte der Konfigurationsdateien so gesetzt sind, dass sie nicht vom Benutzer verändert werden können.

LibreOffice

Jede denkbare LibreOffice-Einstellung lässt sich via XML-Konfigurationsdatei setzen. Die Richtlinien werden in Form von Konfigurationsdateien im System abgelegt, welcher der Nutzer nur lesen, aber nicht verändern darf. Diese Methode der Konfiguration funktioniert übrigens auch unter Windows.

Beispiel: Makro-Sicherheit auf "Sehr Hoch" setzen

<?xml version="1.0"?> <oor:data xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:oor="http://openoffice.org/2001/registry"> <dependency file="main" /> <oor:component-data xmlns:install="http://openoffice.org/2004/installation" oor:package="org.openoffice.Office" oor:name="Common"> <node oor:name="Security"> <node oor:name="Scripting"> <prop oor:name="MacroSecurityLevel" oor:op="fuse" oor:finalized="true"> <value>3</value> </prop> </node> </node> </oor:component-data> </oor:data>

Die Einstellungsnamen zur Verwendung in XML-Datei und Registry lassen sich über das Fenster "Experteneinstellungen" (Menü "Extras" → "Optionen" → "Erweitert") in LibreOffice herausfinden.

Die Eigenschaft oor:finalized="true" sorgt dafür, dass der Nutzer die Einstellung nicht verändern kann.

Firefox

Ebenso können auch im Firefox Einstellungen systemweit erzwungen werden. Es können alle Optionen aus about:config verwendet werden. Es muss eine JS-Datei /etc/firefox/syspref.js angelegt werden.

pref("browser.startup.homepage", "http://...", locked); pref("network.proxy.autoconfig_url", "http://...", locked); pref("network.proxy.type", 2, locked);

Die Option locked sorgt dafür, dass der Nutzer die Einstellung nicht verändern kann.

Google Chrome/Chromium

Auch der Chrome und Chromium können systemweit konfiguriert werden. Alle mögliche Einstellungen sind hier zu finden. Die Konfigurationsdateien müssen im JSON-Format unter folgenden Pfaden abgelegt werden.

{ "HomepageLocation": "www.chromium.org" }

Konfigurationsdateien packen, verteilen und aktualisieren

Es bietet sich an, diese Konfigurationsdateien in ein selbst gepacktes .deb- oder .rpm-Paket zu packen, damit sie einfach verteilt werden können.

Zur Verteilung und Aktualisierung solcher Softwarepakete empfehle ich an dieser Stelle natürlich meinen OCO-Server. Eine Verteilung hierrüber (und nicht über ein klassisches self-hosted Debian-Repository) bietet den Vorteil, dass der Verteilungs-/Updatestatus übersichtlich angezeigt werden kann.

Anwendungssammlung für Linux im Unternehmen

Meine Open Source-Projekte:

Empfehlungen von anderen Anbietern:

Fragen? Fragen!