We've been using the on-site Standard/Community TimeTrex for years as our payroll system for salaried employees and we really like it! Over that time a small handful of HR people have had user accounts on the system. Now we're looking to start doing end-user time tracking, and thus we're looking into LDAP integration. We've been using OpenLDAP on Ubuntu (formerly on Debian) for years and have integrated with a number of other open source projects for authentication without any significant problems. We're currently running TimeTrex v7.1.2 on an Ubuntu 10.04 server.
Unfortunately, I've had a lot of trouble getting LDAP authentication working with TimeTrex and I think I've discovered some "quirks" (bugs?) in TimeTrex's LDAP integration:
- The description for the Bind User Name field says to leave blank for anonymous binding when searching for users. But if you leave it blank it actually tries to bind as the bare TimeTrex username and then as <BindAttribute>=<TimeTrex username>,<Base DN>. Neither of those attempts is very anonymous IMHO.
- OpenLDAP doesn't return a dn attribute. The results of a search (aka "filter") produce entries and the name of each entry is the DN, but it's not an attribute of the entry. LDAP is different from normal databases in that way, and it seems like the ADODB LDAP driver doesn't handle the DN at all. If you were using the normal PHP LDAP library you would use the get_ldap_dn() call on a search result entry to get its DN.
- The way you normally bind as a user is to search for the user's entry using something like the 'uid' attribute, and then bind as the DN of that user. TimeTrex doesn't use the DN directly, and doesn't seem to properly build it. The DN doesn't need to have a username in it at all, so please don't assume that it does. Ours are based on an employee serial number that is never used as a username, it's just used to create a forever unique DN even as usernames are reused as people come and go.
- anonymous searching works (I know that part is a hack, but the logic in authenticate() that uses isBindAuthentication() seems to me like it needs an overhaul to truly support anonymous searching as the configuration UI says it does)
- building a well-formed DN now works when using the Bind Attribute configuration setting (it would be even better if ADODB-LDAP had the capability to just use the official DN that OpenLDAP returns as the "name" of the search result entry)
Code: Select all
--- original/TTLDAP.class.php 2013-07-22 15:56:38.000000000 -0400
+++ maasj/TTLDAP.class.php 2013-09-06 17:23:54.506163026 -0400
@@ -200,10 +200,10 @@
function isBindAuthentication() {
if ( $this->getBindUserName() == '' AND $this->getBindPassword() == '' ) {
- return TRUE;
+ return FALSE;
}
- return FALSE;
+ return TRUE;
}
function getFilterQuery( $user_name ) {
@@ -313,7 +313,7 @@
//to rebind with the discovered bindAttribute to test the password for cases where it may include a fully qualified domain.
//This should avoid the need to suffix the user_name with '@mydomain.com'
if ( isset($ldap_data[$this->getBindAttribute()]) AND $ldap_data[$this->getBindAttribute()] != '' ) {
- $retval = $ldap->Connect( $this->getHost(), $ldap_data[$this->getBindAttribute()], $password, $this->getBaseDN() );
+ $retval = $ldap->Connect( $this->getHost(), $this->getBindDN( $ldap_data[$this->getBindAttribute()] ), $password, $this->getBaseDN() );
Debug::Text('LDAP post-search bind connection result: '. (int)$retval, __FILE__, __LINE__, __METHOD__,10);
} else {
Debug::Text('BindAttribute not found in users LDAP record...', __FILE__, __LINE__, __METHOD__,10);
-Jason