Frische 4.3 Installation

Apps & App Center
12

Huhu,

Was hier genau passiert, dürfte das folgende sein:

  1. Vor der Installation von Kopano existiert eine Benutzerin, nennen wir sie sabine. Da Kopano noch nicht installiert ist, kann sabine logischerweise keine Kopano-LDAP-Attribute gesetzt haben.
  2. Kopano wird installiert. Bei der Installation werden Benutzer nicht verändert, wohl aber die Benutzervorlagen. In den Vorlagen wird das »Kopano-Rolle«-Attribut auf »Kopano-User« gesetzt.
  3. sabine kann sich an Kopano nicht anmelden, weil es bei ihr weiterhin kein Kopano-LDAP-Attribut gibt.
  4. Beim Bearbeiten von sabine in der UMC wird aber als »Kopano-Rolle« = »Kopano-User« angezeigt. Warum? Naja, weil die Drop-Down-Box schlicht den Fall »das Attribut ist im LDAP gar nicht gesetzt« nicht vorsieht. Daher wird sie auf ihren Standardwert gesetzt, was »Kopano-User« ist. In diesem Moment spiegelt die Anzeige in der UMC also nicht die Relität im LDAP-Baum wider.
  5. Speichert man nur, ohne auch nur etwas manuell zu verändern, so sieht die UMC, dass Formularwert »Kopano-Rolle = Kopano-User« nicht mit LDAP-Wert »Attribut gar nicht gesetzt« übereinstimmt, sieht also eine Änderung, und fügt deshalb das LDAP-Attribut hinzu.
  6. Ab sofort hat sabine das LDAP-Attribut dran, Kopano sieht es und erkennt sie als Benutzerin, und sabine kann sich in Kopano anmelden.
  7. Legt man jetzt einen neuen Benutzer an, z.B. klaus, so wird hierbei die in Schritt 2 angepasste Benutzervorlage genommen. Dadurch wird beim Speichern das Attribut auf »Kopano-User« gesetzt. Der neue klaus kann sich somit sofort in Kopano anmelden, weil Attribut vorhanden und richtig gesetzt.

Dass das ganze sich so abspielt, belegt auch die Warnmeldung, die man in Schritt 4 beim Bearbeiten von sabine von der UMC angezeigt bekommt:

DeepinScreenshot_select-area_20180525151352
DeepinScreenshot_select-area_20180525151352621×148 13.6 KB

Letztlich ist das ein Bug, ja, in der UMC oder den Kopano4UCS-Paketen oder wo auch immer. Eigentlich müsste »Attribut nicht vorhanden« von der UMC so gewertet werden wie »Attribut vorhanden und auf Wert none gesetzt«, denn das ist die funktionale Entsprechung aus Sicht von Kopano. Aus funktionaler Sicht der UMC sind die beiden Szenarien aber durchaus unterschiedlich; rein LDAP-semantisch sind »Attribut nicht vorhanden« und »Attribut vorhanden und auf Wert XYZ gesetzt« sehr wohl sehr unterschiedlich.

Vermutlich wird man dieses Problem zwecks Rückwärtskompatibilität nicht in den Kopano4UCS-Paketen fixen können (meine Einschätzung als jemand, der kein Kopano4UCS-Entwickler ist).

Ein theoretischer Workaround wäre, bei Installation von Kopano das Attribut kopano4ucsRole für alle bereits existierenden Accounts hinzuzufügen und zu setzen. Das ist aber aus mehreren Gründen nur theoretisch eine tolle Idee, z.B.:

  1. In UCS@school-Umgebungen und größeren Firmen kommen schnell mehrere 1000 Benutzer zusammen. Die alle zu modifizieren, dauert seine Weile.
  2. Damit würden auch ein Haufen Funktionsaccounts zu Kopano-Postfächern, auch wenn man das oft gar nicht will (z.B. administrator oder falls man einen Account zum Durchsuchen des LDAPs anlegt oder oder doer).

Gruß
mosu