[Freeipa-users] deleting ipa user

[thierry bordaz]

On 04/29/2015 05:58 PM, Andy Thompson wrote:
>>> dn:
>>> nsuniqueid=7e1a1f87-e82611e4-99f1b343-
>> f0abc1a8,cn=username,cn=groups,c
>>> n=accounts,dc=mhbenp,dc=lin
>>> nscpentrywsi: dn:
>>> nsuniqueid=7e1a1f87-e82611e4-99f1b343-
>> f0abc1a8,cn=username,cn=groups,c
>>> n=accounts,dc=mhbenp,dc=lin
>>> nscpentrywsi: objectClass;vucsn-55364a42000500040000: posixgroup
>>> nscpentrywsi: objectClass;vucsn-55364a42000500040000: ipaobject
>>> nscpentrywsi: objectClass;vucsn-55364a42000500040000:
>> mepManagedEntry
>>> nscpentrywsi: objectClass;vucsn-55364a42000500040000: top
>>> nscpentrywsi: objectClass;vucsn-5540deb8000300030000: nsTombstone
>>> nscpentrywsi:
>>> cn;vucsn-55364a42000500040000;mdcsn-55364a42000500040000: gfeigh
>>> nscpentrywsi: gidNumber;vucsn-55364a42000500040000: 1249000003
>>> nscpentrywsi: description;vucsn-55364a42000500040000: User private
>>> group for username
>>> nscpentrywsi: mepManagedBy;vucsn-55364a42000500040000: uid=
>>> username,cn=users,cn=accounts,dc=mhbenp,dc=lin
>>> nscpentrywsi: creatorsName;vucsn-55364a42000500040000: cn=Managed
>>> Entries,cn=plugins,cn=config
>>> nscpentrywsi: modifiersName;vucsn-55364a42000500040000: cn=Managed
>>> Entries,cn=plugins,cn=config
>>> nscpentrywsi: createTimestamp;vucsn-55364a42000500040000:
>>> 20150421130152Z
>>> nscpentrywsi: modifyTimestamp;vucsn-55364a42000500040000:
>>> 20150421130152Z
>>> nscpentrywsi: nsUniqueId: 7e1a1f87-e82611e4-99f1b343-f0abc1a8
>>> nscpentrywsi: ipaUniqueID;vucsn-55364a42000500040000:
>>> 94dc1638-e826-11e4-878a-005056a92af3
>>> nscpentrywsi: parentid: 4
>>> nscpentrywsi: entryid: 385
>>> nscpentrywsi: nsParentUniqueId: 3763f193-e76411e4-99f1b343-f0abc1a8
>>> nscpentrywsi: nstombstonecsn: 5540deb8000300030000
>>> nscpentrywsi: nscpEntryDN:
>>> cn=username,cn=groups,cn=accounts,dc=mhbenp,dc=lin
>>> nscpentrywsi: entryusn: 52327
>>>
>>> thought I tried that before, apparently not.
>> ok, so we have the entry on one server, the csn of the objectclass:
>> tombstone is :
>>
>> objectClass;vucsn-5540deb8000300030000: nsTombstone
>>
>> , which matches the csn in the error log:
>>
>> Consumer failed to replay change (uniqueid 7e1a1f87-e82611e4-99f1b343-
>> f0abc1a8, CSN 5540deb8000300030000): Operations error (1) so the state of
>> the entry is as expected.
>>
>> Now we nend to find it on the other server. If the search for the & filter with
>> nstombstone does return nothing, could you try
> If I run ldapsearch -LLL -o ldif-wrap=no -H ldap://mdhixnpipa01 -x -D "cn=directory manager" -W  -b "dc=mhbenp,dc=lin" "(&(objectclass=nstombstone))" I get below.  If I add nsuniqueid to the filter it returns nothing on the primary server
>
> dn: nsuniqueid=7e1a1f82-e82611e4-99f1b343-f0abc1a8,uid=username,cn=users,cn=accounts,dc=mhbenp,dc=lin
> memberOf: cn=ipausers,cn=groups,cn=accounts,dc=mhbenp,dc=lin
> memberOf: ipaUniqueID=3897c894-e764-11e4-b05b-005056a92af3,cn=hbac,dc=mhbenp,dc=lin
> ipaNTSecurityIdentifier: S-1-5-21-1257946092-587846975-4124201916-1003
> krbLastSuccessfulAuth: 20150421180533Z
> krbPasswordExpiration: 20150720180532Z
> userPassword:: e1NIQTUxMn1wekx2TytqSG9YQWkwL1RMWitXcE44dmFRRnFEWUJ3U3lrMTJab2ErNUdwakdWTVBnSzlJK0txdWF2b0pXdjZKbVZuZjdWb2txbG04NXpiWVhqTXQxUT09
> krbExtraData:: AAJskTZVa2FkbWluZEBNSEJFTlAuTElOAA==
> krbPrincipalKey:: MIIBnKADAgEBoQMCAQGiAwIBA6MDAgEBpIIBhDCCAYAwaKAbMBmgAwIBAKESBBBNSEJFTlAuTElOZ2ZlaWdooUkwR6ADAgESoUAEPiAA10A0LqF2hLTC5EP9ArjKyMvDEuNh7SFNR7uvAba4+sh8WRRVbT7DMByrlPvn1A
> 0miart7lTDnRh89BAbMFigGzAZoAMCAQChEgQQTUhCRU5QLkxJTmdmZWlnaKE5MDegAwIBEaEwBC4QAAc6BbDvPFsSAeCRjrt2yDkm0fiQWTt++y/lbFKDbSkZYSJpFnzSRaaIWW0AMGCgGzAZoAMCAQChEgQQTUhCRU5QLkxJTmdmZWlnaKFBMD
> +gAwIBEKE4BDYYACTz15wnIUghoNOEkvYZJUbcrXhAyFQsW4OpxTCzxInn+33pOsEXPlsdsYfc6uJeVl2bN/IwWKAbMBmgAwIBAKESBBBNSEJFTlAuTElOZ2ZlaWdooTkwN6ADAgEXoTAELhAAE9mQlmMsVmCvtRwKXdSf9b7CFCi4qZjwMj1cTwzD1FH6/IbmDSvRMUVw8wE=
> krbLoginFailedCount: 0
> krbTicketFlags: 128
> krbLastPwdChange: 20150421180532Z
> krbLastFailedAuth: 20150421180457Z
> mepManagedEntry: cn=username,cn=groups,cn=accounts,dc=mhbenp,dc=lin
> displayName: user name
> cn: User Name
> objectClass: ipaobject
> objectClass: person
> objectClass: top
> objectClass: ipasshuser
> objectClass: inetorgperson
> objectClass: organizationalperson
> objectClass: krbticketpolicyaux
> objectClass: krbprincipalaux
> objectClass: inetuser
> objectClass: posixaccount
> objectClass: ipaSshGroupOfPubKeys
> objectClass: mepOriginEntry
> objectClass: ipantuserattrs
> objectClass: nsTombstone
> loginShell: /bin/bash
> initials: GF
> gecos: User Name
> homeDirectory: /home/username
> uid: username
> mail: username at mhbenp.lin
> krbPrincipalName: username at MHBENP.LIN
> givenName: User
> sn: name
> ipaUniqueID: 94d31f06-e826-11e4-878a-005056a92af3
> uidNumber: 1249000003
> gidNumber: 1249000003
> nsParentUniqueId: 3763f192-e76411e4-99f1b343-f0abc1a8
>
>
In fact, nsuniqueid does not appear in this entry. It is a distinguished 
RDN but is missing. Did you run the command with 'nscpentrywsi' 
requested attribute. May be nsuniqueid was hidden for that reason but I 
would be surprised.

nsuniqueid is a key element of replication. I wonder how replication can 
find the entry itself. nsuniqueid could be in the index but then the 
entry is corrupted.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20150429/b8ab3bb3/attachment.htm>