When using LDAP for logins, TimeTrex requires the "Bind Attribute" parameter to be set (this should ALWAYS be the user's Distinguished Name, or at least Relative Distinguished Name if the "Base DN" parameter is set, rather than any oddball attribute; the user's CN attribute is the standard RDN to bind to in the majority of - but not all - installations) or the passed DN becomes "username,<base dn>" (for instance: "username,ou=people,dc=example,dc=com")
Normal LDAP configuration and behaviour only ever requires a search filter and then binds using the user's LDAP Distinguished Name and then authenticates using the user's DN rather than some configured attribute. Sometimes it is common to use the LDAP DN for login to web applications, but this is by far not how every installation handles things. Often LDAP configurations use a different attribute as the username and stay away from what would be the user's RDN.
Also, the "User Filter" parameter should ALWAYS use proper LDAP filter syntax and variables delimiting which parameter is which, for instance: "(&(objectClass=*)(uid=$1)(is_timetrex_user=1))" where "$1" is automatically translated to the username supplied at the login screen when authenticating.
An example of a properly written LDAP module written in PHP (for Codiad in this case) can be found at https://github.com/QMXTech/Codiad-LDAPE ... r/ldap.php .
I may personally rewrite TTLDAP to use proper LDAP behaviour if nobody gets to it before I do.
Use this forum to discuss desired new features for TimeTrex
3 posts • Page 1 of 1
Excuse this silly redundancy, I typed this from my phone... It should say "...and then binds or authenticates using the user's LDAP Distinguished Name (depending on whether the bind DN and password are set in the configuration, of course)"and then binds using the user's LDAP Distinguished Name and then authenticates using the user's DN
I agree with this poster, You are not using best practice when it comes to this issue. Is there a remedy in the works?