UCS@school + read-only AD-Connector + AD

UCS@school
#1

Ich versuche mir ein Bild vom Funktionieren von UCS@School zu machen - als eine sehr interessante Funktion ist mir die WLAN-Steuerfunktion (in dem Fall für Lehrkräfe) ins Auge gestochen.
Die aktuelle Situation ist aber, dass ein AD (mit Exchange) hier steht und das, soweit ich das abschätzen kann auch die “kanonische” Quelle für Authentifizerung bleiben wird, ergo werden die Benutzer auch nur genau dor gepflegt (werden wollen).

Im Moment habe ich somit über den AD Connector einen funktionierenfden read-only sync zwischen UCS und AD. Die Userobjekte sowie AD-Gruppen sind brav rübergekommen.

Um jetzt mal etwas mit UCS@School herumzuspielen, habe ich mal die Pakete installiert und eine Schule erstellen lassen - leider (für unseren Fall) zieht das ganze auch Samba 4 mit rein, was für FreeRADIUS in der Form so nicht absolut notwendig wäre (für andere Funktionen von UCS@School dann durchaus, insofern nachvollziehbar).

Das Problem ist nun, dass UCS@School eine OU für die Schule macht und “Schüler” wie “Lehrer” in der entsprechenden OU abgelegt haben möchte.
Durch den AD-Sync sind die aber in einer OU, wie sie eben vom AD herkommen, inkl. Gruppen. Also weis UCS@School natürlich nicht, wer Schüler und wer Lehrer ist.
Hat das jemand schon einmal gehabt und wenn ja, wo / was für Ansätze gäbe es um so etwas ohne sich zu verbiegen ineinander greifend zu machen (also AD mit UCS@School-Strukturen).
Ich befürchte, dass auf AD-Seite sich kaum OUs verschieben lassen, that said :-\

#2

Hallo,

generell entspricht dies so erstmal keinem dem Standard-Szenario, wesshalb mit erhöhtem Pflege/Einrichtugnsaufwand gerechnet werden sollte.
Bei einer Unidirektionalen Synchronisierung AD -> UCS sollten Sie in der Lage sein, nach dem initialen Sync die Benutzer und Gruppen UCS-seitig an die korrekte Stelle zu verschieben. Nachfolgende Synchronisierungen sollten die entsprechenden Objekte prinzipbedingt weiterhin “finden” können. Hier würde sich ein entsprechendes Testsystem mit Standardszenario anbieten (z.B. ein UCS@School Singlemaster), welchem Sie die Eigenschaften (Rollen, etc.) und Orte der Lehrer- und Schüler-Objekte entnehmen können.

Beachten Sie bitte generell, dass eine Unidirektionale Synchronisation in die andere Richtung UCS -> AD mit deutlich weniger Aufwand verbunden wäre, da dies annähernd out-of-the-box umsetzbar sein sollte.

Mit freundlichen Grüßen,
Tim Petersen

#3

Herzlichen Dank, ein also nicht alltägliches Szenario…

WIr haben effektiv ein UCS@School singlemaster im Test mit Fokus auf FreeRADIUS.

Aus (leidiger) Erfahrung mit der engen Verschränkung von Exchange mit AD sehe ich kaum Chancen, dass eine Unidirektionale Replikation UCS -> AD hier sinnvoll wäre.
Ein Exchange, der seine Benutzer nicht im AD (oder schon nur den Kontakt zu Global Catalogs verliert) streckt schnell die Füsse. Ich denke nur an den Fall mit einer Löschung eines Users
auf UCS-Seite der im AD ein Exchang-Mailbox hat. Ist der AD-User weg wird die Mailbox nicht mehr so einfach erreichbar sein allenfalls nicht mal einfach sauber löschbar sein.

Eine Verschiebung auf UCS-Seite in die korrekten UCS@School OUs von Hand geht, danach klappt es auch weiterhin Gruppen und andere Attribute noch vom AD her zu aktualisieren,
die OU-Verortung bleibt erhalten. - Solange man im AD nicht auf die Idee kommt den User AD-seitig in eine andere OU zu schieben, denn dann landet der User wieder zurück in seiner (neuen) AD OU.

Ich werde mir die Geschichte mit den Berechtigungen/Gruppen/OUs für UCS@School genauer anschauen, allenfalls liessen sich die Gruppen die UCS@School braucht (etwa Klasse) im AD gleich
nennen, so wären diese Elemente schon mal etwas automatisch(er) synchronisierbar. Die Verschiebung in korrekte OUs müsste dann wohl über ein speziell angepasstes Mapping im AD-Connector geshehen.
Heisst wohl noch etwas drüber schlafen und nachdenken.

Danke mal für diese Antwort.

Mastodon