LDAP/Active Directory Authentication

LDAP/Active Directory authentication allows you to authenticate employees against an LDAP (Lightweight Directory Access Protocol) server. This includes Microsoft Active Directory when it is configured with LDAP support (see the notes below).

LDAP/Active Directory authentication has the following properties:

Property	Description
LDAP Server	The host name or IP address of the LDAP server.
LDAP Server Port	The port number of the LDAP server. The default port number is 389 (or 636 if using SSL).
Use SSL	Check this option if you want to connect to the LDAP server using SSL (Secure Socket Layer). This option will increase your security by encrypting all communications between the timesheet application and the LDAP server. Your LDAP server must be configured for SSL for this to work.
Login	The login name of a technical or administrative user, if this LDAP server requires authentication. Depending upon your directory server a simple login name might work, such as "Directory Manager", or you might need to enter a distinguished name such as "CN=ADMINISTRATOR,CN=USERS,DC=PACIFICTIMESHEET,DC=COM". Note that for some Active Directory installations you need to enter this in upper-case. Another variant for Active Directory is of the form admin@pacifictimesheet.com. This is the SAM account name followed by the domain of the Active Directory server.
Password	The login password.
Search Base	The LDAP search base, which determines where a search for employees will start. This is a distinguished name (DN), such as "DC=pacifictimesheet,DC=com".
Search Filter	The LDAP search filter, which is used to find employees in the directory. The value depends on the type of directory server and how it is configured. For many open source LDAP servers the following will work: (&(objectClass=inetOrgPerson)(uid={0})) For Microsoft Active Directory the following will generally work: (&(objectClass=user)(sAMAccountName={0}))
Logging	Check this option to help troubleshoot authentication failures. Errors are logged to the System Event Log, and can be view with the Reports > System Event Log report. For self-hosted systems you can also view detailed information in the log files located in the <PacificTimesheet>/tomcat/logs directory.

You can test these settings by clicking the "Test Configuration" button. This will connect to the specified LDAP server and perform a search, reporting any errors that arise.

When using LDAP/AD authentication you still need to have an employee account in Pacific Timesheet for each employee that will use the system. If an employee has an LDAP/AD login but does not have a Pacific Timesheet login they will not be able to log in into Pacific Timesheet. The LDAP/AD account is linked to the Pacific Timesheet account via the employee's login name. For instance, if using AD you might be using the sAMAccountName attribute to link to Pacific Timesheet (see the Search Filter property, above). So if the sAMAccountName attribute is "jjones" then the Pacific Timesheet login name needs to be "jjones", too.

What if you want to use the employee's email address as the login, but your Active Directory (AD) sAMAccountName attribute is not an email address? Then you can refer to another AD attribute, such as "mail", by altering the Search Filter property described above. For example instead of using (&(objectClass=user)(sAMAccountName={0})) you could instead use (&(objectClass=user)(mail={0})).

In the event of an LDAP failure, such as the directory server being unavailable, or no matching user account being found in the directory, Pacific Timesheet will fail over to standard authentication. The entered login name and password will be checked against the Pacific Timesheet database. This ensures an administrator will still be able to log in using the Pacific Timesheet account, and change the LDAP settings if need be. This also allows you to have accounts in Pacific Timesheet that are not in the directory server, such as 'admin'.

When using LDAP authentication your employees will no longer see the "Change Password" link on their home page (unless an LDAP failure occurred and the standard authentication was used instead, as described above).

Microsoft Active Directory Notes

You will need to enable LDAP support in Active Directory (AD). Then add the object classes and related attributes for the "inetOrgPerson" and "groupOfUniqueNames" object classes to the Active Directory schema by using the Active Directory Management Console snap-in, ADSIEdit. "groupOfUniqueNames" is defined in RFC 2256, "inetOrgPerson" in RFC 2798.

Pacific Timesheet employee accounts are linked to AD accounts via the SAM account name ("sAMAccountName" attribute) by default. You can use a different attribute, e.g. "mail", by entering a custom Search Filter value, as described above. This is useful, for instance, if you are using email addresses for the Pacific Timesheet logins.