You are here: Chapter 7: Configuration and Administration > System Administration > Users > Authentication

Authentication

FootPrints supports several modes of user/password authentication.  You have the option of using FootPrints' internal encryption techniques, where FootPrints maintains its own database of users and passwords.  Alternatively, FootPrints can let the web server perform the authentication, or can authenticate by interfacing with either an LDAP directory server or the Windows user list on Windows, and UNIX/Linux user list on UNIX systems.

FootPrints supports the following methods of password verification for FootPrints users:

NOTE

When using web server authentication with the Customer Service Portal, the customer URL provided on the Customer Service Portal setup page will not bypass customer login. If a customer goes to the regular /footprints URL, they bypass the login correctly.

To administer authentication, select Administration | System from the FootPrints Toolbar, then select Authentication under Users in the main frame.

Each FootPrints user may be assigned either the primary or secondary authentication method. Only the assigned method is attempted when a user tries to authenticate.  If the secondary authentication method selected is None, all FootPrints users are authenticated against the primary authentication method.

There are a variety of ways to add users to the system:

Authentication Methods

FootPrints Authentication (default)

When FootPrints authentication is selected, the FootPrints password file is checked when a user logs in (passwords are encrypted).

FootPrints authentication includes password security features such as email notification on password change, enforced password complexity settings, preventing reuse of previous passwords, password lifetimes, and lockout on a number of incorrect login attempts.

Configure FootPrints Password Authentication

To configure FootPrints password authentication:

  1. Select Administration | System | Authentication from the FootPrints Toolbar.
  2. Select FootPrints Authentication from either the Primary or Secondary Authentication drop-down list.
  3. Optionally, complete the Password Security Configurations section:

NOTE

A system administrator can override the lockout by going to the Administration | System | User Management page, selecting Edit User, selecting the user to edit, and then clicking the Unlocked checkbox at the bottom of the page. In the same way, a workspace administrator can override the lockout from Administration | Workspace | Edit Agents.

NOTE

Someone knowing a user's ID can, by making repeated bad login attempts, lock that user out (i.e., a Denial of Service Attack). This would not affect a user who is logged in when the bad login attempts occurred.

  1. Enter your password and click Save to complete the configuration.

Windows Authentication

When Windows Authentication is selected, the Windows domain password file is used authenticate a user’s password.

To configure Windows Authentication:

  1. Select Administration | System | Authentication from the FootPrints Toolbar.
  2. Select Windows Authentication from either the Primary or Secondary Authentication drop-down list, then click GO.
  3. Fill in the domain name in the box provided.  Multiple domains can be added; each must be entered on a separate line.
  4. Enter your Windows network password and click Save.

Your ID and password are checked against the domain password file.  If either the ID or password isn’t found, you receive an error message, and the change to NT authentication is not made.

NOTE

A system administrator can lockout an individual user from the Administration | System | User Management page using the Edit User function. A locked user can be unlocked from the same page.

The network ID and FootPrints ID for every user in FootPrints must be identical.  For example, if the user’s Windows domain ID is jsmith, her FootPrints ID must also be jsmith.  This must be the case for all Agent and administrator users.  If you do not require unique IDs and passwords for your employee customers or external customers, you can create a shared ID for all customers.  That shared ID must still be present in the network password file.  Refer to the section above for more information about how customer accounts can be created in FootPrints.

Note

If the domain setup exists, the system correctly authenticates against that domain.  If the domain does not exist and a guest account is enabled on the FootPrints server, any password authenticates.  To prevent this from happening, the Guest account on the server must be disabled.  In addition, if a guest account exists in the correctly specified domain, any login also works with any password if the user does not exist in the domain.

LDAP Authentication

When LDAP authentication is selected, the LDAP server is used to authenticate a user’s password.

To configure LDAP Authentication:

  1. Select LDAP from the Primary or Secondary Authentication Method drop-down list.
  2. Select LDAP Authentication from either the Primary or Secondary Authentication drop-down list, then click GO.
  3. Enter the LDAP Authentication Attribute. The LSAP Authentication Attribute is the attribute against which the user is authenticated, for example, uid, samaccountname, or mail.
  4. Enter the LDAP server address (e.g., abc.widget.com).
  5. Enter the LDAP server port (389 is the standard port). An additional option for users beside the standard LDAP port (389) is the Global Catalog port for Active Directory (3268). This enables LDAP to access additional users from trusted domains using a set of common LDAP attributes. The typical scenario in which this would be used is when a large organization has a number of offices that each maintains an Active Directory for its local users. Using the standard port, you might be able to retrieve only a local office's users. Using the Global Catalog port, you can often retrieve everyone, assuming the search base is set correctly.
  6. Enter the LDAP base DN (Distinguished Name). This is the search base for user IDs (samaccountname or uid). An example is: ou=Users, dc=server, dc=com
  7. Optionally enter login information to allow authentication, including DN and password. This can be left blank if the LDAP server allows anonymous binding.
  8. If multiple DNs exist, enter each on a separate line. They are searched in order for authentication from top to bottom.
  9. Enter your FootPrints password and click Save.
  10. Your ID and password are checked against the LDAP server. If either the ID or password is not found, you receive an error message and the change to LDAP authentication is not made.

NOTE

A system administrator can lockout an individual user from the Administration | System | User Management page using the Edit User function. A locked user can be unlocked from the same page.

The LDAP ID and FootPrints ID for every user in FootPrints must be identical. For example, if the user’s LDAP ID is bjones, the FootPrints ID must also be bjones. This must be the case for all Agent and administrator users. If you do not require unique IDs and passwords for your employee customers or external customers, you can create a shared ID for all customer. That shared ID must still be present in the LDAP password file. Refer to the section above for more information about how customer accounts can be created in FootPrints.

