An overview of implementing AD LDS

AD LDS is implemented in Windows Server 2008 as a server role. To install the server role, use Server Manager to add the role. To install the server role on a Windows Server 2008 computerrunning Server Core, run the start /w ocsetup DirectoryServices-ADAM-ServerCore command. During the role installation, you do not need to make any installation decisions other than choosing to install the role. In order to install AD LDS, your user account must be a member of the local Administrators group.

Configuring Instances and Application Partitions

After installing the AD LDS server role, you use the Active Directory Lightweight Directory Services Setup Wizard to create AD LDS service instances. Multiple instances of AD LDS can run simultaneously on the same computer. Each instance of the AD LDS directory service has a separate directory data store, a unique service name, and a unique service description that is assigned during installation. When you run the wizard, you also have the option of creating an application directory partition.

To create a new AD LDS instance by using the Active Directory Lightweight Directory Services Setup Wizard, complete the following steps:

1. Start the Active Directory Lightweight Directory Services Setup Wizard. You can start the wizard from the Administrative Tools menu or from Server Manager.
2. On the Welcome page, click Next.
3. On the Setup Options page, you have a choice of creating a new instance or creating a replica of an existing instance, as shown in image. Click A Unique Instance and then click Next.

4. On the Instance Name page, provide a name for the AD LDS instance that you are installing. The name that you choose must meet the following requirements:
❑ It must be different from other ADAM instances running on the same computer.
❑ It must be no longer than 44 characters.
❑ It must use characters only from the ranges of a through z, A through Z, or 0 through 9.
❑ The name ntds cannot be used.
5. On the Ports page, specify the communications ports that the AD LDS instance uses to communicate. AD LDS can communicate using both LDAP and Secure Sockets Layer (SSL).

6. On the Application Directory Partition page, you can create an application directory partition during the AD LDS installation, as shown in Figure below. If you do not install an application directory partition now, you must create an application directory partition manually after installation. When you create the application partition, you must provide a fully qualified partition name.

7. On the File Locations page, you can view and change the installation directories for AD LDS data and recovery (log) files. By default, AD LDS data and recovery files are
installed in %ProgramFiles%Microsoft ADAMinstancenamedata, where instancename represents the AD LDS instance name that you specified on the Instance Name page.
8. On the Service Account Selection page, select an account to be used as the service account for AD LDS. The account that you select determines the security context in which the AD LDS instance runs. The Active Directory Lightweight Directory Services Setup Wizard defaults to the Network Service account.

9. On the AD LDS Administrators page, select a user or group to become the default administrator for the AD LDS instance. The user or group that you select will have full administrative control of the AD LDS instance. By default, the Active Directory Lightweight Directory Services Setup Wizard specifies the currently logged-on user. You can change this selection to any local or domain account or group on your network.
10. On the Importing LDIF Files page, you can import schema .ldf files into the AD LDS instance, as shown screenshot.

11. On the Ready To Install page, review your installation selections. After you click Next, the Active Directory Lightweight Directory Services Setup Wizard copies files and sets up AD LDS on your computer.

 

 

AD LDS Management Tools

 

In most cases, after you install an AD LDS instance, you will install the application that will use the instance (in fact, the application may install AD LDS and configure the instance for you). However, you can also manage AD LDS instances by using the administration tools provided with AD LDS.

Using the ADSI Edit Tool

ADSI Edit is a Microsoft Management Console (MMC) snap-in for general administration of AD LDS. It is installed as part of the AD LDS and AD DS server roles. To use ADSI Edit to administer an AD LDS instance, you must first connect to the instance. When you open ADSI
Edit for the first time, it is not connected to any directory. To connect to a directory, on the Action menu, click Connect To. On the Connection Settings screen, you must provide the following information:
■ A name for this connection If you choose one of the well-known naming contexts, this name is filled in for you.
■ A connection point This can be a well-known naming context like the configuration or schema partitions, the rootDSE object, or the Default naming context (which only applies to AD DS domains or application directory partitions). If you want to connect to an application directory partition, you must enter the distinguished name of the application directory partition.
■ The server to which you are connecting If you are using a port other than the standard LDAP ports, you must also provide the port number for the connection.

 

 

Using the Ldp.exe Tool

