We have a TRAC installation that was originally set up using the standard old TRAC/Subversion/Apache model. We have added over 80 new users over the past year or so. These users are authenticated using a file (standard issue htpasswd stuff that was part of the original installation).
It is important to note that out of all of the users in the TRAC system, some are part of an LDAP system within this institution and some are not. For those within the institution it makes sense to allow them to use LDAP to authenticate (saves remembering yet another password). Today I have managed to get this to work. It sounds simple but there are a few traps and after a fair while of testing I thought I would share my findings to save you some time.
The first thing that I did was add the word ldap to the relevant http.conf files within the <Location /trac> element.
AuthBasicProvider "file" "ldap"
I then added the following lines to the same area
I was now able to log in using the credentials used in the original file authentication method, however I was unable to log in using LDAP credentials.
I did some googling and found out that there is another couple of lines you can add to allow the authentication methods to fall back in the case of a failure to authenticate using the first method in the pecking order.
I added the following lines to the same area as mentioned above. These allow LDAP authorisation module to authenticate in case of a FILE authentication failure and vica-versa. However for me this was not actually the case. It turns out that the trigger for the fall back to the next authentication method only occurs if there is no match for the given username used during the login. In my case I had my username in both the LDAP and the original TRAC setup. Once I removed the username from the trac_users file (passwd -D trac_users_file username1) it would fall back to LDAP and authenticate correctly.
I did not want the entire institution to be able to access our TRAC so I added the following line
Require ldap-user username1 username2
The only problem now was that this Require statement is not “authentication type/flavour” specific and therefore overrides anyone logging in regardless of if they are using LDAP or FILE.
So it seems at this stage to allow non LDAP users we need Require valid-user (but that lets everyone in the entire institution (LDAP users) to authenticate). To restrict the LDAP to a select few users we end up blocking the non LDAP users. Using groups is out of the question because the lowest granularity within the institutions LDAP is “staff” but only some of those should be able to authenticate.
The final solution that I came up with was amending the LDAP URL as follows and re-adding the “Require valid-user” line to the config.
The pipe symbol used above allows me OR mymate OR myothermate. who are all within a SUB section of server.edu.au to authenticate.
End result we are allowing valid users (listed in the htpasswd created file by trac) and the query to the ldap is taking care of the single user granularity that we were after.