On 07/29/2010 01:30 AM, Rudolf Hatheyer wrote: > Hi, > > I've noticed a difference in behavior between 1.0.x and 1.2.x Version of > FDS. > Version 1.2.x will not return the hole schema (without specifying > attributes objectClasses, matchingRules ). > This change came about from some work to make 389 more standards compliant. The "objectClasses" and "attributeTypes" attributes are defined as operational attributes per RFC 4512. This requires a client to explicitly request those attributes (see RFC 4512, section 4.4). Unfortunately, there is no easy way to change this behavior. Is there no way to make ADSI/VBScript request the attributes to return when querying the subschema entry? It seems like this would be a problem when using any server that follows the LDAPv3 standards with regards to subschema. > This a problem when querying by use of VBScript (i need this ugly stuff > in a windows login script to get specific user data from the LDAP). ADSI > will first do a root-DSE query to determine the provided schema. If the > server returns no schema, ADSI will allow you to query only standard > LDAP V2 attributes (and not my special ones). > > Query a Server with Version 1.2.5 > > # ./ldapsearch -h 192.168.1.202 -b cn=schema -s base "objectclass=*" > version: 1 > dn: cn=schema > objectClass: top > objectClass: ldapSubentry > objectClass: subschema > cn: schema > > Specifying for instance "objectClasses" attribut in the query returns > the wanted data: > > version: 1 > dn: cn=schema > objectClasses: ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass X-ORIGIN > 'RFC 45 > 12' ) > objectClasses: ( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST > aliasedObjectNam > e X-ORIGIN 'RFC 4512' ) > objectClasses: ( 2.5.20.1 NAME 'subschema' AUXILIARY MAY ( > dITStructureRules $ > nameForms $ dITContentRules $ objectClasses $ attributeTypes $ > matchingRule > s $ matchingRuleUse ) X-ORIGIN 'RFC 4512' ) > objectClasses: ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject' > SUP top > [...] > > Query a Server with Version 1.0.4 > > version: 1 > dn: cn=schema > objectClass: top > objectClass: ldapSubentry > objectClass: subschema > cn: schema > objectClasses: ( 2.5.6.0 NAME 'top' DESC 'Standard LDAP objectclass' > ABSTRACT > MUST objectClass X-ORIGIN 'RFC 2256' ) > objectClasses: ( 2.5.6.1 NAME 'alias' DESC 'Standard LDAP objectclass' > SUP top > ABSTRACT MUST aliasedObjectName X-ORIGIN 'RFC 2256' ) > objectClasses: ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject' > DESC 'LD > APv3 extensible object' SUP top AUXILIARY X-ORIGIN 'RFC 2252' ) > [...] > > > Is there a way to configure the 1.2.x series to get the old behavior? > > Regards, Rudolf > >
