2. Operation (Betrieb)
2. Operation (Betrieb)
Wenn ein Client für die Verwendung von RADIUS konfiguriert ist, präsentiert jeder Benutzer des Clients dem Client Authentifizierungsinformationen. Dies kann durch eine anpassbare Login-Eingabeaufforderung erfolgen, bei der der Benutzer seinen Benutzernamen und sein Passwort eingeben soll. Alternativ könnte der Benutzer ein Link-Framing-Protokoll wie das Point-to-Point Protocol (PPP) verwenden, das Authentifizierungspakete enthält, die diese Informationen übertragen.
Sobald der Client solche Informationen erhalten hat, kann er sich entscheiden, die Authentifizierung über RADIUS durchzuführen. Dazu erstellt der Client einen "Access-Request", der Attribute wie den Namen des Benutzers, das Passwort des Benutzers, die ID des Clients und die Port-ID enthält, über die der Benutzer zugreift. Wenn ein Passwort vorhanden ist, wird es mit einer Methode verborgen, die auf dem RSA Message Digest Algorithm MD5 [3] basiert.
Der Access-Request wird über das Netzwerk an den RADIUS-Server übermittelt. Wenn innerhalb einer bestimmten Zeitspanne keine Antwort zurückgegeben wird, wird die Anfrage mehrmals erneut gesendet. Der Client kann auch Anfragen an einen oder mehrere alternative Server weiterleiten, falls der primäre Server ausgefallen oder nicht erreichbar ist. Ein alternativer Server kann entweder verwendet werden, nachdem mehrere Versuche zum primären Server fehlgeschlagen sind, oder nach einem Round-Robin-Verfahren. Retry- und Fallback-Algorithmen sind Gegenstand aktueller Forschung und werden in diesem Dokument nicht im Detail spezifiziert.
Sobald der RADIUS-Server die Anfrage erhält, validiert er den sendenden Client. Eine Anfrage von einem Client, für den der RADIUS-Server kein gemeinsames Geheimnis hat, MUSS stillschweigend verworfen werden. Wenn der Client gültig ist, konsultiert der RADIUS-Server eine Datenbank von Benutzern, um den Benutzer zu finden, dessen Name mit der Anfrage übereinstimmt. Der Benutzereintrag in der Datenbank enthält eine Liste von Anforderungen, die erfüllt sein müssen, um dem Benutzer den Zugriff zu gewähren. Dies umfasst immer die Überprüfung des Passworts, kann aber auch die Client(s) oder Port(s) spezifizieren, auf die der Benutzer Zugriff hat.
Der RADIUS-Server KANN Anfragen an andere Server stellen, um die Anfrage zu erfüllen, in diesem Fall fungiert er als Client.
Wenn Proxy-State-Attribute im Access-Request vorhanden waren, MÜSSEN sie unverändert und in der Reihenfolge in das Antwortpaket kopiert werden. Andere Attribute können vor, nach oder sogar zwischen den Proxy-State-Attributen platziert werden.
Wenn eine Bedingung nicht erfüllt ist, sendet der RADIUS-Server eine "Access-Reject"-Antwort, die anzeigt, dass diese Benutzeranfrage ungültig ist. Falls gewünscht, KANN der Server eine Textnachricht in das Access-Reject einfügen, die vom Client dem Benutzer angezeigt werden KANN. Keine anderen Attribute (außer Proxy-State) sind in einem Access-Reject erlaubt.
Wenn alle Bedingungen erfüllt sind und der RADIUS-Server eine Challenge ausgeben möchte, auf die der Benutzer antworten muss, sendet der RADIUS-Server eine "Access-Challenge"-Antwort. Er KANN eine Textnachricht einfügen, die vom Client dem Benutzer angezeigt werden soll, um zur Antwort auf die Challenge aufzufordern, und KANN ein State-Attribut einfügen.
Wenn der Client ein Access-Challenge empfängt und Challenge/Response unterstützt, KANN er die Textnachricht, falls vorhanden, dem Benutzer anzeigen und den Benutzer dann zur Eingabe einer Antwort auffordern. Der Client übermittelt dann seinen ursprünglichen Access-Request mit einer neuen Request-ID erneut, wobei das User-Password-Attribut durch die Antwort (verschlüsselt) ersetzt wird und das State-Attribut aus dem Access-Challenge, falls vorhanden, enthalten ist. Es SOLLTEN nur 0 oder 1 Instanzen des State-Attributs in einer Anfrage vorhanden sein. Der Server kann auf diesen neuen Access-Request entweder mit einem Access-Accept, einem Access-Reject oder einem weiteren Access-Challenge antworten.
Wenn alle Bedingungen erfüllt sind, werden die Konfigurationswerte für den Benutzer in eine "Access-Accept"-Antwort eingefügt. Diese Werte umfassen den Typ des Dienstes (z.B.: SLIP, PPP, Login User) und alle notwendigen Werte zur Bereitstellung des gewünschten Dienstes. Für SLIP und PPP kann dies Werte wie IP-Adresse, Subnetzmaske, MTU, gewünschte Kompression und gewünschte Paketfilter-Identifikatoren umfassen. Für Zeichenmodus-Benutzer kann dies Werte wie gewünschtes Protokoll und Host umfassen.