[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: ActiveDirectory schema
I am concerned the thread of this discussion may be missing the point.
Some talk of Op atts others talk of schema discovery and reading a
servers schema.
I thought that the reason of a directory was to provide a set of
standard objects and attributes with which most system could work with
and use simple clients and have at the same time a system where there
was some flexibility in name forms, attributes and additional object
classes.
There is a difference between ROOT and TOP
TOP is the highest structural point for all definitions of object
classes - that represent entries. Wheras the ROOT is the highest point
for instanciation of a DIB.
In a distributed world the ROOT may be on one server and its subordinate
entries in another.
If TOP is redefined in one server it needs to be propagated to all
subordinate (and superior) servers so that their structural integrity
for all objects (entries) under that ROOT is maintained.
Redefining TOP also means that the access control information integrity
needs to be coordinated.
Having variations in TOP across interconnected - replicated and
distributed servers makes the system a mess and makes the client
software even more complex.
Redefing TOP in a directory service IMHO is the same as redefining a bit
to be a byte or a string to be an integer.
One should not take the very foundation definitions of an object
oriented information system as defined by the ISO-ITU (and LDAP) and
registered that way - and after 12 years of implementation effort -
redefine it.
This is like redefining country codes for phone numbers!
I would still like to understand from all on this list - what will they
do when their applications reads/browses entries like Country, Location,
OUs (that are used for DIB organisation - like Customers or Books, etc)
what they do when they get all this stuff back. More importantly when
clients switch from server to server (the LDAP way) - how do they deal
with authenitaction and access control issues - as they will probably
need to manage different info/aci environments depending on the values
of TOP used.
What is the User experience here?
By the way Content rules give flexibility to OCs - however, they do not
in any way shape of form say that something which is registered by the
ISO-ITU should be redefined by someone else and the same number used.
The OID indicates ownership. eg joint-iso-itu, X.500, ....
and by saying that these attributes MUST be in TOP just means we all
have to be compatable with all the VALUES of these attributes - world
wide.
IE.
instanceType -
nTSecurityDescriptor --- even on UNIX, etc?
objectCategory
regards alan.
> -----Original Message-----
> From: Salter, Thomas A
> Sent: Tuesday, June 15, 1999 5:56 AM
> To: Alan Lloyd; 'ietf-ldapext@netscape.com '; 'rweltman@netscape.com
> '
> Subject: RE: ActiveDirectory schema
>
> While I agree it's a bad idea to redefine standard object classes, the
> X.500
> standards explicitly allow the same effect through the use of content
> rules.
> It is entirely possible for the effective definition of
> organizationalPerson
> or top or any other class to be vary from one subschema administration
> area
> to another. So, clients that care about the list of permitted
> attributes
> for a particular entry must examine the content rules in the
> appropriate
> subschema object.
>
>
> > -----Original Message-----
> > From: Alan Lloyd [mailto:Alan.Lloyd@OpenDirectory.com.au]
> > Sent: Monday, June 14, 1999 6:35 AM
> > To: 'ietf-ldapext@netscape.com '; 'rweltman@netscape.com '
> > Subject: RE: ActiveDirectory schema
> >
> >
> > I saw this one some time a go..
> > IMHO its means that directory compatibility will be a major issue
> for
> > all servers and clients - world wide.
> >
> > TOP is the hinge pin for all dierctory information objects in all
> > directory systems that are accessed by LDAP and DAP and DSP
> > and LDUP and
> > LDIF...
> >
> > We all have been working with that one OC as defined by the ITU/ISO
> -
> > being abstract for the purpose that other sub-classsed objects can
> be
> > defined and commonly inherit the OC attribute - which all
> > other objects
> > must have..
> > I dont understand why the standard OID (as registered from
> > the ITU/ISO)
> > has been redefined in such a non standard way - Perhaps the ISO-ITU
> > should be asked for comment.
> >
> > So anything to do with structure rules and and object
> > processing in all
> > clients, and servers must now be changed - if this definition is
> > supported.
> >
> > And for all those with LDAP clients as servers - the syntax
> > and search
> > matching rules also have to be supported.
> >
> >
> > As this issue is important to anyone working on directory
> > technology, is
> > there anyone from Microsoft on this list that would like to comment
> > about this re-definition of a formal joint iso-itu OID and
> > its impact on
> > the rest of the worlds standard directory environment?
> >
> > regards alan
> >
> >
> >
> > ----------
> > From: rweltman@netscape.com
> > To: ietf-ldapext@netscape.com
> > Sent: 6/13/99 6:32:47 AM
> > Subject: ActiveDirectory schema
> >
> > I was looking at the schema published in ActiveDirectory
> > (Windows 2000
> > Beta 3) and was a little puzzled. It looks like the objectclass
> "top"
> > has been considerably extended:
> > top
> > OID
> > 2.5.6.0
> > Required
> > objectClass
> > instanceType
> > nTSecurityDescriptor
> > objectCategory
> > Optional
> > cn
> > description
> > distinguishedName
> > whenCreated
> > whenChanged
> > subRefs
> > displayName
> > uSNCreated
> > isDeleted
> > dSASignature
> > objectVersion
> > repsTo
> > repsFrom
> > memberOf
> > uSNChanged
> > uSNLastObjRem
> > showInAdvancedViewOnly
> > adminDisplayName
> > proxyAddresses
> > adminDescription
> > extensionName
> > uSNDSALastObjRemoved
> > displayNamePrintable
> > directReports
> > wWWHomePage
> > USNIntersite
> > name
> > objectGUID
> > replPropertyMetaData
> > replUpToDateVector
> > flags
> > revision
> > wbemPath
> > fSMORoleOwner
> > systemFlags
> > siteObjectBL
> > serverReferenceBL
> > nonSecurityMemberBL
> > queryPolicyBL
> > wellKnownObjects
> > isPrivilegeHolder
> > partialAttributeSet
> > managedObjects
> > partialAttributeDeletionList
> > url
> > lastKnownParent
> > bridgeheadServerListBL
> > netbootSCPBL
> > isCriticalSystemObject
> > frsComputerReferenceBL
> > fRSMemberReferenceBL
> > uSNSource
> > fromEntry
> > allowedChildClasses
> > allowedChildClassesEffective
> > allowedAttributes
> > allowedAttributesEffective
> > possibleInferiors
> > canonicalName
> > proxiedObjectName
> > sDRightsEffective
> > dSCorePropagationData
> > otherWellKnownObjects
> > mS-DS-ConsistencyGuid
> > mS-DS-ConsistencyChildCount
> > createTimeStamp
> > modifyTimeStamp
> > subSchemaSubEntry
> > Some of the new attributes are operational. But is it
> > really okay to
> > redefine "top"?
> > There is also a minor bug in that there is a missing space
> > after the
> > left parenthesis for the MAY and MUST lists:
> > objectClasses: ( 1.2.840.113556.1.5.74 NAME
> > 'categoryRegistration' SUP
> > leaf S
> > TRUCTURAL MAY (localeID $ categoryId $ managedBy $
> > localizedDescription
> > ) )
> >
> > Rob
> >
> >
> >