Drei Welten, ein Netz: wie heterogene Umgebungen zusammenhalten

Worum es geht

Die Geoplan Vermessung AG in Frauenfeld hat 65 Mitarbeitende und drei Welten im Netz. Die Büroarbeitsplätze laufen mit Windows und melden sich am Active Directory ad.geoplan.ch an. Vier Ubuntu-Server (gis01 bis gis04) rechnen GIS-Projekte, jede Person hat dort ein eigenes, lokales Konto. In der Kartografie arbeiten sechs Macs, und das Monitoring der Messstationen läuft in einem selbst betriebenen Grafana mit nochmals eigenen Passwörtern.

Gian, Informatiker Plattformentwicklung im 3. Lehrjahr, macht eine Stichprobe. Auf gis02 findet er zwei Konten von Personen, die die Firma vor über einem Jahr verlassen haben. Beide Konten funktionieren noch. Niemand hat daran gedacht, sie zu löschen, denn beim Austritt wurde «das Konto» gesperrt, und gemeint war das AD-Konto.

Genau das ist das Problem heterogener Netze: Jedes System hat seine eigene Benutzerverwaltung, seine eigene Uhr, seine eigene Vorstellung davon, wie ein Name aufgelöst wird. Bei 65 Personen und 10 Systemen sind das schnell 650 Konten, die jemand pflegen müsste. Dein Ziel in diesem Modul lautet: eine Identität, ein Ort für Rechte, einheitliche Dienste für alle Plattformen. In dieser ersten Lektion verschaffst du dir den Überblick: Welcher Dienst liefert was, wie arbeiten Kerberos und LDAP zusammen, und in welcher Reihenfolge baust du eine solche Integration auf.

Wer liefert was: die Dienste einer gemischten Umgebung

Stell dir eine Gemeinde vor. Die Einwohnerkontrolle weiss, wer hier wohnt, wie die Person heisst und zu welchem Haushalt sie gehört. Das Passbüro stellt Ausweise aus, die eine begrenzte Zeit gültig sind. Der Strassenplan sagt, wo welches Gebäude steht. Und die Kirchturmuhr sorgt dafür, dass alle zur gleichen Zeit beim Termin sind. Ein Active Directory ist genau diese Kombination:

Das Wichtigste daran: Kein Dienst ist an Windows gebunden. Kerberos, LDAP, DNS, NTP, SMB und IPP sind offene Protokolle. Linux und macOS sprechen sie alle. Deine Arbeit besteht darin, jedes System so einzustellen, dass es dieselben Quellen nutzt.

Kerberos und LDAP: zwei Aufgaben, ein Verzeichnis

Viele verwechseln die beiden, weil beide «irgendwas mit Anmeldung» tun. Die Trennung ist aber klar:

• Kerberos beantwortet die Frage: Bist du wirklich Lea Brunner? Das ist Authentifizierung.
• LDAP beantwortet die Fragen: Welche Benutzer-ID hat Lea, in welchen Gruppen ist sie, wo liegt ihr Home-Verzeichnis? Das sind Identitätsdaten, aus denen die Rechte (Autorisierung) abgeleitet werden.

Wie ein Kerberos-Ticket entsteht

Kerberos funktioniert wie ein Festival mit Bändeli. Am Eingang zeigst du einmal deinen Ausweis und bekommst ein Bändeli für den ganzen Tag (das Ticket Granting Ticket, TGT). Willst du in ein Zelt, zeigst du das Bändeli an einem Schalter und bekommst einen Zettel nur für dieses Zelt (das Service-Ticket). Das Zeltpersonal prüft nur den Zettel, deinen Ausweis sieht es nie.

Drei Eigenschaften musst du dir merken, weil sie fast alle Integrationsfehler erklären:

1. Das Passwort geht nie übers Netz. Der Client verschlüsselt einen Zeitstempel mit einem Schlüssel, der aus dem Passwort abgeleitet ist. Der DC kann ihn nur entschlüsseln, wenn das Passwort stimmt.
2. Tickets sind an Zeit gebunden. Weicht die Uhr eines Systems mehr als 5 Minuten (Standardwert) vom DC ab, lehnt Kerberos ab. Die Meldung heisst dann Clock skew too great.
3. Tickets gelten für Namen, nicht für IP-Adressen. Ein Ticket für cifs/fs01.ad.geoplan.ch funktioniert nur, wenn der Client den Server unter diesem Namen anspricht. Darum ist DNS so wichtig.

Auch Server brauchen eine Identität: Ein Linux-Server im AD hat ein Computerkonto (z.B. GIS01$) und speichert dessen Schlüssel in einer Keytab-Datei. So kann er Tickets prüfen und selbst Anfragen ans Verzeichnis stellen, ohne dass jemand ein Passwort eintippt.

Und wann braucht es LDAP allein?

Webanwendungen wie Grafana oder Nextcloud können meist kein Kerberos. Sie nehmen das Passwort im Anmeldeformular entgegen und prüfen es mit einem LDAP-Bind gegen das AD. Das ist bequem, aber dabei geht das Passwort über die Leitung. Deshalb gehört zu jeder LDAP-Anbindung eine verschlüsselte Verbindung (LDAPS). Mehr dazu in Lektion 7.

Die Reihenfolge der Abhängigkeiten

