Peter's Gekko

public Blog MyNotepad : Imho { }

September 2007 - Posts

An architect should code. Period

This has been said over and over again, but as long as it keeps happening it just has to be said again.

A very common career path in IT "promotes" a coder over the years to a program manager with architect responsibilities. And being an architect they stop writing code themselves. The thing I see over and over again is that these people keep living in the programming environment in which they grew up. They did loads of work in VB 6 or classical ASP. When a new piece of software has to be designed, which quite often is supposed to do something similar to the things they built themselves in their heydays, they grab their old projects to demonstrate what they have in mind. Right now I'm facing an ASP.NET site which has to build dynamic pages on the fly based on dynamic sets of data. And the lead architect bases his ideas on an ancient asp site he built years ago. Given the tools of those days it is a well crafted product but in nature it is just plain old asp spitting out html top to bottom. Given today's tools we can write far clearer, more powerful and better maintainable code building an asp.net control tree and leave the rendering of the html to the framework. But our lead architect doesn't know this framework.

The good thing about my lead is that he is very open minded and eager to learn about today's tools. But it would be so much better if working and coding with them would be part of his work. How can you be a good architect when you don't know your building materials or construction tools?

Posted Sep 28 2007, 02:31 PM by pvanooijen with 31 comment(s)

Filed under: Chatter

Reading (Active) Directory information from outside the domain

In a recent post I described some of the basics of retrieving Active Directory information from code. Which is, using the .NET framework, no big deal. But all the code made the assumption that it was running on a machine which was a member of the domain whose Directory was being queried.

The framework classes can be used from a machine outside the domain as well. The DirectorySearcher class, which provided all the AD info, has an overloaded constructor which takes a DirectoryEntry object. This class has several overloaded constructors, several take the path to the directory. Passing in a value you can query the directory from outside the domain.

path = "LDAP://192.168.1.80";

DirectoryEntry adRoot = new DirectoryEntry(path);

DirectorySearcher ds = new DirectorySearcher(adRoot);

This snippet of code queries the domain controller at 192.168.1.80. As you see the location is just an LDAP (Lightweight Directory Access Protocoll) URL. The DirectoryEntry class can operate against any Directory which does implement LDAP. A Windows 2000 and a Windows 2003 domain controller do. But that does not guarantee they have the same behavior. Windows 2000 is far stricter on who has the permission to query the directory, see here for details. You can pass in the credentials required for querying in another overload of the DirectoryEntry

path = "LDAP://192.168.1.80";

DirectoryEntry adRoot = new DirectoryEntry(path, searchUser, searchPasswd);

DirectorySearcher ds = new DirectorySearcher(adRoot);

But (again) the world does not end with just MS networks implementing LDAP. In a upcoming project we'll have to work with a Novell domain. All I need to know is some group membership information. But having seen how different this is between the two MS implementations I'm a little worried. Any advice on the subject is appreciated.