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

[thierry bordaz]

On 08/10/2016 04:37 PM, thierry bordaz wrote:
>
>
> On 08/10/2016 12:51 PM, Alexander Bokovoy wrote:
>> On Wed, 10 Aug 2016, Alexander Bokovoy wrote:
>>> On Wed, 10 Aug 2016, thierry bordaz wrote:
>>>>
>>>>
>>>> On 08/09/2016 01:38 PM, Alexander Bokovoy wrote:
>>>>> On Tue, 09 Aug 2016, thierry bordaz wrote:
>>>>>>
>>>>>>
>>>>>> On 08/09/2016 12:49 PM, Martin Basti wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 08.08.2016 17:30, thierry bordaz wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>
>>>>>>> So, could you provide ack thierry?
>>>>>>>
>>>>>>> Martin
>>>>>>
>>>>>> Sure but I would have to test first :-)
>>>>>>
>>>>>> Alexander, how can I test this ?
>>>>> slapi-nis 0.56.1-1 packages are available in koji for f24-f26:
>>>>> http://koji.fedoraproject.org/koji/packageinfo?packageID=6609
>>>>
>>>> Thanks Alexander. So to test this change is there an other way 
>>>> (simpler) than setting up AD/trust ?
>>> I don't think so. We don't have UPNs in FreeIPA on the level of 
>>> identity
>>> lookups and we don't allow to lookup identity by email, so you are left
>>> with using a proper AD trust and UPN suffixes in AD forest.
>> Attached is an updated patch that adds versioned require of slapi-nis
>> which supports the feature.
>>
>>
>
> Thanks to Lenka, I was able to test the patch with AD trust and a UPN 
> suffix.
>
> The tests looks good as 'getent' on a AD user returns user at ADdomain.
>
> Now if I remove the config change in "cn=users,cn=Schema 
> Compatibility,cn=plugins,cn=config", I get the same results i.e:
>         getent passwd upnuser at UPNsuffix.com
> upnuser at dom-221.idm.lab.eng.brq.redhat.com:*:1965201133:1965201133:UPN 
> User:/:
>
>
> How can I check slapi-nis gets the first value ?
>
> thanks
> thierry
acceptance is now completed (successfully).  ACK