Wie richte ich auf einer Cisco ISE einen Testbenutzer und eine Policy für den automate-tester eines Cisco Switches ein?

## Klare Antwort **Für den `automate-tester` auf einem Cisco Switch brauchst du in ISE in der Regel genau drei Dinge: einen internen Testbenutzer, ein passendes Authorization Profile und eine Policy-Rule, die diesen Benutzer eindeutig matcht. Der häufigste Fehler ist nicht der Benutzer selbst, sondern dass die Rule im falschen Policy Set liegt oder unter einer allgemeineren Rule steht.** ([cisco.com](https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/214975-configure-eap-tls-authentication-with-is.html)) ## So richtest du es sauber ein ### 1) Testbenutzer in ISE anlegen Lege den Benutzer im internen Identity Store an, wenn du bewusst ohne AD/LDAP testen willst. In ISE müssen Benutzerkonten vorhanden sein, damit sich ein User gegen den internen Store authentifizieren kann. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/security/ise/1-4-1/admin_guide/b_ise_admin_guide_141/b_ise_admin_guide_141_chapter_01101.html)) Typischer Weg in aktuellen ISE-Versionen: - **Administration** → **Identity Management** → **Identities** → **Users** - **Add** - Beispiel: - Username: `automate-tester` - Password: eigenes Testpasswort - Identity Group: z. B. `Employee` oder besser eine eigene Gruppe wie `Test-Users` Praktisch ist eine **eigene Identity Group** für solche Tests. Dann baust du die Policy nicht auf einen einzelnen Username, sondern auf eine klar getrennte Testgruppe. Das ist sauberer und später leichter zu entfernen. ### 2) Authorization Profile anlegen Die eigentliche Freigabe passiert nicht über den Benutzer, sondern über das **Authorization Profile**. ISE weist nach erfolgreicher Authentifizierung anhand der Authorization Policy ein Ergebnis zu. Authorization Profiles werden unter den Policy Elements als Result angelegt. ([cisco.com](https://www.cisco.com/en/US/docs/security/ise/1.0/user_guide/ise10_authz_polprfls.html)) Pfad: - **Policy** → **Policy Elements** → **Results** → **Authorization** → **Authorization Profiles** Für einen simplen Switch-Test reicht oft eines dieser Profile: - **PermitAccess** / voller Zugriff - VLAN-Zuweisung - dACL - Web-Redirect, falls du genau so etwas testest Für einen reinen Funktionstest ist **PermitAccess** meist die beste erste Wahl. Das ist der wichtige Unterschied: **Authentifizierung prüft, wer der Benutzer ist; Autorisierung entscheidet, was danach passiert.** ### 3) Policy Set prüfen oder anlegen ISE wertet Policy Sets und die darin enthaltenen Regeln **von oben nach unten** aus. Sobald ein passendes Set bzw. eine passende Rule gefunden wird, greift diese Logik. Wenn dein Testbenutzer nie in der richtigen Rule landet, ist fast immer die Reihenfolge oder die Match-Bedingung falsch. ([cisco.com](https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/214975-configure-eap-tls-authentication-with-is.html)) Pfad: - **Policy** → **Policy Sets** Dort entweder: - vorhandenes Wired-802.1X/MAB-Policy-Set für den Switch nutzen - oder ein separates Test-Policy-Set anlegen Achte darauf, dass das Policy Set wirklich den Traffic deines Switches matcht, z. B. über: - NAS-Port-Type - Device Type / Network Device Group - RADIUS Called-Station-ID - Protocol wie Wired 802.1X ## Die eigentliche Regel ### Authentication Policy Im passenden Policy Set muss die Authentication Policy den internen Store verwenden, wenn dein Benutzer lokal in ISE liegt. Beispiel: - Bedingung: Standard Wired 802.1X - **Allowed Protocols**: passend zu deinem Test - **Identity Source**: **Internal Users** Wenn hier stattdessen nur AD oder ein anderes Identity Source Sequence eingetragen ist, schlägt `automate-tester` trotz korrekt angelegtem Benutzer fehl. ### Authorization Policy Danach legst du eine Rule an, die genau deinen Testbenutzer oder besser seine Gruppe trifft. Cisco beschreibt, dass Authorization Rules über Bedingungen und ein zugeordnetes Profil aufgebaut werden. ([cisco.com](https://www.cisco.com/en/US/docs/security/ise/1.0/user_guide/ise10_authz_polprfls.html)) Beispiel für eine saubere Rule: - Rule Name: `TEST_AUTOMATE` - Condition: - `IdentityGroup = Test-Users` - optional zusätzlich `NetworkDeviceGroup = Switches` - Result: - `PermitAccess` oder dein eigenes Test-Profil **Wichtig:** Diese Rule muss **oberhalb** allgemeiner Regeln wie „Employees“, „Default Wired Access“ oder „Any Authenticated“ stehen, sonst wird sie nie erreicht. ([cisco.com](https://www.cisco.com/en/US/docs/security/ise/1.0/user_guide/ise10_authz_polprfls.html)) ## Praxisbeispiel, das meistens sofort funktioniert Wenn du nur prüfen willst, ob der Switch sauber gegen ISE authentifiziert und autorisiert: 1. Benutzer `automate-tester` lokal in ISE anlegen 2. Gruppe `Test-Users` verwenden 3. Authentication Policy auf **Internal Users** 4. Authorization Rule: `IdentityGroup = Test-Users` 5. Result: `PermitAccess` Damit trennst du den Test klar von produktiven Regeln. Besser als ein Username-Match ist die Gruppe, weil du später weitere Testkonten hinzufügen kannst, ohne die Policy umzubauen. ## Der häufigste Denkfehler Viele richten nur den User ein und erwarten, dass der Zugriff dann automatisch klappt. Das reicht in ISE nicht. **Ohne passende Authorization Rule bekommt der Benutzer zwar eventuell eine erfolgreiche Authentifizierung, aber nicht das gewünschte Zugriffsresultat.** Genau deshalb musst du Benutzer, Identity Source und Authorization Profile immer zusammen denken. ([cisco.com](https://www.cisco.com/en/US/docs/security/ise/1.0/user_guide/ise10_authz_polprfls.html)) ## Wenn der Test trotzdem fehlschlägt Prüfe in dieser Reihenfolge: - **Live Logs**: wurde das richtige Policy Set getroffen - **Authentication Details**: wurde wirklich **Internal Users** verwendet - **Authorization Details**: welche Rule hat gematcht - **Rule Order**: steht deine Testregel weit genug oben - **Switch-Konfiguration**: sendet der Switch wirklich 802.1X oder MAB so, wie deine Policy es erwartet Der entscheidende Punkt ist: **Ein funktionierender Testbenutzer beweist nur dann etwas, wenn du im Live Log siehst, dass genau die beabsichtigte Authentication- und Authorization-Rule gegriffen hat.**