XPLN/Lernbereiche

E07 · Windows / Kea · Produktlogik

Policies, Geräteklassen und PXE

Kapitel in dieser Lernstufe

Das lernst du

  • Clientmerkmale und serverseitige Entscheidungen unterscheiden.
  • Policytreffer mit Positiv- und Negativfällen überprüfen.

Voraussetzungen: F06 · Optionen und VererbungF07 · Reservierungen und ClientidentitätE03 · Relay-Architektur und Option 82

Nicht jede Gerätegruppe benötigt dieselben Parameter. Ein Administrationsnetz kann andere DNS- oder Bootinformationen brauchen als ein gewöhnlicher Arbeitsplatz.

Eine Regel braucht auch einen Standardfall

Merkmal prüfen, Wirkung nachweisenClientmerkmale im REQUESTPasst die definierte Testklasse?Auswahlregel · keine AuthentisierungjaneinSonderprofilACK: DNS .20.11StandardfallACK: DNS .20.10Auch fehlende und überlappende Merkmale testen.
Grafik vergrößern
Merkmal prüfen, Wirkung nachweisenClientmerkmale im REQUESTPasst die definierte Testklasse?Auswahlregel · keine AuthentisierungjaneinSonderprofilACK: DNS .20.11StandardfallACK: DNS .20.10Auch fehlende und überlappende Merkmale testen.
Die schematische Auswahl prüft eine besondere Geräteklasse und ihren Standardfall. Beide Wege enden in überprüfbaren ACK-Optionen. Klassenmerkmale sind keine Authentisierung; Reihenfolge und Mehrfachtreffer richten sich nach dem jeweiligen Serverprodukt.

Merkmale sind keine Vertrauensgarantie

Vendor Class (Option 60) kann einen Clienttyp bezeichnen; User Class (Option 77) eine vom Client mitgeteilte Klasse. Serverprodukte können daraus Auswahlregeln bilden. Vom Client gesendete Zeichenketten sind jedoch ohne zusätzliche Absicherung keine belastbare Benutzer- oder Geräteauthentisierung.

Windows kennt Policies auf unterschiedlichen Ebenen und eine Verarbeitungsreihenfolge. Kea verwendet Klassen, Tests und eigene Auswertungsregeln. Eine Windows-Policy lässt sich nicht durch bloßes Umbenennen in eine Kea-Regel übersetzen.

PXE nicht auf zwei Optionen reduzieren

PXE startet ein Gerät über das Netz. Bootparameter hängen unter anderem von Firmwarearchitektur, Bootdienst und Infrastruktur ab. Statische Bootserver-/Dateinamen für alle Clients können UEFI- und BIOS-Geräte unterschiedlich scheitern lassen. DHCP liefert dabei gegebenenfalls Informationen, überträgt aber nicht selbst das vollständige Bootimage.

Dokumentiere Matchbedingungen, Reihenfolge, Pool-/Optionswirkung und Standardfall. Teste einen passenden Client, einen nicht passenden Client und einen Client mit mehreren passenden Merkmalen. Die tatsächlich gesendeten Optionen sind der Nachweis, nicht die Existenz einer Regel im Dialog.

Klassifizierung und Autorisierung nicht verwechseln

Vendor Class, User Class und Relaykontext können helfen, geeignete Parameter auszuwählen. Ein Merkmal ist aber nicht automatisch fälschungssicher. Wenn ein Gerät seine Klasse selbst übermittelt, darf daraus nicht ohne weitere Kontrolle eine sicherheitskritische Vertrauensentscheidung entstehen. Für eine Policy dokumentierst du deshalb Merkmal, Herkunft, Vergleichsformat und das Verhalten bei fehlendem Merkmal.

Angenommen, nur eine Testklasse soll einen anderen Resolver erhalten. Prüfe einen passenden Client, einen normalen Büroclient und einen Client mit unvollständiger Kennung. Vergleiche jeweils das tatsächlich gesendete ACK. Die bloße Existenz der Regel in der Serveroberfläche beweist weder ihre Auswertung noch die gewünschte Priorität gegenüber anderen Regeln. Überlappende Bedingungen benötigen eine klare, produktspezifisch dokumentierte Reihenfolge.

Netzstart als Kette mehrerer Dienste betrachten

PXE bezeichnet eine Umgebung für den Start über das Netzwerk. Die anfängliche Adresskonfiguration ist nur ein Teil dieser Kette. Danach müssen passende Bootinformationen ausgewählt und die benötigten Dateien beziehungsweise weiteren Dienste erreicht werden. Unterschiedliche Firmware- und Rechnerarchitekturen können verschiedene Startdateien benötigen. Eine globale Angabe für alle Geräte kann deshalb einen Teil der Clients bedienen und andere blockieren.

Trenne in der Diagnose DHCP-Bezug, Auswahl der Bootinformationen, Dateitransfer und weiteren Startprozess. Ein erfolgreiches ACK beweist nicht, dass die Startdatei existiert oder zum Client passt. Ein fehlgeschlagener Dateitransfer rechtfertigt umgekehrt keine zufällige Änderung des Adresspools. Die konkrete PXE-Konfiguration bleibt an das verwendete Produkt und dessen dokumentierten Ablauf gebunden.

DURCHGEARBEITETES BEISPIEL

Eine Geräteklasse erhält abweichendes DNS

  1. Lehrziel: Nur ein registrierter Labor-Client mit der festgelegten Kennung soll DNS .20.11 erhalten; andere bleiben bei .20.10.
  2. Policy zunächst inaktiv bzw. im isolierten Scope erstellen. Bedingung und Verarbeitungsebene dokumentieren.
  3. Beide Testclients neu beziehen lassen, Option 6 im ACK prüfen. Danach einen überlappenden Regeltest durchführen und erklären, warum diese Reihenfolge gewinnt.
  4. Falls ein nicht passender Client die Sonderoption erhält, Bedingungen/Reihenfolge korrigieren; keine pauschale Serveroption als Ersatz setzen.

Ergebnis: Eine gute Policy enthält nicht nur einen positiven Beispielclient, sondern nachgewiesene Grenzen und einen dokumentierten Standardfall.

Typische Fehler

  • Vendor Class ist keine sichere Authentisierung.
  • PXE-Verhalten ist architektur- und produktabhängig.
  • Verarbeitungsreihenfolgen sind keine allgemeine DHCP-Protokollregel.

Praktisch anwenden

P30 öffnen P38 öffnen

Offizielle Quellen

Versionsbezüge geprüft am 14. Oktober 2026. Produktkonfigurationen werden im jeweiligen isolierten Labor validiert.