Ldp.exe is a tool that can be used to administer any LDAP directory service. To use Ldp.exe to administer an AD LDS instance, you must connect and bind to the instance and then display the hierarchy (tree) of a distinguished name of the instance:
1. To connect to an instance using LDP, open a command prompt and type Ldp.exe and then press Enter.
2. On the Connection menu, click Connect. Provide the server name and the port used for the AD LDS instance and choose whether or not to use SSL.
3. After connecting to the instance, you need to provide your credentials by binding to the instance. On the Connection menu, click Bind.
❑ To bind using the credentials that you logged on with, click Bind As Currently Logged-on User.
❑ To bind using a domain user account, click Bind With Credentials; then type the user name, password, and domain name (or the computer name if you are using a local workstation account) of the account that you are using.
❑ To bind using just a user name and password, click Simple Bind and type the user name and password of the account that you are using.
❑ To bind using an advanced method (NTLM, Distributed Password Authentication (DPA), Negotiate, or Digest), click Advanced DIGEST. Then click Advanced, and in the Bind Options dialog box, select the desired method and set other options as needed.

4. After you have been authenticated, on the View menu, click Tree. Type or select the distinguished name for the directory partition that you want to connect to.
5. To view information about the objects in the directory partition, click the object in the left pane. Detailed information about the object is displayed in the right pane, as shown in next figure .

 

6. To edit the object, right-click the object and select one of options for modifying the object or adding child objects.

 

Using the Dsdbutil Tool

Dsdbutil is a directory service management tool that provides much of the same functionality as Ntdsutil does for AD DS. With Dsdbutil, you can:
■ Backup and perform authoritative restores of AD LDS data.
■ Move the AD LDS data files.
■ Change the AD LDS service account and port numbers.
■ List all of the AD LDS instances running on a server.

To use Dsdbutil, start the utility from a command prompt. Then connect to a specific instance by typing Activate Instance instancename. To see all of the commands available in Dsdbutil, type Help. Like Ntdsutil,  Dsdbutil also provides context sensitive help, so typing Help at any
command prompt will display all of the options available in that context.

Configuring Access Control

In AD LDS, each directory object has an access control list (ACLs) that determines which users have access to that object. By default, ACLs are assigned only at the top of each directory partition. All objects in a given directory partition inherit these ACLs. If your application required specific permissions to be assigned at different levels in the directory structure, you can use tools such as Dsacls and Ldp.exe to view and assign permissions. Dsacls is a command-line tool that can be used to view and modify permissions in a directory like AD LDS. Dsacls uses the following syntax.

dsacls object [/a] [/d {user | group}:permissions […]] [/g {user | group}:permissions […]] [/i:{p | s | t}] [/n] [/p:{y | n}] [/r {user | group} […]] [/s [/t]]

Dsacls uses permissions bits in the command to configure permissions on the object. For example, dsacls provides the generic permissions: GR – Generic Read, GE – Generic Execute, GW – Generic Write, and GA – Generic All.

You can also use Ldp.exe to configure permissions on AD LDS objects. To configure permissions using LDP, complete the following steps:
1. Open Ldp.exe and then connect and bind to an AD LDS instance.
2. On the View menu, click Tree View and then select the directory partition that you are connecting to.
3. Right-click the directory partition object for which you want to modify the permissions, click Advanced, and then click Security Descriptor. The Security Descriptor dialog box displays all access control entries (ACEs) and their assigned access rights over the selected directory partition object.

4. Click anywhere in the discretionary access control list (DACL) and then click Add ACE.  Type the distinguished name of the user account and select the appropriate permissions. You can also choose to allow or deny permissions and configure permission inheritance.

SharePoint Security – Authentication

SharePoint Server 2010 on Windows Server 2008 R2 has a lot of possible of authentication scenarios. You are no longer limited to the basic, unfriendly authentication types.  The key is to fully understand the possible security scenarios for authentication, so you will be able to plan the every service security in very detail. In this article I will cover the SharePoint authentication methods, which are obviously very based on the Windows Server 2008 R2 since that is the OS SharePoint runs on.

Authentication Methods for SharePoint Sites

There are three general types of authentication for SharePoint you should know about. The first two types of authentication modes in SharePoint 2010 are Claims Based Authentication (which is new in SharePoint Server 2010) and Classic Mode Authentication (known from previous SharePoint and other Microsoft systems as well). I will start with a short overview of them.

Authentication selection window during the new application creation

