User Label
Identifiziert den Initiator, zum Beispiel Benutzergruppe, AP, Client oder WLAN.
1. Lernziele
- die verschiedenen Labelobjekte in Mist auseinanderhalten
- Labels von Rollen, Site Groups, Tags und Profilen abgrenzen
- Organisation-, Site- und Switch-Scope korrekt wählen
- WxLAN-Quellen und -Ressourcen modellieren
- Switch-Policy-Labels für ACLs einsetzen
- Access-Assurance-Labels als Match und Action verstehen
- Client Labels in der NAC Endpoint Database einordnen
- GBP Tags nicht mit allgemeinen Labels verwechseln
- MSP-Labels zur Organisationsgruppierung verwenden
- Labeländerungen sicher testen und betreiben
Leitfrage: Welches Labelobjekt wird in welchem Scope von welcher Policy Engine ausgewertet – und welche technische Wirkung folgt tatsächlich?
2. Was ist ein Label?
Ein Label fasst mehrere logisch zusammengehörige Benutzer, Geräte, Anwendungen oder Ressourcen unter einem lesbaren Namen zusammen. Eine Policy referenziert anschließend den Namen statt jedes Einzelobjekt erneut aufzulisten.
Rohwerte→Label→Policy Match→Action
Label = Klassifikation oder Referenzgruppe; Policy = Entscheidung und Wirkung
Ein Label erlaubt oder blockiert allein noch keinen Verkehr. Erst seine Verwendung in einer konkreten Policy erzeugt eine fachliche und technische Wirkung.
3. Die Labelwelten in Mist
| Labelwelt | Objekte | Verwendung |
|---|---|---|
| Wireless/WxLAN | Benutzer- und Ressourcenlabels | WLAN-Zugriffsregeln und App-Klassifikation |
| Switch Policies | Source-/Destination-Labels | portprofil- oder RADIUS-basierte ACLs |
| Access Assurance | Auth Policy Labels | Authentisierungs-Match und Permit Actions |
| NAC Endpoints | Client Labels an MAC-Objekten | Match in Auth Policies |
| MSP | Labels an Organisationen | Gruppierung, Filterung, teilweise Policy-/Rollen-Scope |
Keine universelle Labeldatenbank: Gleichlautende Labels in zwei Modulen sind nicht automatisch dasselbe Objekt und werden nicht automatisch synchronisiert.
4. Ähnliche Objekte, aber keine Labels
| Objekt | Zweck | Warum abgrenzen? |
|---|---|---|
| Site Group | Sites gruppieren und Administration/Zuordnung strukturieren | keine Benutzer-/Ressourcenklassifikation |
| Switch Role | Switchregeln oder Upgrade-Zielmengen treffen | Gerätefunktion statt Policylabel |
| Port Profile | Interfacekonfiguration bündeln | Konfigurationsprofil, kein Matchcontainer |
| Device Profile | Gerätekonfiguration zuweisen | Intent statt Klassifikation |
| GBP Tag | numerischer/technischer Gruppenkontext im VXLAN-Policyverfahren | eigenes Enforcementmodell |
| Asset Filter | BLE-Geräte über Payload identifizieren | Location-Filter, keine WxLAN-/NAC-Policy |
5. Scope: Organisation, Site oder Switch
| Scope | Vorteil | Risiko |
|---|---|---|
| Organisation | zentraler Standard und Templateverwendung | große Zielmenge bei Fehler |
| Site | lokale Ressourcen und Regeln | Duplikate und abweichende Semantik |
| Switch | eng begrenzte Switch-Policy-Ausnahme | Sonderfall und geringe Wiederverwendung |
| MSP | Organisationen kundenübergreifend gruppieren | Mandantenscope und Rollenwirkung prüfen |
Ein Label muss dort erstellt werden, wo die konsumierende Policy darauf zugreifen kann. Sichtbarkeit im Portal ist kein Beweis, dass es in jeder anderen Policy Engine auswählbar ist.
6. Wireless- und WxLAN-Labels
Juniper beschreibt WxLAN-Labels als Sammlung von Benutzern oder Ressourcen. Sie werden unter Organization → Wireless → Labels oder – für lokale Anwendungsfälle – unter Site → Wireless → Labels erstellt.
Resource Label
Identifiziert das Ziel, zum Beispiel Anwendung, Hostname, IP-Adresse oder Port.
Organisationsebene ist für WLAN-Template-Policies bestimmt; Siteebene für standortbezogene Policies. Da ältere Juniper-Einzelseiten teilweise nur Organisationlabels für bestimmte WxLAN-Dialoge nennen, wird die tatsächliche Auswahlliste im aktuellen Portal und im verwendeten Policy-Scope geprüft.
7. WxLAN-Labeltypen
| Klasse | Typ | Beispiel |
|---|---|---|
| User | AAA Attribute | RADIUS-Rolle oder Attribut |
| User | Access Point | Benutzer über ausgewählte APs einordnen |
| User | Wi-Fi Client | bestimmte Clientidentitäten |
| User | WLAN | Verkehr eines bestimmten WLANs |
| Resource | Application | erkannte Applikationskategorie |
| Resource | Hostname | updates.example.org |
| Resource | IP Address | Host, Präfix oder Ressourcenbereich |
| Resource | Port | TCP/UDP-Dienst nach Policytyp |
Welche Eingabefelder verfügbar sind, hängt vom Labeltyp ab. Typ und Werte werden so spezifisch wie nötig, aber nicht unnötig fragil gewählt.
8. Labels in einer WxLAN Policy
User Label+Resource Label+Conditions→Allow/Block
| Schritt | Prüfung |
|---|---|
| 1. Benutzergruppe | Wer initiiert den Verkehr? |
| 2. Ressource | Welches Ziel oder welche Anwendung? |
| 3. Regel | Welche Kombination soll matchen? |
| 4. Action | Allow, Block oder weitere angebotene Aktion? |
| 5. Reihenfolge | Welche frühere Regel könnte bereits matchen? |
| 6. Default | Was geschieht ohne Match? |
Die Policy muss mit positivem Match, negativem Match und No-Match getestet werden. Nur ein erfolgreicher Allow-Test beweist nicht, dass die Sperrgrenzen korrekt sind.
9. Policypriorität und Scope
Juniper dokumentiert für WxLAN, dass Regeln einer WLAN-Template-Policy Vorrang vor Site-Regeln haben können: Die Site-Regel greift erst, wenn keine zutreffende Organisations-/Template-Regel bereits matcht.
| Fehlerbild | Prüfung |
|---|---|
| Site-Regel scheint wirkungslos | übergeordnete Template-Regel matcht bereits |
| Label nicht auswählbar | Labelscope passt nicht zum Policyscope |
| zu breite Freigabe | frühere Regel oder zu allgemeines Label |
| unerwarteter Block | Reihenfolge, Default Action und Ressourcenauflösung |
Policywirkung = Scope + Labelauflösung + Regelreihenfolge + Action + Default
10. Unbekannte Anwendungen benennen
Mist verwendet DNS-Antworten, um Anwendungen in Insights zu klassifizieren. Nicht erkannte Ziele können mit einem Hostname-Label lesbarer gemacht werden.
Unknown Traffic→DNS Hostname→Hostname Label→Application Insight
- DNS-Name fachlich und technisch verifizieren
- Label Type
Hostnameverwenden - ein oder mehrere relevante Hostnames hinterlegen
- Traffic erneut erzeugen und Insights prüfen
- CDN-, Alias- und wechselnde Hostnames berücksichtigen
Juniper nennt für die Applications-Anzeige einen Traffic-Threshold von 200 KB. Ein korrektes Label muss deshalb nicht sofort bei sehr wenig Traffic erscheinen.
11. Source-/Destination-Labels für Switches
Switch Policy Labels werden in Switch Templates, auf Siteebene oder am Switch definiert. Sie kategorisieren Benutzer beziehungsweise Quellen und Ressourcen beziehungsweise Ziele für ACL-basierte Policies.
| Richtung | Inhalt | Beispiel |
|---|---|---|
| Source Label | Quellidentität oder Quelladressbereich | IoT-Clients, Drucker, Mitarbeiter |
| Destination Label | Zielressource oder Zieladressbereich | DNS, NTP, Printserver, Internet |
Die konkreten Felder und unterstützten Plattformen werden im aktuellen Switch-Policy-Dialog geprüft. Ein semantischer Name ersetzt nicht die Kontrolle der tatsächlich gerenderten IP-/Filterdefinition.
12. Portprofil- und RADIUS-basierte Switch Policies
| Policytyp | Enforcement | Voraussetzung |
|---|---|---|
| Port Profile-Based | Layer-2-Inputfilter auf Ports mit dem Profil | Port Profile vorbereitet und zugewiesen |
| RADIUS-Based | RADIUS-gesteuerter Filter nach Authentisierung | Filter auf RADIUS-Seite und korrekte Filter-ID |
Source Label→Switch Policy→Destination Label→Permit/Deny
Port Profile und Label übernehmen unterschiedliche Aufgaben: Das Profil wählt Ports und Grundkonfiguration; Labels beschreiben die Kommunikationsbeziehung innerhalb der Policy.
13. RADIUS-basierte Firewallfilter
Bei RADIUS-basierten Switch Policies liegen die Filterdefinitionen beziehungsweise deren IDs auf der RADIUS-Seite. Mist referenziert diese in der Policy.
| Komponente | Verantwortung |
|---|---|
| RADIUS Policy | Authentisierung und Rückgabe passender Filterattribute |
| Filter-ID/VSA | eindeutige technische Referenz |
| Mist Label | lesbare Quell-/Ressourcenklassifikation |
| Switch Policy | Verknüpfung der Gruppen und Aktion |
| EX Switch | technisches Enforcement |
Ein Tippfehler oder fehlender Filter auf dem RADIUS-Server wird nicht dadurch repariert, dass das Mist-Label richtig benannt ist. Beide Systeme müssen konsistent versioniert werden.
14. Access-Assurance-Policy-Labels
Unter Organization → Access → Auth Policy Labels werden Labels für Auth Policies angelegt. Sie können als Matchkriterium und – bei geeigneten Typen – als Permit Action verwendet werden.
Match
Welche Benutzer-, Geräte-, Zertifikats-, SSID-, MDM- oder Directory-Eigenschaft liegt vor?
Permit Action
Welche Attribute wie VLAN, Rolle oder GBP Tag werden bei erfolgreichem Match angewendet?
Juniper erlaubt bei Auth Policy Labels Namen bis 32 Zeichen mit alphanumerischen und unterstützten Sonderzeichen. Eindeutigkeit und sprechende Semantik bleiben wichtiger als maximale Länge.
15. Wichtige Auth-Labeltypen
| Typ | Datenquelle | Verwendung |
|---|---|---|
| AAA Attribute | RADIUS-/AAA-Rolle | Match und teilweise Permit Action |
| Certificate Attribute | CN, Subject, Serial, Issuer, SAN | Zertifikatsbasiertes Match |
| Client List | MAC oder OUI, optional Wildcards | Geräte ohne 802.1X klassifizieren |
| SSID | Called-Station-Kontext | WLAN als Matchkriterium |
| Directory Attribute | IdP-Gruppenmitgliedschaft | Identitätsbasiertes Match |
| MDM Compliance | MDM-Posture: compliant/non-compliant/unknown | Posture-Match |
| Client Label | NAC Endpoint Database | manuelle/integrierte Endpointklassifikation |
16. Client Labels in der NAC Endpoint Database
Ein Client Label ist Text, der einer MAC-Adresse in der Endpoint Database zugeordnet wird, beispielsweise printer, floor2 oder building3. Eine Auth Policy kann danach auf dieses Label matchen.
MAC Endpoint→Client Label→Auth Policy Match→Access Action
| Risiko | Kontrolle |
|---|---|
| MAC Spoofing | Client Label nicht als alleinigen Hochsicherheitsnachweis verwenden |
| stale Zuordnung | Owner und Ablaufdatum pflegen |
| Gerätetausch | altes Endpointobjekt entfernen oder neu binden |
| uneinheitliche Schreibweise | kontrolliertes Vokabular |
| zu breites Label | Policyimpact vor Batchänderung simulieren |
17. Match Any, Match All und Verschachtelung
| Logik | Bedeutung | Beispiel |
|---|---|---|
| Match Any / OR | mindestens ein Kriterium genügt | Mitarbeiter ODER Dienstgerät |
| Match All / AND | alle Kriterien müssen gelten | Mitarbeiter UND compliant UND Corp-SSID |
| Nested | Gruppen aus AND/OR-Ausdrücken | (Gruppe A ODER B) UND compliant |
| No Match | Regel wird übersprungen | nächste Regel oder Default |
Die 2026er Auth-Policy-Oberfläche kennzeichnet verschachtelte Regeln und Match-any/-all visuell. Trotzdem wird die Logik zusätzlich in Klartext dokumentiert; eine Drag-and-Drop-Darstellung ist kein formaler Beweis für die beabsichtigte Semantik.
18. Labels als Permit Action
Nicht jedes Label ist nur ein Eingangskriterium. In Access Assurance können geeignete AAA-/Policyobjekte Aktionen beziehungsweise zusätzliche Attribute repräsentieren.
| Action | Wirkung | Abnahme |
|---|---|---|
| VLAN | dynamische Netzzuweisung | VLAN Ende-zu-Ende vorhanden, DHCP und Gateway |
| Role | logische Zugriffsrolle | nachgelagerte Policy versteht Rolle |
| GBP Tag | Gruppenkontext für GBP | Fabric/Plattform und Policies unterstützen Tag |
| weitere RADIUS Attribute | produktspezifische Autorisierung | NAS verarbeitet Attribut korrekt |
Ende-zu-Ende-Prüfung: Ein Access-Accept beweist nicht, dass das zurückgegebene VLAN, die Rolle oder der GBP Tag im Netzwerk korrekt umgesetzt wird.
19. GBP Tags sind eigene Objekte
Group-Based Policies verwenden Tags zur topologieunabhängigen Mikrosegmentierung über unterstützte EVPN-VXLAN-Plattformen. Sie werden in Switch Template beziehungsweise Site Switch Configuration angelegt und in GBP/Switch Policies referenziert.
| Begriff | Rolle |
|---|---|
| User Group Tag | klassifiziert die Quellgruppe |
| Resource Group Tag | klassifiziert die Zielressource |
| GBP Policy | erlaubt oder blockiert Gruppenbeziehungen |
| VNI/VXLAN | transportiert Segment- und Policykontext |
Juniper listet konkrete Plattform- und Junos-Anforderungen. Diese sind zeitabhängig und werden vor Design geprüft; ein „Tag“ im Namen reicht nicht, um GBP-Fähigkeit zu erzeugen.
20. MSP-Labels
MSP-Labels werden Organisationen zugewiesen, um Mandanten im MSP-Dashboard zu kategorisieren, zu filtern oder in unterstützten SSO-/Policykontexten zu gruppieren.
MSP Inventory→Organisationen wählen→Settings→Labels hinzufügen/entfernen
| Beispiel | Zweck |
|---|---|
region-de | geografische Gruppe |
service-premium | Betriebs-/Serviceklasse |
customer-municipal | Kundensegment |
renewal-q4 | operative Filterung |
MSP-Labels klassifizieren Organisationen, nicht WLAN-Benutzer oder Netzwerkressourcen. Der aktuelle Rollenscope ist funktionsabhängig; Juniper dokumentiert beispielsweise Einschränkungen bestimmter MSP-Network-Admin-Scopes mit Labels.
21. Naming Standard
| Regel | Gutes Beispiel | Schlechtes Beispiel |
|---|---|---|
| Domäne erkennbar | wx-res-dns-internal | dns |
| Quelle/Ziel erkennbar | sw-src-iot-camera | camera |
| Scope nur wenn nötig | site-ber-res-print | label-17 |
| keine Action vortäuschen | auth-idp-finance | allow-finance |
| stabile Semantik | endpoint-managed-printer | temporary-new |
Empfohlenes Schema: <domain>-<direction/type>-<meaning>[-<scope>]. Das ist eine Designempfehlung dieser Unterlage, keine Juniper-Vorgabe.
22. Label-Lifecycle
Welche Policyaussage soll vereinfacht werden?
IP, Hostname, AAA, Zertifikat, Directory, MDM oder manuelles Endpointlabel?
Organisation, Site, Switch oder MSP?
Name, Typ, Werte, Owner und Beschreibung dokumentieren.
Label referenzieren und Regelreihenfolge prüfen.
Positive, negative und No-Match-Fälle.
Hit Count, NAC Events, Insights und Änderungen überwachen.
Referenzen entfernen, Wirkung prüfen, Label löschen.
23. Sicherheit und Governance
- jedes Label besitzt fachlichen Owner und Zweck
- Werte stammen aus autoritativer Datenquelle
- Wildcards und OUIs werden besonders kritisch geprüft
- personengebundene oder sensible Namen vermeiden
- Labeländerungen als Policyänderungen behandeln
- Batchzuweisungen mit Vier-Augen-Prüfung
- Directory-/MDM-Ausfälle und Unknown-Zustand definieren
- Default Deny oder Default Allow bewusst dokumentieren
- alte Labels und ungenutzte Referenzen regelmäßig bereinigen
- API- und Portaländerungen auditierbar halten
Je dynamischer die Datenquelle, desto wichtiger Fail State, Aktualität und Nachweis.
24. Systematische Fehlersuche
| Symptom | Prüfung |
|---|---|
| Label nicht auswählbar | falsche Labelwelt, Scope oder Policytyp |
| Regel matcht nie | Rohwert, Schreibweise, Datenquelle, AND/OR, Reihenfolge |
| Regel matcht zu breit | Wildcard, OUI, CIDR, Match Any und frühere Regel |
| Site Policy wirkungslos | übergeordnete Template-/Org-Regel |
| Unknown App bleibt | DNS-Sichtbarkeit, Hostname, Traffic unter 200 KB, CDN |
| Auth Label vorhanden, falsches VLAN | Permit Action, RADIUS Attribute, VLAN Ende-zu-Ende |
| Switch Policy ohne Wirkung | Port Profile, Filter-ID, Richtung, gerenderte ACL |
| Client Label veraltet | NAC Endpoint, MAC/Owner, Synchronisation |
| GBP-Kommunikation fehlerhaft | Tagzuweisung, Policy, Plattform, VNI/Fabric |
Beweiskette: Rohattribut → Labelauflösung → Regelmatch → Action → Enforcement → Datenverkehr. An jeder Stufe kann ein eigener Fehler vorliegen.
25. Beispielmodell
Use Case: Verwaltete Drucker
| Ebene | Objekt | Aussage |
|---|---|---|
| NAC Endpoint | client-label: managed-printer | inventarisierte MAC gehört zu verwaltetem Drucker |
| Auth Match | Client Label + optional MDM/Certificate | Endpoint erfüllt Identitätsanforderung |
| Permit Action | VLAN PRINTER | Netzsegment zuweisen |
| Switch Source Label | sw-src-managed-printer | Druckerquellen klassifizieren |
| Destination Label | sw-dst-print-services | DNS, NTP und Printserver |
| Switch Policy | Source → Destinations permit; Rest deny | Kommunikation begrenzen |
Die gleichartige Namensgebung macht die Beziehung sichtbar, ohne technisch zu behaupten, dass NAC Client Label und Switch Source Label dasselbe Objekt wären.
26. Produktionscheckliste
Vor Aktivierung
- richtige Labelwelt
- Scope und Consumer
- eindeutiger Name
- Typ und Rohwerte
- Owner und Zweck
- Policyreihenfolge
- Default Action
- Positiv-/Negativtest
Im Betrieb
- Hits und NAC Events
- stale Endpoints
- Directory-/MDM-Sync
- DNS-/App-Veränderungen
- RADIUS-Filter-IDs
- GBP-/Fabricstatus
- Change- und Auditlog
- ungenutzte Labels
Häufige Fehlannahmen
| Behauptung | Bewertung | Einordnung |
|---|---|---|
| „Ein Label erlaubt Verkehr.“ | Falsch | Erst die Policyaction erzeugt Wirkung. |
| „Alle Mist-Labels sind global.“ | Falsch | Module und Scopes besitzen getrennte Objekte. |
| „Switch Role ist ein Policylabel.“ | Falsch | Sie steuert Geräteauswahl, nicht Benutzer-/Ressourcenmatch. |
| „GBP Tag und Label sind dasselbe.“ | Falsch | GBP Tags haben eigenes VXLAN-Enforcementmodell. |
| „MAC Client Label beweist Identität.“ | Falsch | MAC kann gefälscht werden und benötigt Lifecyclekontrolle. |
| „Site-Regel hat immer Vorrang.“ | Falsch | Übergeordnete WxLAN-Template-Regeln können vorher matchen. |
| „Labelname beweist den Inhalt.“ | Falsch | Entscheidend sind Typ, Werte und aktuelle Datenquelle. |
Merksätze
- Label ist Klassifikation; Policy ist Entscheidung.
- Gleicher Name bedeutet nicht gleiches Objekt.
- Scope bestimmt Sichtbarkeit und Wiederverwendung.
- WxLAN trennt Benutzer und Ressourcen.
- Regelreihenfolge ist Teil der Sicherheit.
- Client Labels benötigen einen Endpoint-Lifecycle.
- RADIUS-Filter müssen in beiden Systemen konsistent sein.
- GBP Tags sind keine allgemeinen Labels.
- MSP-Labels gruppieren Organisationen.
- Jede Labeländerung ist potenziell eine Policyänderung.
Offizielle Grundlagen
- WxLAN Access Policies
- Using Labels in a WxLAN Policy
- Use Labels to Identify Unknown Applications
- Switch Configuration Options
- Switch Policies
- Authentication Policy Labels
- Group-Based Policies
- Add or Remove MSP Labels
- MSP Inventory View
- Auth Policy Label Workflow Update 2026
Stand der fachlichen Prüfung: August 2026. Labeltypen, Menüpunkte, Policyfunktionen, Plattformunterstützung und Prioritätsregeln können sich ändern. Für produktive Policies gelten die aktuelle Juniper-Dokumentation, der konkrete Cloudrelease, die gerenderte Konfiguration und ein realer Positiv-/Negativtest.