Part 1 The Outer ProxyAuthentication Flow:
In short, the PPS acts as a relay between the RADIUS client and the external RADIUS server.Note: !!!An outer proxy will fail if the realm is part of a sign-in URL that includes any other realms!!!
- The PPS forwards everything to the external RADIUS server and does not inspect the credentials at all.
- All attributes from the RADIUS client are sent to the external RADIUS server as well, attributes such as NAS-IP-Address and calling-station-ID.
- It is the external RADIUS server that presents its certificate to the supplicant and negotiates the tunneled EAP protocol in the case of 802.1x
- If successful, the external RADIUS server sends an access accept and any return attributes the proxied user is assigned.
- The PPS forwards the response from the external RADIUS server to the RADIUS client including all the return attributes.
Protocols Supported: All protocols supported by the external RADIUS serverPart 2 The Inner ProxyAuthentication Flow:
- In the case of an 802.1x authentication, it is the external RADIUS server’s certificate that is presented to the supplicant during mutual authentication not that of the PPS, ensure the supplicant has the necessary certificates installed to validate the external server.
- The PPS does not monitor users authenticated via an outer proxy; the user will not appear in Active Users. No session is created on the PPS.
- The PPS cannot process any role mapping rules based on the username or directory lookup as the PPS is unaware of the user’s credentials.
- The PPS evaluates the incoming request and determines which realm it should be sent to. If sent to the realm configured for an inner proxy, the PPS decrypts the TLS tunnel in the case of 802.1x.
- For 802.1x the tunnel exists between the PPS and the supplicant.
- The PPS then sends the credentials to the external RADIUS server which will result in a success or failure.
- If successful, the PPS can perform role mapping as with an inner proxy the PPS is aware of the user’s name.
- Any return attributes are defined on and returned by the PPS.
- A session is created.
Protocols Supported: TTLS, PEAP, PAP, CHAP, EAP-MD5, MS-CHAP, and MS-CHAPv2Part 3 Do Not ProxyThe name of this option can be misleading. “Do Not Proxy” means that the PPS will manage all aspects of the authentication which include…
- With the inner proxy it is the PPS device certificate that the supplicant may need to validate in the case of 802.1x.
- With an inner proxy it is the PPS that assigns any return attributes.
- In the case of 802.1x it is the PPS that negotiates the outer protocol and inner protocol in the case of 802.1x.
The external RADIUS server only validates the user’s credentials. The PPS will use PAP to send the user credentials to the external RADIUS server.For a Do Not Proxy to be successful, the incoming authentication request that is to be proxied must have the user’s password in clear text. This means PAP. In the case of 802.1x the supplicant must use PAP, or JUAC. The external RADIUS server will need to validate the plain text password. This means that the database the password resides in must have the password stored in either plain text or us reversable encryption.
- Negotiating the protocol
- Sending its certificate for mutual authentication
- Establishing a TTLS, TLS, or PEAP tunnel if 802.1x is used
- Negotiating the inner protocol if 802.1x
- Perform role-based access control, as with an inner proxy, the PPS knows the username
- Supply any return attributes the user is assigned