Windows Authentication
This is the native, classic type of authentication in Windows systems. There are several methods of Windows Authentication we should mention here:
· Anonymous Authentication: this method allows external and unauthorized users to access the resources. No credentials are required in this method. This method is mostly used for Internet-enabled sites in SharePoint for Internet Sites licensing.
· Basic Authentication: It is a basic Windows method of Authentication, which is insecure and I recommend NOT TO use it. The authorization credentials are sent in clear-text, without any encryption which nowadays is extremely easy to snoop by attacker. This type of authentication should only be used in case of compatibility issues (with browsers, web proxies or firewalls) and only with a secure SSL certificate that will encrypt the sensitive network traffic. Sometimes, old software deployed in the enterprise requires using Basic Authentication (like old monitoring software) – if you’ll ever come into similar situation, try to use SSL with Basic Authentication to encrypt the traffic “manually”.
· Digest Authentication: It is a method similar to Basic Authentication, but it gives you more security because the credentials are encrypted and there is no way to intercept the credentials along the way in the traffic route.
· Certificate Authentication: This method offers the public key certificate mapping authorization. SSL encryption is used for this authentication method. It is not recommended to use this type of authentication over internet traffic.
· NTLM Authentication: It is native for most Microsoft applications (including SharePoint) method of authentication, which is secure and encrypts credentials before they are sent in the network. If you want to move your entire network authentication to Kerberos, you will have to disable NTLM because on most systems it is default authentication method.
· Negotiate Authentication: You can use it with either NTLM or Kerberos authentication (with Kerberos as default). On the client side you have to provide SPN (Service Principal Name) and UPN (User Principal Name) for the account.
Forms Based Authentication
This kind of authentication works with the identity management systems. In SharePoint, it will show up as a typical form authentication where you have two fields (login and password) to enter your credentials. This type of authentication is often used by extranet sites. You can get the users credentials to forms from LDAP based containers, SQL Database or custom, external sources of third party software and credential databases. Forms based authentication fully uses ASP .NET role providers.

Basic Forms Based Authentication form in SharePoint application
Now let me give you an overview of Forms-Based authentication types:
· Lightweight Directory Access Protocol (LDAP) – it can be Active Directory, ADAM or ADFS user/security database.
· Database Based (by default SQL) authentication – in this type of authentication you store permissions in a MS SQL database (or other compatible database system – then you have to install the database native client drivers compatible with ASP .NET).
· Custom, Third Party membership / Role Provider – for most external systems you need to register custom membership provider in web.config file of your forms-enabled application. It hasn’t changed much since MOSS 2007.
Forms Based Authentication can only be enabled in Claims-based applications.
SAML Token Based Authentication
It is the authentication known as Claims Based in SharePoint 2010. It supports Windows Identity Foundation and uses .NET framework entities for Claims Based Authentication. SAML Tokens includes Active Directory Federation Services (available in Windows Server 2008 Enterprise), Windows Live ID authentication and most third party providers. SAML token authentication includes an identity provider security token service (IP-STS), which issues SAML tokens for the users and is used for authorization of these users. If you configure your SharePoint application to authenticate using IP-STS, then that application becomes a relying party STS (RP-STS), which can receive SAML tokens.
Implementing SAML token based infrastructure to your SharePoint farm is a difficult task that requires lot of planning. You need to define identity claim for each user (for example e-mail address as user-identifier), define Claim mappings, create authentication providers to import token-signing certificate, specify a realm that is associated with SAML-Token based SharePoint applications, and finally create a SharePoint application configured to use the SAML-Token enabled authentication provider.
SharePoint Application Zones
SharePoint site application zones define the logical paths for accessing the same web applications. Each web application can include up to five zone definitions. By default, when you create a new web application in SharePoint, it uses the zone named “default”. You can add more zones by extending the web application and use the remaining zones called: intranet, extranet, internet or custom.
In the previous SharePoint versions you could use zones to setup Windows Authentication and Forms authentication to one web application. In the SharePoint 2010 you can only create Windows authentication for Classic Mode authentication, so in this mode using multiple zones will give you the possibility to authenticate from up to five different Active Directory stores. In the Claims Mode web applications you can setup multiple authentication methods for different zones, but if you only want to setup Windows Authentication (from one Active Directory store) and one Forms Authentication (for example from SQL Database user store) – you can do this from single web application zone (for example “default” zone) and you don’t need to extend the web application unless you need to use more than one AD store and Forms store.

