issue getting schema - Version 1.2.x return no operational attributes
 

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 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

--
Rudolf Hatheyer
alpha nova Betriebsgesm.b.H.

Idlhofgasse 59-63
8020 Graz
Tel: 0043/316/722622
Fax: 0043/316/722622-16
Mobil: 0699/14032570

http://www.alphanova.at

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

issue getting schema - Version 1.2.x return no operational attributes
 

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
>
>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users