FYI (this is an excerpt from an article we wrote last year):
We encountered a number of difficulties in adding the RFC 2307 schema to
Active Directory. Schema updating is disabled by default, and has to be enabled
by removing a special ‘schema interlock’. Active Directory’s
usefulness when deploying the RFC 2307 is limited by some fundamental design
attributes of the directory.
- The device object class, which is defined in RFC 2256 as structural, is
defined as abstract in Active Directory. This class is recommended in RFC 2307
as forming the structural class for the ipHost, bootableDevice, and
ieee802Device auxiliary devices. We worked around this by adding a new
concrete subclass, structuralDevice, which allowed ipHost, bootableDevice, and
ieee802Device as auxiliary classes.
- Active Directory doesn’t support multi-valued relative distinguished
names (RDNs) which are created by the TCP/IP services migration script. This
is not a significant issue as containers can be used to unique services’
distinguished names, where services with identical names and different
protocols exist.
- Active Directory marks the commonName (cn) attribute as single-valued, as
are all naming attributes under Active Directory. Many RFC 2307 object classes
represent entities with a canonical name and zero or more aliases by using
multi-valued cn attributes. (The canonical name is determined from the
relative distinguished name, where cn is used to name the entry.) Because of
this limitation, it is difficult to recommend Active Directory as a directory
service for RFC 2307 entities that may be known by multiple names (those other
than netgroups, groups and users).
- Active Directory’s conception of auxiliary classes is essentially
that of an attribute set. As such, auxiliary classes must be associated at
schema definition time with a structural object class, and the auxiliary class
is not listed as a value of the entry’s objectClass attribute. (Section
12.3.2 of X.501 is unclear whether this is the correct behavior.) The latter
means that RFC 2307 implementations that restrict search results on
objectClass (such as ypldapd and nss_ldap) cannot retrieve account data from
Active Directory. This also makes it difficult for a single entry to represent
both a UNIX and an NT user. One can violate the RFC 2307 schema, by making
posixAccount a concrete subclass of User; that mandates every user
having a corresponding NT account, which may not be desirable.
- Adding mandatory attributes (even via an auxiliary class) to an existing
class, such as user, breaks existing UI because the UI doesn’t
accommodate arbitrary attributes. There’s little reason to do so,
however, and one could improve this by developing RFC 2307 property pages, so
that the Management Console may be used to manage RFC 2307 entities.
- In order to workaround these issues whilst leveraging Active
Directory’s management tools, it would be useful to junction external
LDAP directories into the Active Directory namespace. (For example, users with
both NT and UNIX accounts could be stored in Active Directory, and UNIX-only
users in Netscape’s Directory Server.) It doesn’t appear that
Active Directory supports referrals aside from those generated from traversing
the directory ‘forest’. On the other hand, we were able to easily
junction Active Directory into Netscape’s Directory Server by adding a
referral to the latter directory. It appears that Netscape’s
Meta-Directory may solve some of these problems.
Once we had worked around the above problems, we were able to test the
internal build of ypldapd for NT successfully with a standard NIS client. The
most useful (and least drastic) changes Microsoft could make would be to list
auxiliary classes as values of objectClass, and to allow multi-valued naming
attributes.