Related Topics
How RADIUS Server Authentication Works
RADIUS is a protocol that was originally designed to authenticate remote users to a dial-in access server. RADIUS is now used in a wide range of authentication scenarios. RADIUS is a client-server protocol, with the Firebox as the client and the RADIUS server as the server. (The RADIUS client is sometimes called the Network Access Server or NAS.) When a user tries to authenticate, the device sends a message to the RADIUS server. If the RADIUS server is properly configured to have the device as a client, RADIUS sends an accept or reject message back to the device (the Network Access Server).
When the Firebox uses RADIUS for an authentication attempt:
- The user tries to authenticate, either through a browser-based HTTPS connection to the device over port 4100, or through a connection using Mobile VPN with IPSec. The device reads the user name and password.
- The device creates a message called an Access-Request message and sends it to the RADIUS server. The device uses the RADIUS shared secret in the message. The password is always encrypted in the Access-Request message.
- The RADIUS server makes sure that the Access-Request message is from a known client (the Firebox). If the RADIUS server is not configured to accept the device as a client, the server discards the Access-Request message and does not send a message back.
- If the device is a client known to the RADIUS server and the shared secret is correct, the server looks at the authentication method requested in the Access-Request message.
- If the Access-Request message uses an allowed authentication method, the RADIUS server gets the user credentials from the message and looks for a match in a user database. If the user name and password match an entry in the database, the RADIUS server can get additional information about the user from the user database (such as remote access approval, group membership, logon hours, and so on).
- The RADIUS server checks to see whether it has an access policy or a profile in its configuration that matches all the information it has about the user. If such a policy exists, the server sends a response.
- If any of the previous conditions fail, or if the RADIUS server has no matching policy, it sends an Access-Reject message that shows authentication failure. The RADIUS transaction ends and the user is denied access.
- If the Access-Request message meets all the previous conditions, RADIUS sends an Access-Accept message to the device.
- The RADIUS server uses the shared secret for any response it sends. If the shared secret does not match, the device rejects the RADIUS response.
To see diagnostic log messages for authentication, Set the Diagnostic Log Level and change the log level for the Authentication category.
- The device reads the value of any FilterID attribute in the message. It connects the user name with the FilterID attribute to put the user in a RADIUS group.
- The RADIUS server can put a large amount of additional information in the Access-Accept message. The device ignores most of this information, such as the protocols the user is allowed to use (such as PPP or SLIP), the ports the user can access, idle timeouts, and other attributes.
- The device only requires the FilterID attribute (RADIUS attribute number 11). The FilterID is a string of text that you configure the RADIUS server to include in the Access-Accept message. This attribute is necessary for the device to assign the user to a RADIUS group, however, it can support some other Radius attributes such as Session-Timeout (RADIUS attribute number 27) and Idle-Timeout (RADIUS attribute number 28).
For more information on RADIUS groups, see the next section.
About RADIUS Groups
When you configure RADIUS authentication on your Firebox, you can set the Group Attribute number. Fireware OS reads the Group Attribute number you specify in your configuration to determine which RADIUS attribute carries RADIUS group information. Fireware OS recognizes only RADIUS attribute number 11, FilterID, as the Group Attribute. When you configure the RADIUS server, do not change the Group Attribute number from the default value of 11.
When the Firebox gets the Access-Accept message from RADIUS, it reads the value of the FilterID attribute and uses this value to associate the user with a RADIUS group. (You must manually configure the FilterID in your RADIUS configuration.) Thus, the value of the FilterID attribute is the name of the RADIUS group where the device puts the user.
The RADIUS groups you use in your Firebox configuration are not the same as the Windows groups defined in your domain controller, or any other groups that exist in your domain user database. A RADIUS group is only a logical group of users the Firebox uses. Make sure you carefully select the FilterID text string. You can make the value of the FilterID match the name of a local group or domain group in your organization, but this is not necessary. We recommend you use a descriptive name that helps you remember how you defined your user groups.
Practical Use of RADIUS Groups
If your organization has many users to authenticate, you can make your Firebox policies easier to manage if you configure RADIUS to send the same FilterID value for many users. The Firebox puts those users into one logical group so you can easily administer user access. When you create a policy that allows only authenticated users to access a network resource, you use the RADIUS Group name instead of adding a list of many individual users.
For example, when Mary authenticates, the FilterID string RADIUS sends is Sales, so the Firebox puts Mary in the Sales RADIUS group for as long as she is authenticated. If users John and Alice authenticate next, and RADIUS puts the same FilterID value Sales in the Access-Accept messages for John and Alice, then Mary, John, and Alice are all in the Sales group. You can create a policy that allows the group Sales to get access to a resource.
You can configure RADIUS to return a different FilterID, such as IT Support, for the members of your internal support organization. You can then add a different policy to allow IT Support users to get access to resources.
For example, you might allow the Sales group to access the Internet using a Filtered-HTTP policy. Then you can filter their web access with WebBlocker. A different policy in Policy Manager can allow the IT Support users to access the Internet with the Unfiltered-HTTP policy, so that they get access to the web without WebBlocker filtering. You use the RADIUS group name (or user names) in the From list of a policy to show to which group (or which users) the policy applies.
Timeout and Retry Values
An authentication failure occurs when no response is received from the primary RADIUS server. After three authentication attempts fail, Fireware OS uses the secondary RADIUS server. This process is called failover.
This number of authentication attempts is not the same as the Retry number. You cannot change the number of authentication attempts before failover occurs.
The Firebox sends an Access-Request message to the first RADIUS server in the list. If there is no response, the device waits the number of seconds set in the Timeout text box, and then it sends another Access-Request. This continues for the number of times indicated in the Retry text box (or until there is a valid response). If there is no valid response from the RADIUS server, or if the RADIUS shared secret does not match, Fireware OS counts this as one failed authentication attempt.
After three authentication attempts fail, Fireware OS uses the secondary RADIUS server for the next authentication attempt. If the secondary server also fails to respond after three authentication attempts, Fireware OS waits for the Dead Time interval (10 minutes by default) to elapse. After the Dead Time interval has elapsed, Fireware OS tries to use the primary RADIUS server again.