Freeipa 4.3.1
389-ds: master
Test case:
Create a freeipa-server (or a standalone instance) # create a user with 'givenname: foo' ipa user-add --first=foo --last=bar fbar ----------------- Added user "fbar" ----------------- User login: fbar First name: foo Last name: bar Full name: foo bar Display name: foo bar Initials: fb Home directory: /home/fbar GECOS: foo bar Login shell: /bin/sh Kerberos principal: fbar@<real> Email address: fbar@<domain> UID: 1080000003 GID: 1080000003 Password: False Member of groups: ipausers Kerberos keys available: False ldapsearch -LLL -D "cn=directory manager" -w ... -b "cn=users,cn=accounts,SUFFIX" uid=fbar givenname sn dn: uid=fbar,cn=users,cn=accounts,SUFFIX givenname: foo sn: bar ipa user-mod fbar --first=Foo ipa: ERROR: Type or value exists: #audit log dn: uid=fbar,cn=users,cn=accounts,SUFFIX result: 20 changetype: modify add: givenName givenName: Foo - delete: givenName givenName: foo
Note the if the order of the modification, deletes the current value before setting the new one, the MOD succeeds
ldapmodify -D "cn=directory manager" -w ... dn: uid=fbar,cn=users,cn=accounts,SUFFIX changetype: modify add: givenName givenName: Foo - delete: givenName givenName: foo modifying entry "uid=fbar,cn=users,cn=accounts,SUFFIX" ldap_modify: Type or value exists (20) ldapmodify -D "cn=directory manager" -w ... dn: uid=fbar,cn=users,cn=accounts,SUFFIX changetype: modify delete: givenName givenName: foo - add: givenName givenName: Foo modifying entry "uid=fbar,cn=users,cn=accounts,SUFFIX" # the audit log is dn: uid=fbar,cn=users,cn=accounts,SUFFIX result: 20 changetype: modify add: givenName givenName: Foo - delete: givenName givenName: foo - ... dn: uid=fbar,cn=users,cn=accounts,SUFFIX result: 0 changetype: modify delete: givenName givenName: foo - add: givenName givenName: Foo -
According to https://www.ietf.org/rfc/rfc4511.txt 4.6:
A list of modifications to be performed on the entry. The entire list of modifications MUST be performed in the order they are listed as a single atomic operation. While individual modifications may violate certain aspects of the directory schema (such as the object class definition and Directory Information Tree (DIT) content rule), the resulting entry after the entire list of modifications is performed MUST conform to the requirements of the directory model and controlling schema [RFC4512].
I did tests with SunDSEE7 and openldap 2.4.40,
on both products the behaviour is the same as in 389, the mod in the order add/delete is rejected, the mod in the order delete/add succeeds
Per weekly meeting:
Close this (we behave the same as OpenLDAP and SunDS) RHDS always returned this failure. This is a problem of freeipa that incorrectly order the modifications.
This is not invalid, just wontfix (see comment:1).
Metadata Update from @nhosoi: - Issue set to the milestone: 0.0 NEEDS_TRIAGE
Metadata Update from @vashirov: - Issue set to the milestone: None (was: 0.0 NEEDS_TRIAGE)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/1900
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Invalid)
Login to comment on this ticket.