Wer bei Geoplan einfach mit realm join auf gis01 beginnt, scheitert. Nicht weil der Befehl falsch ist, sondern weil die Grundlagen fehlen. Integrationsarbeit hat eine feste Reihenfolge, die sich aus den Abhängigkeiten ergibt:

• DNS zuerst, weil Linux und macOS die DCs über SRV-Einträge finden und Kerberos mit Namen arbeitet.
• Dann die Zeit, weil Kerberos ohne gleiche Uhren nicht funktioniert und Logs sonst nicht vergleichbar sind.
• Dann die Identität: Server und Macs ins AD aufnehmen, Rechte über Gruppen steuern.
• Darauf bauen Dateien, Drucker und Anwendungen auf. Für Anwendungen braucht es zusätzlich vertrauenswürdige Zertifikate.
• Zum Schluss Logging und Dokumentation, denn erst wenn alles läuft, weisst du, was du überwachen musst.

Schritt für Schritt: Bestandesaufnahme der Geoplan-Umgebung

Bevor Gian etwas ändert, erfasst er den Ist-Zustand. Du gehst genauso vor.

Schritt 1: Die Domäne erfassen. Auf einem DC oder einem Admin-PC mit den RSAT-Werkzeugen:

Get-ADDomain | Select-Object DNSRoot, NetBIOSName, PDCEmulator
Get-ADDomainController -Filter * | Select-Object Name, IPv4Address, OperatingSystem

Ergebnis: Domäne ad.geoplan.ch, NetBIOS-Name GEOPLAN, zwei DCs dc01 (10.30.0.11, zugleich PDC-Emulator) und dc02 (10.30.0.12).

Schritt 2: Einen Linux-Server untersuchen. Auf gis01:

hostnamectl                       # Name, Betriebssystem, Kernel
resolvectl status                 # welcher DNS-Server wird genutzt?
timedatectl                       # Zeitzone, ist die Uhr synchronisiert?
getent passwd | awk -F: '$3 >= 1000 && $3 < 60000 {print $1, $3}'   # lokale Personenkonten

Die Ausgabe zeigt: DNS-Server ist 10.30.10.1 (der Router, nicht der DC), die Zeit kommt von ntp.ubuntu.com, und es gibt elf lokale Konten.

Schritt 3: Einen Mac untersuchen. Im Terminal eines Kartografie-Macs:

sw_vers                                   # macOS-Version
scutil --dns | grep nameserver            # aktive DNS-Server
sudo systemsetup -getnetworktimeserver    # Zeitquelle

Der Mac nutzt den DC als DNS (per DHCP), aber time.apple.com als Zeitquelle.

Schritt 4: Die Erreichbarkeit der DCs prüfen. Zwischen dem Server-Netz und den DCs steht eine Firewall. Von gis01 aus:

nc -zv dc01.ad.geoplan.ch 53 88 389 445 464 636 3268

nc -z testet nur, ob ein TCP-Port antwortet. UDP-Ports wie NTP (123) prüfst du später direkt mit dem Dienst.

Schritt 5: Die Ergebnisse festhalten.

Schritt 6: Massnahmen in der richtigen Reihenfolge ableiten. Aus der Tabelle ergibt sich Gians Plan: DNS auf allen Linux-Systemen auf die DCs, Zeit überall von den DCs, dann die Server ins AD, danach Fileserver, Grafana und Logging.

Prüfe jetzt mit einem kleinen Programm, ob die Firewall alle Ports durchlässt, die ein Linux-Server im AD braucht.

Typische Fehler

• Linux-Server mit dem Router oder 8.8.8.8 als DNS. Öffentliche DNS-Server kennen die SRV-Einträge der internen Domäne nicht. realm discover findet dann nichts. Korrektur: Die DCs als einzige DNS-Server eintragen.
• Zeit aus dem Internet statt vom DC. Solange die Firewall den Zugriff erlaubt, geht es gut. Wird er gesperrt oder ein Snapshot zurückgesetzt, driftet die Uhr, und Kerberos scheitert. Korrektur: Alle Systeme holen die Zeit von den DCs.
• Mit dem Domänenbeitritt anfangen. Ohne Bestandesaufnahme weisst du nicht, welche lokalen Konten es gibt und welche Dienste davon abhängen. Korrektur: Erst Ist-Zustand erfassen, dann planen.
• Kerberos und LDAP verwechseln. Wer meint, LDAP «macht die Anmeldung», sucht bei Clock skew too great im falschen Protokoll. Korrektur: Kerberos prüft die Identität und ist zeitkritisch, LDAP liefert Daten.

Zusammenfassung

• Heterogene Netze sind der Normalfall. Ziel ist eine Identität im AD für alle Plattformen statt lokaler Konten auf jedem System.
• Das AD liefert DNS, Kerberos, LDAP und Zeit. Alles offene Protokolle, die auch Linux und macOS sprechen.
• Kerberos beweist die Identität mit zeitlich begrenzten Tickets, ohne Passwort im Netz. Es ist zeitkritisch (Standard 5 Minuten Toleranz) und arbeitet mit Namen.
• LDAP liefert Benutzer, Gruppen und Attribute. Webanwendungen prüfen Passwörter oft per LDAP-Bind, deshalb immer über LDAPS.
• Die Reihenfolge lautet: DNS, Zeit, Identität, dann Dateien, Drucker, Anwendungen mit Zertifikaten, zum Schluss Logging und Doku.
• Am Anfang steht eine Bestandesaufnahme auf allen Plattformen, die du später als Vergleich nutzt.