I was able to cheat it on the replica where the user was not partially
deleted.
I had to recreate and reattach the deleted group.
Then detach it with
ipa group-detach
Then delete the user.
Then the replication took care of the rest of the masters and purged the
remainders.
Any idea how to do it easier? I cannot refer user by dn: because when i
try, even with a not
problematic user i get no such object? Any idea?
--
*Sándor Juhász*
System Administrator
*ChemAxon* *Kft*.
Building Hx, GraphiSoft Park, Záhony utca 7, Budapest, Hungary, H-1031
Cell: +36704258964
On Wed, Aug 7, 2019 at 4:32 PM Sandor Juhasz <sjuhasz(a)chemaxon.com> wrote:
You have found the key i guess - related to the mepmanagedentry. The
issue
can be reproduced.
Detaching and deleting the managed group results in the not deletable user.
Now the question is, how do i get out of it?
--
*Sándor Juhász*
System Administrator
*ChemAxon* *Kft*.
Building Hx, GraphiSoft Park, Záhony utca 7, Budapest, Hungary, H-1031
Cell: +36704258964
On Wed, Aug 7, 2019 at 4:21 PM Sandor Juhasz <sjuhasz(a)chemaxon.com> wrote:
> Many cases for service users the matching group was created by either
> error or mistake.
> Where those service users are mostly under some group collecting them,
> also assigned
> as GID.
> So the leftovers were detached and deleted, so there is less confusion.
> So far there were no issues like this.
> --
> *Sándor Juhász*
> System Administrator
> *ChemAxon* *Kft*.
> Building Hx, GraphiSoft Park, Záhony utca 7, Budapest, Hungary, H-1031
> Cell: +36704258964
>
>
> On Wed, Aug 7, 2019 at 4:10 PM Rob Crittenden <rcritten(a)redhat.com>
> wrote:
>
>> Sandor Juhasz wrote:
>> > Was detached and deleted prior to the user's deletion.
>> > First modified by
>> > dn: cn=<USERID>,cn=groups,cn=accounts,dc=cxn
>> > changetype: modify
>> > delete: objectclass
>> > objectclass: mepManagedEntry
>> > -
>> > delete: mepManagedBy
>> >
>> > Then deleted.
>>
>> I don't know if this is the issue or not but the user still shows:
>>
>> objectClass: mepOriginEntry
>> mepManagedEntry: cn=<USERID>,cn=groups,cn=accounts,dc=cxn
>>
>> What led you to manually disconnect the group?
>>
>> rob
>>
>> > --
>> > *Sándor Juhász*
>> > System Administrator
>> > *ChemAxon* *Kft*.
>> > Building Hx, GraphiSoft Park, Záhony utca 7, Budapest, Hungary, H-1031
>> > Cell: +36704258964
>> >
>> >
>> > On Wed, Aug 7, 2019 at 3:58 PM Rob Crittenden <rcritten(a)redhat.com
>> > <mailto:rcritten@redhat.com>> wrote:
>> >
>> > Sandor Juhasz via FreeIPA-users wrote:
>> > > We have an entry, what after clicking delete on the UI got
>> partially
>> > > deleted.
>> > > The compat tree entry is gone.
>> > > The accounts tree entry is there.
>> > > ldapsearch finds the entry by uid, but does fail by dn.
>> > > ipa user-show <USERID> finds the user
>> > > ipa user-del <USERID> says no such user
>> > > ldapdelete fails to delete the entry by dn with err=32
>> > > Web ui shows user
>> > > User content can be modified from ipa cli and web ui - like name,
>> > shell,
>> > > but cannot be deleted
>> > > Other entries can be created and deleted without issue.
>> > > We have 4way master-master replication. Tried cli on 3 and got
>> same
>> > > result and issue.
>> > > The third is not touched and the entry is available there both
>> > accounts
>> > > and compat tree.
>> > >
>> > >
>> > > ipa-server-4.6.4-10.el7.centos.3.x86_64
>> > > CentOS Linux release 7.6.1810 (Core)
>> > >
>> > > On full broken master:
>> > > # <USERID>, users, accounts, cxn
>> > > dn: uid=<USERID>,cn=users,cn=accounts,dc=cxn
>> > > gecos: FOO BAR
>> > > displayName: FOO BAR
>> > > krbLastAdminUnlock: 20190807124134Z
>> > > krbLoginFailedCount: 0
>> > > memberOf: cn=ipausers,cn=groups,cn=accounts,dc=cxn
>> > > memberOf: cn=somegroup1,cn=groups,cn=accounts,dc=cxn
>> > > memberOf: cn=somegroupt2,cn=groups,cn=accounts,dc=cxn
>> > > gidNumber: <GID>
>> > > uidNumber: <UID>
>> > > ipaUniqueID: <RANDOMUNIQUEID>
>> > > cn: BAZ
>> > > givenName: FOO
>> > > krbPrincipalName: <USERID>@CXN
>> > > mail: <MAIL>
>> > > homeDirectory: /home/<USERID>
>> > > sn: BAR
>> > > initials: cU
>> > > loginShell: /bin/false
>> > > objectClass: ipaobject
>> > > objectClass: person
>> > > objectClass: top
>> > > objectClass: ipasshuser
>> > > objectClass: inetorgperson
>> > > objectClass: organizationalperson
>> > > objectClass: krbticketpolicyaux
>> > > objectClass: krbprincipalaux
>> > > objectClass: inetuser
>> > > objectClass: posixaccount
>> > > objectClass: ipaSshGroupOfPubKeys
>> > > objectClass: mepOriginEntry
>> > > krbCanonicalName: <USERID>@CXN
>> > > uid: <USERID>
>> > > mepManagedEntry: cn=<USERID>,cn=groups,cn=accounts,dc=cxn
>> > > krbPasswordExpiration: 20170615133527Z
>> > > krbLastPwdChange: 20170615133527Z
>> > > krbExtraData:: AAIfjUJZcm9vdC9hZG1pbkBDWE4A
>> >
>> > Can you check to see if the group entry exists,
>> > cn=<USERID>,cn=groups,cn=accounts,dc=cxn via ldapsearch?
>> >
>> > rob
>> >
>>
>>