- Clavister CorePlus 8.x, 9.x
- Clavister cOS Core 10.x
RADIUS (Remote Authentication Dial In User Service) is a protocol that allows for user-authentication against one centralized database, while simplifying the administrative work. To help synchronize the user information against other services, Active Directory is commonly used for storage of user information. It is therefore ideal to let Active Directory act as the centralized database, while RADIUS is used to authenticate users. This is exactly what Internet Authentication Service, IAS (shipped by default in Windows 2000 Server), is designed to do.
Integrating the Clavister Security Gateway with this environment makes it possible to authenticate users against Active Directory. This is desirable, because no external database will be required, and no modifications to the existing Active Directory database will have to be made.
Table of contents
- Overview of the authentication chain
- Objectives with this article
- Configuring IAS with the Clavister Security Gateway
- Configuring User Authentication on the Clavister Security Gateway
- Testing the set-up
Objectives with this article
In this article, we will set up an environment that will grant access to users that belong to the Window-Group "TrustedUsers”, which is defined and populated in a Active Directory, if they authenticate themselves between 08.00 and 17.00 on a weekday. We will allow user authentication via HTTP on the Clavister Firewall, and create a simple test rule to test the set-up.
Configuring IAS with the Clavister Firewall
It is assumed that Active Directory and Internet Authentication Service (IAS from now on) are already installed on a Windows 2000 server. If not, please follow the instructions by Microsoft to do so before proceeding.
Adding an IAS client
In order for a client to be allowed to communicate with IAS, IAS must first recognize it. To add the Clavister Firewall to IAS known clients, start IAS and chose “add new client”. First enter a friendly name of the client, and press Next.
Now enter an IP Address of the Clavister Security Gateway. Make sure that “RADIUS Standard” is selected as the Client-Vendor and that the “Client must always send signature attribute in the request” is un-checked. Also enter a shared secret. This secret must also later be entered in the Clavister Security Gateway so be sure to remember it.
The shared secret is used to encrypt the user-password when a RADIUS-packet is being transmitted, so the same consideration as when choosing a regular password should be taken (the password should be hard to guess, not to small, etc). The Clavister Security Gateway supports shared secrets up to 100 characters. Remember that the shared secret is case-sensitive.
When this information has been filled in, press Finish. The Clavister Security Gateway client should now be visible in the “Clients” folder.
Creating a Remote Access Policy
A remote access policy is basically a rule-set. It tells the IAS server if a user should be denied or granted access, based on a set of credentials, i.e. Windows-Group, Time and Date, and source IP address. In this example, we will grant access to users that belong to the Window-Group “TrustedUsers”, if they authenticate themselves between 08.00 and 17.00 on a weekday. If any of these requirements ails, the user is not allowed to log in, and authentication will fail.
It is assumed that this group already exists in Active Directory. First enter a friendly name for the remote access policy and press the Next button.
Next press the Add button to choose which conditions that should be met in order to grant access for this policy. Choose “Windows-Groups” and press Add.
Now chose the Windows-group that the user must belong to in order to grant access. Note that the users in this group must have Dial in permission set in order to be able to authenticate themselves. In our case, this is the “TrustedUsers” group. Select the group from the list of available groups, press Add, and then OK.
If more groups should be allowed access, just press Add again, and do the above operation again. For this example, we are satisfied with just one group, so click on OK.
Now, a new attribute that restricts login time and date must be chosen. From the “Select Attribute” menu, select “Day-And-Time-Restrictions” and press Add.
This defines that logins between 08.00 and 17.00 on weekdays are permitted. If a login occurs at any other time, this policy will fail, and authentication is denied
Now press OK. The basic credentials have now been defined, so press Next. Be sure to mark the checkbox that says “Grant remote access permissions”, and press Next again. You will now be asked if you want to edit your profile. Do this by pressing the “Edit Profile” button.
Clavister Vendor Specific attributes
IAS must notify the Clavister Security Gateway that any user the matches this policy belongs to the “TrustedUsers” group. This is done by letting IAS send a Vendor-Specific-Attribute (VSA) to the Clavister Security Gateway as a part of the remote policy. In the Dial-In-Profile, Click on the advance-tab. You will see two already existing attributes, Service-Type and Framed-Protocol. The Clavister Security Gateway requires none of these attributes, so simply remove them. To add the Clavister-VSA, press the Add button.
A list of attributes like the ones in the picture above will now be presented. Choose the Vendor-Specific attribute and press Add. Also in the next screen press Add.
The VSA must now be configured.
In order to define that this is a "Clavister Attribute", the Clavister Vendor Code is required. Select Enter Vendor Code, and type 5089. Also make sure that "Yes. It conforms" Is selected. Now press the Configure Attribute button.
The vendor-assigned attribute number is simply 1, and the attribute format is String. The Attribute value is a comma-separated list of groups that the users belong to. In this case, only the users in the “TrustedUsers” group have access to this policy, so just fill in that.
Note: It is also possible to specify more than one group. Just separate each group with a comma, for example “TrustedUsers, Employees, Personal”. This would tell the Clavister Security Gateway that a user that matches this policy belongs to three groups, “TrustedUsers”, “Employees”, and “Personal”. The Clavister Security Gateway supports up to 32 groups per policy.
When this information has been filled in, press OK. Your policy has now been configured to send group information to the Clavister Security Gateway.
Configuring RADIUS settings
Before the remote access policy is completed, the supported authentication methods need to be defined. To do so, click on the Authentication-tab in the Dial-In-Profile.
The Clavister Security Gateway supports the authentication methods PAP (Password Authentication Protocol) and CHAP (Challenge Handshake Authentication Protocol). If you choose CHAP, you will have to store the user password in Active Directory using reversibly encryption. Please refer to IAS help chapter “Authentication Methods” for further explanations about the difference between PAP and CHAP. In this example we will use CHAP, so make sure that the box that says “Encrypted Authentication” is checked, and that all other settings are unchecked. Now press OK. Your remote policy has now been created.
Configuring User Authentication on the Clavister Security Gateway
At the Security Gateway, we specify that we want the "TrustedUsers" users to authenticate themselves. Furthermore, we specify that we want use HTTP-authentication.
Adding the User Authentication Server
First of all, the IAS server needs to be added to the Clavister Security Gateway. Enter the User Authentication Servers section, located in the Miscellaneous folder.
Name – Symbolic name of the authentication server.
Type – The type of authentication server to use. Set this to RADIUS.
IP Address – IP address of the IAS server, which was previously set up.
Port – The port of the IAS server, default is 1812.
Shared Secret - The shared secret, which was entered in the IAS server. Note that this is case-sensitive!
Confirm Secret – Confirm that the shared secret is entered correctly by entering it again
Now, we must create a User Authentication Rule that specifies which users will be allowed to authenticate, and how this will be processed. In our case, we want to let users belonging to "TrustedUsers" to authenticate.
Adding a User Authentication Rule
Create a new User Authentication Rule by entering the User Authentication Rule section, located in the Miscellaneous folder.
Name – Symbolic name for the user authentication rule.
Interface - The interface, which the connection was received on.
Network - The network object that the incoming IP address must be a part of. In our example, the "TrustedUsers" users come from this network. This network object has previously been defined in the "Hosts and Networks" section.
Agent - HTTP. We want the users to authenticate themselves by surfing to the Security Gateway (port 80) with a browser. We would have set this to XAUTH it we wanted XAUTH-authentication (which is used when establishing a VPN tunnel)
Authentication Source – Set this to RADIUS
Authentication Method - We set this to CHAP in the IAS server, so we must set this to CHAP here too.
Authentication Servers - Select the IAS Server, which was previously defined.
Login Type - Set this to FORM. This means that the authenticating user will be presented a HTML page containing a HTML-FORM when surfing to the Security Gateway. This form contains two fields, one for username and one for password.
Leave the other fields blank.
Idle Timeout - We specify that we want our authenticated users to have an Idle Timeout of 3600 seconds (60 minutes). That means, if the user has been inactive for 60 minutes (which means that the Security Gateway has not seen any traffic from this user for this amount of time), he/she will be automatically logged out. As soon as the Security Gateway sees any traffic from this user, the timeout-countdown will be updated to the max value (60 minutes in this case).
Allow multiple logins per username - allows users with the same username to login from different source IP addresses.
Now we have successfully created a User Authentication Rule. We allow authentication to users coming from the "if1_net" network, and we have defined that they will authenticate via HTTP. Furthermore, logged in users will get an idle timeout of 60 minutes.
However, this rule only specifies who and how. In order to test this set-up, we also need to specify a rule, which will only trigger if a user from the "TrustedUsers" group is logged in.
Enabling User Authentication in a network object
In order to create user authentication specific rules, user authentication information is entered in the network objects.
We specify the network that the "TrustedUsers" comes from (192.168.0.0/24 in this example), and enter the group membership in the "User Authentication" tab.
Enabling User Authentication in a rule
Now it is possible to use the previously created user authentication enabled network object in the rule section.
- The first rule is the interesting rule. It will only trigger (allow ping to Security Gateway) if a user, which is a member of the group "TrustedUsers", is currently logged in.
- The second rule specifies that we allow access to port 80, TCP, to the Security Gateway. This is necessary in order to allow HTTP authentication.
- The third rule simply drops anything else.
To successfully test the set-up, the windows-group "TrustedUsers" must be populated with at least one user. We assume that this is the case, and that Alice is a member of the "TrustedUsers" group. Remember to check the box that says "store password using reversibly encryption" in Active Directory, as we are using CHAP as the encryption-method.
First of all, make sure that the set-up is correct by pinging the Security Gateway. You should not receive a reply (as you are not authenticated yet).
Now, start your favorite browser and enter the URL to the Security Gateway. You should be presented with a login screen asking for a username and password. Enter the username (Alice) and the password and press "Submit".
If the password and the link between the Clavister Security Gateway and IAS (and thus Active Directory) are correct, you should be greeted with a "success" page. You should now be able to successfully ping the Security Gateway:
In case the test was not successful, ensure that:
- You allow access to port 80 on the Security Gateway.
- The Security Gateway is able to communicate with the IAS server (UDP, and in our case port 1812).
- The shared secret is typed exactly the same on both the Security Gateway and on the IAS server.
- The user in Active Directory is allowed to Dial-in.
- As we are using CHAP, the password of the user must be stored "using reversibly encryption" in Active Directory.
- You are trying to login at an allowed time of day (i.e. 08.00-17.00 on a weekday).
- The correct privilege information ("TrustedUsers") is defined in both the IAS server and in the source network object used in the "PingSecurity Gateway" rule.
For further information, please consult the Clavister Manual.