Working with AD LDS
In this exercise, we install the AD LDS role and set up a new LDS instance. We also bring up our T0RDC02 Core server that runs RODC for the flexecom.local domain, and we will install LDS using the command line. We then configure our instance to replicate between the two AD LDS servers and take a look at directory structure using ADSIedit.msc.
Installing LDS on a Full Install server is very simple: in the Server Manager, click Add Roles, check off Active Directory Lightweight Directory Services, click Next twice, then Install, and Finish. On a Core installation, it is only slightly more complicated.
1. Log on to the Core installation and type in the following command, to confirm that LDS is not yet installed, and to check its full role spelling:
oclist |find "ADAM"
2. You will see output similar to the following:
Not Installed:DirectoryServices-ADAM-ServerCore
3. This confirms that our Core server is not yet running LDS. Let's install the role by executing the following command:
ocsetup DirectoryServices-ADAM-ServerCore
4. You can rerun the command from Step 1, until you see "Not Installed" changed to "Installed." This completes AD LDS installation on the Core server.
Now that we have LDS roles on two servers, let's set up an LDS instance. To kick-start this process, Microsoft created the AD LDS Setup Wizard, located in the Administrative Tools. Launch it and click Next on the first screen. Then, follow these steps:
1. Choose A Unique Instance and click Next.
2. On the Instance Name page, type in ITILLERY and click Next.
3. On the Ports page, the wizard detected that we are running on an AD DS server, which takes default LDAP protocols. The wizard offers ports 50,000 for LDAP and 50,001 for LDAP SSL. Remember these ports, as you will need this later, and click Next.
4. On the Application Directory Partition page, choose "Yes, create an application directory partition," and type in the following partition name: dc=itillery,dc=net. Click Next. This creates an equivalent of application partition in AD DS. Without a partition, our instance is just an LDAP service sitting on the network and not serving any data.
5. On the File Locations page, accept defaults and click Next.
6. On the Service Account Selection page, you need to select an identity for the AD LDS instance we are about to create. The default is a Network Service account, and it will do for the demo installation, but in the real world you may want to assign a service account, in order to better restrict and manage what this service can and cannot do on your network. Click Next.
7. On the AD LDS Administrators page, you need to determine who will be able to fully manage your LDS instance. Click This Account and then select the Domain Admins security group (FLEXECOM\Domain Admins in our case). Click Next.
8. On the Importing LDIF Files page, you are invited to import about half a dozen different object schemas. Recall our AD DS discussions related to objects, classes, and schemas. You will need to import schema extensions
(¡1 Active Directory Lightweight Directory Services Setup Wizard
FIGURE 10-19
Importing LDIF files
Importing LD1F Files
You can import data from Lightweight Directory Interchange Format {LDIF)files into your AD LDS application directory partition.
To configure the AD LDS service in a specific way, import one or more of the LDIFfiles listed below.
LDIFflle name
Descnptioi
H S-Adam Sync Metadata. LD F M S-AD LD S-Display Specifiers. LD F MS-AZMan.LDF MS-lnetOrg Person.LDF MS-User.LDF MS-UserProxy.LDF MS-UserPraxy Full.LDF
ADAM Sync metadata schema extension. Required fc
AD LDS Display specifiers schema and display specif
AD LDS schema extensions for AzMan.
AD LDS inetOrgPerson, user and related classes.
AD LDS user class and related classes.
AD LDS simple userProxy class.
AD LDS full userProxy class. Requires MS-User.LDF
Cancel
Help before you can create any objects in the application partition we are adding. These schemas are shown on Figure 10-19. Select all schemas and click Next.
1. Click Next again and complete the installation process. Click Finish when done. Management of the LDS partition can be done using the adsiedit. msc MMC console. Ensure that the instance is running (net start ADAM_ itillery) and then open adsiedit.msc.
2. In ADSI Edit, right-click the root container and select Connect To. Then, provide connection information similar to what is shown on Figure 10-20.
3. ADSI Edit will connect to your fully functional LDS service (see Figure 10-21). Since you are familiar with containers, OUs, objects, distinguished names, etc., this should not be new at this point. LDS is no different from AD DS, taking a purely directory-minded point of view (of course, AD DS
is the full domain service with KDC, FSMO, etc., but their directory engines run on the same code and are managed using the same tools).
4. To create a new OU using ADSI Edit, right-click the partition root (dc=itillery,dc=net) and select New | Object. On the dialog shown on Figure 10-22, select organizationalUnit and click Next.
FIGURE 10-20
Connecting to an AD LDS instance using ADSI Edit
FIGURE 10-21
5. On the next screen, type in Users as the name and commit this change.
6. To create a new user in LDS, repeat Step 3 in the Users OU, and select user as object type.
7. To create a group, use the group object type. Then, after providing a name for your new group, click More Attributes. Find a property called member, and feel free to add as many user objects as you wish. Figure 10-23 shows this dialog, and the less-than-friendly way of providing distinguished names of user accounts.
ADSI Edit, looking at the LDS instance
FIGURE 10-21
ADSI Edit, looking at the LDS instance
FIGURE 10-22
Creating a new object in LDS
8. Note that once the group is created, you can modify its Member attribute to include security groups and user accounts from AD DS domains.
FIGURE 10-23
Adding users to LDS groups
In addition to working with our lightweight directory, we can add other servers into the replication topology and ensure that LDS is fault tolerant and is replicating much the same way as AD DS would. Since our replica would be running on a Core server, we need to provide an answer file and execute it with the adaminstall.exe utility:
[ADAMInstall]
InstallType=Replica
InstanceName=ITILLERY
ApplicationPartitionsToReplicate="dc=itillery,dc=net"
LocalLDAPPortToListenOn=500 00
SourceServer=tordc01.flexecom.local
SourceLDAPPort=50 00 0
Save this file as itillery.txt in C:\Windows\Adam on TORDC02 (our Core installation server), and using a command prompt, execute adaminstall /answer:itillery.txt
This will automatically create an LDS replica instance, configure it into the most appropriate AD DS site, relative to the IP address of the Core server, and then replicate all schema extensions, as well as custom objects we created using ADSIedit. msc. You can see that the resemblance to AD DS' dcpromo is quite strong. Launch the dssite.msc console and retarget the console to our LDS instance, as shown in Figure 10-24. Note that both LDS servers are now set up in the same site and are set to replicate once an hour by default. Now, you may want to use ADSI Edit to connect to TORDC02:50000, our GUI-less server, and confirm that our custom objects made their way over to the other side.
Finally, there will be occasions when we want to sync up AD DS data into LDS, and keep it synchronized. This can be achieved using the following steps:
1. First we need to extend the LDS configuration schema to support integration with Windows Server 2008 AD DS. This can be done by running the following command:
ldifde -i -u -f c:\windows\adam\ms-adamschemaw2k8.ldf -s TORDC01:50000 -j . -c "cn=Configuration,dc=X" #configurationNamingContext
2. Next, you may need to import ADAM Sync Metadata extensions, if you hadn't checked all schemas during LDS installation. This can be done using the following command:
ldifde -i -s TORDCC1:5CCCC -c CN=Configuration,DC=X #ConfigurationNamingContext -f MS-
AdamSyncMetadata.ldf
FIGURE 10-24
Retargeting the dssite. msc console to manage AD LDS replication
Change Directory Server
Current Directory Server: TORDCOI.flexecom .local
|
Name |
I Site |
DC Type 1 DC Version |
1 Status |
|
|tondc01 .flexecom.local:£D[}ü"| | |
Unavailable | ||
|
TORDCOI.flexecom.bcal |
Toronto |
GC W2KB |
Unavailable |
|
TORDCB2.flexecom.bcal |
Toronto |
GC; RODC W2K8 |
Online |
l~ Save this setting for the current console
Cancel
Help l~ Save this setting for the current console
Cancel
Help
3. Edit the C:\Windows\Adam\MS-AdamSyncConf.xml file with the following parameters:
<source-ad-name> = flexecom.local <source-ad-partition> = dc=flexecom,dc=local <source-ad-account> = service account of your choice d. <account-domain> = flexecom.local <target-dn> =dc=itillery,dc=net <base-dn> = dc=flexecom,dc=local g. <object-filter> = unchanged, but can be set to (objectClass=user) to filter only for user objects
4. Save the file as C:\windows\adam\flexecom.xml. Then, execute the following command:
adamsync /install tordc01:50000 flexecom.xml
5. Finally, we are ready to run the actual synchronization:
adamsync /sync /tordc01:50000 dc=itillery,dc=net
This command can be triggered as needed in order to pull AD DS objects into AD LDS. If you are getting error messages, or no new objects in LDS, try modifying the base-dn parameter to be more precisely targeted to one of the OUs, reinstall the XML configuration, and rerun the replication command.
Post a comment