[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
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