[Freeipa-devel] [PATCH 0213] support multiple uid values in slapi-nis users map
thierry bordaz
tbordaz at redhat.com
Wed Aug 10 14:37:05 UTC 2016
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
More information about the Freeipa-devel
mailing list