[Freeipa-devel] Ticket #2866 - referential integrity in IPA

[Rich Megginson]

On 09/11/2012 10:51 AM, Martin Kosek wrote:
> On 09/04/2012 04:40 PM, Rich Megginson wrote:
>> On 09/03/2012 08:42 AM, Martin Kosek wrote:
>>> On 08/27/2012 06:29 PM, Rich Megginson wrote:
> ...
>>> This is the plan I plan to take:
>>> 1) Add pres,eq indexes for all un-indexed attributes that we want to check:
>>> sourcehost
>>> memberservice
>>> managedby
>>> memberallowcmd
>>> memberdenycmd
>>> ipasudorunas
>>> ipasudorunasgroup
>> ok
> ...
>
> Implementation of the Referential Integrity in IPA works OK so far, I just hit
> a strange issue when indexing memberallowcmd and memberdenycmd attributes in IPA:
>
> dirsrv errors log:
> ...
> [11/Sep/2012:11:39:53 -0400] - The attribute [memberdenycmd] does not have a
> valid     ORDERING matching rule - error 2:s
> [11/Sep/2012:11:39:58 -0400] - userRoot: Indexing attribute: memberdenycmd
> [11/Sep/2012:11:39:58 -0400] - userRoot: Finished indexing.
> ...
>
> This cause RI to fail to handle this attribute in IPA (which is expected based
> on the error message).
>
> I checked the attributes types, they look like that:
>
> attributetypes: ( 2.16.840.1.113730.3.8.7.1 NAME 'memberAllowCmd' DESC 'Refere
>   nce to a command or group of commands that are allowed by the rule.' SUP dist
>   inguishedName EQUALITY distinguishedNameMatch ORDERING distinguishedNameMatch
>    SUBSTR distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN
>   'IPA v2' )
>
> attributetypes: ( 2.16.840.1.113730.3.8.7.2 NAME 'memberDenyCmd' DESC 'Referen
>   ce to a command or group of commands that are denied by the rule.' SUP distin
>   guishedName EQUALITY distinguishedNameMatch ORDERING distinguishedNameMatch S
>   UBSTR distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'I
>   PA v2' )
>
> "distinguishedNameMatch" ORDERING rule looks wrong, it is only a matching rule.
> Anyone knows why it was defined that way? Or what should be a correct setting
> for this attribute instead? caseIgnoreOrderingMatch seems as a logical choice...
Not sure.  The problem is that, in LDAP, there isn't a concept of 
"ordering" or "substring" matching on DN values.  
http://www.ietf.org/rfc/rfc4517.txt - there is only 
distinguishedNameMatch which is an EQUALITY rule.  Do you really need 
ordering and substring here?  The problem with using some other ordering 
or substring matching rule is that it will not properly normalize the DN 
valued string, so you may get incorrect results.
>
> I will have to fix the attributeTypes definition in IPA before we can enable
> index&  RI for them.
>
> Thanks,
> Martin