[Freeipa-users] Re: Changing case of user attributes fails

2017-09-07 Thread Ludwig Krispenz via FreeIPA-users


On 09/07/2017 03:21 AM, Fraser Tweedale via FreeIPA-users wrote:

On Wed, Sep 06, 2017 at 02:05:56PM -0400, Anthony Clark via FreeIPA-users wrote:

It may possibly be related to this, but this is marked as fixed for 4.3:
https://pagure.io/freeipa/issue/5456

I'm on 4.4.0-14.el7.centos.7

A user had their lastname entry added with the wrong case.  I attempted to
update it by changing the case, got an error like this:

[Wed Sep 06 17:46:08.010202 2017] [:error] [pid 15253] ipa: INFO:
[jsonserver_session] acl...@dev.redacted.net: user_mod/1(u'pboppe',
sn=u'Boppe', version=u'2.213'): DatabaseError

I changed it to something else entirely, then changed it to the correct
case.

This happened on attributes: "lastname", "fullname", "displayname",
"initials", "gecos".  I didn't test it elsewhere.

Is there a ticket already for this or should I create a new one?  I don't
want to create work for the IPA devs :)

Thanks,

Anthony Clark


This is expected behaviour.  In the IETF spec for user schema, the
'sn' attribute[1], which is based on the 'name' attribute[2], uses
the `caseIgnoreMatch' equality rule.  So the LDAP server correctly
determines that there is no change to perform.

[1] https://tools.ietf.org/html/rfc4519#section-2.32
[2] https://tools.ietf.org/html/rfc4519#section-2.18

Arguably we should detect this in IPA and reject the change without
contacting the database, but the failure is expected, so feel free
to file a ticket anyway.
 The attributes are case insensitive and so xxx and xXx are the same 
value. But in DS we are nice and always keep the original spelling and 
also allow replacements with identical values. I think it is the other 
way round, IPA already catches thes identical changes and should allow them


Cheers,
Fraser
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


[Freeipa-users] Re: Changing case of user attributes fails

2017-09-06 Thread Fraser Tweedale via FreeIPA-users
On Wed, Sep 06, 2017 at 02:05:56PM -0400, Anthony Clark via FreeIPA-users wrote:
> It may possibly be related to this, but this is marked as fixed for 4.3:
> https://pagure.io/freeipa/issue/5456
> 
> I'm on 4.4.0-14.el7.centos.7
> 
> A user had their lastname entry added with the wrong case.  I attempted to
> update it by changing the case, got an error like this:
> 
> [Wed Sep 06 17:46:08.010202 2017] [:error] [pid 15253] ipa: INFO:
> [jsonserver_session] acl...@dev.redacted.net: user_mod/1(u'pboppe',
> sn=u'Boppe', version=u'2.213'): DatabaseError
> 
> I changed it to something else entirely, then changed it to the correct
> case.
> 
> This happened on attributes: "lastname", "fullname", "displayname",
> "initials", "gecos".  I didn't test it elsewhere.
> 
> Is there a ticket already for this or should I create a new one?  I don't
> want to create work for the IPA devs :)
> 
> Thanks,
> 
> Anthony Clark
>
This is expected behaviour.  In the IETF spec for user schema, the
'sn' attribute[1], which is based on the 'name' attribute[2], uses
the `caseIgnoreMatch' equality rule.  So the LDAP server correctly
determines that there is no change to perform.

[1] https://tools.ietf.org/html/rfc4519#section-2.32
[2] https://tools.ietf.org/html/rfc4519#section-2.18

Arguably we should detect this in IPA and reject the change without
contacting the database, but the failure is expected, so feel free
to file a ticket anyway.

Cheers,
Fraser
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org