[Freeipa-devel] [PATCH 0213] support multiple uid values in slapi-nis users map

[thierry bordaz]

On 08/08/2016 05:20 PM, Alexander Bokovoy wrote:
> On Mon, 08 Aug 2016, thierry bordaz wrote:
>>
>>
>> On 08/08/2016 04:20 PM, Alexander Bokovoy wrote:
>>> On Mon, 08 Aug 2016, thierry bordaz wrote:
>>>>
>>>>
>>>> On 08/08/2016 10:56 AM, Alexander Bokovoy wrote:
>>>>> On Mon, 08 Aug 2016, Lukas Slebodnik wrote:
>>>>>> On (08/08/16 11:35), Alexander Bokovoy wrote:
>>>>>>> On Mon, 08 Aug 2016, Martin Basti wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 08.08.2016 09:34, Alexander Bokovoy wrote:
>>>>>>>>> When SSSD resolves AD users on behalf of slapi-nis, it can
>>>>>>>> accept any
>>>>>>>>> user identifier, including user principal name (UPN) which may be
>>>>>>>>> different than the canonical user name which SSSD returns.
>>>>>>>>>
>>>>>>>>> As result, the entry created by slapi-nis will be using
>>>>>>>> canonical user
>>>>>>>>> name but the filter for search will refer to the original 
>>>>>>>>> (aliased)
>>>>>>>>> name. The search will not match the newly created entry.
>>>>>>>>>
>>>>>>>>> The issue is fixed  in slapi-nis-0.56.1 by returning two 
>>>>>>>>> values for
>>>>>>>>> 'uid' attribute: the canonical one and the aliased one. This 
>>>>>>>>> way the
>>>>>>>>> search will match.
>>>>>>>>>
>>>>>>>>> Standard LDAP schema allows multiple values for 'uid' 
>>>>>>>>> attribute. We
>>>>>>>>> actually use the same trick for 'cn' attribute in the groups map
>>>>>>>>> already.
>>>>>>>>>
>>>>>>>>> https://fedorahosted.org/freeipa/ticket/6138
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> should we bump requires to slapi-nis-0.56.1 in freeipa.spec?
>>>>>>> No, this is not required. In Fedora we'll submit a combined 
>>>>>>> update --
>>>>>>> I've built slapi-nis-0.56.1-1 packages for f24, f25, and rawhide 
>>>>>>> already
>>>>>>> but did not submit a Bodhi request.
>>>>>>>
>>>>>> How is combined updated related to requires to slapi-nis-0.56.1?
>>>>>> It will not prevent tu update freeipa without new slapi-nis.
>>>>>>
>>>>>> e.g.
>>>>>> dnf update freeipa-server.
>>>>> An update file in FreeIPA that is proposed by this patch does not 
>>>>> affect
>>>>> operation of the older slapi-nis deployment once update is applied.
>>>>>
>>>>
>>>> Hi,
>>>>
>>>> Is '%first' returning the first value of the attribute 'uid' ?
>>>> If there are several values (canonical, alias,... ), does the order 
>>>> matters ?
>>> We insert the canonical one first and it seems that 389-ds does not
>>> change the order, at least in my tests. You can see the output in the
>>> bug https://bugzilla.redhat.com/show_bug.cgi?id=1361123#c2
>>
>> From ldap pov (https://tools.ietf.org/html/rfc4511#section-4.1.7) the 
>> order of the values is not preserved.
>> I think it is a bit risky to rely on a specific order especially with 
>> complex updates (adding several values in a single mod, replace) and 
>> replication.
>> would it help to add canonical value with a subtype (e.g. 
>> 'uid;canonical: <value>') ?
> Not sure how what you are mention is relevant here. We talk about
> slapi-nis map cache entries which are not modified, replaced or
> replicated anywhere by anything other than slapi-nis itself. When
> entries are changed by slapi-nis, they are regenerated from scratch.
>
> Your worries do not apply here.
ok.
I understand my mistake, I was thinking the compat entry had a 
associated real entry in ldap and this real entry had two uid values.