15 Jahre GNU+Linux auf dem Unternehmensdesktop

Vortragender

• Paul Hänsch
• Freiberuflicher IT-Berater seit ca. 2012

Triggerwarnung

Triggerwarnung

Dieser Vortrag enthält Meinungen!

• ja, man kann Dinge auch anders machen
• vielleicht mache ich sie später auch noch anders

Demo: Nicht-Grafischer Boot

Motivation Für den Vortrag

• Eigentlich wollte ein Kollege darüber schreiben

Domainumgebung

• "Das geht nur unter Windows"

Wie macht Windoze das?

1. Auf Dateien zugreifen

• → Fileserver

  • SMB / CIFS
  • NFS
  • SSHFS

Was noch?

2. Benutzerlogins

• → PAM
• → Clients müssen das wissen!
• Alle Clients!

Irgendwas Fehlt noch...

3. "Directory-Service" (aka. "Verzeichnis-Dienst")

• UID-Mappings
• Zusätzliche Benutzerdaten (Klarname, Heimverzeichnis, Login-Shell)
• Gruppenzugehörigkeiten!

Technische Implementierung

• Vergleich Windoof-Domäne:

  • Active-Directory + CIFS
• = LDAP + Kerberos + Samba

Passwortspeicher

Passwortspeicher: Kerberos

Die Theorie

• Benutzer erhalten beim Login ein "TGT"
• Alle Dienste (Dateien, Verzeichnis, Web-Apps) Authentisieren den Benutzer über ein Service-Ticket
• → Vorteil: Das User-Passwort berührt niemals die Netzwerkdienste
• → Läuft ein Netzwerkdienst "Amok", kann er nicht die Credentials sammeln um andere Dienste zu beeinflussen.

Passwortspeicher: Kerberos

Die Praxis

• Wie setzt man Kerberos für Applikation $XY auf?

• Applikation soll auch außerhalb des Realms genutzt werden (private Laptops)

  • Doch wieder Passworte!

• Fallback-Methode:

  • Die Applikation fragt das User-Passwort ab, holt sich das TGT, fertich!
  • → Verwirft alle Versprechen und Vorteile von Kerberos
  • → Behält aber allen Mehraufwand

Passwortspeicher: Kerberos

Die Praxis

• Wie ändern Benutzer an der Client-Maschine ihr eigenes Passwort

  • Wait, what!?

Passwortspeicher: Kerberos

Die Praxis

• Inkompatibel mit /etc/shadow-Passworten
• → Technikänderung involviert Benutzer = wenig Raum für Expreimente

• Redundante Passwortspeicher

  • → Mögliche Divergenz wenn Dienste temporär offline sind
• Alternativ: auf Shadow-Passworte verzichten
• Macht das Basissystem abhängig von laufendem Kerberos-Daemon
• → Nope!

Fazit Kerberos

LDAP

Fazit LDAP

NIS

Die Clientsysteme

Wie war das noch gleich

1. Benutzerlogins

   • → PAM

   • → Clients müssen das wissen!

     • Alle Clients!

Clientkonfiguration

Die Klassische Lösung

• Configmanagement für die Clientsysteme

Alternativ

• Es gibt nur ein Clientsystem

  • → PXE-Boot

PXE-Boot

NFS / NBD

• Vorteil NFS: Änderungen im Verzeichnis sind direkt am Client sichtbar
• Nachteil NFS: Änderungen im Verzeichnis sind direkt am Client sichtbar

NBD

• Client-Image muss "gebacken" werden
• Client-Image im Betrieb austauschbar
• Server braucht keine Root-Rechte
• (Copy-on-Write pro Client)

Heimverzeichnisse

Gruppenverzeichnisse

Automatisierung

• Puppet
• Salt
• GNU Make

Automatisierung

Config-Dateien vorgeben

• Beispiel Mime-Typ-Assoziation
• Beispiel SSL-Zertifikate
• SSH-Host-Keys
• Firefox bookmarks
• Thunderbird....

Remoteuser

Früher

• Mitarbeiterinnen sollen von eigenen Geräten von remote zugreifen können
• → VPN-Lösung: PPTP, weil vorinstalliert in Windows
• Laminierte VPN-Kärtchen mit Zugangsdaten

Remoteuser

Heute

• Mitarbeiter bekommen eigene Notebooks
• Lokaler Account mit root-Rechten

• VPN-Einwahl via SSH

  • SSH-Keys können bei Bedarf deaktiviert werden
• kein automatischer Abgleich von Arbeitsdaten

Standorte

Hardware

Root-Server

Corona 2020: irgendwas mit Video

• Distribution (aka. Download)
• Live-Streaming (One-to-many)
• Gruppenchat (Many-to-many)
• → Server blieb zunächst ungenutzt

Root-Server

Planung für die Zukunft