Active Directory Lightweight Directory Service Part 1

Introduction

many directory services requirements for an organization. However, AD DS also has many dependencies that make its deployment and management a complex task. Because AD DS provides the core authentication and authorization services for most organizations, it can also be very difficult to make changes such as schema changes to the directory. At the same time, many organizations are deploying applications that use an external directory service. These applications may require the directory service to provide authentication services or to store application configuration information.

Although AD DS could be configured to support these applications, this may not be the best solution because of the issues related to incompatible schema change, replication traffic, or the risks of making changes to the infrastructure directory. As an alternative, Windows Server 2008 provides the Active Directory Lightweight Directory Services (AD LDS) server role, which you can use to deploy a Lightweight Directory Access Protocol (LDAP)–compliant directory service to provide support for these directory-enabled applications. AD LDS provides much of the same directory service functionality as AD DS but does not require the deployment of domains or domain controllers. AD LDS provides a much more flexible deployment model; for example, you can run multiple instances of AD LDS concurrently on a single computer, with an independently managed schema for each AD LDS instance. You can also configure AD LDS replication so that the same AD LDS data is distributed across multiple computers.

AD LDS Overview

The Lightweight Directory Service is useful for situations in which applications need access to a directory service, but you do not want to risk compromising your Active Directory database. In this article, you will be introduced to the Lightweight Directory Services, its uses, and capabilities.

When Microsoft introduced the Active Directory with Windows 2000, it didn’t take long before people began to realize that the Active Directory was really little more than a centralized database, and that the Active Directory could be used for purposes for which it was never intended.

For a while, it seemed as though almost every software vendor was designing their wares to be Active Directory integrated. Many such applications stored their configuration information in the Active Directory, and some even whet so far as to actually treat the Active Directory as an alternative to a SQL database and store actual application data in the Active Directory database.

Today, most of the third party software publishers seem to take less invasive approach to the way that they interface with the Active Directory. Many applications read Active Directory data, but not nearly as many applications seem to store data within the Active Directory as did a few years back. Although I can only speculate on the reasons for this, I suspect that it has something to do with the fact that the Active Directory has become a critical component of the network infrastructure, and many administrators are reluctant to perform unnecessary schema extensions (which are almost always necessary to support applications that store data within the Active Directory).

Even though software publishers may not use the Active Directory to quite the extent that they once did, I think that it is safe to say that the Active Directory can be very useful for supporting various applications. To show you what I mean, consider the fact that Microsoft still designs many of their server applications with a high degree of Active Directory integration. Exchange Server 2007 and Exchange Server 2010 for example, are designed in such a way that all of the server configuration information is stored in the Active Directory, rather than being stored locally on the server. The advantage to doing so is that it makes it possible to regenerate a failed server on the fly.

Suppose for instance that you had a catastrophic hard disk failure on an Exchange 2010 server that was hosting the Hub Transport Server Role. Because of the way that Exchange stores its configuration information in the Active Directory, you wouldn’t even have to restore a backup in order to fix the problem. Instead, you would start out by resetting the Computer account for the failed server within the Active Directory. You would then install Windows and any applicable service packs onto a new server. Next, you would assign that server the same computer name as your failed server had used, and join the new server to the Active Directory. Because you reset the Active Directory computer account, the new server is able to use it.

From there, fixing the problem is as simple as running Exchange Server’s Setup program with a special switch. Setup installs the necessary binaries, and then configures the server according to the configuration information found in the Active Directory. The new server can be up and running in less than an hour, and without ever restoring a backup.

My point is that the Active Directory can be very useful for application support, but that many software publishers are reluctant to use it to the extent that Microsoft does, because of the stigma that’s attached to making Active Directory schema extensions.

Another reason why you don’t see more software publishers storing a lot of data in the Active Directory has to do with Active Directory replication. Generally speaking, any data that is stored in the Active Directory must be replicated to all of the domain controllers in the domain (possibly even all of the domain controllers in the forest). As such, if an application were to store a large volume of data in the Active Directory, that data could impact the speed of the normal replication process – especially if that data changes frequently.

