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 [email protected] >> [email protected]:*: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
