Check to make sure that BOTH are Global Catalogs.
Howto:
1.) Open Active Directory Sites and Services.
2.) Scroll down, expand the site that your DC's are in. Expand
`Servers'.
3.) Expand each of your DC's so that they're showing `NTDS Settings'.
4.) Right-click on 'NTDS Settings', select `Properties'.
5.) Ensure that the `Global Catalog' checkbox on each is checked.
DISCLAIMER:
I'm assuming that you've already checked your replication, made sure everything else is working properly, etc. This is intended to be a quick-check option.
As Rajeev has pointed out in comments, Active Directory IS an LDAP server and more, and the AD LDS service is a "free" Windows Server role that is provided to do specifically what he is looking for. AD provides many extras (replication, Kerberos, federation, etc.) that you would have to build on your own with a Free/OSS solution like OpenLDAP+postgres+kerberos. There are other (primarily commercial) directory services which have similar abilities.
Licensing should probably not be an issue. You are probably going to have AD installed if your deployment is going to be primarily Windows-based (for the computer accounts, admin accounts, etc.), and this will be relatively small (looks like a 5-user CAL at most). Any "user" objects that you create in LDS for your public users will not be counted against the licenses for your AD DS accounts. You can contact Microsoft Licensing to verify this.
Using AD LDS definitely has some great benefits, your proposed installation may be too small to realize some of them though.
- Replication is probably the #1 "freebie" you get with LDS. Your AD DS Sites and Subnets topology can be used to manage replication automatically, just like for AD DS. But with only one LDS server, you won't need replication.
- Most of the newer tools for backup, maintenance, reporting, etc. will all work as well with LDS as they do with DS. So, if you already have some off-the-shelf tools in-house, you can probably just use them for your LDS. Again, your setup sounds too small for this to be a big benefit.
- If you are ALREADY familiar with the care and maintenance of AD DS, using LDS will be generally familiar and will build on a knowledge-set you already have. This can mean significant improvements in supportability and manageability, any scripting knowledge you have will be generally transferrable, etc. This is a bonus.
- And again, LDS is "free" with Windows, if you've installed a 2003/2008 server then LDS is included. This is also a bonus.
- With Windows Server 2008 R2 you get all the cool features from the AD DS code-base (snapshots, etc.)
All that said... If you don't have any particular experience with AD, and don't have any particular infrastructure already in place to handle it, you may not see much benefit by going this route. Based on the size of your described deployment, you could almost certainly go with an OSS setup like LAMP + OpenLDAP, depending on your comfort-zone and what you are application requirements are.
Keep in mind that if you are doing any kind of user management, then you are going to very, VERY sorry if your approach is just "stick a bunch of user names and passwords in a SQL table." User management is a complex process that has already been solved countless times before. Handling passwords is something you just should not be doing unless you already have lots of experience in security related programming. Please don't roll your own!
Find a suitable commercial or OSS framework that has been designed already to handle AAA* correctly, something like OpenID is probably not a terrible idea. Jeff Atwood's blog (he runs a website, you may have heard of it...) has a number of posts discussing these issues around his work on StackOverflow and ServerFault.
Any way, I hope this discussion helps.
Best Answer
NLB is your best option here. With DNS or an SCP clients can choose a random server to connect to. LBS can be configured to fail-over when required. While you can configure multiple AD LDS instances to be a single configuration set, sometimes (more often than I'd like) applications will use the "random server" to make multiple updates to attributes in a form. Eg I add user jsmith , If someone else is adding user jsmith no conflict will be reported because I'm on a different instance. When replication occurs one of these gets renamed as cnf:GUID and now has to be sorted out. This is the same as regular AD however there is generally some admin noticing that user jsmith can't log in. I've seen crappy apps using LDS with DNS that have lots of cnf object sticking around due to lack of maintenance. NLB solves that problem by allowing fail-over instead of round robin. It's typically pretty tough to overload LDS.