Active Directory Notes

“Active Directory is capable of holding a billion objects—enough to hold account, computer, mailboxes and group memberships for every person in the western hemisphere.” However, a directory information tree for merely 150,000 objects could exceed 2 gigabytes.

These notes are primitive, but one must start somewhere. These are gathered here for convenience instead of being spread throughout the other notes I keep on work topics.

I ripped a lot of this stuff off from some Addison-Wesley pages (meaning, I drew my notes from them) which proved to be some pretty useful reading. Kudos to Addison-Wesley for putting up on the web. See links at bottom of this page.

This document tries, but not very hard or successfully, to differentiate strictly between what is Active Directory, LDAP or X.500. There are some references to Novell’s eDirectory product where useful and accurate. There was going to be an AD-eDir/eDir-AD lexicon, but it quickly became absurd and useless to try. Instead, here is an Active Directory lexicon.

Lexicon...

Term	Definition
attribute	also referred to as a property.

class	Contains information about specific types of objects including users, computers and services. A class is a bundle of attributes with a name. All LDAP classes derive from a class called top. Directory service designers strive to limit complexity by defining the maximum number of classes and attributes necessary to describe the objects of interest that need to be stored in the database. There are cetain attributes that every class has in common with all other classes, for example, the common-name. Top is an abstract class. There are three types of classes in LDAP: Abstract classes exists solely from which to derive other object classes including top device, person and security object. Structural classes have objects in Active Directory including user, group and computer. Auxiliary are used to extend the scheme of an abstract class; these include mail-recipient, dynamic-object, MS-MMS object, sam-domain, sam-domain-base and security-principal. These three class types act like assembly line robots designed to produce objects. The structural classes are the tools and dies that stamp and shape the objects. The abstract classes are the mill workers and pattern makers that build the tools and dies. The auxiliary classes act like a custom shop at the end of the line where special versions of standard objects are turned out.

COM	Component Object Model; Microsoft COM technolog in Windows enables software components to communicate. COM is used by developers to create reusable software components, link components together to build applications and take advantage of Windows services. The family of COM technologies includes COM+, distributed COM (DCOM) and ActiveX Controls.

directory information base (DIB)	in X.500, the information is stored in a directory information base.

directory information tree (DIT)	in X.500, the DIB is divided into hierarchically structured pieces called a directory information tree. These pieces may be distributed across more than one server.

directory service agent (DSA)	in both LDAP and X.500, the server(s) that host(s) copies of the information base.

distinguished name (DN)	in LDAP, a distinguished name includes an object’s entire path to the root of its namespace, e.g.: `cn=csantana,cn=guitarists,dc=guitarists,dc=com`. All DNs must be unique.

domain	In Active Directory, a domain defines a separate namespace, security and management structures and naming context.

domain component (DC)	represents the top of an LDAP tree that uses DNS to define its namespace. Active Directory chose this scheme making under influence of those designers that had the Internet in mind (`dc=Vintela,dc=com`).

fully-qualified distringuished name (FQDN)	also, fully distinguished name (FDN), in LDAP, a distinguished name includes an object’s entire path to the root of the directory tree, e.g.: `cn=csantana.ou=guitarists.o=guitarists.com`.

naming context (NC)	what Novell calls a partition, separate pieces of the DIB. When a client submits a query for information about an object, the system must determine which DSA hosts the naming context containing the object in question. If a DSA cannot respond to a query using its information, it sends the client a referral to another DSA higher or lower in the tree (depending on the distinguished name) that might have the information. LDAP is like Walmart to X.500’s (and Novell’s) Nordstrom’s in that it places the burden of searching on the client—giving referrals instead of going and getting the information.

organizational unit (OU)	acts as a container that holds other objects providing structure to the LDAP namespace. In Active Directory, OU is the only general-purpose container; in eDirectory, there also exists O (organization), but that is really equivalent to DC. eDirectory was designed long before the Internet became a driving force (`ou=Engineering.o=Novell`).

relative distringuished name (RDN)	in LDAP, the path to the object relative to another, e.g.: `cn=csantana,cn=guitarists`.

RootDSE	a sort of “rural signpost” maintained separately by each DSA to give useful information about the service. It can describe the content, controls and security requirements of the service. Clients use it to select an authentication method and formulate search requests.

LDAP representation...

An object is represented thus (in Java pseudo code)...

	public class LdapObject
	{
	   String  cn;                   // common name
	   String  sn;                   // surname (family name if user)
	   String  name;                 // (not guaranteed to be used)
	   String  givenName;            // (neither surname nor middle name)
	   String  initials;             // initials of names
	   String  distinguishedName;

	   String  description;          // human-readable description of object

	   String  o;                    // organization name
	   String  ou;                   // organizational unit name
	   String  title;                // organizational title

	   String  userPassword;         // (if user)
	   String  userCertificate;      // (if user)

	   Value   x500UniqueIdentifier; // to distinguish between objects with identical names
	   String  c;                    // two-letter country code
	   String  st;                   // state or province
	   String  street;               // street address
	   ---- other postal crap ----

	   String aliasedObjectName;     // used if entry/object is an alias
	}

Poop I need to work through...

Mostly fragments of a conversation about a new feature I need to add to the vasjoin.sh script. This stuff will be added elsewhere in this document, into a spec or simply deleted.

Starting in VAS 3.1, upm-search-path will no longer be stored in /etc/opt/quest/vas/vas.conf, but in the miscellaneous VAS cache (/var/opt/quest/vas/vasd/vas_misc.vdb).

An OU attribute has a cn property.