In spite of these challenges, there is a way to reap the benefits of Active Directory integration, without impacting your Active Directory database in the process. Windows Server 2008 and Windows Server 2008 R2 include a service called the Active Directory Lightweight Directory Service, or AD LDS.  A similar service also exists in Windows Server 2003, but goes by the name Active Directory Application Mode (or ADAM).

Conclusion

Now that I have talked about what the AD LDS means and what it is used for, I want to turn my attention to using this service in your own organization. In Part 2, I will begin discussing the hardware and the software requirements for using AD LDS.

In case you are not familiar with AD LDS, it provides you with an environment that is very similar to, but completely separate from, the Active Directory. AD LDS is a standalone service that has no dependency on the Active Directory Directory Service. In fact, it is common to deploy AD LDS in environments in which no Active Directory domains exist.

A perfect example of such a situation is Microsoft Exchange Server. Earlier I said that Exchange Server 2007 and 2010 are both designed to store all of their configuration information in the Active Directory database. There is one big exception to this however.

Exchange Server defines a series of roles that dictate how an Exchange Server is configured, and what tasks the server performs. All but one of the server roles are designed to store the server configuration in the Active Directory.

The server role that does not use the Active Directory is known as the Edge Transport Server Role. The Edge Transport Server is designed to reside at the network perimeter and keep the other Exchange Servers from being directly exposed to the Internet.

Because the Edge Transport Server is exposed to various Internet based threats, making it a member of an Active Directory domain could be a potential security risk. If someone were able to compromise the edge transport server, they may be able to use it to gain information about the Active Directory.

To keep this from happening, the Edge Transport Server cannot be a domain member, and it cannot host any other Exchange Server roles. Even so, the Edge Transport Server does require access to a minimal amount of Active Directory information so that it can do its job. Rather than provide the server with direct access to the Active Directory, Microsoft has designed the Edge Transport Server role to use AD LDS.

One of the backend Exchange Servers reads the required information from the Active Directory, and sends the information to the AD LDS partition on the Edge Transport Server. That way, the Edge Transport Server has access to the information that it needs, without being able to access the Active Directory. Incidentally, the Edge Transport Server also stores its own configuration information in the AD LDS partition, just as other Exchange Server roles store configuration information in the Active Directory.

Understanding AD Design Concepts for Exchange Server 2010

After all objectives, dependencies, and requirements have been mapped out, the process of designing the Exchange Server 2010 environment can begin. Decisions should be made in the following key areas:

. AD design

. Exchange server placement

. Global catalog placement

. Client access methods

Understanding the AD Forest

Because Exchange Server 2010 relies on the Windows Server 2008 AD for its directory, it is therefore important to include AD in the design plans. In many situations, an AD implementation, whether based on Windows Server 2003, or Windows Server 2008, AD already exists in the organization. In these cases, it is necessary only to plan for the inclusion of Exchange Server into the forest.

If an AD structure is not already in place, a new AD forest must be established. Designing the AD forest infrastructure can be complex, and can require nearly as much thought into design as the actual Exchange Server configuration itself. Therefore, it is important to fully understand the concepts behind AD before beginning an Exchange Server 2010 design.

In short, a single “instance” of AD consists of a single AD forest. A forest is composed of AD trees, which are contiguous domain namespaces in the forest. Each tree is composed of one or more domains.

The simplest designs often work the best. The same principle applies to AD design. The designer should start with the assumption that a simple forest and domain structure will work for the environment. However, when factors create constraints, multiple forests can be established to satisfy the requirements of the constraints.

Determining Exchange Server 2010 Placement

Previous versions of Exchange Server essentially forced many organizations into deploying servers in sites with greater than a dozen or so users. With the concept of site consolidation in Exchange Server 2010, however, smaller numbers of Exchange servers can service clients in multiple locations, even if they are separated by slow WAN links. For small and medium-sized organizations, this essentially means that a small handful of servers is required, depending on availability needs. Larger organizations require a larger number of Exchange servers, depending on the number of sites and users. In addition, Exchange Server 2010 introduces new server role concepts, which should be understood so that the right server can be deployed in the right location.

Understanding Exchange Server 2010 Server Roles

Exchange Server 2010 firmed up the server role concept outlined with Exchange Server 2007. Before Exchange Server 2007/2010, server functionality was loosely termed, such as referring to an Exchange server as an OWA or front-end server, bridgehead server, or a mailbox or back-end server. In reality, there was no set terminology that was used for  Exchange server roles. Exchange Server 2010, on the other hand, distinctly defines specific roles that a server can hold. Multiple roles can reside on a single server, or multiple servers can have the same role. By standardizing on these roles, it becomes easier to design an Exchange Server environment by designating specific roles for servers in specific locations.

