Hallo,
ich hab leider mehrere Rejects für ein Windows-Maschinenkonto. Das Konto wurde zunächst unbenannt und anschließend wegen Problemen beim Login über die UMC neu angelegt. Vom Zeitstempel her müssen die Rejects nach dem Neuanlegen entstanden sein.
Über univention-s4search ist das Konto nicht aufzufinden, aber über univention-ldapsearch. Das Triggern eines UCS-Resyncs erzeugt leider nur einen weiteren Reject.
Wie kriege ich die Rejects aufgelöst?
Viele Grüße,
SirTux
Die entsprechende aus der connector-s4.log:
ALREADY_EXISTS: {'info': "00002071: samldb: Account name (sAMAccountName) 'hostname$' already in use!", 'desc': 'Already exists'}Ein univention-s4search sAMAccountName=hostname$ ergibt, daß es ein Objekt CN=pan\0ACNF:Zensiert,CN=bla,CN=windows,CN=Computers,DC=top2,DC=top1 im Samba 4 gibt. Das muß ich vermutlich per ldbdel löschen oder?
Also konkret vorgehen müßte ich so, oder liege ich da falsch?
/etc/init.d/samba4 stop
ldbdel -H /var/lib/samba/private/sam.ldb "CN=pan\0ACNF:Zensiert,CN=bla,CN=windows,CN=Computers,DC=top2,DC=top1"
/etc/init.d/samba4 startIch hab mich jetzt einfach getraut und das Teil gelöscht 
Die Rejects haben sich dann automatisch aufgelöst.
Leider ist der Spuk noch nicht vorbei. Das Maschinenkonto wird nach wenigen Minuten wieder unbenannt in so einen seltsamen Namen (ist aber nicht der selbe!) 
Hat vielleicht jemand eine Idee?
EDIT: Die Unbenennung passiert sogar innerhalb weniger Sekunden. Beim Client handelt es sich um einen Windows Server 2008R2 Standard.
Löschen aus LDAP und Samba 4 und anschließendes Neuanlegen hilft leider auch nicht. In welchen Log-Dateien könnte ich denn noch gucken?
Hallo,
mit “\0ACNF:” werden im AD Objekte markiert, für die es Replikations-Konflikte gibt. Ich würde vermuten, dass beim ursprünglichen Umbenennen, Löschen und Neuanlegen des Rechnerkontos irgendwo etwas stecken geblieben ist und jetzt mind. zwei Samba AD Server jeweils andere Varianten des Objektes halten, was dann zu dem Replikationskonflikt führt. Kann das hinkommen?
Ist mit “samba-tool drs showrepl” etwas zu sehen?
Der saubere Weg wäre vermultich alle Objekte aus allen Verzeichnisdiensten zu löschen und auch das Aufräumen des Tombstones abzuwarten (die Dauer kann man nach unten konfigurieren). Der unsaubere Weg wäre wohl, den Windows-Server aus der Domäne zu nehmen, lokal umzubenennen und dann neu zu joinen - ich weiß aber nicht ob das bei dem Server überhaupt ein gangbarer Weg ist.
Schönen Gruß,
Michael Grandjean
Vielen Dank für die Hinweise zu solch später Stunde 
Die einzigen “Failures”, die bei “samba-tool drs showrepl” zu sehen sind, betreffen den Backupserver, der für gewöhnlich ausgeschaltet ist.
Als nächstes werde ich vielleicht einfach mal den Backupserver starten und alle Insatanzen des Maschinenkontos löschen wie Sie vorgeschlagen haben. Morgen werde ich es dann noch mal probieren das Konto über die UMC neu anzulegen.
Ich habs jetzt doch schon mal jetzt probiert. Leider bleibt das Problem bestehen. Wenn das Objekt mit ldbdel gelöscht wird, verschwindet es aber aus allen DCs.
EDIT: Vielleicht war es einfach zu kurz. Wie ist denn die Dauer vom Tombstone? Ich hab irgendwo was von 3 Tagen gelesen.
EDIT2: Ich bin jetzt mir nicht sicher, ob es mir vorher nur nicht aufgefallen ist: Kurz nach dem Löschen taucht das Objekt wieder auf. Also auf den Tombstone zu warten hilft daher wahrscheinlich nicht
EDIT3: In /var/lib/samba/private/sam.ldb.d/DC=TOP2,DC=TOP1.ldb gibt es mehrere Einträge unter “Deleted Objects”. Muß man vielleicht erst da aufräumen?
Das war wohl der Connector. Ich hätte eigentlich schwören können ich hätte es über die UMC vorher entfernt.
Anscheinend sind es wohl eher 60 Tage. Das kann ich dann also gefahrlos runtersetzen auf einen Tag. Oder habe ich dann Probleme zu erwarten?
So ich hab den Wert jetzt nach Anleitung mit ldbedit geändert auf 1 (er war auf 180). Wann schlägt der Tombstone dann nun zu?
Die ersten zwei sind nun weg. Bis spätestens morgen sind die anderen dann hoffentlich auch Geschichte.
Hallo,
mal zur Vollständigkeit: Der Tombstone-Mechanismus dient in erster Linie dazu, ein Löschen von Objekten bei einer Multi-Master-Replikation wie im AD sauber durchführen zu können. Wird bspw. ein Benutzer CN=kermit gelöscht, landet sein Benutzerobjekt als sog. Tombstone mit dem Namen “CN=kermit\0ADEL:” unterhalb von “CN=Deleted Objects”. Das AD führt damit praktisch Buch darüber, welche Objekte in letzter Zeit gelöscht wurden. “CN=Deleted Objects” ist ein versteckter Container und taucht AFAIR auch nur auf, wenn explizit danach gesucht wird, bei univention-s4search z.B. mit “–cross-ncs” als Parameter. Standardmäßig werden Tombstones 60 Tage lang aufbewahrt (bei manchen Windows Versionen sogar 180).
Wenn du jetzt die Tombstone-Lifetime auf 1 Tag runtergesetzt hast, sollte das gelöschte Objekt nach 24 Stunden endgültig weg sein.
Ein Objekt zu löschen und unter selben Namen neu anzulegen ist für die OpenLDAP-Seite von UCS kein Problem. Für Active Directory (egal ob Microsoft oder Samba) eigentlich auch nicht (die SID ändert sich aber!). Problematisch wird es, wenn der Löschvorgang noch nicht überall hin repliziert wurde, das Objekt also nicht überall als “ist gelöscht” markiert ist, bevor ein Objekt mit dem selben Namen neu angelegt wird. Dann kommt es zu solchen Fehlermeldungen hier:
ALREADY_EXISTS: {'info': "00002071: samldb: Account name (sAMAccountName) 'hostname$' already in use!", 'desc': 'Already exists'}Deshalb: Wenn der Backup in der Regel aus ist (zumindest länger als die Tombstone-Lifetime), wird der solche Änderungen nicht mitbekommen und das Spiel kann für andere gelöschte Objekte von vorne losgehen.
Ich würde grob folgendes versuchen:
Zunächst erstmal danke für die Erläuterungen. Beim nächsten mal werde ich den Backupserver vorher einschalten.
Ich hab ihn gestartet. Die Replikation funktioniert so weit.
Rejects gibts seit gestern Abend keine mehr, die mit der Sache zu tun haben. Alle Objekte habe ich gestern Abend auch gelöscht. Die unter “Deleted Objekts” wurden alle bis eben vom Tombstone entfernt. Diesen Teil habe ich daher übersprungen.
Das Rechnerkonto war wie gesagt nicht mehr vorhanden. Beim Neuanlegen über die UMC tritt der Fehler leider wieder auf
Wie wäre es, wenn ich das Konto mal in einem anderen Container anlegen würde? Könnte das was bringen?
Was ist eigentlich mit “samba-tool dbcheck”? Macht es Sinn, das mal laufen zu lassen?
Edit: Findet leider auch nichts. Bei “samba-tool drs showrepl” gibt es übrigens auch Einträge unter “OUTBOUND NEIGHBORS”, alle mit “Last success @ NTTIME(0)”. Ist das ein Problem?
Hm so findet es was (ausgeführt auf dem Backupserver, aber auf dem Master findet er den Konflikt auch):
# samba-tool dbcheck --check-for-conflicts
[...]
Delete the conflict object or delete the non-conflict object and rename the conflict object to CN=hostname,CN=bla,CN=windows,CN=Computers,DC=top2,DC=top1?
[1] delete the conflict object CN=hostname\0ACNF:Zensiert,CN=bla,CN=windows,CN=Computers,DC=top2,DC=top1
[2] delete the non-conflict object CN=hostname,CN=bla,CN=windows,CN=Computers,DC=top2,DC=top1 and rename the conflict object to CN=hostname,CN=bla,CN=windows,CN=Computers,DC=top2,DC=top1
[3] none
What do you want to do ['1', '2', '3']? 2
Failed to delete DN CN=hostname,CN=bla,CN=windows,CN=Computers,DC=top2,DC=top1 : (66, 'subtree_delete: Unable to delete a non-leaf node (it has 1 children)!')
Failed to rename object CN=hostname\0ACNF:Zensiert,CN=bla,CN=windows,CN=Computers,DC=top2,DC=top1 into CN=hostname,CN=bla,CN=windows,CN=Computers,DC=top2,DC=top1 : (68, 'Entry CN=hostname\\0ACNF:Zensiert,CN=bla,CN=windows,CN=Computers,DC=top2,DC=top1 already exists')
Checked 542 objects (0 errors)Anscheinend habe ich es jetzt hingekriegt. Zuerst habe ich das Unterobjekt gelöscht und das Tool wieder ausgeführt, diesmal erfolgreich.
Dann war es aber noch nicht vorbei. Anschließend konnte ich doch auf jeden DC noch ein “0ACNF”-Objekt finden, was ich seperat löschen mußte. Zuletzt habe ich das Konto über die UMC neu angelegt und bis jetzt scheint alles in Ordnung zu sein.
@Michael Vielen Dank für deine Hilfe. Ohne dich hätte ich es vermutlich nicht geschafft.
Hallo,
freut mich, dass du es lösen konntest
Das allermeiste hast du ja aber schon selber gemacht, ich hab nur bisschen Theorie geliefert.
Schönen Gruß,
Michael