Jumping over LDAP hurdles

LDAP is nothing new, but until recently I had never had the need to create LDAP lookups from an application to a directory server. Most of today’s platforms are usually LDAP compliant and handle this themselves, thereby abstracting developers and administrators from the LDAP server internals. Under normal circumstances you just have to read the platform/framework configuration documentation, create a system account for the application to use to bind to the LDAP server, and the platform takes care of the rest itself… well more or less :-).

Context

In the past I have read a lot about LDAP, and for some reason I had got the idea in my head that working with LDAP was difficult. In practice it turned out to be pretty simple once you got past a few hurdles. The ASP.NET application I was maintaining needed to switch from LDAP services supplied by Lotus Domino to Microsoft Active Directory. The application was using Active Directory for user authentication, but for all the other services it was using the LDAP directory supplied by Lotus Domino. There were historic reasons why this was the case, but it didn’t make sense anymore. To make matters worse, the data in two directory services were not synchronized so users were complaining that their user data was displayed incorrectly in the application UI. Of course this was true since it was being read from a mix of directory servers.

From my brief experience from working with this technology there are three basic hurdles you need to jump over to get something working.

Binding

The first thing you need to do is bind to a LDAP directory which is LDAP jargon for authenticating to the LDAP server. It sounds simple enough… However, when creating a URL I usually write the protocol specifier using lowercase characters. Doing this was giving me a very cryptic error from the Microsoft .NET runtime since I was using a protocol specifier that looked similar to ldap://server/query… Luckily Google was my friend on this occasion and I soon found out why I was getting complaints from the .NET runtime environment. It seems the .NET System.DirectoryServices.DirectoryEntry class does not like the protocol specifier in lowercase characters when connecting with Active Directory, so ldap:// has to be converted to LDAP:// which I still find to be a bit strange. Is this a platform specific bug? I could not find any information in any LDAP documentation that specifies that this is necessary…

Directory structure

The next thing to do is get familiar with your specific directory structure. I used the free Softerra LDAP browser to help me here. It will let you query the directory and display the results. It will also let you traverse the tree using the GUI which is useful to get a feel for the LDAP tree. Your tree will probably be site specific and you will need to know where to look to create a meaningful and efficient LDAP query. For lookup efficiency you should avoid starting your query at the directory’s root node. I was working for a large enterprise with thousands of users and groups. Starting a query at the wrong place would kill performance. In my case I was using an auto-complete function on the UI to call upon a backend lookup service so it had to be fast.

LDAP query syntax

Building the LDAP query is where you probably will spend most of your time. The query syntax itself may seem difficult to read at first, but you get used to it fast. If you’ve ever worked with a scientific calculator then I guess you can think of it working much that same way, only backwards :-). So to find an object that has objectclass=person and a shortname attribute starting with “joe” you could write (&(objectclass=person)(shortname=joe*)). The “&” works as a logical AND and the objectclass is the LDAP object type to return (there are other types of standard LDAP objects). Also note the wildcard. To expand our search example to find people with a shortname starting with “joe” or “kent”, the query could be written as (&(objectclass=person)(|(shortname=joe*)(shortname=kent*))). Notice the “|” symbol for the logical OR. Also note the parenthesis in the query limiting the AND and OR functionality. It may be hard to read at first. This is where a LDAP query tool as mentioned above may come in handy when testing your query.

Advertisements

Microsoft Certified Technology Specialist – .NET Framework 3.5 ASP .NET Applications

So I finally reached my goal. Today I completed the test 70-536 Microsoft .NET Framework – Application Development Foundation, and with the earlier completion of 70-562 Microsoft .NET Framework 3.5, ASP.NET Application Development (see my prior posting), I can now call myself a “Microsoft Certified Technology Specialist (MCTS) – .NET Framework 3.5 ASP .NET Applications”. Yes, I am really glad this is over for now – and so is the wife and children 🙂

The test today (70-536) was harder than I initially anticipated. Like last time, I prepared by reading through the Self-paced training kit and taking notes in Notepad++. After reading through the book I then took a closer look at the test’s online curriculum and used MSDN to supplement my notes with relevant information. In the end I had 4662 lines of notes to be exact! Given the chance again I would probably look at the curriculum before reading each chapter of the book since it clearly tells you which skill set the chapter is covering. You should then be able to see if it covers everything you need.

For some odd reason the book doesn’t cover every skill mentioned in the curriculum. The classes ProtectedData and ProtectedMemory come to mind, although I can’t recall getting any questions about either of them. Apart from an early run, I didn’t use the practice tests on CD-ROM since I consider the question quality lacking, some times annoying, and some times plain wrong! If I had even more time I might have used a bit more time here, but I think playing with MSDN and testing examples gives higher value. Let me add that the CD-ROM practice tests I had installed applied to .NET 2.0 – some of the answers had changed for .NET 3.5. The test itself claims not to be .NET version specific.

My overall experience of taking this exam was a positive one. I learned an awful lot, but the questions on the test are made to make you uncertain. Simple things that you thought you knew well are now the source of uncertainty. Compared to the Certified Java Programmer exam (which I took a few years ago) this test does not delve deep in to the details or syntax of the C# language, but stays in the world of the .NET framework – as the title says.