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

Alexander Bokovoy abokovoy at redhat.com
Wed Aug 10 07:03:37 UTC 2016


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.
-- 
/ Alexander Bokovoy




More information about the Freeipa-devel mailing list