Bug Tracker Blog by Corey Trager

LDAP, Active Directory integration

by Corey Trager 29. January 2008 04:14

The next BugTracker.NET releases will include some LDAP support, as well as support for its window's incarnation, Active Directory.  LDAP is a new technology for me.  It wasn't clear to me how to get started learning it.  With a new programming language, there's always a "Hello World" tutorial for getting started but I had trouble finding a "Hello World" style tutorial for LDAP, targeted to somebody who needed an introduction to even basic LDAP concepts, like "distinguished name".  I was able to get OpenLDAP up and running but for a while I didn't know what to do with it.  I didn't know what to put in an LDIF file - I didn't understand that I was defining both the schema and data at the same time with the LDIF.  But eventually a few things clicked and I got it. Now that I know a little bit more, I think these are the resources that WOULD have been helpful had I been lucky enough to have stumbled upon them when I needed them, which I wasn't:


What is LDAP support, concretely?   What does it mean that BugTracker.NET supports LDAP?   A first step - my first step -  is to check users' passwords against the ones stored in the LDAP directory instead of the ones stored in the database, so that passwords can be the same across applications.  The next step would be automatic user creation.  That is, for BugTracker.NET to work - for just about any tracker to work - there needs to be a row in the tracker's database for that user.   It's not enough that the user exists in the LDAP directory, it also needs to exist in the database. So, what a tracker can do, if a user/password combo is authenticated against LDAP, is create the database row the first time the user logs into the tracker.  The tracker could either create a bare bones user, with default characteristics, or the tracker could use some attributes from LDAP to set the corresponding attributes in the tracker db.  For example, there could be an attribute in the LDAP directory that BugTracker.NET should intrepet as corresonding to the corresponding BugTracker.NET "organization" of a user. Another way of using LDAP is to create a tool that allows admins to do an initial mass import of users.

I did my testing using OpenLDAP only. I knew there needed to be a way for others to set specify configuration settings different from mine. For my first step, these were the items I knew enough to allow the admin to configure in Web.config:

<add key="AuthenticateUsingLdap" value="1"/>  <!-- a switch for turning LDAP integration on/off -->
<add key="LdapServer" value=""/>
<add key="LdapUserDistinguishedName" value="uid=$REPLACE_WITH_USERNAME$,ou=people,dc=mycompany,dc=com"/>  <!-- a template for the distinguished name -->

And here's the code.   I didn't allow "AuthType" to be configurable, because I didn't know if it matters in the real world.  I don't have any experience to know.

        public static bool check_password_with_ldap(string username, string password)
            string dn = btnet.Util.get_setting(

            string ldap_server = btnet.Util.get_setting(

            dn = dn.Replace("$REPLACE_WITH_USERNAME$", username);
            LdapConnection ldap = new LdapConnection(ldap_server);
            System.Net.NetworkCredential cred = new System.Net.NetworkCredential(dn, password);
            ldap.AuthType = AuthType.Basic;
            bool bResult = false;

                btnet.Util.write_to_log("LDAP authentication ok: " + username);
                return true;
            catch (LdapException e)
                string s = e.Message;

                if (e.InnerException != null)
                    s += "\n";
                    s += e.InnerException.Message;

                // write the message to the log
                btnet.Util.write_to_log("LDAP authentication failed: " + s);
                return false;

Does the code above look reasonable?  I hope so. 

Something I should have done right up front was to take a look at the LDAP documentation of some of the other BugTrackers, like Jira, FogBugz, Bugzilla.   When I did finally look at how other applications were handling it, I found the most detailed concrete information from Jira, especially just this screenshot below.  I guess everything there is there for a reason, so I can see that I will have to add more configurability in the future.   But, I have to crawl before I can walk, so I'll release what I have this weekend and then see what kind of feedback and code contributions I get.





2/8/2008 1:16:22 PM #

This is a great first step, but we can't use it yet, as all our LDAP authentication calls must be done over a secure (SSL, port 636) connection which means the AuthType parameter would be a critical addition for us to start using this. Basic means that the password would be sent unencrypted over the network, and as this is a central resource giving access to lots of systems, wouldn't be acceptable from a security point of view.  Keep up the good work though!  Smile

Colin Jones |

2/8/2008 1:19:29 PM #

Did I just say Basic means it's unencrypted - didn't mean that.  But we would need some way of doing this over SSL on port 636...

Colin Jones |

2/8/2008 3:16:27 PM #

Thanks Colin - I only have my own little OpenLDAP to test with, so the improvements in the integration are probably going to have to rely on folks link you experimenting with the code and then me merging the experiments back into the mainline codebase. (Feel free to write me directly about this at ctrager@yahoo.com.)

I suspect you could get the different port by changing the hostname from, like, YOURHOST to YOURHOST:636 in Web.config?. Could you try it?

Regarding Basic versus whatever, below are your choices, from the Microsoft documentation.  Just change the "Basic" in authenticate.cs to what you think. You can do it with Notepad. The file will recompile automagically.

Anonymous Indicates that the connection should be made without passing credentials. The value is equal to 0.  

Basic Indicates that basic authentication should be used on the connection. The value is equal to 1.  

Digest Indicates that the Digest Access Authentication should be used on the connection. The value is equal to 4.  

Dpa Indicates that Distributed Password Authentication (DPA) should be used on the connection. The value is equal to 6.  

External Indicates an external method will be used to authenticate the connection. The value is equal to 8.  

Kerberos Indicates that Kerberos authentication should be used on the connection. The value is equal to 9.  

Msn Indicates that it is authenticated by “Microsoft Network Authentication Service”. The value is equal to 7.  

Negotiate Indicates that Microsoft Negotiate authentication should be used on the connection. The value is equal to 2.  

Ntlm Indicates that Windows NT Challenge/Response (NTLM) authentication should be used on the connection. The value is equal to 3.  

Sicily Indicates a negotiation mechanism (Sicily) will be used to choose MSN, DPA or NTLM. This should be used for LDAPv2 servers only. The value is equal to 5.  

Corey Trager |

6/30/2009 4:53:34 PM #

I really like bugtracker and the idea of using a centralized user account system outside of bugtracker seems like a great idea (one username/password to remember)

However I would like to use the System.Web.Membership aka aspnetdb aka ASP 2.0 authentication to store user names, passwords, roles etc. Has anyone done this or looked into it?


Wocketfast |

7/13/2009 9:32:30 PM #

Pingback from answerspluto.com

list of urls 4 « Answers Pluto

answerspluto.com |

1/31/2010 6:59:02 AM #

Pingback from site-super-tracker.com

LDAP, Active Directory integration «  Site Super Tracker

site-super-tracker.com |

Comments are closed

Powered by BlogEngine.NET


Comment RSS