OK, enough of the sales pitch!! Let's have some fun.
If you have ever attempted to install Active Directory for your applications, you know that it can be a complex and daunting task, especially ensuring that all your dependencies are in place and working well. With AD\AM, you simply download the .exe, provide a path to extract the files to, and then run a wizard with your specific information to install. There is no DNS to set up, no IP address ranges, sites, or any of the other fun stuff you have with AD. In fact, your machine doesn't even need to have a fixed IP address.
|Figure 1. Run the ADAMretailX86.exe Package|
This section walks through the install, but feel free to skip as far ahead as you feel comfortable doing.
Once the download has finished, run the ADAMretailX86.exe package (or the package you downloaded). This will provide a screen similar to that shown in Figure 1.
|Figure 2. Browse to the Path and Run the "adamsetup.exe" File|
Specify a directory for the path that you want to run AD\AM from, in my case C:\ADAMInstall. The rest of this article refers to this directory (actually using %SYSTEMDRIVE%\ADAMInstall).
Once the package extracts the files, you need to browse to the path and run the "adamsetup.exe" file. This will give you a screen similar to that shown in Figure 2.
Click Next, and the EULA screen appears (as shown in Figure 3).
If you are at all like me, you probably just accepted the agreement. Though, the responsible side of me has to warn you that you should thoroughly read the EULA.
Next, you have the option of installing just the Administration tools or AD\AM and the Administration tools (see Figure 4). Ensure you select "ADAM and ADAM administration tools". Otherwise, you will get just the tools for managing AD\AM without the LDAP database.
Now you can begin the AD\AM-specific installation procedures.
|Figure 4. Install the Administration Tools Only or AD\AM and the Administration Tools|
In Figure 5, you see two options:
- A unique instance This is the option for this tutorial. It allows you to perform a brand-new installation of AD\AM.
- A replica of an existing instance This is the option for a more complex AD\AM configuration, including object replication among AD\AM instances (see, it is like Active Directory).
|Figure 5. AD\AM-specific Install: Unique Instance or Replica Existing Instance|
Click Next after selecting "A unique instance."
The next screen allows you to name your installation (see Figure 6). For this article, I use "DevX".
You will see the Service name at the bottom of the screen prefixed with "ADAM_" (AD\AM will install as a single service on your machine).
Note: When you install the service, it installs as DevX (you will see this in Figure 17 a little later) without the prefix. Not until you look at the properties of the service, will the service name have the prefix. It's just one of those lovely little quirks.
Next, you specify the ports that AD\AM will use (see Figure 7). By default, the ports are:
- 389 Standard LDAP port non-encrypted. Most connections will be established over this port.
- 636 Standard LDAP SSL encrypted port. This port allows for secure connections to encrypt data sent to and from the AD\AM instance.
If 389 and 636 are not options on your screen, don't worry. This just means that you have another service listening on those ports, for example Active Directory (a domain controller) or another instance of AD\AM.
|Figure 7. Specify the Ports That AD\AM Will Use|
Note: If ports 389 and 636 are not available, AD\AM will use ports within the 50,000 range. You can change these port numbers, but if any other services are being used on the port numbers you choose, you could have a conflict. Also, don't forget the port numbers you set your AD\AM instance to, as you will need them shortly.
In the next screen (see Figure 8), you define an Application Partition (in AD this is known as a name space). You can install AD\AM without defining an Application Partition, but this would give you an empty AD\AM shell, which would be a bit useless when getting AD\AM ready for an app.
|Figure 8. Define an Application Partition|
In the Application Partition, type "CN=Corp,DC=DevX,DC=COM". This will be the name of your application partition. AD\AM supports not only DNS naming styles but also X.500 directory partition naming styles. X.500 naming styles take the form of organization, country (e.g., o=DevX,c=US).
In case you were wondering, "CN" stands for Common Name, and "DC" stands for Domain Component. The combination of these naming parts forms the entire name for the directory partition.
AD\AM has three directory partitions (or naming contexts), which are part of the installation process:
- Schema This partition contains the schema definition for the LDAP database. It is very similar to the table definitions inside a SQL database, which do not contain data per-say but the description of the type of data they can hold.
- Configuration This directory partition contains the information for sites, services, and partitions within the AD\AM instance. For example, it provides the information to allow AD\AM to replicate data among other AD\AM directories.
- Application This directory partition holds the specific data for your application (e.g., the users and groups). It is the only optional partition at installation time.
|Figure 9. Specify Where to Store the Data and Data Recovery Files|
In the next screen (see Figure 9), you can specify the file paths for where to store the Data and Data Recovery files for the instance:
- Data Files These files, which finish with a .dit extension, are for the core data and schema definitions written to the directory.
- Data Recovery Files These files, which finish with a .edb extension, are used in a similar way as the log file in SQL Server, allowing transactions to be rolled back.
You will notice that the path also contains the name of the instance from Figure 6. This allows you to locate, back up, and restore the files very simply (no complex or conflicting paths).
Note: If you have a high-volume AD\AM instance (lots of writes to the database), you may want to separate the .dit and .edb files onto separate physical spindles, as you would for SQL Server.
Once you have specified the path (the defaults are fine for this example), you need to specify the credentials that the AD\AM service will run under, as shown in Figure 10. I created a local user (non-administrator) on my machine called ServiceADAM.
|Figure 10. Specify the Credentials That AD\AM Service Will Run Under|
You can run AD\AM under a specified account or the restrictive Network Service account. If you do not require access outside of the local machine, create a local user account (as I did). If you require access to other machines, as in a DMZ environment, you can use either a domain user account or, of course, the Network Service account.
Note: The Network Service account is a special account used for accessing resources across your network. However, the service on the remote machine (i.e., AD\AM) must also run under the Network Service account so that the resources can be accessed as that user. This is a great way of getting access to resources on remote machines, especially in a WorkGroup scenario where no domain credentials are available.
If you created a local user account, you may be prompted with a dialog as shown in Figure 11. For an account to run as a service, it needs certain rights (e.g., the "Log on as a service" right).
|Figure 11. Account Needs Certain Rights to Run as a Service|
Note: You can see the specific permissions given to any service account by using the Local Computer Policy MMC console (gpedit.msc). Once you have loaded the console, navigate to Computer Configuration -> Windows Settings -> Security Settings -> Local Policy -> User Rights Assignment.
Select Yes and the installer will configure any rights that the service account needs for you.
In the earlier screen (Figure 10), you configured the account that the AD\AM service is run as, and in this screen (Figure 12) you configure the levels of access within the AD\AM instance for a specific user or group.
|Figure 12. Configure the Levels of Access Within the AD\AM Instance|
By default, the AD\AM installer assigns the logged-on user administrative privileges within the AD\AM instance. However, I generally assign the local Administrators group (as indicated) full administrative privileges within the AD\AM instance. This allows anyone within that group access to the AD\AM instance. If you are in a domain, you should take into consideration that Domain Admins (and any members of that group) will gain administrator access into your AD\AM instance.
Figure 13 shows where you can extend your default AD\AM schema with pre-configured schema extensions, which ship with AD\AM. In this example, I import the MS-InetOrgPerson and MS-User schema extensions, which allow you to replicate users from a domain directly into your AD\AM instance.
By the way, MS-AZMan is used for Authentication Manager (AZMan) and MS-UserProxy is used for passing authentication attempts off to a domain controller. At this point, AD\AM and AZMan have limited integration, that is, until Service Pack 1 for Windows 2003.
You can download additional LDAP Data Interchange Format (LDIF) files or use the additional files that ship with the AD\AM installer to extend your schema. But in this instance, you don't need any additional LDIF structures.
|Figure 14. Summary of the Choices You Have Made|
Hint: You can open the LDIF or LDF files with your favourite text editor to see what they contain.
In the screen shown in Figure 14, the installer provides a summary of the choices you have made. If you need to modify any of the installation parameters, go back and edit them before clicking Next.
Once you have clicked Next, you will see an installation screen similar to that shown in Figure 15.
Finally, you will see the screen in Figure 16, which provides a summary of the tasks completed, along with any warnings. Notice that you don't even need a reboot after installing AD\AM, which is not at all like AD!
There you are, your AD\AM instance is complete. You should perform a couple of minor checks to make sure all has gone well. For example, ensure the service is running (as shown in Figure 17). Notice that the service name is the name you entered for the AD\AM service in Figure 6. If you view the properties of the service, you will see the service name prefixed with "ADAM_".
Additionally, ensure that the .dit and .edb files are in the correct path, as specified in Figure 9.