AppGate supports many different authentication methods. Multiple authentication methods can be configured and used simultaneously in a single AppGate system. Exactly which authentication methods that are available to each user is determined by the individual user definition.
The Authentication Methods overview panel lets the Appgate administrator configure exactly which authentication methods that should be available on the AppGate system. It is possible to change the name that is presented to the user for each of the authentication methods. Only the methods that are added here will be presented to the users.
Each entry in the list has two fields:
- Name
The name that will be presented in the authententication methods list in the AppGate client. This name will also be used when specifying authentication methods for users elsewhere in the Console.
- Type
The type of the authentication method. It is set when adding the authentication method. It can be any of the ones listed below.
To add an authentication method, select it from the 'Add authentication method' drop down list. It is possible to add multiple instances of radius authentication. The other authentication types does not support multiple instances.
There is much confusion regarding the term "Certificate". It is sometimes used to refer to the combination of the signed certificate and the associated key. In this document we use the strict definition where the private key is not included.
Certificate authentication is where the user proves his identity by proving that he has the private key which is associated with a certain certificate. On the client side, the certificate usually resides on a smart-card or on the local disk. For more information regarding the client side of certificate authentication see Section 3.3.14, “Using certificate authentication”.
A certificate contains a Distinguished Name (DN) (for instance
CN=Sune Halvmesyr,O=AppGate,C=SE)
and the public key corresponding to the private key of the user. The
information in a certificate is usually not considered sensitive,
and certificates are often publicly available. The secret data
is the corresponding private key.
User certificates are issued by a Certificate Authority (CA). The CA certifies that the user specified by the certificate DN really possesses the private key referenced therein. The CA puts its stamp of approval by signing the certificate.
When doing certificate authentication, the AppGate server will first check that the user name is valid, by checking the defined account databases. If the user passes this check, the AppGate server verifies that the certificate is signed by an approved CA. All valid CA certificates installed on the AppGate server are assumed to be approved. The protocol also verifies that the user has the private key corresponding to the certificate.
To enable certificate authentication, mark the check box labeled 'Enabled' and then press 'Save'. This will make the other elements clickable.
The settings here apply to all loaded CA certificates. The default values should be good, but some CA's have certificates which are broken in various ways and may require tweaking of these policy settings. AppGate Console tells whether or not a loaded certificate fulfills the policies.
- Require CA bit
Requires that all CA certificates have the CA bit set in the basic constraints field.
- Require key cert. sign bit
Requires that all CA certificates have the keyCertSign bit in the keyUsage field set.
- Expire CRLs
Honor the expiration time set in any downloaded CRLs.
- Check cert. path length
Means that the certificate path length is checked against the path length specified in the basic constraints.
- Require CRL sign bit
Means that the CA certificate must have the CRLSign bit set in the keyUsage field.
To install a CA certificate, click on the 'Upload certificate' button and choose the file containing the CA certificate to upload. Certificate files can be in PEM or PKCS#7 (.p7b) format. All certificates found in a file will be installed on the AppGate server. Multiple certificate files can be installed on the AppGate server.
It is also possible to export a certificate file from the AppGate server. This process will not delete the file from the server, but create a copy on the local machine.
It is only possible to export and delete entire certificate files, not individual certificates within files.
Each CA certificate has its own configuration for how to handle CRLs. The default setting is 'ignore' which simply disables CRL handling for that CA certificate.
Other possible CRL types are 'HTTP' and 'LDAP' where the CRL is fetched from an external site regularly. Both these types let you specify from where to fetch it and how often.
It is also possible to specify 'file' as the CRL type. In this case the configuration consists of a path name on the AppGate server and a poll interval. This is meant to be used when there is an external program which downloads the CRL file to the AppGate server.
The passwords for AppGate users are fully managed by
the AppGate software. The standard Unix files
/etc/passwd and /etc/shadow
are not used, so normal operating system tools can not be used to
manipulate the AppGate passwords. AppGate includes a command-line tool
ag_passwd_util which can be used to manipulate
AppGate passwords. For usage information run
ag_passwd_util -h on the AppGate server.
These settings apply to local passwords only. They do not apply to passwords stored in LDAP, Radius or other external authentication systems (except the banned password setting). There is no maximum length of passwords and all characters are significant.
These settings apply to users and administrators when they change their passwords.
- Minimum length
Minimum length of a user's password
- Non-lowercase
The minimum number of characters which must be something else than a lowercase letter; such as an uppercase letter, a digit or a special character.
- Non-alphanumeric
The minimum number of characters which must be special characters (not letters or digits). Note that a character which satisfies this requirement also satisfies the non-lowercase requirement.
- Path of an external password quality checking program
Full path to an external password checking program. The program must already be installed on the AppGate server (or servers if this is a cluster configuration). AppGate will pass the username and password to the quality checking program via STDIN. The format of the information passed to STDIN is as follows:
username\n(username followed by newline)password\n(password followed by newline)
The password checking program must return zero as exit code if the password is OK, or non-zero if the password fails the checks.
- Allow Administrator to override quality checks
If this option is checked, then the Administrator may override all quality checks when setting a password for a local user account.
The policy defined herein controls whether and when the users may or must change their passwords. Note that these settings can be overridden on an individual basis. See the section called “Password Authentication”.
- Password can be changed by user
Controls whether users can change their passwords at any time, or if they must wait a specific number of days from the last change until the password can be changed again.
- Warn that password needs to be changed
How many days after a password change the AppGate system starts to warn the user that he must change password. 0 means "do not warn".
- Force user to change password
Number of days, after the last password change, until the system forces the user to change password. 0 means "never force a password change".
- Disable password unless changed
Disable a password when it has became this many days old. The user will not be able to log on again if this has happened. 0 means "do not disable".
How many old passwords the AppGate system will remember for each user. A user will not be allowed to change his password to any of these.
It is possible to deny setting and/or block logins with a list of
certain easily guessable passwords. The list of passwords may be
configured by setting the
ag_passwd.banned_passwords in appgate.conf.
By default this list is set to ban passwords that are the same as
the username and some passwords that are frequently used by
password guessing tools.
- Deny setting banned passwords
If this option is checked, then banned passwords may not be set.
- Deny logging in with banned password
If this option is checked, then it is not possible to login with a banned password. Note that this also applies to passwords that are used to login by using LDAP Bind.
The Radius authentication method uses one or more separate Radius servers on the network. The Radius servers hold a database of accounts. The accounts should also be defined on the AppGate server, in which case the user names on the Radius servers must match the user names on the AppGate server. It is also possible to automatically import users from the Radius servers, see Section 4.3.4, “Radius”.
It is possible to add multiple instances of the radius authentication method. The instances can handle the same set of users or different sets of users.
For each instance of radius methods it is possible to define i multiple redundant servers. These must serve the same data. The AppGate server will only use the second server if the first does not respond, and so on.
The options which control Radius authentication are:
- Hostname(s)
Names, or IP addresses, of the Radius servers.
- Port(s)
Which port to talk to each Radius server on. The standard value here is 1812, but 1645 has been used in the past.
- Retries
How many times the AppGate server should try to contact each Radius server before giving up.
- Timeout(s)
How long time, in seconds, to wait for an answer from each Radius server.
- Shared secret
A secret shared between the AppGate and the Radius servers which is used to protect the communications.
- Repeat shared secret
The text in 'Shared secret' is not visible, therefore it must be entered again here, to ensure that it is entered correctly.
- Initial prompt
The first prompt for a password to send to the user. See below for details.
In the fields 'Hostname(s)', 'Port(s)', 'Retries' and 'Timeout(s)', one or more values can be entered, separated by commas or white space. The number of server instances configured is the highest number of values in any of these fields. If any field holds less values than this number, the last value is repeated.
Radius authentication is implemented using a challenge-response protocol. There are three different ways the protocol may start.
The default is that the user may enter his Radius password in the login dialog. This password is then included in the first request to the Radius server. This mode can be turned off by setting the client configuration option
gui_radiuspasswordto 'no'. For more information on client configuration options, see Section 3.4, “Client configuration”.The second mode is that the client does not let the user enter the password in the login dialog, but instead displays a dialog which contains the initial prompt configured here, and space for the user to enter the reply. The given reply is included in the first request to the Radius server.
The last mode is that the client is configured to not allow the user to enter the password in the first dialog, and no initial prompt has been defined (i.e. an empty string). In this case, the AppGate server will send a request with an empty password to the Radius server. The Radius server will probably deny this request, but the reply will contain a prompt which the AppGate client will show to the user, along with an entry field where the user may enter the password.
It is possible that the Radius server requires more than one interaction with the user. In this case, the later prompts will be provided by the Radius server.
The SecurID authentication method uses separate SecurID server(s) (also known as RSA/ACE servers). The SecurID server holds a database of accounts. The accounts may also be defined on the AppGate server, in which case the user names on the SecurID server must match the user names on the AppGate server. It is also possible to use SecurID as an Account database, see Section 4.3.5, “RSA ACE/Server”.
The SecurID screen shows whether or not a SecurID configuration file has been installed. To install a configuration file, press 'Upload sdconf.rec' and select the file to upload.
The AppGate server will receive and store a node secret the first time it talks to the SecurID server. This node secret is later used to encrypt the communications between the AppGate server and the SecurID server. Sometimes, mostly for debugging purposes, one needs to clear this secret. This can be done by pressing the button 'Clear node secret'. The SecurID server also knows whether or not it has sent a secret to the AppGate server, so the state may need to be cleared in the SecurID administration tool as well.
The AppGate server will communicate with the SecurID server on UDP port 5500. Make sure that any firewalls between the AppGate server and the SecurID server allows this communication.
When configuring the SecurID server each AppGate server should be added as an Agent Host . The following should be noted:
Agent typeshould be set toUnix AgentEncryption Typeshould be set toDESThe SecurID server may be configured to make reverse lookups in the DNS on the IP address of the AppGate server. It is therefore important that the AppGate server is registered in the DNS or that the SecurID server has a hosts file entry for the AppGate IP address.
When a SecurID token is in "New PIN mode", the user initiate a PIN change by leaving the PIN field empty, but fill in the code field (the random digits).
To be able to use the Entrust authentication method, an Entrust client must be installed on the AppGate server, so that Entrust/PKI may be accessed. The Entrust client is third party software and is not included in the AppGate distribution.
The AppGate server must be configured for Entrust authentication. The following steps must be taken:
Install the needed Entrust shared libraries on the AppGate server. The libraries needed are:
libEntrust.soandlibkmp.so.For Entrust 6.0 SP2, these files can be found on the Entrust CD in the tar-archive named
etipsectk-6_0_SP2-solaris-tar.Z. These libraries must be located in the same directory, which may be placed anywhere in the file system on the AppGate server. The full path of the directory must be specified with theag_entd.entrust_dirvariable in appgate.conf. This can be done with the following command:ag_cfggetset -s ag_entd.entrust_dir
pathInstall the Entrust initialization file (
entrust.ini). This file specifies where the Entrust Directory and Entrust/Authority servers are located, in addition to many other configuration options. For information on how to create this file, see the documentation for your Entrust/PKI software.The full file name of the Entrust initialization file is configured with the
ag_entd.entrust_initfilevariable in appgate.conf. E.g.:ag_cfggetset -s ag_entd.entrust_initfile
path_to_entrust.iniThe file
entrust.inimust include at least the following settings:[Entrust Settings] Manager=
Entrust_server+709 Server=ldap_server+1701 Authority=Entrust_server+829 ClientType=Heavy SearchBase=Search_base[ASH Information] [Login Strings]Create an Entrust profile for the AppGate server. The AppGate server needs to log on to Entrust in order to verify the certificates and signatures which are used in the authentication process. This means that the AppGate server needs to have an Entrust user and an Entrust profile for this user. The profile consists of a file named
something.epfThe Entrust user for the AppGate server, and the profile for that user, must be created by the Entrust/PKI Administration tools. This profile must then be transferred to the AppGate server and put in a suitable directory.
The full file name of the Entrust profile for the AppGate server is configured with the
ag_entd.entrust_profilevariable in appgate.conf. E.g.:ag_cfggetset -s ag_entd.entrust_profile
full_path_of_entrust_profileThe Entrust profile also needs a password. This must be the password that was set for the profile when it was created. It is configured with the
ag_entd.entrust_passwordvariable in appgate.conf [2]. E.g.:ag_cfggetset -s ag_entd.entrust_password
passwordTo complete the configuration of Entrust, enable the AppGate Entrust daemon in appgate.conf with the command:
ag_cfggetset -s ag_entd.enabled 1The Entrust daemon can now be started with:
/etc/init.d/ag_entd startIf the Entrust Directory Server and/or Entrust/Authority is located on the secure network behind the AppGate server, a client will not be able to access these directly. The solution is to create the following three IP access components under a service in the database:
An IP access to the LDAP port (default 389) on the Entrust directory server.
An IP access to the Entrust Key Management port (default 709) on the server that hosts Entrust/Authority.
An IP access to the Entrust Authority port (default 829) on the server that hosts Entrust/Authority.
These services containing the IP accesses must then be made available for users who should be able to use Entrust.
The AppGate Client user may then select whether he will log on to Entrust in 'Direct' mode or in 'AppGate' mode. If 'AppGate' mode is selected, AppGate Client will tell the Entrust software on the client computer to switch to Entrust on-line mode as soon as the services containing the IP accesses have been established. This functionality is only available if AppGate Client is used. These IP access components may also be used for all other Entrust applications on the client computer that need to access the Entrust directory.
The name of the service holding these components must then be configured in appgate.conf by using the
agsh.entrust_ldap_service,agsh.entrust_mgmt_serviceandagsh.entrust_auth_servicevariables. E.g.:ag_cfggetset -s agsh.entrust_ldap_service
ldap_serviceag_cfggetset -s agsh.entrust_mgmt_servicemgmt_serviceag_cfggetset -s agsh.entrust_auth_serviceauth_service
As soon as the configurations above are done, the AppGate server is ready to handle user authentication using Entrust.
However, one must also configure how the AppGate server should recognize that a user exists, and that this user actually is expected to authenticate using Entrust. Note that when a user logs in to the AppGate server with Entrust, he does not enter any user name. The username is implicitly the Distinguished Name that is stored within the Entrust Certificate of the user.
The AppGate server needs to be able to map the Distinguished Name (DN) of a user to an AppGate user name. In the simple scenario, this is done by defining a new AppGate user, checking the Entrust authentication check box, and entering the DN, all in the user dialog in AppGate Console.
It is also possible to use LDAP to have the AppGate server verify that the DN represents a valid user. In this case the user dialog on the AppGate Console is not used, as the AppGate user is created "on the fly" if the LDAP server acknowledges that the user exists. See Section 4.3.3, “LDAP/AD”
When using PublicKey authentication, the client proves that it has the private key which goes with a public key stored on the AppGate server. The private key is usually stored in a password-protected file on the client.
This authentication method only works for users defined in the AppGate local database (not an external account source). The key-pair needed can be generated from the user page in the AppGate console.
It used to be that public-key authentication required that the user had a permanent account and that the public-key was stored in the home directory of that account. But that is no longer a requirement. The public-key can now be stored in the AppGate database. But AppGate will still look in the users home-directory if no key is found in the database.
The needed key-pair (a private and a public key) can be generated in the user-page of the AppGate console. The generated private key file is in the openssh format.
Kerberos authentication lets a client machine, which is already logged in to the Kerberos domain, to log on to the AppGate without any user interaction. That is the client machine can use the existing Kerberos ticket to authenticate to the AppGate server.
Note that the client machine must already be authenticated to the Kerberos domain, and be able to talk to the Key distribution center (KDC), before it can use the AppGate Kerberos authentication. This means that the KDC can not be located behind the AppGate server.
Kerberos is by default used in Windows domains so this authentication method is very useful if the AppGate server is used to protect some internal resources where the client machines already are logged on to the domain.
It is important that all computer clocks are synchronized when running Kerberos. If the clocks are too far off then it simply will not work.
Kerberos needs to be configured and have a keytab file before it can be enabled. The AppGate server will try to come up with suitable default values (based on the domain of the AppGate server name) and fill them in if it finds the KDC.
The keytab file can either be generated by the AppGate server or, if that fails, generated and uploaded manually. The AppGate server is able to generate the keytab file automatically if the KDC is an Active Directory server and you have access to an account which can do domain administration.
The options which must be given for Kerberos authentication are:
- Realm
Name of the Kerberos realm - this must be all upper-case.
- DNS Domain
Name of the DNS domain - this must be all lower-case.
- KDC
Hostname of the KDC - this must be all lower-case.
The AppGate server must have a keytab file before it can accept Kerberos authentication requests. The AppGate server can try to generate this file once Kerberos has been configured (the 'Generate keytab file' button) or it is possible to upload a keytab file generated by other means.
On client machines running Windows 2000 SP4 or later, Windows XP SP2 or later, or Windows 2003 or later, a registry modification is needed in order to allow the AppGate Client to generate the proper credentials to send to the AppGate server. This registry modification is not needed on machines running earlier versions of Windows.
The registry modification is that the key
allowtgtsessionkey (of type
REG_SZ) in
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters
needs to be set to 1. The key must be created if it does not
already exist. The machine must be rebooted after the key has
been set.
More information can be found in Microsoft kb 308339.
This section documents how to manually create a keytab file on a windows server. This should only be done if the AppGate server failed to generate the keytab file via the "Generate keytab" button.
This procedure uses the 'ktpass.exe' tool which is part of the Windows Support Tools. This must be installed before the keytab can be created. Note that the version of ktpass included with Windows 2003 SP1 has a bug and the server needs to be upgraded to SP2 (see Microsoft kb 919557).
The first step is to create a computer object for the AppGate server on the AD server. The object must be marked as a Pre-Windows 2000 computer. The name used here must be the short form of the AppGate node name. See the parameters table below for details.
The keytab file can be generated with the
ktpass command. It can be run like this
(one line):
ktpass -princ host/fqdn@REALM-mapuserDOMAIN\name$ -crypto DES-CBC-MD5 +DesOnly -ptype KRB5_NT_SRV_HST +rndPass -out krb5.keytab
The parameters needed are:
| fqdn | The fully qualified domain name of the AppGate server. That is the node name of the AppGate server. The node name can bee seen in the relevant system panel under Network/Cluster Management. This name must include the DNS domain. Note that this must be lower-case. |
| REALM | Name of the Kerberos realm. Note that this must be all upper-case. |
| DOMAIN | Name of the Windows domain. Note that the name must be all upper-case. |
| name | This is the short-name of the AppGate server. That is the first part of the fqdn parameter and it should be lower-case. |
If we for example assume that the AppGate server's fully qualified domain name is 'agserver.appgate.com', the Kerberos realm is 'APPGATE.COM' and the Windows domain is 'APPGATE', the resulting command is
ktpass -princ host/agserver.appgate.com@APPGATE.COM -mapuser APPGATE\agserver$ -crypto DES-CBC-MD5 +DesOnly -ptype KRB5_NT_SRV_HST +rndPass -out krb5.keytab
Older versions of the ktpass
command do not support the +rndPass
switch. It works just as well to replace this with
"/pass random_passwd".
[2] Please note that this password is stored as clear text. The password itself is of no use without the profile file, thus we do not have to worry about a peek-over-the-shoulder-attack here. Hashing the password would not have helped much since the hash must be reversible and thus would not offer any real protection. We believe that leaving the password in the clear is preferable to hashing it, as the hashing makes it look more secure while in practice it is not.