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

[thierry bordaz]

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>') ?