Re: [389-users] issue getting schema - Version 1.2.x return no operational attributes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users


[Index of Archives]     [Fedora Directory Users]     [Fedora Directory Devel]     [Fedora Announce]     [Fedora Legacy Announce]     [Kernel]     [Fedora Legacy]     [Share Photos]     [Fedora Desktop]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Big List of Linux Books]     [Gimp]     [Yosemite News]

  Powered by Linux