Stufe I · Abfolge

Gebt srv01 und srv02 feste Adressen mit netplan und prüft sie:

• Prüft auf beiden Servern mit ip -br addr und cat /etc/netplan/*.yaml, wie die Adresse heute zustande kommt.
• Legt auf srv02 die Datei unten an, passt die Schnittstelle an und wendet sie mit netplan try an.
• Prüft Adresse, Route, DNS-Server und Erreichbarkeit mit den Befehlen unten.
• Prüft srv01 auf dieselbe Weise: Adresse 10.30.0.10, Gateway 10.30.0.1. Welchen DNS-Server muss der Domänencontroller selbst fragen?
• Startet beide Server neu und prüft, ob alles bleibt.

Nachschlagen Suchbegriffe für Handbuch, Herstellerdoku und RFC: netplan · netplan try · systemd-resolved

Zu zweit Diese Aufgabe bearbeitet ihr zu zweit.

# /etc/netplan/01-szt3.yaml auf srv02
network:
  version: 2
  ethernets:
    ens18:
      dhcp4: false
      addresses:
        - 10.30.0.11/24
      routes:
        - to: default
          via: 10.30.0.1
      nameservers:
        addresses: [10.30.0.10]
        search: [szt3.internal]

sudo chmod 600 /etc/netplan/01-szt3.yaml
sudo netplan try          # 120 s Zeit zum Bestaetigen, sonst Rueckfall
sudo netplan apply
ip -br addr show ens18
ip route
resolvectl status ens18
ping -c 3 10.30.0.1
ping -c 3 srv01.szt3.internal

Stufe I · Abfolge

Richtet Kea auf srv02 ein und holt an einem Windows-Client eine Adresse:

• Stellt sicher, dass im Labornetz kein anderer DHCP-Dienst läuft (Virtualisierung, Router).
• Installiert Kea, sichert die mitgelieferte Konfiguration und ersetzt sie durch die Grundkonfiguration unten. Die Lease-Zeit lasst ihr vorerst weg.
• Prüft die Datei mit kea-dhcp4 -t, startet den Dienst und lasst das Journal mitlaufen.
• Holt an einem Windows-Client eine neue Adresse und vergleicht ipconfig /all mit der Konfiguration.
• Schneidet auf srv02 mit tcpdump mit und ordnet die vier Nachrichten DORA zu.
• Lest im Lease-Eintrag auf srv02 ab, mit welcher Lease-Zeit Kea ohne eure Angabe arbeitet.

Nachschlagen Suchbegriffe für Handbuch, Herstellerdoku und RFC: Kea DHCPv4 Configuration · kea-dhcp4 -t · RFC 2131 · tcpdump

Zu zweit Diese Aufgabe bearbeitet ihr zu zweit.

{
  "Dhcp4": {
    "interfaces-config": {
      "interfaces": [ "ens18" ]
    },
    "lease-database": {
      "type": "memfile",
      "persist": true,
      "name": "/var/lib/kea/kea-leases4.csv"
    },
    "authoritative": true,
    "subnet4": [
      {
        "id": 1,
        "subnet": "10.30.0.0/24",
        "pools": [ { "pool": "10.30.0.100 - 10.30.0.199" } ],
        "option-data": [
          { "name": "routers", "data": "10.30.0.1" },
          { "name": "domain-name-servers", "data": "10.30.0.10" },
          { "name": "domain-name", "data": "szt3.internal" },
          { "name": "ntp-servers", "data": "10.30.0.11" }
        ]
      }
    ]
  }
}

sudo apt install kea-dhcp4-server
sudo cp /etc/kea/kea-dhcp4.conf /etc/kea/kea-dhcp4.conf.orig
sudo nano /etc/kea/kea-dhcp4.conf
sudo kea-dhcp4 -t /etc/kea/kea-dhcp4.conf      # nur pruefen, nicht starten
sudo systemctl restart kea-dhcp4-server
systemctl status kea-dhcp4-server
sudo journalctl -u kea-dhcp4-server -f

ipconfig /release
ipconfig /renew
ipconfig /all

sudo tcpdump -ni ens18 -vv 'port 67 or port 68'     # auf srv02, dann am Client ipconfig /renew
sudo tcpdump -ni ens18 port 53                         # auf srv01, dann am Client nslookup

Stufe II · Algorithmus

Legt Poolgröße und Lease-Zeit für den Schichtbetrieb fest und tragt die Reservierungen ein:

• Zählt, wie viele Adressen der Pool im ruhigen Betrieb gleichzeitig braucht: 32 Teilnehmerplätze aus dem Pool und bis zu 30 Notebooks von HLG.
• Überlegt, was beim Schichtwechsel um 14 Uhr passiert: Die Notebooks der Frühschicht gehen, ihre Leases laufen weiter. Stellt ein Modell auf: Wie lange hält ein Notebook seine Adresse höchstens, nachdem es gegangen ist?
• Rechnet für Lease-Zeiten von 4 h, 8 h, 12 h, 24 h und 8 Tagen (Standard bei Windows Server), wie viele Adressen höchstens gleichzeitig belegt sind. Prüft auch den Fall, dass HLG in allen drei Schichten kommt.
• Wählt eine Lease-Zeit und begründet sie in drei Sätzen. Rechnet T1 und T2 nach RFC 2131 aus und tragt alle drei Werte in Sekunden in Kea ein.
• Entscheidet, wo die acht Reservierungen liegen, im Pool oder außerhalb, und tragt sie ein. Prüft an ra-tr, ob die Adresse kommt.

Nachschlagen Suchbegriffe für Handbuch, Herstellerdoku und RFC: valid-lifetime · renew-timer · rebind-timer · Kea Host Reservations · RFC 2131 4.4.5

Im Team Diese Aufgabe bearbeitet ihr im Team.

Stufe II · Algorithmus

Prüft und ergänzt DNS in Samba:

• Prüft von srv02 und von einem Windows-Client aus, ob die SRV-Einträge für LDAP und Kerberos und der A-Eintrag von srv01 antworten.
• Legt die Reverse-Zone für 10.30.0.0/24 an und tragt PTR-Einträge für beide Server und beide Drucker ein.
• Tragt A-Einträge für srv02, prn-a und prn-b ein, dazu portal.szt3.internal und einen MX-Eintrag für die Domäne. Entscheidet, ob portal ein A-Eintrag oder ein Alias wird, und worauf der MX zeigen darf.
• Richtet die Weiterleitung für Namen außerhalb auf den Resolver des Standorts ein und testet sie.
• Haltet für jeden Eintrag den Testbefehl, die erwartete und die beobachtete Antwort fest.

Nachschlagen Suchbegriffe für Handbuch, Herstellerdoku und RFC: samba-tool dns · dns forwarder · in-addr.arpa · RFC 2782 · RFC 2181

Zu zweit Diese Aufgabe bearbeitet ihr zu zweit.

host -t SRV _ldap._tcp.szt3.internal
host -t SRV _kerberos._udp.szt3.internal
host -t SRV _ldap._tcp.dc._msdcs.szt3.internal
host -t A srv01.szt3.internal
host 10.30.0.11                       # Rueckwaertsaufloesung
dig @10.30.0.10 de.pool.ntp.org       # Name ausserhalb: Weiterleitung

sudo samba-tool dns zonelist srv01 -U administrator
sudo samba-tool dns zonecreate srv01 <zone> -U administrator
sudo samba-tool dns add srv01 <zone> <name> <typ> <daten> -U administrator
sudo samba-tool dns query srv01 <zone> @ ALL -U administrator

Stufe II · Algorithmus

Baut die Zeithierarchie mit chrony bis zu den Windows-Clients:

• Zeichnet, woher srv02, srv01, die Windows-Clients und der Linux-Client ihre Zeit holen sollen.
• Installiert chrony auf srv02, lasst es aus dem NTP-Pool synchronisieren und erlaubt Anfragen aus 10.30.0.0/24.
• Installiert chrony auf srv01, lasst es nur von srv02 synchronisieren und richtet das Signieren für Windows über ntp_signd ein.
• Prüft auf beiden Servern Quelle, Stratum und Versatz mit chronyc und auf srv02, welche Clients fragen.
• Prüft an einem Windows-Client Typ, Quelle und Versatz mit w32tm.

Nachschlagen Suchbegriffe für Handbuch, Herstellerdoku und RFC: chrony.conf allow · ntpsigndsocket · Samba Time Synchronisation · w32tm NT5DS · RFC 5905

Zu zweit Diese Aufgabe bearbeitet ihr zu zweit.

# /etc/chrony/chrony.conf auf srv02 (Auszug)
pool de.pool.ntp.org iburst maxsources 4
allow 10.30.0.0/24

# /etc/chrony/chrony.conf auf srv01 (Auszug, die pool-Zeilen entfernt)
server srv02.szt3.internal iburst
allow 10.30.0.0/24
ntpsigndsocket /var/lib/samba/ntp_signd

sudo apt install chrony                 # ersetzt systemd-timesyncd
sudo chown root:_chrony /var/lib/samba/ntp_signd     # nur auf srv01
sudo chmod 750 /var/lib/samba/ntp_signd              # nur auf srv01
sudo systemctl restart chrony
chronyc sources -v
chronyc tracking
sudo chronyc clients                   # auf srv02: wer holt Zeit?

w32tm /query /source
w32tm /query /status
w32tm /query /configuration
w32tm /stripchart /computer:srv01.szt3.internal /samples:3 /dataonly

Stufe II · Algorithmus

Rechnet aus, wann ein Client ohne Zeitabgleich an Kerberos scheitert:

• Ein Client hat keinen Zeitabgleich, seine Uhr hat eine Gangabweichung von 50 ppm. Rechnet aus, um wie viele Sekunden er je Tag abweicht.
• Rechnet aus, nach wie vielen Tagen er die Grenze von 5 Minuten überschreitet.
• Rechnet nach, was passiert, wenn auch der Domänencontroller keinen Zeitabgleich hat und seine Uhr mit 50 ppm in die andere Richtung abweicht.
• Rechnet beides mit Python nach und kopiert Code und Ausgabe in euer Protokoll.
• Schreibt einen Satz, was die Rechnung für eine Umgebung bedeutet, die in Teil 2 aus einem Abbild installiert wurde.

Nachschlagen Suchbegriffe für Handbuch, Herstellerdoku und RFC: ppm · Gangabweichung Quarz · Kerberos clock skew

Allein Diese Aufgabe bearbeitest du allein.

Stufe III · Heuristik

Kreist das Ticket „Anmeldung geht nur manchmal“ ein:

• Lest das Ticket und die Auszüge unten. Schreibt auf, welche Beobachtung zu welcher Schicht der Anmeldekette gehört.
• Stellt Vermutungen auf und legt fest, mit welchem Test ihr jede bestätigt oder verwerft. Fangt unten an.
• Ordnet jede Ursache den Plätzen zu, die sie betrifft. Begründet, warum der Fehler „nur manchmal“ auftritt.
• Schreibt die Abhilfe je Ursache mit Befehl oder Konfigurationszeile und den Nachtest.
• Schreibt einen Satz an die Leitung Schulung: Was war los, und was ist bis morgen 6 Uhr erledigt?

Im Team Diese Aufgabe bearbeitet ihr im Team.

# Auszug /etc/kea/kea-dhcp4.conf, geaendert am Freitag, 15:10 Uhr
{ "name": "domain-name-servers", "data": "10.30.0.10, 10.30.0.1" },

rb-03> ipconfig /all   (Auszug)
   DHCP-Server . . . . . . . . . . . : 10.30.0.11
   DNS-Server  . . . . . . . . . . . : 10.30.0.10
                                       10.30.0.1
rb-03> nslookup -type=SRV _ldap._tcp.dc._msdcs.szt3.internal 10.30.0.1
*** _ldap._tcp.dc._msdcs.szt3.internal wurde von 10.30.0.1 nicht gefunden: Non-existent domain.

rb-07> w32tm /query /status   (Auszug)
Leap-Indikator: 3(nicht synchronisiert)
Stratum: 0 (nicht angegeben)
Quelle: Local CMOS Clock
rb-07> w32tm /query /configuration   (Auszug)
NtpServer: pool.ntp.org,0x9 (Lokal)
Type: NTP (Lokal)