Client access server (CAS)

The CAS role allows for client connections via nonstandard methods such as Outlook Web App (OWA), Exchange  ActiveSync, Post Office Protocol 3 (POP3), and Internet Message Access Protocol (IMAP). Exchange Server 2010 also forces MAPI traffic and effectively all client traffic through the CAS layer. CAS servers are the replacement for Exchange 2000/2003 front-end servers and can be load balanced for redundancy purposes. As with the other server roles, the  CAS role can coexist with other roles for smaller organizations with a single server, for example.

Edge Transport server

The Edge Transport server role was introduced with Exchange Server 2007, and consists of a standalone server that typically resides in the demilitarized zone (DMZ) of a firewall. This server filters inbound SMTP mail traffic from the Internet for viruses and spam, and then forwards it to internal Hub Transport servers. Edge Transport servers keep a local AD Application Mode (ADAM) instance that is synchronized with the internal AD structure via a mechanism called  EdgeSync. This helps to reduce the surface attack area of Exchange Server. The Edge Transport role can only exist by itself on a server, it cannot be combined with other roles.

Hub Transport server

The Hub Transport server role acts as a mail bridgehead for mail sent between servers in one AD site and mail sent to other AD sites. There needs to be at least one Hub Transport server within an AD site that contains a server with the mailbox role, but there can also be multiple Hub Transport servers to provide for redundancy and load balancing. HT roles are also responsible for message compliance and rules. The HT role can be combined with other roles on a server, and is often combined with the CAS role.

Mailbox server

The mailbox server role is intuitive; it acts as the storehouse for mail data in users’ mailboxes and down-level public folders if required. All connections to the mailbox servers are proxied through the CAS servers.

. Unified Messaging server

The Unified Messaging server role allows a user’s Inbox to be used for voice messaging and fax capabilities.

Any or all of these roles can be installed on a single server or on multiple servers. For smaller organizations, a single server holding all Exchange Server roles is sufficient. For larger organizations, a more complex configuration might be required.

In some cases with very small organizations, the number of users is small enough to warrant the installation of all AD and Exchange Server 2010 components on a single server. This scenario is possible, as long as all necessary components—DNS, a global catalog domain controller, and Exchange Server 2010—are installed on the same hardware.

In general, however, it is best to separate AD and Exchange Server onto separate hardware wherever possible.

Active Directory Lightweight Directory Service

Introduction

The Lightweight Directory Service is useful for situations in which applications need access to a directory service, but you do not want to risk compromising your Active Directory database. In this article, you will be introduced to the Lightweight Directory Services, its uses, and capabilities.

When Microsoft introduced the Active Directory with Windows 2000, it didn’t take long before people began to realize that the Active Directory was really little more than a centralized database, and that the Active Directory could be used for purposes for which it was never intended.

For a while, it seemed as though almost every software vendor was designing their wares to be Active Directory integrated. Many such applications stored their configuration information in the Active Directory, and some even whet so far as to actually treat the Active Directory as an alternative to a SQL database and store actual application data in the Active Directory database.

Today, most of the third party software publishers seem to take less invasive approach to the way that they interface with the Active Directory. Many applications read Active Directory data, but not nearly as many applications seem to store data within the Active Directory as did a few years back. Although I can only speculate on the reasons for this, I suspect that it has something to do with the fact that the Active Directory has become a critical component of the network infrastructure, and many administrators are reluctant to perform unnecessary schema extensions (which are almost always necessary to support applications that store data within the Active Directory).

Even though software publishers may not use the Active Directory to quite the extent that they once did, I think that it is safe to say that the Active Directory can be very useful for supporting various applications. To show you what I mean, consider the fact that Microsoft still designs many of their server applications with a high degree of Active Directory integration. Exchange Server 2007 and Exchange Server 2010 for example, are designed in such a way that all of the server configuration information is stored in the Active Directory, rather than being stored locally on the server. The advantage to doing so is that it makes it possible to regenerate a failed server on the fly.

Suppose for instance that you had a catastrophic hard disk failure on an Exchange 2010 server that was hosting the Hub Transport Server Role. Because of the way that Exchange stores its configuration information in the Active Directory, you wouldn’t even have to restore a backup in order to fix the problem. Instead, you would start out by resetting the Computer account for the failed server within the Active Directory. You would then install Windows and any applicable service packs onto a new server. Next, you would assign that server the same computer name as your failed server had used, and join the new server to the Active Directory. Because you reset the Active Directory computer account, the new server is able to use it.

From there, fixing the problem is as simple as running Exchange Server’s Setup program with a special switch. Setup installs the necessary binaries, and then configures the server according to the configuration information found in the Active Directory. The new server can be up and running in less than an hour, and without ever restoring a backup.

My point is that the Active Directory can be very useful for application support, but that many software publishers are reluctant to use it to the extent that Microsoft does, because of the stigma that’s attached to making Active Directory schema extensions.

Another reason why you don’t see more software publishers storing a lot of data in the Active Directory has to do with Active Directory replication. Generally speaking, any data that is stored in the Active Directory must be replicated to all of the domain controllers in the domain (possibly even all of the domain controllers in the forest). As such, if an application were to store a large volume of data in the Active Directory, that data could impact the speed of the normal replication process – especially if that data changes frequently.

In spite of these challenges, there is a way to reap the benefits of Active Directory integration, without impacting your Active Directory database in the process. Windows Server 2008 and Windows Server 2008 R2 include a service called the Active Directory Lightweight Directory Service, or AD LDS.  A similar service also exists in Windows Server 2003, but goes by the name Active Directory Application Mode (or ADAM).

In case you are not familiar with AD LDS, it provides you with an environment that is very similar to, but completely separate from, the Active Directory. AD LDS is a standalone service that has no dependency on the Active Directory Directory Service. In fact, it is common to deploy AD LDS in environments in which no Active Directory domains exist.

A perfect example of such a situation is Microsoft Exchange Server. Earlier I said that Exchange Server 2007 and 2010 are both designed to store all of their configuration information in the Active Directory database. There is one big exception to this however.

Exchange Server defines a series of roles that dictate how an Exchange Server is configured, and what tasks the server performs. All but one of the server roles are designed to store the server configuration in the Active Directory.

The server role that does not use the Active Directory is known as the Edge Transport Server Role. The Edge Transport Server is designed to reside at the network perimeter and keep the other Exchange Servers from being directly exposed to the Internet.

Because the Edge Transport Server is exposed to various Internet based threats, making it a member of an Active Directory domain could be a potential security risk. If someone were able to compromise the edge transport server, they may be able to use it to gain information about the Active Directory.

To keep this from happening, the Edge Transport Server cannot be a domain member, and it cannot host any other Exchange Server roles. Even so, the Edge Transport Server does require access to a minimal amount of Active Directory information so that it can do its job. Rather than provide the server with direct access to the Active Directory, Microsoft has designed the Edge Transport Server role to use AD LDS.

One of the backend Exchange Servers reads the required information from the Active Directory, and sends the information to the AD LDS partition on the Edge Transport Server. That way, the Edge Transport Server has access to the information that it needs, without being able to access the Active Directory. Incidentally, the Edge Transport Server also stores its own configuration information in the AD LDS partition, just as other Exchange Server roles store configuration information in the Active Directory.

Now that I have talked about what the AD LDS is and what it is used for, I want to turn my attention to using this service in your own organization. In Part 2, I will begin discussing the hardware and the software requirements for using AD LDS.

The Planning Process

Planning for the deployment of AD LDS can actually be something of a trial and error experience because Microsoft really doesn’t give you a lot to go on. If you look at Microsoft’s AD LDS Overview on TechNet, you can see that the Hardware and Software Considerations section consists of a block of text telling you to “Use performance counters, testing in the lab, data from existing hardware in a production environment, and pilot roll outs to determine the capacity needs of your server.”

So what is Microsoft really saying here? Well, I think that the statement in the paragraph above can best be summarized like this:

In order to deploy AD LDS, one needs only to have a server that is capable of running Windows Server 2008. However, depending on how AD LDS is being used the server may have to support a considerable workload. It is therefore necessary to take measures to ensure that your server hardware is up to the job.

If this statement is true, then the most logical approach to AD LDS planning is to take a look at the types of resources AD LDS consumes, and base any capacity planning efforts on those types of resource consumption.

