nach dem Upgrade von LMN 7.2 auf LMN 7.3 haben wir folgendes Problem:
Beim Aktivieren des Klassenarbeitsmodus für eine beliebige Klasse erscheint bei jedem Schüler ein rotes Rechteck mit der Aufschrift
Im Moment ist es nicht möglich, das Verzeichnis für das Teilen im Home-Verzeichnis eines anderen Lehrers zu erstellen oder ihre Verwaltungsgruppen zu verwalten.
Aus der Fehlermeldung werde ich zwar nicht ganz schlau, vermute jedoch, dass hier irgendein Berechtigungsproblem vorliegt.
Die Homeverzeichnisse der Examusers werden zwar in /srv/samba/schools/default-school/examusers erstellt, allerdings können sich die SuS weder mit ihrem regulären Usernamen schueleruser, noch mit dem Examusernamen schueleruser-exam am Client anmelden.
Ein sophomorix-user -iu schueleruser | grep -i exammode gibt folgendes aus
sophomorixExamMode: lehreruser
Über die WebUi kann der Klassenarbeitsmodus nicht mehr beendet werden. Das geht nur noch mit sophomorix-exam-mode --unset --participants schueleruser. Danach kann man sich wieder am Client mit dem Benutzer schueleruser anmelden.
Woran könnte das liegen? @Arnaud: Wie kann ich das Problem sinnvoll debuggen?
Es gibt manchmal am Start Kompilierungsfehler oder SSL-Meldungen, das sollte nicht relevant sein. Was wichtig ist, ist was passiert nach dem Start von KA-Modus.
vielen Dank für den Tipp mit dem Dev-Mode. Nachdem ich mir die Ausgaben angeschaut habe, war relativ schnell klar, dass es nicht an der Webui liegt, wie Du ja auch schon vermutet hast.
Also ging die Suche weiter.
In den letzten Wochen habe ich mehrere Anläufe genommen, den Fehler zu finden und bin nun endlich der Ursache auf die Schliche gekommen.
zeigten, dass kein neuer Benutzer schueleruser-exam angelegt werden konnten:
##################################################################################
# Creating examuser for user: schueleruser (start) #
##################################################################################
...
ERROR in Sophomorix::SophomorixSambaAD::AD_examuser_create:
0000202F: lib/ldb/ldb_key_value/ldb_kv_index.c:3065: Failed to re-index objectSid in CN=schueleruser-exam,OU=Examusers,OU=default-school,OU=SCHOOLS,DC=DOMAIN,DC=TLD - lib/ldb/ldb_key_value/ldb_kv_index.c:2910: unique index violation on objectSid in CN=schueleruser-exam,OU=Examusers,OU=default-school,OU=SCHOOLS,DC=DOMAIN,DC=TLD
...
Dieser Fehler tauchte beim Upgradevorgang bei der der Installation vom Paket linuxmuster-tools7 ebenfalls auf und zwar an der Stelle, wenn die Klassen auf die neuen Gruppen klassenname-parents und klassenname-students geprüft werden:
...
Checking students groups from schoolclass klassenname
{'msgtype': 105, 'msgid': 2, 'result': 19, 'desc': 'Constraint violation', 'ctrls': [], 'info': '0000202F: lib/ldb/ldb_key_value/ldb_kv_index.c:3065: Failed to re-index objectSid in CN=klassenname-parents,OU=klassenname,OU=Students,OU=default-school,OU=SCHOOLS,DC=DOMAIN,DC=TLD - lib/ldb/ldb_key_value/ldb_kv_index.c:2910: unique index violation on objectSid in CN=klassenname-parents,OU=klassenname,OU=Students,OU=default-school,OU=SCHOOLS,DC=DOMAIN,DC=TLD'}
...
Der gleiche Fehler tauchte bei uns auch schon einmal im September 2024 auf
und konnte damals nur durch das Zurückspielen eines Backups behoben werden.
Analyse
Komisch dabei war jedoch, dass wohl für einige der Klassen die neuen Gruppen angelegt werden konnten und ab irgendeiner Klasse eben nicht mehr.
Da ich mehrere Upgradeversuche mit unterschiedlichen Ausgangszuständen der LMN 7.2 unternommen habe, konnte ich die Constraint violation leider nicht auf eine bestimmte Klasse eingrenzen.
Bei der Recherche dieses Fehlers und dessen Ursache im Netz las ich immer wieder, dass die Constraint violation immer dann auftritt, wenn versucht wird, ein Objekt im AD mit einer objectSid anzulegen, die bereits an ein anderes Objekt im AD vergeben wurde. Da ich ein absoluter DAU bin, konnte ich mir darauf aber keinen Reim machen.
Wie um alles in der Welt kann ich herausfinden, welche objectSid des neu anzulegenden Objekts verwendet wird?
Jede objectSid (Object Security Identifier) ist wie folgt aufgebaut:
S-1-5-21-<DomainID>-<RID>
Die DomainID ist für alle objectSid gleich, die RID (Relative Identifier) ist eine fortlaufende Nummer. Mit dem Anlegen eines neuen AD-Objekts wird die RID jeweils um 1 inkrementiert. Somit wird sichergestellt, dass jede objectSid im AD eindeutig ist.
Damit das AD immer weiß, welche RID für das zuletzt im AD angelegte objectSid erfolgreich vergeben wurde, wird dieser Wert im RID Set des Domänen Controllers im Attribut rIDNextRID gespeichert und kann wie folgt abgefragt werden:
Bleibt nur noch zu überprüfen, ob die rIDNextRID mit der höchsten RID übereinstimmt, die an ein im AD existierenden Objekt vergeben wurde. Dazu lässt man sich alle objectSid im AD auflisten, filtert die RID heraus, sortiert diese numerisch nach der Größe und gibt nur die letzte RID aus:
Passt doch!
Aber warum kommt es dann trotzdem zu einer Constraint violation?
Um das zu verstehen, muss man folgendes wissen: Werden Objekte im AD gelöscht (z. B. beim Beenden einer Püfung in der Webui), werden diese nicht sofort restlos aus dem AD entfernt, sondern landen als sogenannte Tombstones im versteckten AD-Zweig „Gelöschte Objekte“. Durch Hinzufügen des Schalters --show-deleted in obigem ldbsearch-Kommando kann man sich zusätzlich die objectSid der gelöschten Objekte ausgeben lassen:
Hoppla! Offenbar gibt es in meinem Fall vier Objekte im AD, die eine größere RID haben als im Zähler rIDNextRID abgespeichert. Will man nun ein neues Objekt im AD anlegen, dann würde dieses die objectSid mit der RID15497 bekommen. Weil im AD jedoch bereits ein Objekt mit genau dieser objectSid existiert, schlägt das Anlegen des neuen Objekts mit einer Constraint violation fehl.
Lösung
Um im AD wieder neue Objekte anlegen zu können, müssen wir die rIDNextRID im RID Set anpassen, und zwar auf die höchste im AD vorkommende RID, in diesem Fall auf die Nummer 15500. Dazu muss man das Attribut rIDNextRID im RID Set direkt in der Datei sam.ldb mittels ldbedit verändern (Editierung erfolgt mittels Editor vi). Achtung: Mit ldbedit kann man sich unter Umständen das komplette AD zerschießen.
→ Vorher ein Backup der Datei /var/lib/samba/private/sam.ldb oder einen Snapshot erstellen. You have been warned!
Et voilà! Das Anlegen von Prüfungen über die Webui ist wieder möglich.
Ursachenforschung
Bleibt noch die Frage zu klären, wie es überhaupt dazu kommen konnte, dass im AD Objekte existieren, die eine höhere RID haben, als im Attribut rIDNextRID des RID Set hinterlegt ist. Dazu ließ ich mir mit
Diese Objekte stammten nachweislich von einem Upgrade-Versuch auf LMN 7.3, der in den Herbstferien stattfand. Neben dem AD als Primary-DC (server) läuft in unserem Netz noch ein zweiter Full DC (dc2). Aus irgendwelchen Gründen kam es wohl zu einem Replikationsfehler.
Eine mögliche Erklärung dafür ist, dass beim Zurückspielen eines Snapshots der server-VM versehentlich nicht berücksichtigt wurde, dass die dc2-VM auf gleichen Zeitpunkt zurückgesetzt werden muss. Dann nämlich repliziert dc2 seinen aktuelleren Stand Richtung server. Allerdings werden dabei nur die Objekte repliziert, die einen neueren Stand haben, als im Primary DC. Da das Attribut rIDNextRID des RID Set ausschließlich auf dem Primary DC existiert, wird der RID-Zähler mit dem Zurückspielen des Snapshots auf einen früheren Stand zurückgesetzt, der natürlich kleiner ist als die höchste im AD existierende RID.
… was für eine Geschichte.
Ich hab das jetzt gelesen, wie damals die Hackergeschichten in der ct … so spannend war das.
Mein größten Respect für deine Ausdauer!
diese Frage kann ich dir leider nicht beantworten, das hat wohl historische Gründe. Aber ja, ich gebe Dir recht, ein RODC würde für den aktuellen Anwendungsfall absolut ausreichen und es ist bereits geplant, den Full DC gegen einen RODC auszutauschen.
der zweite beschreibbare AD-DC war damals mit der SAMBA Version 4.7.6 von Ubuntu 18.04 LTS die empfohlene Lösung. Zwar sollte ab SAMBA 4.7.6 RODC nicht mehr experimentell sondern secure sein, in der Praxis gab es aber immer wieder Probleme damit und ein Einsatz eines RODC wurde erst nach dem Upgrade auf lmn7.2 empfohlen Externer LDAP/AD Mirror lmn 7.x - #44 von Maurice
Das SAMBA-Projekt führt RODC weiterhin als offenes/weiterzuentwickelndes Feature im Roadmap-Bereich „Active Directory Server“. Roadmap - SambaWiki
In der Praxis heißt das:
RODC kann funktionieren (v.a. Branch-Office/“schlechte Physische Security”, wo man bewusst keinen RW-DC hinstellen will), aber für “wir wollen einfach Redundanz/Failover und Ruhe” ist ein zweiter vollwertiger RW-DC in Samba-land meistens die robustere, weniger „kantenreiche“ Wahl – genau weil manche Windows-RODC-Mechaniken in Samba bis heute nicht 1:1 so umgesetzt sind. Samba Security Documentation - SambaWiki
Ein SAMBA 4 RODC ist eben im Moment noch kein AD-Light den man mal eben mit dazu stopfen kann.
Ein Beispiel:
Client wählt einen DC (DC Locator / Site / DNS SRV / Caches). Mal landet der Client bei einem writable DC, mal bei einem RODC. Passwort ändern (STRG+ALT+ENTF → Kennwort ändern) ist eigentlich ein Use-Case, der bei Windows-RODCs funktioniert, weil der RODC die Änderung an einen RW-DC weiterleiten (proxy) soll. Microsoft Learn Samba-RODC macht dieses Proxying aber nicht: Samba lehnt Passwortänderungen am RODC schlicht ab („proxying behaviour is not implemented“). SambaWiki
Ergebnis in der Praxis:
Trifft der Client beim Kennwortwechsel einen RW-DC → klappt.
Trifft er einen Samba-RODC → schlägt fehl.
Aus Sicht der Anwender: „mal geht’s, mal nicht“ – abhängig davon, welcher DC gerade erwischt wird.
Ergebnis: IT direkt aus der Hölle
Wenn RODC, dann sollte man den auch als solchen betrachten und z.B. in die DMZ stopfen, wo er z.B. externe LDAP-Anfragen (Moodle, Webuntis etc.) bedient (sofern man hier nicht bereits andere IAM-Methoden einsetzt).