The next section of this document described how to configure LDAP security.

Configuring LDAP Security

Method of Security Used

By default, FootPrints communicates with LDAP via an unsecured connection. This topic describes how to use secured LDAP connections.

LDAP communication can be secured using Transport Layer Security (“TLS”). FootPrints uses a method called “Start TLS,” which means an initial connection is made to the LDAP server over a standard port (typically, 389). Then the connection is changed to a secured TLS connection over a standard LDAP port.

In addition to LDAPS, we have code to do an LDAP secured connection (“LDAPS”) over a secured port (typically, 636).

Setting Start TLS:
  1. Select LDAPS from the LDAP Security Type drop-down.
  2. Select the SSL Version (if unsure, stay with the default).
  3. Select how you wish to handle Certificate Verification. “Require” means that FootPrints will not connect to the remote LDAP server unless the server offers a certificate, which can be compared to the certificate uploaded by the administrator. If they are the same, the connection will be made. This is the most secure method. “Optional” also requires that a certificate be uploaded, but a comparison is only made if the server offers a certificate. In the absence of the server providing a certificate, the connection will be made. “None” means that no checking of a certificate will be required and therefore no certificate must be uploaded. Although the connection will be secured, there is no verification that FootPrints is connecting with the correct server.
  4. If selecting “Require” or “Optional” for Certificate Verification, either a previous certificate can be used or a new one uploaded. In either case, the certificate provided must be the certificate of the certificate authority ("CA") who signed the server's certificate in PEM (Base-64) format (this will be the server's own certificate if the certificate is self-signed) . The certificate can be in any directory on the FootPrints server and can have any name, so long as it is in pem format.
Setting LDAPS:
  1. Select LDAPS from the LDAP Security Type drop-down.
  2. Select how you wish to handle Certificate Verification. “Require” means that FootPrints will not connect to the remote LDAP server unless the server offers a certificate, which can be compared to the certificate uploaded by the administrator. If they are the same, the connection will be made. This is the most secure method. “Optional” also requires that a certificate be uploaded, but a comparison is only made if the server offers a certificate. In the absence of the server providing a certificate, the connection will be made. “None” means that no checking of a certificate will be required and therefore no certificate must be uploaded. Although the connection will be secured, there is no verification that FootPrints is connecting with the correct server.
  3. If selecting “Require” or “Optional” for Certificate Verification, either a previous certificate can be used or a new one uploaded. In either case, the certificate provided must be the certificate of the certificate authority ("CA") who signed the server's certificate in PEM (Base-64) format (this will be the server's own certificate if the certificate is self-signed) . The certificate can be in any directory on the FootPrints server and can have any name, so long as it is in pem format.

NOTE

FootPrints secures only with server certificates, not client certificates.

Active Directory can use only LDAPS. (Refer to http://support.microsoft.com/?id=321051 for additional information.)

UNIX Authentication

When UNIX authentication is selected, the UNIX password file is used to authenticate a user’s password.  This option is only available if FootPrints is installed on a UNIX or Linux server.

To configure UNIX password authentication:

  1. Select Administration | System | Authentication from the FootPrints Toolbar.
  2. Select UNIX from either the Primary or Secondary Authentication drop-down list, then click GO.
  3. Enter your FootPrints password and click Save.
  4. Your ID and password are checked against the UNIX password file.  If either the ID or password is not found, you receive an error message and the change to UNIX authentication is not made.

NOTE

A system administrator can lockout an individual user from the Administration | System | User Management page using the Edit User function. A locked user can be unlocked from the same page.

No additional information needs to be defined; FootPrints automatically finds the UNIX password file for the system.  The UNIX ID and FootPrints ID for every user in FootPrints must be identical.  For example, if the user’s UNIX ID is ebennet, the FootPrints ID must also be ebennet.  This must be the case for all Agent and administrator users.  If you do not require unique IDs and passwords for your employee customers or external customers, you can create a shared ID for all customers.  That shared ID must still be present in the UNIX password file.  Refer to the section above for more information about how customer accounts can be created in FootPrints.

Web Server Authentication

In this method, password checking is handled by the web server, not FootPrints.

To enable this feature:

  1. Select Administration | System | Authentication from the FootPrints Toolbar.
  2. Select Web Server Authentication from the Primary Authentication Method drop-down list.
  3. Click GO.
  4. In order to put the web server in charge of passwords, anonymous access must first be taken away from the five FootPrints web aliases: "footprints", "MRcgi", "help", "MRimg", and "tmp".  If the web server is dedicated to running just FootPrints, you can disallow anonymous access on the whole site, instead of setting permissions on each alias.

On Windows:

On UNIX/Apache:

If anonymous access is disallowed, when the user tries to access the FootPrints login:

or

The user's password is authenticated according to the configuration of the web server.  The FootPrints user ID must be identical to the user ID authenticated by the web server or access is not granted.

NOTE

Login lockout does not work for web server authentication.

Note

If Web Authentication is used, it must be the only authentication method; it cannot be combined with any other authentication method.

Switching Back to FootPrints Authentication

If Windows, LDAP, or UNIX authentication is chosen, then new users are created in FootPrints and the authentication method is switched back to FootPrints, the users’ passwords default to their user IDs.   Users who were added to FootPrints before switching to an alternative authentication method retain their original FootPrints passwords.

Security Notes on Denial of Service Attacks

Someone knowing a user's ID can, by making repeated bad login attempts. This would not affect a user who is logged in when the bad login attempts occurred.