The name of an OU is stored in the ou attribute on the ou object. In most cases when you create an OU in windows Active Directory Users and Computers (ADUC), it doesn’t populate the cn attribute of the OU object. We rely on this value being set (as it is indexed).

What is the difference between display name and common name?

Display name is not the same as common name, though it may hold the same value.

It all depends upon how the directory uses things.

Common name, technically could be a multivalues attribute, however in AD Microsoft opted not to do this. The display name isn’t used on organizational unit objects but could be in other directory services.

If you look, most objects have a cn, name, displayname, and possibly other naming-type attributes. What is important is where and how each one is used. Typically, name is not indexed, but cn and possibly displayName are.

displayNames are usually composed of the cn plus the container object’s displayName, and the relative distinguished is usually just the cn.

To answer your question directly, yes you can search for an object by any attribute you want as long as you know it’s value. There are many attributes that have the same value on an object. The difference between a search and a good search, however, is whether or not the filter attributes are indexed.

Potentially, there are three names on every object: name, cn or common name and dn or display name.

Active Directory eading...

Trying to get through this, but don’t have quite time to get it all, so in the immortal words of the Terminator: I’ll be back...

VAS Join Browser

The shell script...

	#!/bin/sh
	VASTOOL=/opt/quest/bin/vastool

	# Usually these will be read from the user or sources from an answers file...
	user=administrator
	password=Test1234
	#FDN=A-DEV-DC01.A.DEV # FDN of domain controller (for a.dev)
	FDN=H-DC01.H.DEV      # FDN of domain controller (for h.dev)

	search()
	{
	  # These searches are ONLY for containers or organizational units...
	  # Use vastool search to look up, in $FDN (-h), the object attributes (-s
	  # one), an object whose class is either container or organizational unit...
	  if [ -z ${base_OU} ]; then
	    $VASTOOL -u $user -w $password -s search -h $FDN -s one\
	    "(|(objectclass=container)(objectclass=organizationalunit))" dn 2>/dev/null\
	    | sort -u | sed "s/dn: //g"
	    echo "Select the current OU"
	  else
	    echo ".."
	    $VASTOOL -u $user -w $password -s search -h $FDN -s one -b "$base_OU"\
	    "(|(objectclass=container)(objectclass=organizationalunit))" dn 2>/dev/null\
	    | sort -u | sed "s/dn: //g"
	    echo "Select the current OU"
	  fi
	}

	echo "   User:     $user"
	echo "   Password: $password"
	echo "   FDN:      $FDN"

	old_IFS=$IFS
	IFS='
	'

	while [ -z ${BASE} ]; do
	  select answer in `search`; do
	    echo "Answer: $answer"

	    if [ $answer = \.\. ]; then
	      base_OU=`echo $base_OU | cut -d, -f2-`
	      echo "Current working OU is $base_OU"
	      break
	    elif [ $answer = "Select the current OU" ]; then
	      BASE=$base_OU
	      break
	    else
	      base_OU=$answer
	      echo "Current working OU is $base_OU"
	      break
	    fi
	  done
	done

	IFS=$old_IFS
	$ECHO "The \$BASE var is set to $BASE"

Learning vastool search...

The filter strings are from RFC 2254 (The String Representation of LDAP Search Filters).

	russ@taliesin:~> vastool -u administrator -w Test1234 -s search -h H-DC01.H.DEV \
	-s one "(|(objectclass=container)(objectclass=organizationalunit))" dn
	dn: CN=Computers,DC=h,DC=dev

	dn: OU=Domain Controllers,DC=h,DC=dev

	dn: CN=ForeignSecurityPrincipals,DC=h,DC=dev

	dn: OU=Groups - Bulk,DC=h,DC=dev

	dn: CN=Program Data,DC=h,DC=dev

	dn: CN=System,DC=h,DC=dev

	dn: OU=Unix Container,DC=h,DC=dev

	dn: CN=Users,DC=h,DC=dev

	dn: OU=Users - Bulk,DC=h,DC=dev

...add the sort -u here to rid us of blank lines:

	russ@taliesin:~> vastool -u administrator -w Test1234 -s search -h H-DC01.H.DEV \
	-s one "(|(objectclass=container)(objectclass=organizationalunit))" dn | sort -u
	dn: CN=Computers,DC=h,DC=dev
	dn: CN=ForeignSecurityPrincipals,DC=h,DC=dev
	dn: CN=Program Data,DC=h,DC=dev
	dn: CN=System,DC=h,DC=dev
	dn: CN=Users,DC=h,DC=dev
	dn: OU=Domain Controllers,DC=h,DC=dev
	dn: OU=Groups - Bulk,DC=h,DC=dev
	dn: OU=Unix Container,DC=h,DC=dev
	dn: OU=Users - Bulk,DC=h,DC=dev

...and, finally, use sed to get rid of “dn: ”:

	russ@taliesin:~> vastool -u administrator -w Test1234 -s search -h H-DC01.H.DEV \
	-s one "(|(objectclass=container)(objectclass=organizationalunit))" dn | sort -u | sed "s/dn: //g"

	CN=Computers,DC=h,DC=dev
	CN=ForeignSecurityPrincipals,DC=h,DC=dev
	CN=Program Data,DC=h,DC=dev
	CN=System,DC=h,DC=dev
	CN=Users,DC=h,DC=dev
	OU=Domain Controllers,DC=h,DC=dev
	OU=Groups - Bulk,DC=h,DC=dev
	OU=Unix Container,DC=h,DC=dev
	OU=Users - Bulk,DC=h,DC=dev