The AppGate server can use multiple databases where users are defined, this includes external systems such as LDAP (Active Directory) server. Both Local accounts, accounts defined on the AppGate Server, and external account databases may be configured and used simultaneously in an AppGate system. The username lookup on the AppGate server is handled by the ag_userd daemon.
Observe that a user account is not an authentication method. The AppGate system makes a clear distinction between a user account and an authentication method. As an example, a user may be defined and have an account in LDAP/AD but still be authenticated using RSA SecurID. But an important property of a user account is to provide information to the AppGate system on what authentication methods a particular user is allowed to use.
To add an account source, select the kind of source under the "Add account source" drop down box. A new configuration panel for that particular type of account source will appear. Details on how to configure the different types of account sources can be find below.
To delete an account source, select it and press the "Delete account source" button. Local Accounts can't be deleted.
For each account source there are six fields. The purpose of these fields are:
- Enabled
If checked, this account source is active. If unchecked, this account source is not used when trying to find an account source. This can be handy when temporary disabling an account source. The Local Accounts source can not be disabled.
- Type
Indicates what type the account source is.
- Name
This is the name of the account source. When a user successfully authenticates, the attribute
login.account_sourcewill be set to the name of the account source of that user.- User name selector
See below for details on how this is used.
An empty field means that all user names are matches.
To match a string at the end of an user's name, just type in the string. For example
@companywill match the user namejohn@company, but not the user namejohan@company.com.To match a string at the beginning of an user's name, a regular expression is needed. Regular expressions are surrounded with a pair of
/to distinguish them from the normal end matching.The selector/^pre_/will match the user namepre_john, but notxpre_john.- Continue
If checked, ag_userd will continue to look for the user in the next account source in the list if no user was found in this account source (even though the user name matched the selector). If not checked, ag_userd will stop looking in the other sources and report back that no such user existed.
- Remove selector
If checked, ag_userd will remove that matching selector from the user's name before using it to look for that user in the account source. Note that for the rest of the session, the user's name will still be the complete name, and the stripped name only will be used when communicating with the account source.
For example, assume that the selector is
@companyand Remove selector is checked. When an userjohn@companytries to log in,@companyis removed from his name and onlyjohnis used when trying to find John is this account source. If John was able to authenticate, the attributelogin.usernamewill still be set tojohn@companyandlogin.search_namewill be set tojohn. If Remove selector is unchecked when John logs on, both attributes will be set tojohn@company.
Since the AppGate Server can use more than one account source, it must find out which account source a user that is logging on belongs to. This is done by ordering the different account sources and by matching the user name against the selectors.
In the (slightly contrived) example above, six different account sources are configured. These are the steps that ag_userd goes through when it search for an account source.
1. First ag_userd looks for the user in the Local Accounts (since the selector is empty it matches everything). If no user witch matching user name was found, ag_userd will continue to look at the next account source.
2. If the user tries to login with a certificate where the DN ends with
dc=company,dc=com ag_userd will select the account
source named Certificate as this user's account source.
3. If an user with the name john@enterprise
tries to login, ag_userd will try to locate him in the account source
called enterprise.com. But first ag_userd removes
the selector @enterprise from the name, and just use
the name john when communicating with
enterprise.com's LDAP/AD server. Note that the AppGate Server still
will use john@enterprise internally as the user's
name for the rest of the session, and just use john
when communicating with the LDAP/AD server. If John had tried to use
the name john@enterprise.com, this account source
would not had match, since only user names that ends with
@enterprise matches.
4. The case is identical with the one above, except that another
John would use the name john@company. ag_userd would
use the name john when communicating with
company.com's LDAP/AD server.
5. If an user with name rad_john tries to login,
ag_userd first removes the selector rad_ and then
queries the RADIUS server for the user john. If
john existed on the RADIUS server, this account
source will be used. If he didn't exists, the next account source will
not be tried and ag_userd will report back that the user didn't exists.
6. If no user was found in the first five account sources, ag_userd will try to find the user in the SecurID source. If not user was found there either, ag_userd will report back that no such user exists.
With the Server Administration Tool, creating and managing users of the AppGate system should be easy and intuitive.
In order to create a new user, click on 'New...' in the summary screen or right-click on 'Local Accounts' and select 'New user'. It is also possible to create a new local account by cloning an existing account. This is done by right-clicking on the account to clone in the list of accounts and then selecting "Clone" in the pop up menu.
To remove an existing account, select the user in question and press the button "Delete".
Screen shot illustrating the 'User' panel with the 'Authentication' tab selected.
The common part of the panel consists of:
User name: login name of user. The user name must be a maximum of 32 characters. It may only contain alpha-numeric characters (digits, capital letters, and lowercase letters), periods (.), underscores (_), and hyphens (-). Also, all user names MUST start with a letter and include at least one lowercase letter. Temporary accounts may contain anything except semicolons (;).
Full name: full name of user. This field may NOT contain the characters semicolon (;) or equals (=).
The 'Authentication' tab consists of check-boxes that indicate which authentication methods a user is permitted to use. Only the authentication methods that have been configured for the system will be shown. Some authentication methods will require more than just the check-box. For detailed information on all of the possible authentication methods, see Section 4.3, “Authentication Methods”. The 'Certificate' method require a Distinguished Name to be entered. If the 'Certificate' method is selected, the 'Distinguished Name' field will become active and is required. Refer to the section below entitled 'Password Authentication' if password authentication is to be used.
The 'Roles' tab consists of two lists showing the Roles the user belongs to/does not belong to: these two lists indicate what roles have been created and are available to choose for the user. Initially, all roles will be in the 'Roles user does not belong to' list. To move a role over and make a user belong to it, select the role and then click on the left-pointing arrow. The role can also be taken away from the user by selecting the role in the 'Roles user belongs to' list and clicking on the right-pointing arrow.
The 'Misc' tab consists of:
Organization: organization of user (company name, department, etc.).
Mobile phone#: The mobile phone number of the user. This is used for provisioning. The button "Send provisioning SMS to user" will be enabled when a mobile phone number has been entered. See Section 3.2.9, “Over the air provisioning of mobile clients” for more details about provisioning.
IP-tunneling addr: This field may contain a fixed IP-tunneling address which this user will be assigned when logging in. If left empty, which is the default, then the user will get a random address from the pool. For more details see Section 4.10.3, “IP Tunneling pools”.
Expires: when the account will no longer be usable. This field is a drop-down list box with a calendar. The administrator may either select 'Never' or a calendar day.
Unix account: if this box is checked, a Unix account is created on the server along with the AppGate user. If the box is not checked the user will be mapped to one of many many "temporary" accounts which were created when AppGate was first installed. A user does not necessarily get mapped to the same temporary ID every time he logs on. The advantage of using temporary accounts is that user names are not restricted by the operating system. In other words, an administrator may configure a username in the AppGate database that is greater than 32 characters and contains characters that a normal Unix username cannot contain. A Unix account can be useful if the particular user actually needs to log on to the AppGate server itself, he will then have a fixed home directory where files can be stored.
When password authentication is enabled, an administrator may choose to override the global password parameter for the specific user currently being managed. Click on the 'Password configuration' button to open the 'Password configuration' window. The 'Password configuration' window is shown in below.
Password configuration allows the administrator to select whether or not a user can change his password. It also allows the administrator to force the user to change the password the next time he logs on.
Additionally, password configuration allows the administrator to override the global password policy. See the section called “Global password policy” for information on global password policies. The following fields are available:
Password can be changed by user: check 'Override global' to the left of this setting to activate it. The 'Changeable' setting controls whether a user can change his password at any time, or whether he is forced to wait a specific number of days from the last change until a new password can be chosen.
Warn that password needs to be changed: check 'Override global' to the left of this setting to activate it. This setting determines when to warn the user about password expiration.
Force user to change password: check 'Override global' to the left of this setting to activate it. Users can be forced to change their password at certain intervals, or they may never be forced to change their passwords at all.
Disable password unless changed: check 'Override global' to the left of this setting to activate it. This setting determines the expiration date of the password, or disables expiration.
NOTE: For all of the previously mentioned fields, the setting 'number of days' indicates the number of days from the last password change.
Also, when using password authentication, the administrator may prevent individual user from logging in by password. This is accomplished by selecting the 'Disable password' check box on the modification screen of the particular user. When selected, the user is no longer allowed to log on to the AppGate system.
The AppGate Server integrates with LDAP and Active Directory servers in real-time. The integration with an LDAP/AD server enhances the AppGate solution by allowing all user ID information to be stored in the LDAP/AD directory rather than requiring the creation of individual users in the AppGate database. Also, the Roles that the user is a member of may be stored in the LDAP/AD directory. The list of enabled authentication methods for each user can also be stored in the LDAP/AD directory. Finally, the user may authenticate against the LDAP/AD directory using a userid and password. AppGate servers configured to use LDAP/AD are not bound by the name rules of Unix accounts and can support more than 64,000 user accounts.
If the LDAP/AD server supports TLS/SSL encryption, this will be used when connecting to the LDAP/AD server.
The use of an LDAP/AD server is transparent to the AppGate clients. Users of the AppGate clients simply supply the appropriate UserID and authentication information. Then the AppGate server communicates with the LDAP/AD server seamlessly to verify the user. AppGate servers can be configured to use LDAP/AD and local user accounts simultaneously.
The following prerequisites must be met before LDAP/AD can be used with an AppGate server:
A functional LDAP/AD server must already be installed on the network.
The LDAP/AD server must support simple authentication.
The LDAP/AD configuration is broken up in a number of tabs and a wizard. The functionality of the tabs and the wizards largely overlaps. This means that everything which can be configured via the wizard can also be modified via the tabs. It is also always possible to rerun the wizard to update the configuration.
The recommended way of configuring LDAP/AD is to use the wizard when setting it up for the first time and then do subsequent tweaks using the tabs.
The following fields should be completed regarding the LDAP/AD servers:
- Hosts
The host name(s) of the LDAP/AD servers. Can be one host or a list of hosts. Port numbers may also be specified (i.e.
ldapserver.my.domainor"ldapserver1.my.domain ldapserver2.my.domain:636").If more than one LDAP/AD server is given, they must all serve the same name space. This list should not be used to access several LDAP/AD servers as source for different accounts. However, if that functionality is needed one should define multiple LDAP/AD account sources, see the beginning of this chapter: Section 4.2, “User accounts”.
The LDAP wizard contains a "Find LDAP servers" button which tries to find LDAP servers in DNS. If DNS is slow or misconfigured it may take a few seconds to do this search.
- Bind user
The username the AppGate server should bind as when issuing LDAP/AD queries (i.e.
"cn=admin, o=AppGate, c=US"orAdministrator@foo.bar). If left empty no bind will be done when connecting to the LDAP/AD server.- Password
The password of the bind user.
- Timeout
How long time in seconds the AppGate Server should be waiting for a response from the LDAP/AD server before giving up.
- Search base
Base for LDAP searches (i.e.
"o=AppGate, c=us"or"cn=Users, dc=demonet, dc=appgate, dc=com").The LDAP wizard will automatically try to find a number of possible values for the search base. The first search base in the list is usually the correct one.
- Search expression
Search expression for LDAP/AD queries, according to RFC2254. See below for details.
The LDAP wizard suggests a few search expressions.
- Search scope
Scope for searches. It can be
Base,SubtreeorOneand controls how deep into the LDAP/AD tree searches should go.- Follow referrals
This box should be checked if referrals are to be followed when searching the LDAP/AD database. Active Directory Servers do not follow referrals, so do not check this box if an Active Directory server is used.
- Always use UTF-8 for LDAP searches
When this box is checked the AppGate server will convert the search expression into UTF-8 before sending it to the LDAP server. This only matters when the search expression contains non-ASCII characters. This box should normally be checked.
- Allow search expressions with missing attributes
The AppGate server will normally not do an LDAP search if the search expression contains attributes that can't be resolved. If this box is checked then the missing attributes will be replaced with an empty string and the search will be done anyway. This can be useful if users can log on either with username/password or a certificate, and the search expression can in that case be set to
"(|(sAMAccountName={USER})(cn={cn}))"and by checking this box the search will be done even if a certificate isn't used and the cn attribute therefore isn't defined.
The following authentication methods may be available for LDAP users. Exactly which methods are shown depends on which methods are defined on the AppGate server.
- Certificate
Check here if standard/Verisign X.509 certificates should be used for authentication.
- LDAP Login/Bind
Check here if the authentication should be handled by the LDAP/AD server for LDAP/AD users.
- Radius
Check here if the Radius authentication method should be used for all LDAP/AD users.
- SecurID
Check here if the SecurID authentication method should be used for all LDAP/AD users.
- Kerberos
Check here if the Kerberos authentication method should be used for all LDAP/AD users.
- From LDAP field
Checking this means that the authentication method for users found to exist in LDAP/AD will be determined dynamically. The name of an LDAP/AD field should be given here. This field must exist within the user record in LDAP. The AppGate server will use the value of this field to determine the authentication method to use. Possible attribute values are
password,securid,radius/0,kerberos,certificateand The use ofpasswordas a value implies the method as the above "LDAP Login/Bind". If this is a possible value of the above specified field, the special stringX-AGLDAP=simpleshould be entered into the next field called 'Data'.- Data
If 'From LDAP field' is checked, this value may be used to name a field in the user record in LDAP, its value defines the data to be used with the authentication method.
- Forward account
If set, this account name will be used when accessing NetBIOS shares. It will also be used when doing
%Usubstitutions and answering ident queries.For instance, when accessing an Active Directory server, this may be set to
{sAMAccountName}.- Local account
This should normally be left empty. It is only used if the LDAP/AD accounts correspond to local permanent accounts. If set, this should evaluate to the name of the local permanent account, for instance
{uid}or{cn}.- IP-tunneling addr
This field may contain the name (enclosed in curly braces) of an attribute in LDAP which contains a fixed IP-tunneling address which this user will be assigned when logging in. If left empty, which is the default, then the user will get a random address from the pool. For more details see Section 4.10.3, “IP Tunneling pools”.
- Support for Active Directory account information
If set, it is assumed that the LDAP server is an Active Directory server, and the users are able to change their passwords through an AppGate client. The reason that this is a separate option is that different LDAP servers use different methods of password management. Please note that the Active Directory server must be configured to use TLS/SSL, otherwise the Active Directory will not allow the user to change his password.
- Warn user X days before Active Directory password expires
If set, and a value higher than zero is given, a user who logs on after this number of days remain before his password must be changed, receives a warning. This requires that 'Support for Active Directory account information' is set.
- Change password as
When using LDAP to communicate with an AD server there are some limitations when handling expired passwords. A user may not bind with an expired password, but it is necessary to bind before changing the password. The "change password as" setting makes it possible to circumvent this limitation.
If set to "bind user" the bind user will be used when users change their AD password. For this to work, the bind user need have enough privileges to change user passwords. A bind user that is a member of the group Account Operators is recommended instead of using a full Domain Administrator.
If set to "user" the user's own privileges will be used to change the password. Because of how LDAP works, it is not possible for a user to change the password if it has already expired or if the "user must change password at next logon" flag has been set.
At least one of the following fields must be configured to configure roles for LDAP/AD users:
- Hardcoded roles
Select the roles that all LDAP/AD users should be members of.
- Look in LDAP/AD attribute
LDAP/AD attribute of the user which resolves to a space-separated list of roles on the AppGate server.
The list of roles below determines which roles the LDAP/AD administrator may put in this attribute.
- As AppGate user
LDAP/AD users will have the same role(s) as this template user.
- Part of DN
LDAP/AD users will have the specified part of the distinguished name as role (e.g. ou). This is of course only applicable if the user is authenticating using a certificate with a DN.
- From AD group membership
Select mappings from AD groups to AppGate roles. If
Resolve past mapped groupsis checked the AppGate server will recursively follow group memberships in AD.The list of groups is updated from the AD server whenever the
Get groupsbutton is pushed.It is also possible to apply a filter to limit the groups shown. The desired word should just be entered into the filter text field and once return is pressed (or the
Applybutton is pressed the list of groups is reduced to only shown AD groups which contain the specified string.
It is possible to map attributes from LDAP/AD to AppGate attributes. The AppGate attributes can be used when the server determines what roles and services the user has access to. When pressing the Add button, a dialog window appears. The name of the LDAP/AD attribute must be surrounded by curly braces. The name of the AppGate attribute does not need to be the same as the LDAP/AD name.
You can always test your LDAP/AD configuration by entering a username and pressing the Test button. You will see the response from the LDAP/AD server.
LDAP/AD search expressions should be written in the
format defined by RFC2254. To include the entire username of the
connecting user, insert {USER} in the
expression.
Users who authenticate using any of the certificate-based
methods will have their distinguished name (DN) as username. To
use the entire DN as search expression, include
(&{*}) in the expression. To use certain
attributes (components) of the DN, include
{ in
the search expression. attribute_name should always be in
lower-case as the AppGate will canonize all incoming attributes
to lower-case. If there is more than one attribute with the
same name, it is possible to specify one with
attribute_name}{ where n = 0 is the
rightmost occurrence. It is also possible to use regular expression
substitution to only use a part of username or DN in the search
expression. The forms are
attribute_name
[n]}{
or
attribute_name:regexp}{.
The regular expression must contain a subexpression inside a pair of
parentheses, and the text that match the subexpression will be used
as substitution. Only one subexpression is allowed in the regular
expression.
attribute_name
[n]:regexp}
Examples:
sAMAccountName={USER}Search for a user record which contains an attribute named sAMAccountName where the value is equal to the username of the connecting user. This is an useful example for a typical Active Directory user.
distinguishedName={USER}Search for a user record which contains an attribute named distinguishedName where the value is equal to the Subject attribute in a X.509 certificate presented by the user. This is an useful example for doing certificate authentication with certificates created by a Windows public key infrastructure. The
(&{*})expression mentioned below can't be used, as it requires that the user has all components in the DN as attributes in his LDAP entry.(|(distinguishedName={USER})(sAMAccountName={USER}))A combination of both the previous entries. This will try them both and use the first one which matches. It is very useful if you want to have an user which can log on both with certificate and with some other authentication method.
(uid={USER})Search for users whose UID is equal to the username of the connecting user.
(&{*})Use the entire DN as search expression.
(cn={cn})Search for users having the same common name as the connecting user.
(&(cn={cn})(o={o}))Search for users having the same common name and organization as the connecting user.
(&(cn={cn}) (ou={ou[0]}))For a user with a DN of "cn=test, ou=LevA, ou=LevB, o=Xy" this search expression will expand to "(&(cn=test) (ou=LevB))".
(serial={cn:([01234567890ABCDEF]+)$})For a user with a DN of "cn=Trasan Apansson DEADBEEF, dc=appgate, dc=com", where DEADBEEF is a serial number that is unique in LDAP catalog, this search expression will expand to "(serial=DEADBEEF)".
Active Directory is handled as any other LDAP account source, but some AD specific features are supported: password management and mapping of AD group membership to AppGate roles.
The bind user is used to verify if a user exists in the
LDAP catalogue and to list all AD groups. It may also be
used when a user is forced to change the password before
logging on depending on the "change password as" setting
under Active Directory options. The bind user therefore
must have sufficient privileges to perform these
operations. It is often not appropriate to assign those
privileges to the bind user, and Domain User is not
sufficient. "Account Operators" serves this purpose and
allows to bind to the domain. It is therefore suggested that
an AD account "appgateadmin" with account operators privileges
is created, and the bind user is set to
appgateadmin@company.com.
The search base for an AD server should often be based on the
domain components. For example, the search base for
company.com should probably be
dc=company,dc=com. It is of course
possible to narrow this down by adding more components to the
search base.
It is strongly recommended that the AD server is configured for encrypted communication. The AD server will not permit any users to change their passwords via AppGate unless encrypted communication is enabled. This is done by ensuring that the AD server has a valid certificate. The AppGate server will automatically set up an encrypted session if it is supported by the AD server.
The three accounts sources Certificate, Radius and RSA ACE/Server can be called virtual accounts sources. This is because they are actually not queried during the user account look up phase. They will instead be used as a "last resort" account source when the user can not be found in any other account source. As there is no real look up made, the configuration also becomes very static when it comes to Role membership etc. Because of this, virtual accounts are mostly used when there happens to be a large homogeneous group of users who should belong to the same Role and are not defined in an LDAP system or so.
The Certificate user account source can be used as a "virtual" account source. The benefit is that the users need not be explicitly defined in any real database at all. It will suffice that the user can provide a valid certificate and the AppGate will assume that the user has an account. Authentication will also be fixed to use the Certificate.
Observe that using Certificate as a user account database is very limited and not that often used. This is because the AppGate does not really look up the user anywhere, this in turn means that such things as Role membership becomes a static configuration.
In order to configure the AppGate server to allow access to certificate users, the configuration screen below must be completed. That is the roles these users should have access to must be defined. A Certificate account database can not be configured together with a Radius or RSA ACE/Server account database. The authentication method for users from the Certificate account database will always be Certificate.
The AppGate Server can use Radius as "virtual" user account source. The benefit is to allow for all user information to be stored on the Radius server rather than requiring the creation of individual users in the AppGate Local account database or in LDAP/AD.
Observe that using Radius as a user account database is very limited and not that often used. This is because the AppGate does not really look up the user, it will just assume that the user must be defined in Radius as the user is not first found in any of the other user account databases. This assumed user will also be assumed to belong to a static set of Roles and only be allowed to use Radius as authentication method.
In order to configure AppGate to use a Radius account database specify which roles the users from the Radius account database should have. Due to limitations in the Radius protocol, roles can not be specified on the Radius server. The authentication method for users from the Radius account database will always be Radius, and must be configured as described in Section 4.3.3, “Radius” - these settings will be used when contacting the Radius account database.
The AppGate Server can use a RSA ACE/Server as a "virtual" user account source. The benefit is to allow for all user information to be stored on the RSA ACE/Server server rather than requiring the creation of individual users in the AppGate Local account database or in LDAP/AD.
Observe that using RSA ACE/Server as a user account database is very limited and not that often used. This is because the AppGate does not really look up the user, it will just assume that the user must be defined in the RSA ACE/Server as the user is not first found in any of the other user account databases. This assumed user will also be assumed to belong to a static set of Roles and only be allowed to use RSA ACE/Server as authentication method.
The AppGate Server integrates with an RSA ACE/Server in real-time. The integration with an RSA ACE/Server enhances the AppGate solution by allowing all user ID information to be stored on the RSA ACE/Server rather than requiring the creation of Local Accounts in the AppGate database.
In order to configure AppGate to use an RSA ACE/Server account database, specify which roles the users from the RSA ACE/Server account database should have. Due to limitations in the RSA ACE/Agent, roles can not be read from the RSA ACE/Server. The authentication method for users from the RSA ACE/Server account database will always be SecurID, and must be configured as described in Section 4.3.4, “SecurID” - these settings will be used when contacting the RSA ACE/Server account database.
