# Regeln ## Allgemein Alle von Ihnen konfigurierten Regeln werden angewendet **nach** erfolgreicher Anmeldeinformationen-Authentifizierung, was bedeutet, dass die Regeln erst nach Bereitstellung gültiger Authentifizierungsdaten wirksam werden. Dies impliziert, dass zum Passieren der ersten Authentifizierungsschranke gültige **Trusted Roots** (zertifikatbasierte Authentifizierung) oder **Benutzer** (benutzername- und passwortbasierte Authentifizierung) zu Ihrer Instanz hinzugefügt werden müssen. ### Standardregel Um Störungen einer bestehenden Instanz zu vermeiden oder falls Sie die Rule Engine überhaupt nicht verwenden möchten, ist jede Authentifizierung standardmäßig zulässig, wenn keine Regel definiert ist. Dies wird durch unsere Standardregel realisiert **Jede Authentifizierung erlaubt**. {% hint style="warning" %} Die Standardregel **Jede Authentifizierung erlaubt** erfordert weiterhin das Vorhandensein gültiger Authentifizierungsdaten für eine erfolgreiche Netzwerkauthentifizierung. {% endhint %} ### Reihenfolge der Regelverarbeitung Wenn Sie mehrere Regeln konfiguriert haben, werden diese in der Reihenfolge angewendet, die Sie in Ihrem Webportal sehen – von oben nach unten. Die einzige Ausnahme ist die **Jede Authentifizierung erlaubt** Regel, die, falls sie konfiguriert ist, als letzter Schritt behandelt wird. Dies ist besonders hilfreich während eines Einführungs-/Rollout-Szenarios, in dem Sie möglicherweise nicht sicher sind, ob Ihre Regeln alle Anwendungsfälle oder Standorte abdecken. Alle Authentifizierungsanfragen, die von den vorherigen Regeln abgelehnt werden, werden dann weiterhin von der Standardregel akzeptiert. Im Dashboard können Sie dann die Geräte/Benutzer beobachten, die bei allen anderen Regeln fehlschlagen, und die Regeln entsprechend korrigieren/erweitern. Falls Sie am Ende eine große Anzahl von Regeln haben, empfehlen wir – um eine hohe Leistung beizubehalten – die Regeln so anzuordnen, dass die wahrscheinlichsten Regeln zuerst getroffen werden.

Regeln anzeigen

## Regeloptionen ### Authentifizierung * Nur bestimmte Authentifizierungsquellen zulassen * z. B. WiFi oder LAN (VPN-Unterstützung ist in Arbeit) * Nur bestimmte Authentifizierungstypen zulassen * z. B. Zertifikat oder Benutzername+Passwort #### Zertifikatbasierte Authentifizierung * Nur bestimmte Trusted CAs (Root- oder ausstellende CAs) zulassen * Nur bestimmte Intune-IDs zulassen oder das Zertifikatsattribut vollständig ignorieren #### Benutzername-/passwortbasierte Authentifizierung * Nur Benutzernamen zulassen, die zu einem Regex-Muster passen ### Konfiguration #### Infrastrukturelle Einschränkungen * Definieren Sie, welche **SSIDs** zulässig sind * Definieren Sie, welche **Access Points oder Netzwerkswitches** zulässig sind (MAC-basiert) #### VLAN-Zuweisung VLAN-IDs zuweisen ... * Statisch * Durch Auswertung einer benutzerdefinierten **Zertifikaterweiterung** * Durch Parsen von Attributen in Ihrem Zertifikat **Betreffname** #### Zusätzliche RADIUS-Rückgabeattribute Standardmäßig können Sie aus der folgenden Liste von Rückgabeattributen wählen, die Sie als Teil einer passenden Regel zurückgeben können: * Filter-Id * Fortinet-Group-Name * Framed-MTU * Tunnel-Password * Cisco-AVPair * Class {% hint style="info" %} RADIUS-Rückgabeattribute ermöglichen es Netzwerkadministratoren, spezifische Einstellungen für einzelne Benutzer oder Gruppen zu definieren. Zum Beispiel, * Für die Benutzerprofilkonfiguration kann ein Attribut die maximale Sitzungsdauer, zulässige Dienste (z. B. VPN oder WLAN) und die Methode der IP-Adresszuweisung festlegen. * Für die dynamische IP-Adresszuweisung kann ein Attribut festlegen, dass der Benutzer eine statische IP-Adresse erhalten oder DHCP für die dynamische Zuweisung verwenden soll. * Für Zugriffskontrolle und Autorisierung bestimmt ein Attribut die Zugriffsebene des Benutzers (z. B. Gast, Mitarbeiter, Administrator) und etwaige Einschränkungen (z. B. Zeitlimits). * Für die Sitzungsverwaltung kann ein Attribut das Sitzungs-Timeout (wie lange der Benutzer verbunden bleiben kann), das Leerlauf-Timeout (Trennung nach Inaktivität) und die maximale Anzahl gleichzeitiger Anmeldungen festlegen. * Für Quality of Service (QoS) kann ein Attribut beispielsweise Sprachverkehr gegenüber Datenverkehr für einen bestimmten Benutzer priorisieren. Anbieter können ihre eigenen benutzerdefinierten Attribute erstellen (anbieterspezifische Attribute oder VSAs). Diese ermöglichen zusätzliche Funktionen über die standardmäßigen IETF-Attribute hinaus. VSAs sind innerhalb des Standardattributs 26 eingebettet. {% endhint %} Zusätzliche RADIUS-Attribute zurückgeben ... * Statisch * Durch Auswertung einer benutzerdefinierten **Zertifikaterweiterung** * Durch Parsen von Attributen in Ihrem Zertifikat **Betreffname** --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.radiusaas.com/de/admin-portal/settings/rules.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.