On 08/10/2016 05:27 PM, thierry bordaz wrote:
> 
> 
> 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@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 upnu...@upnsuffix.com
>> upnu...@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
> 

bump

so ACKed ab's 213-1 fixes https://fedorahosted.org/freeipa/ticket/6138 ?

-- 
Petr Vobornik

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to