I installed ADLDS to my development machine in hopes to be able to test authentication from .NET code without having to have a separate machine (or even VM) running Active Directory. Everything went well until I tried to add a user to the "domain". Here's what I have done so far:

FIRST: Installed Active Directory Lightweight Directory Services (AD LDS) for Windows7, checking all the boxes for the classes and modules (sorry, can't remember exactly what that wizard step was talking about). As a result, I'm able to connect to my domain controller using the newly-installed tool "Active Directory Sites and Services":

Successful connection to DC from Sites and Services

NEXT: Installed Remote Server Administration Tools for Windows 7 with Service Pack 1 (SP1).

THEN: Ran the "Active Directory Users and Computers" snap-in and tried to connect to my local machine as the "Domain Controller". When I did that, here's what I got:

Successful connection to DC

But, then when I clicked OK to view the users in the domain, I got...

Error from AD Users and Computers

I understand that ADLDS stands up a lightweight Domain Controller... is it so lightweight that I can't even add users for testing authentication? Is there something I can do or add to this instance to make users possible in ADLDS?

  • Can you explain why you are trying to do this? I'm asking as I suspect the core thing you're after won't work (and so answering this question is irrelevant...I can explain why) but need to know the intent to know for sure... Sep 10, 2012 at 21:47
  • I'm writing an app that's supposed to authenticate against Active Directory. I am trying hard to avoid installing Windows Server on a VM so that I can hit a real domain controller. Sep 10, 2012 at 21:59
  • 1
    Why are you "trying hard" to avoid testing your app against a real-world environment?
    – MDMarra
    Sep 12, 2012 at 10:27
  • 1
    And developers wonder why their code often doesn't work the same when deployed to the real world. :) Sep 12, 2012 at 12:31
  • 1
    "Having lighter-weight systems to test against in a development environment is pretty important to developing software." - I'd argue that having a test configuration that is analogous to a production configuration is much more important...
    – MDMarra
    Sep 12, 2012 at 16:58

1 Answer 1


I can tell you how to do this (and I do below) but I first want to make a run at telling you about the cons.

The core issue is that AD domains are not the same thing as ADLDS. While the core code base is the same (ldap head, storage, replicator, ...) the protocol suite offered on top is different. And this is where it will get you. Many would say that if you're running your app on Windows, using pure LDAP binds as a form of auth is not ideal...using Windows APIs (ex: LogonUser) is a far better path. And this sort of dependency will always fail against LDS as it is only the LDAP core, not the rest of the protocol suite.

That said, many things do work the same. And so you can create users in LDS, so long as you import the user schema extension. This used to ship with the LDS product itself (ms-user.ldf or something like this) so search for *ldf files on your disk and you should find it kicking around. Even when you do this, however, not all tools will work. Tools like the one above might or might not, I honestly can't remember anymore. It will be a semi-random set. I predict you will never be fully satisfied.

This is not to say your dev effort can't be successful...I have done exactly what you are doing. You just will need to learn to live w/o the full toolset. LDP and adsiedit will soon become your friends.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .