Scenario 2: Multiple Domains in the Same/Different Forests

Description of the Environment

For this scenario, visualize an enterprise with multiple sites worldwide, as shown in the following image:

 

Assumptions

  • Each site has its own Active Directory domain.
  • All domains are separate domains in the same or different forests.
  • There is an AAA Server on each site.

Goals

The goal is to fully manage all users and devices from a single AAA Server Administration Console. This means that operators using the Administration Console should be able to:

  • Assign a device to any user in any of the Active Directory domains or forests.
  • Handle help desk tasks for any user in any of the Active Directory domains or forests.

In this scenario, we do not connect to the Active Directory through the global catalog. An Active Directory infrastructure natively enables access to data from different domains through the global catalog. A global catalog:

  • Is a domain controller that stores a copy of all Active Directory objects in a forest.
  • Stores a full copy of all objects in the directory for its host domain and a partial copy of all objects for all other domains in the forest.

The partial copies of all domain objects included in the global catalog are those most commonly used in user search operations. Storing the most commonly searched upon attributes of all domain objects in the global catalog provides users with efficient searches without affecting network performance with unnecessary referrals to domain controllers.

See the Microsoft website for further information.

As shown in the following image, the global catalog can be used to read and write data on domainA, but it can be used only for read operations on domainB, domainC, and domainD. The assignment of a device to a user who is member of domainB, domainC, or domainD cannot be handled through the global catalog.

 

In this scenario, in order for any Administration Console to assign a device to any user, the AAA Server must use LDAP (port:389) or LDAPS (port:636). Therefore, do not connect the AAA Server to the Active Directory through the global catalog (ports 3268 or 3269).

In the following sections, each of the Administration Consoles connect to the forest root domain through LDAP and each AAA Server is configured to connect to its local domain controller.

AAA Server Configuration

See the Installing the AAA Server for Remote Access for information concerning the installation and standard configuration of the AAA Server. This section only describes the only the configuration parameters related to the integration with Active Directory.

We describe the configuration of the AAA Server for the following two sites:

  • Site A:

    • Active Directory Domain: domainA
    • First domain created in the forest the AAA Server: APSRVA

  • Site B:

    • Active Directory Domain: domainB
    • AAA Server: APSRVB

  • Both sites:

    The AAA Server Administration Console registry DWORD key HKEY_LOCAL_MACHINE/SOFTWARE/ActivCard/ActivPack/ActivPackAdmin/LDAPReferralDomainOrForestMode must be set to 1.

    Note: If the key does not exist in the registry, you must create it manually.

The following image shows the LDAP options for this scenario:

 

LDAP Settings

The AAA Server is configured to connect to domainA through LDAP:

  • Both servers (APSRVA and APSRVB) must be created in the server tree of the Administration Console.
  • APSRVA inherits the default LDAP options that have been previously defined, as shown in the following image:

    •  

APSRVB must use specific LDAP settings to connect to domainB. The following image shows the necessary LDAP configuration of APSRVB:

 

For performance reasons, AAA Server B connects to its local LDAP server.

LDAP Queries

As shown in the following image, you can create a Global LDAP query to retrieve users from both domainA and domainB. You can also create queries to retrieve users from multiple forests.

 

You can use the Test button to verify that this query correctly retrieves users from both domains, as shown in the following image:

 

Using only the query that has been configured previously, it is now possible to assign devices to the displayed users. The outcome is shown in the following image:

 

How this Works

The first domain created in Active Directory represents the root domain of the entire forest. It contains information related to the configuration and the schema of the forest. Domain trees in a forest share a common configuration, a common schema and a global catalog. These characteristics, in conjunction with trust relationships, distinguish a forest from unconnected trees.

Transitive, bi-directional trust relationships are natively established between the forest root domain and the other root domains of the other domain trees that are subsequently created in the forest.

Due to the transitivity of the trust relationships that is in place between domains, the authentication mechanism of a domain can also be used for the authentication to any of the other trusted domains. Please refer to the Microsoft website for further information.

When a requested object exists in the directory but is not present on the contacted domain controller, name resolution depends on that domain controller's knowledge of how the directory is partitioned. In a partitioned directory, by definition, the entire directory is not always available on any one domain controller.

An LDAP referral is a domain controller's way of indicating to a client application that it does not have a copy of a requested object (or, more precisely, that it does not hold the section of the directory tree where that object would be, if in fact it exists). The domain controller gives the client a location that is more likely to hold the object, which the client uses as the basis for a DNS search for a domain controller. Ideally, referrals always reference a domain controller that indeed holds the object.

However, it is possible for the referred-to domain controller to generate yet another referral, although it usually does not take long to discover that the object does not exist and to inform the client. Active Directory returns referrals in accordance with RFC 2251.

In its Configuration container, every domain controller has information about the other domains in the forest. When an operation in Active Directory requires action on objects that might exist in the forest but are not located in the particular domain that is stored on a domain controller, that domain controller must send the client a message that describes where to go to continue this action. That is, the client is "referred" to a domain controller that is presumed to hold the requested object.

Roaming is Supported in a Multi-Domain Environment

The above configuration natively enables such a roaming support for challenge/response authentication. It is necessary only to ensure that all relevant user groups are added to all necessary gates on the different servers, as shown in the following image:

 

If GroupA refers to the members of domainA, this configuration allows the users from domainA to successfully authenticate with challenge/response from the AAA Server located on Site B, with the authentication being directly validated by APSRVB.

With synchronous authentication, the keys and counters needed to validate the password are modified after each successful authentication attempt. In order to avoid a situation in which all authentication servers are synchronized and have all authentication data for all users, only a reference is necessary for a given user (or, more precisely, the authentication device that has been assigned to that user). A user is defined on only one server and referenced on the other ones. In this example, APSRVB must contact APSRVA in order to validate the password sent by the user.

In the following image, the yellow key is present only for APSRVA. This demonstrates that only the keys and counters required to validate the passwords of the members of GroupA are present on APSRVA.

 

Limitation with the Scenario

The creation of groups cannot be fully based on Active Directory as the AAA Server LDAP options map only to a single organizational unit for the configuration of LDAP groups. To resolve this limitation, you can create groups based on attribute checking.