[Freeipa-users] ipa user-find finds user but ipa user-del fails

[Martin Kosek]

On 09/04/2014 10:31 PM, Ron wrote:
> So I tried to delete an entry on IPA01 without success:
> 
> [root at ipa01 ~]# ldapdelete -D
> "uid=admin,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca" -W -x
> "cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=xxxx,dc=abc,dc=ca"
> Enter LDAP Password:
> ldap_delete: Server is unwilling to perform (53)
>     additional info: Deleting a managed entry is not allowed. It needs
> to be manually unlinked first
> 
> Same problem if I try to use ldapmodify:
> 
> [root at ipa01 ~]# ldapmodify -D
> "uid=admin,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca" -W -x
> Enter LDAP Password:
> dn:
> cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=xxxx,dc=abc,dc=ca
> changetype: modrdn
> newrdn: uid=19000
> deleteoldrdn: 0
> 
> modifying rdn of entry
> "cn=userxyz+nsuniqueid=62c9c682-32ce11e4-8c13b928-a98b9061,cn=groups,cn=accounts,dc=xxxx,dc=abc,dc=ca"
> ldap_rename: Server is unwilling to perform (53)
>     additional info: Renaming a managed entry is not allowed. It needs
> to be manually unlinked first.
> 
> (19000 is just an unused uid)
> 
> Would this be because of the private group associated with the user?

Exactly.

> How do I unlink the entry?  Would I use the following?
> ipa group-detach userxyz

You would normally use it, but I am not sure it would work given that group DN
is changed with the nsuniqueid RDN.

However, you can manually detach the group with ldapmodify:

$ kinit admin
$ ipa group-show fbar --all --raw
  dn: cn=fbar,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test
  cn: fbar
  description: User private group for fbar
  gidnumber: 82600004
  ipaUniqueID: 2fbdbdd2-34c7-11e4-a98a-001a4a2221bf
  mepManagedBy: uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test
  objectClass: posixgroup
  objectClass: ipaobject
  objectClass: mepManagedEntry
  objectClass: top

$ ldapmodify -Y GSSAPI -h `hostname`
SASL/GSSAPI authentication started
SASL username: admin at MKOSEK-FEDORA20.TEST
SASL SSF: 56
SASL data security layer installed.
dn: cn=fbar,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test
changetype: modify
delete: objectClass
objectClass: mepManagedEntry
-
delete: mepManagedBy
mepManagedBy: uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test

modifying entry "cn=fbar,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test"


Now the ldapdelete on group should work.

> Thanks again for all your help!
> -Ron
> 
> On 09/04/2014 02:48 AM, Martin Kosek wrote:
>> Ah, ok. As Rob advised, you will need to delete it via ldapdelete CLI or via
>> any LDAP GUI application of choice.
>>
>> BTW, this is upstream ticket tracking better means to resolve replication
>> conflicts:
>> https://fedorahosted.org/freeipa/ticket/1025
>>
>> Martin
>>
>> On 09/03/2014 10:44 PM, Ron wrote:
>>> By the way, all three replica servers show the same:
>>>
>>> [root at ipa]# ipa user-find --all --raw --login phys210e | grep dn:
>>>   dn:
>>> nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca
>>>
>>> [root at ipa01]# ipa user-find --all --raw --login phys210e | grep dn:
>>>   dn:
>>> nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca
>>>
>>> [root at ipa02]# ipa user-find --all --raw --login phys210e | grep dn:
>>>   dn:
>>> nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=phys210e,cn=users,cn=accounts,dc=xxxx,dc=abc,dc=ca
>