| Home Prev |  cOS Core 14.00.15 Administration Guide
|
Next |
|---|
The following list summarizes the steps for user authentication setup with cOS Core:
Have an authentication source which consists of a database of users, each with a username/password combination. Any of the following can be an authentication source:
A local user database internal to cOS Core.
A RADIUS server which is external to the Clavister firewall.
An LDAP server which is external to the Clavister firewall.
An OIDC provider which is external to the Clavister firewall.
Define an Authentication Rule which describes which traffic passing through the firewall is to be authenticated and which authentication source will be used to perform the authentication. These are described further in Section 9.2.6, Authentication Rules.
If required, define an IP object for the IP addresses of the clients that will be authenticated. This can be associated directly with an authentication rule as the originator IP or can be associated with an Authentication Group.
Set up IP rule set entries to allow the authentication to take place and also to allow access to resources by the clients belonging to the IP object set up in the previous step.
The sections that follow describe the components of these steps in detail. These are:
A Local User Database is a registry internal to cOS Core which contains the profiles of authorized users and user groups. Combinations of usernames/password can be entered into these with passwords stored using reversible cryptography for security. By default, a single local user database exists called AdminUsers. Extra databases can be created by the administrator as required.
Username/Password Length Limits
Each user in a local user database will have a username and password with the following length restrictions:Maximum username length: 31 characters.
Maximum password length: 72 bytes.
Note that the maximum password length is given as bytes and not characters. This is because a special character could use up 2 bytes of the 72 byte limit.
Example 9.1. Creating a Local User Database
This example shows how to create a new user database called lan_users.
Command-Line Interface
Device:/> add LocalUserDatabase lan_users
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Only two groups are already defined in cOS Core and they have the group names administrators and the auditors. The privileges given to these groups are described later in the section. A new group is not explicitly created as a separate configuration object. Instead, it is implicitly created when a group name is associated with the user.
Group names created by the administrator have the following constraints:
Group names are entered as text strings which are case sensitive and can have a maximum length of 128 characters.
The only characters that cannot be used in a group name are spaces and commas.
The only limit on the number of group names is the number of unique combinations that can be created from 128 characters.
Where a user is a member in multiple groups, the group names are entered as a comma delimited list. For example: group1,group2,group3.
Example 9.2. Adding a User with Group Membership
This example shows how to add a new user to the local database called lan_users. The name of the user will be myusername with the password myuserpassword and with membership in the two groups lan_group and employees.
Command-Line Interface
Change the CLI context to be the local database:
Device:/> cc LocalUserDatabase lan_usersNow, add a user to this database:
Device:/lan_users> add User myusername
Password=myuserpassword
Groups=lan_group,employeesAfter adding any additional users, change the context back to the default:
Device:/lan_users>ccDevice:/>
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Administrators and Auditors Group Membership
When a new user is defined, it can optionally be given membership in one of the following default groups:The administrators group
Members of this group can log into cOS Core through the Web Interface or InControl as well as through the remote CLI interface and are allowed to edit the cOS Core configuration. Only one user can be logged in with administrator privileges at once (although that single administrator can be logged in with more than one simultaneous session).
The auditors group
This is similar to the administrators group but members are only allowed to view the configuration data but cannot change it. Any number of audit users can be logged in at once.
Using Authentication Groups with IP Rule Sets
Authentication groups are not used directly with Authentication Rule objects but are instead associated with the source network or destination network IP object used in the IP rule set entry that allows the traffic.When specifying the Source Network for an IP rule set entry, a user defined IP address object can be used where the Authentication Group property for that address object has been specified. This will mean that the IP rule set entry will then only apply to logged-in clients who also belong to the source network's associated authentication group.
Alternatively, the Destination Network could be used so that only authenticated servers are available to clients. Authentication of a server is achieved by opening a single connection once to cOS Core as though the server were a client.
The result of doing either is to restrict access to given networks by having IP rule set entries that will only apply to members of certain groups. To gain access to a network there must be an IP rule set entry that allows it and the client must belong to the same group as that specified for the Source Network or Destination Network address object.
For an example of setting up user authentication using group membership, see Example 9.5, “User Authentication Setup for Web Access” which is found later in this section.
PPTP/L2TP Configuration
If a client is connecting to the Clavister firewall using PPTP/L2TP then the following three options can also be specified for entries in the local cOS Core user database chosen as the authentication source:Static Client IP Address
This is the IP address which the client must have if it is to be authenticated. If it is not specified then the user can have any IP. This option offers extra security for users with fixed IP addresses.
Network behind user
If a network is specified for this user then when the user connects, a route is automatically added to the cOS Core main routing table. This existence of this added route means that any traffic destined for the specified network will be correctly routed through the user's PPTP/L2TP tunnel.
When the connection to the user ends, the route is automatically removed by cOS Core.
![[Caution]](images/caution.png) |
Caution: Use the network option with care |
|---|---|
|
The administrator should think carefully about what the consequences of using this option will be. For example, setting this option to all-nets will possibly direct all Internet traffic through the tunnel to this user. |
Metric for Networks
If the Network behind user option is specified then this is the metric that will be used with the route that is automatically added by cOS Core. If there are two routes which give a match for the same network then this metric decides which should be used.
![[Note]](images/note.png) |
Note: Other auth sources do not have a PPTP/L2TP option |
|---|---|
Specifying an SSH Public Key
With PPTP/L2TP clients, using a key is often an alternative to specifying a username and password. A private key can be specified for a local database user by selecting a previously uploaded cOS Core SSH Client Key object.When the user connects, there is an automatic checking of the keys used by the client to verify their identity. Once verified, there is no need for the user to input their username and password.
To make use of this feature, the relevant SSH Client Key object or objects must first be defined separately in cOS Core. Client keys are found as an object type within Key Ring in the Web Interface or InControl. Definition requires the uploading of the public key file for the key pair used by the client.
Reasons for Using External Servers
In a larger network topology with a larger administration workload, it is often preferable to have a central authentication database on a dedicated server. When there is more than one Clavister firewall in the network and thousands of users, maintaining separate authentication databases on each device becomes problematic. Instead, an external authentication server can validate username/password combinations by responding to requests from cOS Core. To provide this, cOS Core supports the Remote Authentication Dial-in User Service (RADIUS) protocol.RADIUS Usage with cOS Core
cOS Core can act as a RADIUS client, sending user credentials and connection parameter information as a RADIUS message to a designated RADIUS server. The server processes the requests and sends back a RADIUS message to accept or deny them. One or more external servers can be defined in cOS Core. FreeRADIUS is an open source implementation of a RADIUS server. FreeRADIUS usage with cOS Core is discussed in an article in the Clavister Knowledge Base at the following link:https://kb.clavister.com/324736398
Using RADIUS with an Active Directory™ Server
It is possible to use a Microsoft Active Directory (AD) server as the RADIUS server configured in cOS Core. This is discussed further in an article in the Clavister Knowledge Base at the following link:https://kb.clavister.com/324735916
RADIUS Security
To provide security, a common shared secret is configured on both the RADIUS client and the server. This secret enables encryption of the messages sent from the RADIUS client to the server and is commonly configured as a relatively long text string. The string can contain up to 128 characters and is case sensitive.RADIUS uses PPP to transfer username/password requests between client and RADIUS server, as well as using PPP authentication schemes such as PAP and CHAP. RADIUS messages are sent as UDP messages via UDP port 1812.
The Primary Retry Interval property for an Authentication Interval object, specifies the behavior after the primary RADIUS server is unresponsive and a secondary server is used instead. If the Primary Retry Interval is set to zero, the selected secondary server will continue to be used even though the primary server may become available later.If set, the Primary Retry Interval property specifies the number of seconds to wait before cOS Core tries to reach the primary server again. These retries will continue indefinitely. If the primary server becomes available, cOS Core will immediately switch back to it from the secondary.
By default, the Source IP property will be set to Automatic and the IP address of the firewall's sending interface will be used as the source address for traffic sent to the RADIUS server. If this property is set to Manual, a specific source IP address can be used for traffic sent to the server.If the source IP address is specified, the administrator must also manually configure cOS Core to ARP publish the IP address on the sending interface. Doing this is described in Section 3.5.3, ARP Publish.
Support for Groups
RADIUS authentication supports the specification of groups for a user. This means that a user can also be specified as being in the administrators or auditors group.Automatic IP Address Allocation
With IPsec, L2TP and PPTP tunnels for roaming clients, it is possible for cOS Core to automatically allocate IP addresses as part of the RADIUS authentication process.Depending on how it is configured, a RADIUS server can optionally return IP address information to cOS Core in its Access-Accept message when it authenticates a client. cOS Core will automatically recognize and use the following parameters in a RADIUS Accept-Access message:
Framed-IP-Address
This parameter is an IP address allocated for the client which cOS Core automatically will send to the connecting client as a part of the tunnel negotiation.
Framed-IP-Netmask
In some cases, the client might be a network device, such as another firewall with a network behind it. The Framed-IP-Netmask parameter requires that the Framed-IP-Address is also present in the Access-Accept message. The netmask together with the IP address is combined to form a route which will be sent to the client as a part of the tunnel negotiation as a definition of the network behind the client.
Framed-Route
This can be sent by the RADIUS server instead of Framed-IP-Address and Framed-IP-Netmask. The route will be sent to the client as a part of the tunnel negotiation as a definition of the network behind the client.
This IP address information will be automatically sent to the client in either of the following ways:
During the IKE negotiation phase of IPsec tunnel setup.
Over PPP when setting up an L2TP or PPTP tunnel.
In addition, cOS Core will automatically add a route to its configuration if either the Framed-IP-Address, Framed-Route or the Framed-IP-Address along with Framed-IP-Netmask parameter is received. The automatic addition of this route can be controlled in the normal way by setting the relevant property in the tunnel object for the automatic addition of routes.
Example 9.3. Configuring a RADIUS Server
The following steps illustrate how a RADIUS server is configured. Assume that the cOS Core object will have the name rs_users and the IPv4 address radius_ip which is already defined in the address book.
The connecting port will be 1812 (the default) and a shared secret of mysecretcode will be used for security.
A retry timeout value of 2 means that cOS Core will resend the authentication request to the server if there is no response after 2 seconds. There will be a maximum of 3 retries.
Command-Line Interface
Device:/> add RadiusServer rs_users
IPAddress=radius_ip
SharedSecret=mysecretcode
Port=1812
RetryTimeout=2InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
OpenID Connect (OIDC) is an authentication protocol built on top of OAuth 2.0. It is designed to provide a simple and secure way to authenticate users and allow them to access protected resources using a single set of credentials.
OIDC can be used to authenticate users connecting via OneConnect.
OIDC can be configured in two ways:
|
Note: OIDC can only be used together with OneConnect |
|---|---|
|
Any other authentication agents such as HTTP, EAP, XAuth etc. are not supported. |
When a OneConnect client initiates a connection towards an OIDC configured OneConnect Interface, cOS Core will reply with OIDC specific data including the OIDC Discovery endpoint URL. The client will contact the Discovery Endpoint (OpenID Provider) to retrieve the information it needs to perform the authentication. Upon successful authentication the client will receive a signed OIDC Token.
The client will then send the Token to the system (firewall) as proof that it is allowed to login. cOS Core will validate the signature and the content of the Token and verify that the Token has not expired. See below image for a visual representation of the sequence of events.
OIDC provider object
The OIDC provider object(s) are created under Policies->User Authentication->User Directories-> OIDC. These objects can be used either on the OneConnect server or on a User Authentication Rule. The OIDC provider object(s) contain the following options.OIDC Discovery Endpoint
URL to where an OpenID provider publishes its metadata. The system will use this URL to retrieve OIDC Discovery data needed for OIDC validation.
|
Note: Only HTTPS is supported. |
|---|---|
|
OpenID Connect extends OAuth 2.0, it inherits OAuth 2.0's requirements for using HTTPS to secure communications. The OAuth 2.0 specification mandates the use of encrypted HTTPS for all communication involving the exchange of tokens and other sensitive data. |
OIDC Client ID
An Identifier (ID) assigned to a client application that wishes to interact with an OpenID provider. On some OpenID providers this identifier may be specified while others assign a Client ID during client setup.
Verify ID Token Nonce
Verifies that the nonce claim in the OIDC ID Token received during OIDC authentication matches the nonce sent to the OIDC Client during Authentication initiation. The nonce is generated and is unique for the specific OneConnect/OIDC Authentication session.
Verify OIDC provider certificate
Verify OIDC provider certificate using the configured root certificates.
Certificate
Selects one or more root, intermediate or self signed certificates to validate OIDC provider certificate against.
OpenID provider configuration
OneConnect clients spawns a web browser for the user to authenticate against the ID provider. A OneConnect specific Redirection URI is necessary to make the web browser return data back to the OneConnect client when the user has been authenticated. The OpenID provider must be configured to allow the OneConnect redirection Uniform Resource Identifier (URI) parameter.The OneConnect Redirection URI parameter for Android and iOS/MacOS:
com.clavister.oneconnect://oauth/
The OneConnect Redirection URI parameter for Windows (IPv4 & IPv6):
http://127.0.0.1/oneconnect/oauth/ http://[::1]/oneconnect/oauth/
Example 9.4. Configuring an OIDC provider
The following steps illustrate how an OIDC provider object is added to cOS Core for later use in a OneConnect server or a user authentication rule.
Command-Line Interface
Device:/> add OIDCprovider OIDC_provider1
OIDCDiscoveryEndpoint=https://mydomain.eu/.well-known/openid-configuration
OIDCClientId=oneconnect
VerifyNonce=YesInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Lightweight Directory Access Protocol (LDAP) servers can also be used with cOS Core as an authentication source. This is implemented by the Clavister firewall acting as a client to one or more LDAP servers. Multiple servers can be configured to provide redundancy if any servers become unreachable.
Setting Up LDAP Authentication
There are two steps for setting up user authentication with LDAP servers:Define one or more user authentication LDAP server objects in cOS Core.
Specify one or a list of these LDAP server objects in a user authentication rule.
One or more LDAP servers can be associated as a list within a user authentication rule. The ordering of the list determines the order in which server access is attempted.
The first server in the list has the highest precedence and will be used first. If authentication fails or the server is unreachable then the second in the list is used and so on.
LDAP Issues
Unfortunately, setting up LDAP authentication may not be as simple as, for example, RADIUS setup. Careful consideration of the parameters used in defining the LDAP server to cOS Core is required. There are a number of issues that can cause problems:LDAP servers differ in their implementation. cOS Core provides a flexible way of configuring an LDAP server and some configuration options may have to be changed depending on the LDAP server software.
Authentication of PPTP or L2TP clients may require some administrative changes to the LDAP server and this is discussed later.
Microsoft Active Directory™ as the LDAP Server
A Microsoft Active Directory (AD) can be configured in cOS Core as an LDAP server. There is one option in the cOS Core LDAP server setup which has special consideration with Active Directory and that is the Name Attribute. This should be set to SAMAccountName.Due to LDAP protocol limitations, an LDAP user group set to primary cannot be received by cOS Core from the Microsoft LDAP server and used in security policies.
An article in the Clavister Knowledge Base further discusses using LDAP with Active Directory for authentication and can be found at the following link:
https://kb.clavister.com/324735916
Defining an LDAP Server
One or more named LDAP server objects can be defined in cOS Core. These objects tell cOS Core which LDAP servers are available and how to access them.Defining an LDAP server to cOS Core is sometimes not straightforward because some LDAP server software may not follow the LDAP specifications exactly. It is also possible that an LDAP administrator has modified the server LDAP schema so that an LDAP attribute has been renamed.
To fully understand LDAP setup, it is important to note some setup values are attributes. These are:An LDAP attribute is a tuple (a pair of data values) consisting of an attribute name (in this manual we will call this the attribute ID to avoid confusion) and an attribute value. An example might be a tuple for a username attribute that has an ID of username and a value of Smith.
These attributes can be used in different ways and their meaning to the LDAP server is usually defined by the server's database schema. The database schema can usually be changed by the server administrator to alter the attributes.
General Settings
The following general parameters are used for configuration of each server:Name
The name given to the server object for reference purposes in cOS Core. For example, cOS Core authentication rules may be defined which reference this name.
This value has nothing to do with the Name Attribute described below. It is only for use by cOS Core and not the LDAP server.
IP Address
The IP address of the LDAP server.
Port
The port number on the LDAP server which will receive the client request which is sent using TCP/IP.
The default port number is 389.
Source IP Selection
By default (Automatic), the IP address of the firewall's sending interface will be used as the source address for traffic sent to the LDAP server. If this property is set to Manual, a specific source IP address can be specified.
If a specific source IP address is specified, the administrator must also manually configure cOS Core to ARP publish the IP address on the sending interface. Doing this is described in Section 3.5.3, ARP Publish.
The default value is Automatic.
Timeout
This is the timeout length for LDAP server user authentication attempts in seconds. If no response to a request is received from the server after this time then the server will be considered to be unreachable.
The default timeout setting is 5 seconds.
Name Attribute
The Name Attribute is the ID of the data field on the LDAP server that contains the username. The cOS Core default value for this is uid which is correct for most UNIX based servers.
If using Microsoft Active Directory this should be set to SAMAccountName (which is NOT case sensitive). When looking at the details of a user in Active Directory, the value for the user login name is defined in the SAMAccountName field under the Account tab.
|
Note: The LDAP server database determines the correct value |
|---|---|
|
This is an attribute tuple and the LDAP server's database schema definitions determines the correct ID to use. |
Retrieve Group Membership
This option specifies if the groups that a user belongs to should be retrieved from the LDAP server. The group name is often used when granting user access to a service after a successful login.
If the Retrieve Group Membership option is enabled then the Membership Attribute option, described next can also be set.
Membership Attribute
The Membership Attribute defines which groups a user is a member of. This is similar to the way a user belongs to either the admin or audit database group in cOS Core. This is another tuple defined by the server's database schema and the default ID is MemberOf.
In Microsoft Active Directory, the groups a user belongs to can be found by looking at a user's details under the MemberOf tab.
Use Domain Name
Some servers require the domain name in combination with a username for performing successful authentication. The domain name is the host name of the LDAP server, for example myldapserver. The choices for this parameter are:
Do Not Use - This will not modify the username in any way. For example, testuser.
Username Prefix - When authenticating, this will put <domain name>\ in front of the username. For example, myldapserver/testuser.
Username Postfix - When authenticating, this will add @<domain name> after the username. For example, testuser@myldapserver.
If the choice is other than Do Not Use, the Domain Name parameter option described below should be specified.
Different LDAP servers could handle the domain name differently so the server's requirements should be checked. Most versions of Windows Active Directory require the Postfix option to be used.
When using the OpenLDAP server and with most non-Microsoft LDAP servers, this property should be set to Do not use and the next property Combined User Name should be enabled.
Combined User Name
When using the OpenLDAP server, the Use Domain Name property should be set to Do not use and this property should be enabled. Other non-Microsoft LDAP servers will probably also require that this option be enabled.
Optional Attribute
If the Combined User Name property is enabled, it is also possible to use this property to specify an optional text attribute to be sent to the server. For example, if this property is set to:
ou=people
This is inserted between the name and the base objects. For example, the resulting attributes might now become:
uid=someuser,ou=people,dc=somedomain,dc=com
Routing Table
The cOS Core routing table where route lookup will be done to resolve the server's IP address into a route. The default is the main routing table.
Database Settings
The Database Settings are as follows:Base Object
Defines where in the LDAP server tree search for user accounts shall begin.
The users defined on an LDAP server database are organized into a tree structure. The Base Object specifies where in this tree the relevant users are located. Specifying the Base Object has the effect of speeding up the search of the LDAP tree since only users under the Base Object will be examined.
![[Important]](images/important.png) |
Important: The Base Object must be specified correctly |
|---|---|
|
If the Base Object is specified incorrectly then this can mean that a user will not be found and authenticated if they are not in the part of the tree below the Base Object. The recommended option is therefore to initially specify the Base Object as the root of the tree. |
The Base Object is specified as a comma separated domainComponent (DC) set. If the full domain name is myldapserver.local.eu.com and this is the Base Object then this is specified as:
DC=myldapserver,DC=local,DC=eu,DC=com
The username search will now begin at the root of the myldapserver tree.
Administrator Account
The LDAP server will require that the user establishing a connection to do a search has administrator privileges. The Administration Account specifies the administrator username. This username may be requested by the server in a special format in the same way as described previously with Use Domain Name.
Password/Confirm Password
The password for the administrator account which was specified above.
Domain Name
The Domain Name is used when formatting usernames. This is the first part of the full domain name. In the examples above, the Domain Name is myldapserver. The full domain name is a dot separated set of labels, for example, myldapserver.local.eu.com.
This option is only available if the Server Type is NOT set to Other.
This option can be left empty but is required if the LDAP server requires the domain name when performing a bind request.
Optional Settings
There is one optional setting:Password Attribute
The password attribute specifies the ID of the tuple on the LDAP server that contains the user's password. The default ID is userPassword.
This option should be left empty unless the LDAP server is being used to authenticate users connecting via PPP with CHAP, MS-CHAPv1, MS-CHAPv2 or when using SSL VPN.
When it is used, it determines the ID of the data field in the LDAP server database which contains the user password in plain text. The LDAP server administrator must make sure that this field actually does contain the password. This is explained in greater detail later.
When LDAP is used with SSL VPN, the Password Attribute must be specified as userPassword or Description based on the setting for the Agent option in the user authentication rule object.
Bind Request Authentication
LDAP server authentication is automatically configured to work using LDAP Bind Request Authentication. This means that authentication succeeds if successful connection is made to the LDAP server. Individual clients are not distinguished from one another.LDAP server referrals should not occur with bind request authentication but if they do, the server sending the referral will be regarded as not having responded.
LDAP Server Responses
When an LDAP server is queried by cOS Core with a user authentication request, the following are the possible outcomes:The server replies with a positive response and the user is authenticated.
Clients using PPP with CHAP, MS-CHAPv1 or MS-CHAPv2 is a special case and authentication is actually done by cOS Core, as discussed later.
The server replies with a negative response and the user is not authenticated.
The server does not respond within the Timeout period specified for the server. If only one server is specified then authentication will be considered to have failed. If there are alternate servers defined for the user authentication rule then these are queried next.
Usernames may need the Domain
With certain LDAP servers, the domain name may need to be combined with the username when the user is prompted for a username/password combination.If the domain is mydomain.com then the username for myuser might need to be specified as myuser@mydomain.com. With some LDAP servers this might be myuser@domain mydomain.com\myuser or even mydomain\myuser. The format depends entirely on the LDAP server and what it expects.
Real-time Monitoring Statistics
The following statistics are available for real-time monitoring of LDAP server access for user authentication:LDAP Authentication CLI Commands
The CLI objects that correspond to LDAP servers used for authentication are called LDAPDatabase objects (LDAP servers used for certificate lookup are known as LDAPServer objects in the CLI).A specific LDAP server that is defined in cOS Core for authentication can be shown with the command:
Device:/> show LDAPDatabase <object_name>The entire contents of the database can be displayed with the command:
Device:/> show LDAPDatabase
LDAP Authentication and PPP
When using a PPP based client for PPTP or L2TP access, special consideration has to be taken if LDAP authentication is to succeed with CHAP, MS-CHAPv1 or MS-CHAPv2 encryption. The two cases of (A) normal PPP authentication and (B) PPP with encryption are examined next.A. Normal LDAP Authentication
Normal LDAP authentication for Webauth, XAuth, or PPP with PAP security is illustrated in the diagram below. An authentication bind request with the username and password is sent to the LDAP server which then performs the authentication and sends back a bind response with the result.
The processing is different if a group membership is being retrieved since a request is sent to the LDAP server to search for memberships and any group memberships are then sent back in the response.
Note that when the LDAP server is a Microsoft Active Directory™ server and clients connect with PPTP, PAP must be used for communication to the AD server and this will not provide encryption. This issue is discussed further in an article in the Clavister Knowledge Base at the following link:
https://kb.clavister.com/324735650
B. PPP Authentication with CHAP, MS-CHAPv1 or MS-CHAPv2 Encryption
If PPP with CHAP, MS-CHAPv1 or MS-CHAPv2 is used for authentication, a digest of the user's password will be sent to cOS Core by the client. cOS Core cannot just forward this digest to the LDAP server since this will not be understood.
The solution is for cOS Core to obtain the password in plain-text from the LDAP server, create a digest itself, and then compare the created digest with the digest from the client. If the two are the same, authentication is successful but it is cOS Core that makes the authentication decision and not the LDAP server.
To retrieve the password from the LDAP server, two things are needed:
The Password Attribute parameter needs to be specified when defining the server to cOS Core. This will be the ID of the field on the LDAP server that will contain the password when it is sent back.
This ID must be different from the default password attribute (which is usually userPassword for most LDAP servers). A suggestion is to use the description field in the LDAP database.
In order for the server to return the password in the database field with the ID specified, the LDAP administrator must make sure that the plain text password is found there. LDAP servers store passwords in encrypted digest form and do not provide automatic mechanisms for doing this. It must therefore be done manually by the administrator as they add new users and change existing user's passwords.
This clearly involves some effort from the administrator, as well as leaving passwords dangerously exposed in plain text form on the LDAP server. These are some of the reasons why LDAP may not be viewed as a viable authentication solution for CHAP, MS-CHAPv1 or MS-CHAPv2 encrypted PPP.
When cOS Core receives the password digest from the client, it initiates a Search Request to the LDAP server. The server replies with a Search Response which will contain the user's password and any group memberships. cOS Core is then able to compare digests. The diagram below illustrates this process.
|
Important: The link to the LDAP server must be protected |
|---|---|
|
Since the LDAP server is sending back passwords in plain text to cOS Core, the link between the Clavister firewall and the server must be protected. A VPN link should be used if the link between the two is not local. Access to the LDAP server itself must also be restricted as passwords will be stored in plain text. |
An Authentication Rule should be defined when a client establishing a connection through a Clavister firewall is to be prompted for a username/password login sequence.
Authentication Rules are set up in a similar way to other cOS Core security policies, and that is by specifying which traffic is to be subject to the rule. They differ from other policies in that the connection's destination network/interface is not of interest but only the source network/interface of the client being authenticated.
Authentication Rule Properties
An Authentication Rule object has the following properties:Authentication Agent
The type of traffic being authenticated. This can be one of:
ARPCache
This sends the MAC address of the client's interface to a RADIUS server for authentication and is applicable to any type of traffic.
This option is explained further in Section 9.2.8, MAC Authentication.
HTTP
Allows HTTP web connections to be authenticated via a predefined or custom web page. This is the default value for the agent property and is described further in Section 9.2.7, HTTP Authentication.
Note that an IP rule set entry allowing client access is required with this agent type. The Destination Interface for this entry must be core.
MAC authentication can also be performed using this option and this is explained further in Section 9.2.8, MAC Authentication.
HTTPS
Allows HTTPS web connections to be authenticated via a predefined or custom web page. This is also described further in Section 9.2.7, HTTP Authentication.
Note that an IP rule allowing client access to core is also required with this agent type.
This is the IKEv1 authentication method which is used as part of IPsec tunnel establishment. The client can have an IP address which is either IPv4 or IPv6.
XAuth is an extension to the normal IKE exchange which provides an additional security by requiring clients to provide credentials.
Note that an IP rule allowing client access to core is not required with this agent type.
L2TP/PPTP/SSL VPN
This is used specifically for L2TP, PPTP or SSL VPN authentication.
Note that an IP rule set entry allowing client access to the core interface is not required with this agent type.
Also note that the PPP Agent Options for the authentication rule can be changed when this agent type is selected. By default, the PAP, CHAP, MS-CHAP and MS-CHAPv2 options are enabled and the Allow no authentication option is disabled. For SSL VPN, only the PAP option should be left enabled.
EAP
This is the IKEv2 authentication method which is used as part of IPsec tunnel establishment. It authenticates the IP address of the client, which can be an IPv4 or IPv6 address.
The Originator IP and Terminator IP are not configurable with this method since they are already defined on an associated IPsec Tunnel object as the Local Endpoint and the Remote Endpoint.
Note that an IP rule set entry allowing client access to the core interface is not required with this agent type.
OneConnect
This option is used only when setting up a OneConnect Interface. This type of setup is discussed in detail in Section 10.7, OneConnect VPN.
Authentication Source
This specifies that authentication is to be performed using one of the following:
LDAP - Users are looked up in an external LDAP server database. Using LDAP servers is described further in Section 9.2.5, External LDAP Servers.
OIDC - Users are looked up in an external OIDC provider database. Using an OIDC provider object is described further in Section 9.2.4, External OpenID Connect Provider.
RADIUS - An external RADIUS server is used for lookup. Using RADIUS servers is described further in Section 9.2.3, External RADIUS Servers.
Disallow - This option explicitly disallows all connections that trigger this rule. Such connections will never be authenticated.
Any Disallow rules are best located at the end of the authentication rule set.
Local - Users are looked up in a local user database within cOS Core. Local user databases are described further in Section 9.2.2, Local User Databases.
Allow - With this option, all connections that trigger this rule will be authenticated automatically. No database lookup occurs.
Interface
The source interface on which the connections to be authenticated will arrive. This property must be specified and allows different rules to be associated with different interfaces. With a source of XAuth or EAP, the interface would be the IPsec tunnel name. However, a value of any can always be specified to associate a rule with all interfaces.
Originator IP
The source IP or network from which new connections will arrive. For PPP this will be the Originator IP. This is not specified in the rule for XAuth or EAP as it is the Local Endpoint of the IPsec tunnel.
Terminator IP
The terminating IP with which new connections arrive. This is only specified where
the Authentication Agent is PPP.
This is not specified in the rule for:
XAuth or EAP, as it is the Remote Endpoint of the IPsec tunnel.
OneConnect, as it is the Server IP of the OneConnect server.
Connection Timeouts
An Authentication Rule can specify the following timeouts related to a user session:Idle Timeout
How long a connection is idle before being automatically terminated (1800 seconds by default).
Session Timeout
The maximum time that a connection can exist (no value is specified by default).
If an authentication server is being used then the option to Use timeouts received from the authentication server can be enabled to have these values set from the server.
Multiple Logins
An Authentication Rule can specify how multiple logins are handled where more than one user from different source IP addresses try to login with the same username. The possible options are:Allow multiple logins per username.
Allow multiple logins so that more than one client can use the same username/password combination.
Allow only one login per username, disallow the rest.
Allow only one login per username.
Allow only one login per username, disallow the rest without exception. (strict)
This option deals with the specific case of an IKEv1 IPsec client that performs an IKE rekey operation. With some client software, the client is not logged out with the rekey so that cOS Core thinks that a second authentication with the same username is being performed. The previous option allows this to take place. This option will not allow authentication after an IKE rekey with the same credentials if the client has not first logged itself out.
Allow one login per username.
Only one login per username is allowed. A second login attempt with the same username will be successful only if the existing user can by logged out and this will only happen if they have been idle for a specific length of time.
The idle time default is 10 seconds but this value can be changed.
The general term HTTP authentication is used in this publication to refer to authentication related to both the HTTP and HTTPS protocols. Where users are communicating through a web browser using the HTTP or HTTPS, authentication is often performed by cOS Core presenting the user with HTML pages to retrieve the required user credential information. This is sometimes also referred to as WebAuth. HTTP/HTTPS authentication setup requires further considerations which are discussed in this section.
The Management Web Interface Port May Need To Be Changed
If HTTP authentication is going to be applied to users connecting via the cOS Core management Ethernet interface then it will collide with the Web Interface's remote management service which, by default, also uses TCP port 80 (for HTTP) and 443 (for HTTPS) by default. To avoid this problem, the Web Interface port number must be changed before configuring HTTP authentication.This is done by going to System > Remote Management > Advanced settings in the Web Interface and changing the settings WebUI HTTP port and WebUI HTTPS port. For example, the HTTP port number could be changed to 81.
For HTTP and HTTPS authentication there is a set of properties in an authentication rule called Agent Options. Among these options are the following related to HTTP/HTTPS:Login Type - This can be one of:
HTML form - The user is presented with an HTML page for authentication which is filled in and the data sent back to cOS Core with a POST. A predefined HTML file in cOS Core will be used but this can be customized as described below in Section 9.3, Customizing Authentication HTML.
BASIC authentication - This sends a 401 - Authentication Required message back to the browser which will cause it to use its own inbuilt dialog to ask the user for a username/password combination. A Realm String will appear in the browser's dialog to identify the source of the 401 message. The default value for this is admin and this can be changed by setting the Realm String property of the Authentication Rule object.
HTML form is recommended over BASICAUTH because, in some cases, the browser might hold the login data in its cache.
MAC authentication - Authentication is performed for HTTP and HTTPS clients without a login screen. Instead, the MAC address of the connecting client is used as the username. The password is the MAC address or a specified string.
MAC authentication is explained further in Section 9.2.8, MAC Authentication.
If the Agent is set to HTTPS then the Host Certificate and Root Certificate(s) have to be chosen from a list of certificates already loaded into cOS Core. Certificate chaining is supported for the root certificate.
IP Rule Set Entries are Needed
HTTPand HTTPS authentication cannot function unless an entry is added to the IP rule set to explicitly allow authentication to take place.Consider the example of a number of clients on the local network lan_net who would like access to the Internet through the wan interface. To allow authentication of these clients, the IP rule set should contain the following entries:
| # | Action | Src Interface | Src Network | Dest Interface | Dest Network | Service |
|---|---|---|---|---|---|---|
| 1 | Allow | lan | lan_net | core | lan_ip | http-all |
| 2 | Allow/NAT | lan | trusted_users | wan | all-nets | http-all |
| 3 | Allow/NAT | lan | lan_net | wan | all-nets | dns-all |
The first rule allows the authentication process to take place and assumes the client is trying to access the lan_ip IP address, which is the IP address of the interface on the Clavister firewall where the local network connects.
The second rule allows normal surfing activity but lan_net cannot be used as the source network since the rule would trigger for any unauthenticated client from that network. Instead, the source network is an administrator defined IP object called trusted_users which is the same network as lan_net but has additionally either the Authentication option No Defined Credentials enabled or has an Authentication Group assigned to it (which is the same group as that assigned to the users).
The third rule allows DNS lookup of URLs.
|
Note: Do not alter predefined service objects |
|---|---|
|
Do not modify the predefined http-all service which is used in the IP rule set entries above. This can cause authentication to fail. |
Forcing Users to a Login Page
With this setup, when users that are not authenticated try to surf to any IP except lan_ip they will fall through the IP rules and their packets will be dropped. To always have these users come to the authentication page, a SAT rule set entry must be added. The rule set will now look like this:| # | Action | Src Interface | Src Network | Dest Interface | Dest Network | Service |
|---|---|---|---|---|---|---|
| 1 | Allow | lan | lan_net | core | lan_ip | http-all |
| 2 | Allow/NAT | lan | trusted_users | wan | all-nets | http-all |
| 3 | Allow/NAT | lan | lan_net | wan | all-nets | dns-all |
| 4 | Allow/SAT | lan | lan_net | wan | all-nets all-to-one 127.0.0.1 |
http-all |
The SAT entry catches all unauthenticated requests and must be set up with an all-to-one address mapping that directs them to the address 127.0.0.1 which corresponds to core (cOS Core itself).
Further Discussion on Creating a "Captive Portal"
Creating a "Captive Portal" where the user is forced to enter correct login credentials for access to any resources behind the firewall is discussed further in an article in the Clavister Knowledge Base which can be found at the following link:https://kb.clavister.com/346366059
Example 9.5. User Authentication Setup for Web Access
The configurations below shows how to enable HTTP user authentication for the user group lan_group on lan_net. Only users that belong to the group users can get Web browsing service after authentication, as it is defined in the IP policy.
It is assumed that the authentication IPv4 address object lan_users_net has been defined and this has its Groups property set to lan_group. The group lan_group has been used as the Groups property of individual users in the lan_users database.
Command-Line Interface
A. Set up an IP policy to allow HTTP authentication:
Device:/> add IPolicy Name=http_auth
SourceInterface=lan
SourceNetwork=lan_net
DestinationInterface=core
DestinationNetwork=lan_ip
Service=http-all
Action=AllowB. Set up an authentication rule:
Device:/> add UserAuthRule Name=http_auth
AuthSource=Local
Interface=lan
OriginatorIP=lan_net
LocalUserDB=lan_users
LoginType=HTMLFormNote that the Agent property has a default value of HTTP.
C. Set up an IP policy to allow authenticated users to browse the Internet:
Device:/> add IPolicy Name=allow_http_auth
SourceInterface=lan
SourceNetwork=lan_users_net
DestinationInterface=wan
DestinationNetwork=all-nets
Service=http-all
Action=Allow
SourceAddressTranslation=NAT
NATSourceAddressAction=OutgoingInterfaceIPInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A. Set up an IP policy to allow HTTP authentication:
B. Set up an authentication rule:
C. Set up an IP policy to allow authenticated users to browse the Internet:
MAC authentication (sometimes referred to as ARP authentication) is authentication based on the MAC address of a connecting client's Ethernet interface. This is useful if the administrator wants to ensure that access is simple for a particular device and the user will not be required to type in their credentials. cOS Core sends the MAC address of the connecting client to a RADIUS or LDAP server which then looks the MAC address up in its database and tells cOS Core if the client is authenticated or not. Note that using a local database with MAC authentication is not supported in cOS Core.
Setting Up MAC Authentication
MAC authentication can be configured in one of two ways:For HTTP or HTTPS traffic only
Create an Authentication Rule object with the Authentication agent set to HTTP or HTTPS and set the Login Type under Agent Options to be MAC authentication.
For any type of traffic using ARP Cache
Create an Authentication Rule object with the User Agent property set to ARPCache and set the Authentication Source to be RADIUS or LDAP.
Unlike the previous method, this method can be used for any traffic but has the disadvantage of requiring further steps which are explained below.
Note that if the Authentication Source is set to Allow then all users will be automatically authenticated without reference to a database. The only advantage to doing this is that the administrator can easily see a list of logged in users by going to: Status > Run-time Information > User Authentication in the Web Interface.
Other Required Steps with the ARP Cache Method
When using the ARP Cache method, the following configuration steps are needed so that the cOS Core ARP cache contains the data needed for successful authentication:Below the IP rule set entry that allows the authenticated traffic, there must be a second entry which triggers on the same traffic but has the action Deny plus the deny behavior Reject. This ensures that clients that are not yet authenticated will still have their MAC addresses placed into the ARP cache. If the second rule set entry is not present, authentication will not work.
The time between ARP cache refreshes should be adjusted downwards so that should a connection be broken, for instance by an idle timeout, the cache is updated within a reasonable time. This is done by reducing the ARP advanced setting ARP expire.
If a connection idle timeout occurs then the affected client will not be able to login again until the cache is updated. An acceptable value for the ARP expire setting needs to be determined based on the size of the network. A large network may need a higher value. The ARP expire setting must be lower than the connection timeout setting.
Sending the MAC Address to a Server
In both the above methods of ARP authentication, cOS Core will use a RADIUS or LDAP server to authenticate the client. cOS Core will always send the MAC address itself as the username when communicating with the server.By default, the password sent to the server is also the client's MAC address. However, this can be changed to a specific password by setting the MAC Auth Secret property of the Authentication Rule object.
Specifying the MAC Address on the Authenticating Server
The MAC address is entered as a text string in the database of the authenticating server. This text string must follow the format sent by cOS Core and this is a series of six hexadecimal two character lower-case values separated by a hyphen ("-") character. For example:00-0c-19-f9-14-6f
Dealing with Duplicate MAC Addresses
If there is a router between the firewall and connecting clients, cOS Core will receive the same MAC address from the router instead of the original client MAC address. This causes problems because cOS Core is set up by default to not allow clients to duplicate MAC addresses.The problem is solved by enabling the Allow clients behind router to connect property of the Authentication Rule object.
