Managing Domain Services for Windows domain boundary

Domain Services for Windows (DSfW) is a product suite bundled with Open Enterprise Server (OES) starting from OES2 SP1 release. Till OES2 SP2 release, the DSfW domain boundary is restricted to a single eDirectory partition. This eDirectory partition is the one that the domain is mapped to. For ex: if domain is mapped to eDirectory partition ou=acme,o=acme_root, then the domain covers only the objects (users, groups, containers) of this single partition alone.

Before we get into the DSfW domain boundary enhancement, let's take a look at the mapping of a DSfW domain. Unlike in the Active Directory model, where the domain namespace and the LDAP namespace always overlap i.e. is mapped to dc=acme,dc=com, it is different with DSfW. This difference brings in a lot of flexibility in DSfW. Thus a domain namespace can be mapped to any eDirectory namespace (given that the conditions are met). One of the conditions is that the mapping of a child domain is always below and within the subtree of the parent domain mapping. For Ex: if is mapped to ou=acme,o=acme_root, then child domain should be mapped to some partition that lies below ou=acme,o=acme_root i.e. ou=…,ou=…,ou=acme,o=acme_root.

By now it is obvious that a DSfW domain is mapped to an eDirectory partition. For a non-name mapped kind of installation, this mapping is implicit. However, for this discussion, the non-name mapped kind can be ignored.

Starting from OES2 SP3, a DSfW domain can be extended beyond the mapped eDirectory partition. What this means is a single DSfW domain can cover more than one eDirectory partition. These additional partitions that a DSfW domain can cover should be continuous, hierarchical and under the subtree of the mapped eDirectory partition. The list of eDirectory partitions covered under a DSfW domain can change reflecting the current needs of an enterprise.

In the above diagram, till OES2 SP2 release, a DSfW domain can cover just one partition. Hence there are 3 domains to cover the 3 partitions of the subtree. With OES2 SP3, it is possible to cover the whole subtree with 3 partitions in a single DSfW domain.

The ability to cover all of the subtree in a single DSfW domain provides a lot of benefits. A few mentioned below are

    • Reduced number of domains


    • Reduced Administration – only one domain to manage


    • Reduced complexity

    Reduced Hardware

DSfW domain boundary management

We looked at the details and benefits of the DSfW domain boundary enhancement. In this section, let's take a look at how to manage the DSfW domain boundary.

The DSfW domain boundary can be managed using the command line tool – domaincntrl. This tool is located at /opt/novell/xad/sbin/domaincntrl.

This tool has 3 basic operations

    • add – adds a new eDirectory partition to the DSfW domain


    • remove – removes an existing eDirectory partition from the DSfW domain

    list – lists the current set of eDirectory partition of a DSfW domain

Let's run through an example, to get an understanding of the domaincntrl tool

bfrd:~ # domaincntrl

Usage: domaincntrl [--list|--add|--remove|--samify|--desamify|--preps] [-a|-d|-o|-F]

The above command lists the usage

bfrd:~ # domaincntrl --list

Failed to get the handle, probably the kerberos ticket is not available, Local error

The above command fails as the Kerberos ticket cache is empty as shown in the below command

bfrd:~ # klist

klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)

Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached

Get the kerberos ticket for the domain administrator
bfrd:~ # kinit administrator
Password for administrator@TWOW.EDC:

bfrd:~ # domaincntrl --list

The partitions that are part of the domain twow.edc are:

The command now lists the current eDirectory partition set. It contains only the mapped eDirectory partition.

bfrd:~ # domaincntrl --add

Select one of the partition to add it to the domain name space.

[1] ou=bldg1,dc=twow,dc=edc

Enter 'q' to escape the operation.
Choose the partition:1
Validating the partition for addition.
Verifying if ou=bldg1,dc=twow,dc=edc is a partition.
Verifying if ou=bldg1,dc=twow,dc=edc is under domain root partition.
Verifying if ou=bldg1,dc=twow,dc=edc is part of any other domain.
Verifying that all the domain controllers of twow.edc hold the replica of the partition ou=bldg1,dc=twow,dc=edc.
Verifying if addition of this partition ou=bldg1,dc=twow,dc=edc will introduce gaps in the domain name space.
Verifying if dc=twow,dc=edc is a partition.
Verifying if dc=twow,dc=edc is already a domain partition.
The selected partition dc=twow,dc=edc is a domain partition
Waiting for domain boundary change information to sync
Successfully extended the domain partition boundary with ou=bldg1,dc=twow,dc=edc
Verifying if the partition ou=bldg1,dc=twow,dc=edc is associated with a password policy.
Samifying the partition ou=bldg1,dc=twow,dc=edc

The 'domaincntrl –add' lists the list of eDirectory partitions that can be added to the DSfW domain. The list here has one entry. On selecting the eDirectory partition, after a set of validations, the eDirectory partition is added to the DSfW domain which is reflecting in the below command.

bfrd:~ # domaincntrl --list

The partitions that are part of the domain twow.edc are:


How To-Best Practice
Comment List
Related Discussions