Should you find yourself on this page and wonder just what ADAM or AD LDS is and what it could do for you, head on over to Microsoft’s TechNet site for more details.
For those in the know (or just beginning to know), this will be a quick step-by-step on setting up a stand-alone instance of AD LDS (same steps will largely apply for ADAM). If you are asking yourself, “Why post something that is already available in a myriad of blogs and/or a step-by-step guide by Microsoft?”, then I can only assuage your concern with this; I am imparting my experience to an unknown audience who may or may not be skilled in the art of Google searches and TechNet trolling; As a result, what I write on this (and any other) topic will hopefully help at least one person have an “A-HA!” moment, even if this has been outlined elsewhere. And now, on to the show.
Setting up a stand-alone instance of AD LDS
Prerequisites: You will need to insure that the AD LDS server role has been installed on the end point where you plan to install your stand-alone instance. This is fairly self-explanatory, but if in doubt as to how to accomplish this task, go here.
Setup Steps:
1. Create and AD LDS instance by clicking Start -> Administrative Tools -> Active Directory Lightweight Directory Services Setup Wizard.
The Setup Wizard appears.
2. Click Next.
The Setup Options dialog box appears.
For the sake of this guide, a unique instance will be the primary focus. I will have a separate post regarding AD LDS replication at some point in the near future.
3. Select A unique instance.
4. Click Next and the Instance Name dialog box appears.
The instance name will help you identify and differentiate it from other instances that you may have installed on the same end point. The instance name will be listed in the data directory for the instance as well as in the Add or Remove Programs snap-in.
5. Enter a unique instance name, for example IDG.
6. Click Next to display the Ports configuration dialog box.
7. Leave ports at their default values unless you have conflicts with the default values.
8. Click Next to display the Application Directory Partition dialog box.
This is an area that was somewhat confusing for me when I first tried installing an ADAM instance. Given that I was fairly new to all things LDAP and Active Directory, I did not understand why it was important to create an application directory partition and what I should use for the partition name.
Note: The partition name should be something unique and follow the normal distinguished name syntax. For example, I used dc=idg,dc=local. If translated to a domain name, it would be idg.local. To keep things simple, I would recommend using something that is indicative of your project and is unique to avoid naming exceptions down the line.
9. Select Yes, create an application directory partition and enter the Partition name of your choosing, for example dc=idg,dc=local.
10. Click Next to display the File Locations dialog box.
Take note that the instance name you added in step 4 is indicated in the data storage path.
11. Leave the AD LDS File locations at their default values.
12. Click Next to display the Service Account Selection dialog box.
13. Select an account to associate with ADAM:
For this guide, we will only use the default option for “Network Service Account”. I will discuss when to use “This Account” in my guide on synchronizing AD LDS with Active Directory.
Attention:If you select Network service account, you must add the passPromptflag when installing the AD LDS Synchronization configuration XML file. You can avoid this by selecting This Account with the User name and Password for an Administrative user.
If you select Network service account, the following warning may appear.
Click Yes to continue.
14. Click Next to select the account and display the AD LDS Administrators dialog box.
For a stand-alone instance, using the currently logged on user will be sufficient. I will note when you should select “This account” in my guide on synchronizing AD LDS with Active Directory.
15. Ensure that Currently logged on user: is selected and click Next.
The Importing LDIF Files dialog box appears.
16. Select Import the selected LDIF files for this instance of AD LDS.
If you are setting up a stand-alone AD LDS instance, add MS-InetOrgPerson.LDF or MS-User.LDF to the Selected LDIF files section. I typically use MS-InetOrgPerson.LDF when I setup a stand-alone instance of AD LDS, however, you might have a need for the MS-User.LDF if you plan on testing with attributes that are more in line with that of your domain controller.
17. Select Next to display the Ready to Install dialog box.
18. Click Next to install the new AD LDS instance.
Once the installation is complete, a successful completion message appears.
19. Click Finish.
You have just setup your stand-alone AD LDS instance. Pretty easy, no? If you are wondering what to do with it at this point, the sky is pretty much the limit. It is standard to have some concept of how this instance will be leveraged in your project prior to installation.
For my job, a stand-alone instance will give me dummy data I can leverage with the custom schema for my multi-factor authentication platform. As everyone knows, dummy data is rarely a good substitute for real user data.
Stick around for my next post in the continuing AD LDS 101 series where I show you how to synchronize real data from your domain controller to your AD LDS instance.
{ 1 comment… read it below or add one }
Your guide was 10x more helpful than that technet eyesore. Thank you.