Learned something worth remembering and passing along today at work regarding the utility ldifde that microsoft ships with both Windows Server and ADAM.

I was attempting to import an ldif file into ADAM with ldifde but the file kept getting spit back at me with “Invalid DN Syntax”. I had imported this exact same file a couple weeks ago on another identical machine, so it wasn’t making any sense. The command I was executing included a macro of sorts (#configurationNamingContext) but it wasn’t getting expanded like it should have, causing the import to fail.

After some investigation, it appears two different versions of the utility are shipped, and only the one in the C:WindowsADAM directory seems to work with the macros. I had been running the command from a different directory, so the version in system32 was getting used and causing problems.

So, if you’re trying to import and ldif file into ADAM, be sure you’re running ldifde from the correct location!

Some of you developers out there I’m sure have heard of our used Spy++ to investigate windows messages. Microsoft has posted Managed Spy which does some of what the original app did but for managed .net code.

Get it here

Last I mentioned, I was learning about the benefits of Active Directory Application Mode. The code is 95%+ complete, and the solution is working exactly as I wanted. ADAM has fit in wonderfully and is providing a very good foundation for an authorization and authentication system.

There really haven’t been many problems, other than a very small universe of documentation. The .NET 2.0 class library has some great additions for dealing with security descriptors (System.Security.AccessControl) and directory services (System.DirectoryServices) in general. Without these namespaces, it would have been a bear to deal with.

When tasked with building this stuff, I first looked at incorporating Microsoft’s Authorization Manager (AzMan) which can also sit atop an Active Directory. It provided a lot of what our solution needed but lacked one critical piece – the ability to have a security hierarchy. It only allows you to define a flat list (technically a hierarchy of two levels) of operations to secure when we needed a tree. So, building our own on ADAM has been working out great!

About a week ago, a coworker and I ran across a nifty C# operator that neither of us has seen before: the “??”.

We both know and use the ternary operator (“?”), but it took a quick look in the MSDN documentation to learn that A ?? B will return A if A is not null, B otherwise.

So instead of X = (A == null) ? B : A; we can write X = A ?? B;

That’s all for now class.

The other day I realized I have what seems to be an ackward way of going about designing (at a high level) software. When presented with a problem (requirements, etc) that I need to solve, it doesn’t seem like I really put my brain to work on it. I find myself putzing around, shufling papers, surfing the web, reading, etc.. instead of actively “working” on the problem at hand. Every now and then I will check-in on the problem in my head and see if I see the answer. If not, it’s back to doing whatever else I was doing.

That will continue for a few days, while I feel like I’m half-asleep and in a stupor. Inevitably, the solution will form in my head without me having actively focused on it. It’s almost as if I don’t want to brute-force an answer, but let it stew until the answer presents itself.

The past several projects at work have been like that. The outcomes have been interesting and have worked very well, so I suppose this approach isn’t a problem. Sure feels a little strange though.

Anyone else do this?

As a software developer I’ve stayed far away from anything having to do with Active Directory. That’s for the network guys! That’s what I’ve always thought at least, until last week.

That’s when I began doing some research for an application’s Authentication and Authorization system. I kept coming back to the Microsoft recommended approach of storing application user information in a directory service, but I didn’t want to have the application require an Active Directory or, worse, require customers to apply schema changes to their AD (something I’d expect to be met with a lot of resistance).

Then I discovered Active Directory Application Mode, ADAM for short. It provides essentially the same functionality (from an application’s viewpoint) as its big brother – you can extend the schema with custom classes and attributes, assign security rights, authenticate users, etc., all without impacting an organization’s infrastructure.

Now an application can be installed with its own directory service. Regarding users, it can be its own user store (ADAM Users) and/or reference domain accounts. This is exactly the functionality we need, the ability to have domain and non-domain accounts co-exist in a clean manner, with the ability to store information on each without requiring the customer to change their AD schema. I’m very excited about using ADAM, it seems to fit exactly where we need and should supply a solid (and standard) foundation for our Authorization and Authentication system. Pretty cool if you ask me.