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

2016-08-25 Thread Martin Basti 



On 25.08.2016 10:32, Alexander Bokovoy wrote:

On Tue, 23 Aug 2016, thierry bordaz wrote:

acceptance is now completed (successfully).  ACK


bump

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



Yes that is my understanding. patch 213-1 fixes #6138.
I verified that lookup of UPN entries does return the domain. But did 
not know how to check that entries with multiple uid values only 
returns the first value.

Can we push 0213-1?

Pushed to master: fab1f798ed6dfdb0b7de7c4fc4fe353f1d97177b

--
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

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

2016-08-25 Thread Alexander Bokovoy 

On Tue, 23 Aug 2016, thierry bordaz wrote:

acceptance is now completed (successfully).  ACK


bump

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


Yes that is my understanding. patch 213-1 fixes #6138.
I verified that lookup of UPN entries does return the domain. But did 
not know how to check that entries with multiple uid values only 
returns the first value.

Can we push 0213-1?
--
/ Alexander Bokovoy

--
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

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

2016-08-23 Thread thierry bordaz 



On 08/23/2016 12:41 PM, Petr Vobornik wrote:

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: ') ?

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 ?


Yes that is my understanding. patch 213-1 fixes #6138.
I verified that lookup of UPN entries does return the domain. But did 
not know how to check that entries with multiple uid values only returns 
the first value.



--
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

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

2016-08-23 Thread Petr Vobornik 
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: ') ?
>> 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

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

2016-08-10 Thread 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: ') ?

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

--
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

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

2016-08-10 Thread thierry bordaz 



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: ') ?

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

--
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

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

2016-08-10 Thread Alexander Bokovoy 

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: ') ?

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.


--
/ Alexander Bokovoy
From 4a75c02c66e2ecacb0cb3b6e8c2255805e9f68b5 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy 
Date: Thu, 4 Aug 2016 09:58:50 +0300
Subject: [PATCH 2/5] support multiple uid values in schema compatibility tree

---
 freeipa.spec.in | 4 +++-
 install/updates/10-schema_compat.update | 4 
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/freeipa.spec.in b/freeipa.spec.in
index 78ab8ca..c8146e1 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -12,9 +12,11 @@
 %if 0%{?rhel}
 %global samba_version 4.0.5-1
 %global selinux_policy_version 3.12.1-153
+%global slapi_nis_version 0.56.0-4
 %else
 %global samba_version 2:4.0.5-1
 %global selinux_policy_version 3.13.1-158.4
+%global slapi_nis_version 0.56.1
 %endif
 
 %define krb5_base_version %(LC_ALL=C rpm -q --qf '%%{VERSION}' krb5-devel | 
grep -Eo '^[^.]+\.[^.]+')
@@ -157,7 +159,7 @@ Requires(pre): systemd-units
 Requires(post): systemd-units
 Requires: selinux-policy >= %{selinux_policy_version}
 Requires(post): selinux-policy-base >= %{selinux_policy_version}
-Requires: slapi-nis >= 0.56.0
+Requires: slapi-nis >= %{slapi_nis_version}

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

2016-08-10 Thread Alexander Bokovoy 

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: ') ?

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

--
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

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

2016-08-10 Thread thierry bordaz 



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: ') ?

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 ?




--
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

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

2016-08-09 Thread Alexander Bokovoy 

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: ') ?

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

--
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

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

2016-08-09 Thread thierry bordaz 



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: ') ?

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 ?

thanks
thierry

--
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

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

2016-08-09 Thread Martin Basti 



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: ') ?

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

--
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

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

2016-08-08 Thread thierry bordaz 



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: ') ?

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.


--
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

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

2016-08-08 Thread Alexander Bokovoy 

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: ') ?

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

--
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

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

2016-08-08 Thread thierry bordaz 



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: ') ?




--
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

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

2016-08-08 Thread Alexander Bokovoy 

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

--
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

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

2016-08-08 Thread thierry bordaz 



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 ?


thanks
thierry

--
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

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

2016-08-08 Thread Alexander Bokovoy 

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.

--
/ Alexander Bokovoy

--
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

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

2016-08-08 Thread Lukas Slebodnik 
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.

LS

-- 
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

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

2016-08-08 Thread Alexander Bokovoy 

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.

--
/ Alexander Bokovoy

--
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

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

2016-08-08 Thread Martin Basti 



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?

Martin^2
-- 
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

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

2016-08-08 Thread Alexander Bokovoy 

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


--
/ Alexander Bokovoy
From 359328c45465c25a2c34629511bf30097b0b8b0a Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy 
Date: Thu, 4 Aug 2016 09:58:50 +0300
Subject: support multiple uid values in schema compatibility tree

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.

https://fedorahosted.org/freeipa/ticket/6138

---
 install/updates/10-schema_compat.update | 4 
 1 file changed, 4 insertions(+)

diff --git a/install/updates/10-schema_compat.update 
b/install/updates/10-schema_compat.update
index e4c257d..fbe8703 100644
--- a/install/updates/10-schema_compat.update
+++ b/install/updates/10-schema_compat.update
@@ -87,3 +87,7 @@ add:schema-compat-entry-attribute: 
%ifeq("ipauniqueid","%{ipauniqueid}","objectc
 add:schema-compat-entry-attribute: 
%ifeq("ipauniqueid","%{ipauniqueid}","ipaanchoruuid=:IPA:$DOMAIN:%{ipauniqueid}","")
 add:schema-compat-entry-attribute: ipaanchoruuid=%{ipaanchoruuid}
 add:schema-compat-entry-attribute: 
%ifeq("ipaanchoruuid","%{ipaanchoruuid}","objectclass=ipaOverrideTarget","")
+
+dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config
+add:schema-compat-entry-attribute: uid=%{uid}
+replace:schema-compat-entry-rdn: uid=%{uid}::uid=%first("%{uid}")
-- 
2.7.4

-- 
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