Being that Microsoft doesn’t seem to provide a lot of clear guidelines for AD LDS capacity planning, I tend to think that one of the best approaches is to treat the capacity planning process similarly to the capacity planning process that you would use for domain controllers. After all, an AD LDS server is very similar to a domain controller. Both AD LDS servers and domain controllers host nearly identical directory services. Of course there are differences that you have to keep in mind. Active Directory capacity planning usually takes the number of users into account, while AD LDS capacity planning is usually more about anticipating the number of LDAP requests that will be made against the server. However, both Active Directory and AD LDS capacity planning often require you to plan for things like topology and replication.

The Differences between Domain Controllers and AD LDS Servers

Of course even though domain controllers and AD LDS servers are very similar at the architectural level, the simple fact that domain controllers are used to authenticate logins and implement Windows security policies means that there are some aspects of domain controller planning that simply will not apply to the planning process for AD LDS.

One such difference is that AD LDS does not use the concept of forests like the Windows Active Directory does. In an Active Directory environment, a forest is a collection of domains. Every forest is completely independent, although forests can be joined together through the use of federated trusts.

AD LDS does not use the concept of forests and domains like Windows domain controllers do. Instead, the primary structural element used by AD LDS is that of a service instance (which Microsoft often refers to as an instance).  An instance refers to a single AD LDS partition. Each instance has its own individual service name, directory data store, and service description.

As I’m sure you probably already know, a Windows domain controller can only service a single domain. In contrast, a single server running AD LDS can host multiple instances. This means that a single AD LDS server can contain multiple directories.

Of course this raises an interesting question. In an Active Directory environment, clients communicate with domain controllers using the Lightweight Directory Access Protocol (LDAP). Like most other protocols, LDAP is designed to use specific port numbers. For example, LDAP typically uses port 389 for directory queries. If LDAP communications need to be encrypted then port 636 is uses instead. Domain controllers that are functioning as global catalog servers use ports 3268 and 3269 for global catalog related functions. With all of this in mind, you may be wondering which ports AD LDS uses.

Well, AD LDS does not have to worry about performing any global catalog functions, so we can rule out the use of ports 3268 and 3269 right off the bat. AD LDS does however make use of ports 389 and 636 in exactly the same way that a domain controller would.

So what happens if a server is hosting multiple AD LDS instances? Typically, the first instance to be created would be assigned to use ports 389 and 636. When the second instance is created, Windows sees that these ports are in use, and begins scanning for unused ports beginning with port 50,000. Assuming that port 50,000 is available it will be used for standard LDAP communications with the second AD LDS instance. Port 50,001 will be used for SSL encrypted LDAP communications with the second AD LDS instance.

If you were to create a third AD LDS instance on the server, then Windows would see that ports 389 and 636 were in use, so it would begin looking for unused ports starting with 50,000. Since ports 50,000 and 50,001 have already been assigned, the third LDAP partition will be assigned to ports 50,002 and 50,003.

DNS Requirements

Another difference between the Active Directory and AD LDS is that the Active Directory is totally dependent on DNS servers. Without DNS, the Active Directory cannot function. AD LDS on the other hand does not require DNS.

In some ways this makes sense. The Active Directory uses DNS as a mechanism for maintaining the domain hierarchy. There is no domain hierarchy associated with AD LDS, so DNS is unnecessary.

Installing the Active Directory Lightweight Directory Service

Installing AD LDS is actually a very simple process. To do so, open the Server Manager, and then click on the Add Roles link. When you do, Windows will launch the Add Roles Wizard. Click Next to bypass the wizard’s welcome screen and you will be taken to a screen that displays all of the available server roles.

Select the Active Directory Lightweight Directory Services check box, as shown in Figure A.

Figure A: Active Directory Lightweight Directory Service.

Click Next, and you will see an introductory screen that explains what the AD LDS is and what it does. Click Next and Windows will display a confirmation message indicating that the AD LDS server role is about to be installed. Click theInstall button to begin the installation process.

The entire installation process usually only takes about 30 seconds to complete. After the server role finishes installing, click the Close button to complete the installation process. Unlike some of the Windows 2008 server roles, installing the AD LDS role does not require you to reboot the server.

Conclusion

In this article, I have explained some of the differences between the Active Directory and AD LDS. In Part 3 of this series, I will begin showing you the basics of working with AD LDS.