Der Linux-Desktop im Unternehmen
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.
- Verzeichnis für systemweite Konfigurationsdateien unter Windows:
C:\Program Files\LibreOffice\share\registry
- Verzeichnis für systemweite Konfigurationsdateien unter Linux:
/usr/lib/libreoffice/share/registry
- Dateiendung:
.xcd
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.
- Verzeichnis für erzwungene systemweite Konfigurationsdateien für Google Chrome:
/etc/opt/chrome/policies/managed
- Verzeichnis für optionale systemweite Konfigurationsdateien für Google Chrome:
/etc/opt/chrome/policies/recommended
- Verzeichnis für erzwungene systemweite Konfigurationsdateien für Chromium:
/etc/chromium/policies/managed
- Verzeichnis für optionale systemweite Konfigurationsdateien für Chromium:
/etc/chromium/policies/recommended
- Dateiendung:
.json
{
"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:
-
Simple Signer
PDF-Dateien mit einem persönlichen Zertifikat signieren
-
LAPS4LINUX
Lokales Admin-Passwort automatisch ändern und im Verzeichnisdienst (LDAP) speichern - Linux-Implementation der "Local Administrator Password Solution"
-
Jabber4Linux (Softphone) + Pidgin (Textnachrichten)
Ersatz für Cisco Jabber Softphone und XMPP-Chat
-
QuickSync4Linux
Dateien und Kontakte mit Gigaset-Telefonen austauschen
-
Confluence Companion App for Linux
Dateien aus dem Kollaborationssystem Confluence mit lokalen Programmen bearbeiten
-
LDAPPWD-Desklet
Desklet für den Cinnamon-Desktop, welches den Passwortablauf eines Domänen-Accounts anzeigt
-
OCO-Server / OCO-Agent
Inventarisierungs- und Softwareverteilungssystem für Linux, macOS und Windows-Clients.
-
MASTERPLAN
Webbasierte Dienstplansoftware
-
WebPW
Webbasierter Passwortsafe
Empfehlungen von anderen Anbietern:
-
SoftMaker Office / FreeOffice
Sehr gute Microsoft-Office-kompatible Alternative zu LibreOffice (u.a. für Liebhaber der Ribbon-Menüs)
-
DaVinci Resolve
Umfangreiche Videobearbeitungssoftware für professionelle Ansprüche zum erschwinglichen Preis
-
LibreOffice Draw & Master PDF Editor
Software zum Bearbeiten von PDFs (Alternative zu Adobe Acrobat Pro)