search for: dupliate

...ssue and why the dbcheck fails with that uncaught exception. How would I fix such a duplicate key in that file through sam.ldb? To identify the dup key I creted a tdbdump and then counted the keys: awk '$1 ~ /^key/ {print $3}' DOMAINDNSZONES.tdbdump |sort|uniq -c | sort -nr | head the dupliate entry is { key(42) = "DN=@INDEX:USNCHANGED:p0000000000000048557\00" data(116) = "h\19\01&\02\00\00\00&\00\00\00 at INDEX:USNCHANGED:p0000000000000048557\00\00\00\00\00\00)\00\00\00\0B\00\00\00 at IDXVERSION\00\01\00\00\00\01\01\04\00\00\00 at IDX\00\01\00\00\00\01\103\00$s$...

...g, do it through sam.ldb. You may find the ldbsearch '--cross-ncs' switch useful here. > > To identify the dup key I creted a tdbdump and then counted the keys: > > awk '$1 ~ /^key/ {print $3}' DOMAINDNSZONES.tdbdump |sort|uniq -c | > sort -nr | head > > the dupliate entry is > > { > key(42) = "DN=@INDEX:USNCHANGED:p0000000000000048557\00" > data(116) = > "h\19\01&\02\00\00\00&\00\00\00 at INDEX:USNCHANGED:p0000000000000048557\00\00\00\00\00\00)\00\00\00\0B\00\00\00 at IDXVERSION\00\01\00\00\00\01\01\04\00\00\00 at IDX\00...

Hello Timo, your patch introducing pass_attr_names and user_attr_names fixed the problem of the 'shared' attr_names member of [passdb|userdb]_ldap_conn as I answered in the relative thread. Now I think there is a problem while comparing user-provided and ldap-provided passwords causing a false 'password mismatch' situation, while using PLAIN mechanism with LDAP authentication.

> Anything after the 'Join failed' can be ignored, it is just an > artefact of the cleanup. > > I posted this: > > Do not remove the existing database, well not unless you want to > recreate your domain. > > I will amend it: > > Do not touch 'DC=DOMAINDNSZONES,DC=COMPANY,DC=INTRA.ldb' (or any of the > other files in the same directory)