Outlook Nutzung eines fremden Postfaches per grommunio-admin einrichten

fxb

Hallo Community,

wir nutzen die aktuelle Grommunio Subscription Version auf einem Debian 13. Genutzt wird Outlook in einer aktuellen Version, z.B. 2021 H&B / LTSC, 2024 H&B / LTSC (ist für diesen Fall egal, das Problem tritt überall da auf).

Angenommen wir haben ein Postfach info@meinedomain.de und einen Benutzer user@meinedomain.de .

Die automatische Einbindung der Ansicht des Postfach info@ im Outlook beim Benutzer user@ funktioniert nur dann, wenn der zusätzliche store owner in der Grommunio Verwaltung in der GUI eingefügt wird.

Wenn ich auf der Shell per
grommunio-admin exmdb info@meinedomain.de folder grant 0x9 user@meinedomain.de storeowner einrichte, dann ist die so gesetzte Berechtigung in der Grommunio Verwaltung bei dem Postfach info@ unter Permissions / Additional store owners sichtbar. Im Outlook des Benutzers user wird dieses Postfach aber nicht automatisch zur Ansicht hinzugefügt. Das funktioniert so nicht.

Das gleiche ist wohl auch bei der Berechtigung sendas der Fall. Auf der Shell per
grommunio-admin user sendas info@meinedomain.de add user@meinedomain.de funktionert nicht nutzbar im Outlook. Das muss in der Grommunio GI zusammengeklickt werden.

Um das Problem zu lösen bleibt im Moment nur: in der GUI erst die per Shell eingerichtete Berechtigung beim Benutzer löschen, die Einstellung speichern, dann die Berechtigung wieder setzen und wieder speichern.

Gibt es dafür eine Lösung? Muss zusätzlich zum grommunio-admin Befehl noch etwas anderes angegeben werden?

WalterH

Man muss zwischen Rechten auf einen Ordner und das Recht die ganze Mailbox zu verwenden unterscheiden. Der Befehl mit "folder grant 0x9" erstellt nur ein Recht auf einen Ordner.
In der GUI kann man die "Full Permissions" auf eine Mailbox setzen und nur diese werden vom Autodiscover ausgewertet und dem Outlook mitgeteilt, damit der Outlook die Mailbox automatisch einbindet.
"Send as" kann man auch im GUI neben den "Full Permissions" setzen. Optional kann man "Full Permissions" auch über die Command Line setzen.

fxb

WalterH Man muss zwischen Rechten auf einen Ordner und das Recht die ganze Mailbox zu verwenden unterscheiden. Der Befehl mit "folder grant 0x9" erstellt nur ein Recht auf einen Ordner.
In der GUI kann man die "Full Permissions" auf eine Mailbox setzen und nur diese werden vom Autodiscover ausgewertet und dem Outlook mitgeteilt, damit der Outlook die Mailbox automatisch einbindet.

Danke für die Antwort. Ja, Problem verstanden, so etwas in der Art habe ich mir gedacht.

Zurück zur Frage:
Gibt es eine Möglichkeit mit einem Befehl über die Shell die ganze Mailbox einem anderen Nutzer so freizugeben wie man es in der GUI kann und wenn ja: wie?

Steakie

WalterH Direkt nebendran ist auch "Folders", was ein GUI für g-admin exmdb commands bereitstellt @fxb

WalterH

Sollte so funktionieren:
grommunio-admin exmdb your@mailbox.tld folder grant 0x9 userwithfullrights@mailbox.tld 0x2000
Allerdings werden die rechte immer als 0x2800 (freebusysimple,storeowner) gesetzt anstelle von 0x2000 (storeowner), Muss man noch nachprüfen.

fxb

WalterH Sollte so funktionieren:
grommunio-admin exmdb your@mailbox.tld folder grant 0x9 userwithfullrights@mailbox.tld 0x2000
Allerdings werden die rechte immer als 0x2800 (freebusysimple,storeowner) gesetzt anstelle von 0x2000 (storeowner), Muss man noch nachprüfen.

Ich habe das eben mit mehreren komplett neuen Postfächern geprüft. Das funktioniert so nicht.

Ja, das Recht auf die oberste Ebene / den Ordner 0x9 wird mit 0x2800 gesetzt auch wenn man 0x2000 angegeben hat.
Aber auch hier wird das Postfach nicht automatisch im Outlook des anderen Rechteinhabers angezeigt.

Welche Möglichkeiten gibt es noch?

WalterH

Ich vermute, das es mit 0x2800 zu tun hat. Hat meiner Meinung nach vor längerer Zeit schon mal funktioniert, so habe ich das in meiner Dokumentation stehen. Ich mache ein Suopport Ticket auf.

fxb

WalterH Hat meiner Meinung nach vor längerer Zeit schon mal funktioniert

Unsere ältesten Installationen sind etwas über 3 Jahre alt. Wir haben das Thema damals so nicht verfolgt, daher kann ich nicht sagen ob das damals / jemals funktioniert hat.
Aber seit längerem (mind. 1 Jahr) skripten wir das alles und da hat es lt. unserer Erfahrung noch nie funktioniert.

Danke für das Ticket. Du weißt eher was da reingehört 😉

fxb

Wenn ich das auf der Shell mit z.B.

PASS="superstrenggeheim" gromox-dscli -e user@meinedomain.de -v

teste, dann unterscheidet sich die Antwort die per Autodiscover als XML ausgeliefert wird.

Die Postfächer, die per Gromunio GUI ihre Rechte bekommen haben, werden bei den berechtigten Benutzern in der XML Antwort im Tag <AlternativeMailbox> mit dem Typ Delegate und weiteren Daten aufgeführt.

Bei den Postfächern, bei welchen die Berechtigung auf der Shell vergeben wurde (ich habe schon so einige Kombinationen probiert, auch zusätzlich sendas und delegates) fehlen bei den berechtigten Nutzern diese Daten komplett. Da sind nur die öffentlichen Ordner beschrieben aber keine zusätzlichen Benutzerpostfächer.

fxb

Steakie Direkt nebendran ist auch "Folders", was ein GUI für g-admin exmdb commands bereitstellt

Ja, ist bekannt dass es diese Stelle in der GUI gibt. Ich sehe nur nicht was uns das nutzt.

Unser Problem ist es, dass wir nach Möglichkeit alles skripten wollen (müssen, auf Grund der Menge) und dafür eben keine GUI verwenden wollen sondern die Shell.

WalterH

Das ist die Antwort vom Support:

Das Setzen von storeowner Rechten über grommunio-admin exmdb sorgt nicht automatisch für den Eintrag den man für den Automount braucht. Hierfür müssen in der mysql-DB grommunio in der Tabelle secondary_store_hints noch die entsprechenden UserIDs hinzugefügt werden. Ein Entwickler Ticket gibt es dafür schon.

fxb

WalterH Hierfür müssen in der mysql-DB grommunio in der Tabelle secondary_store_hints noch die entsprechenden UserIDs hinzugefügt werden.

Danke dafür.
Ja, genau das hatte mir cursor auch schon geschrieben:

mysql grommunio -e "
INSERT IGNORE INTO secondary_store_hints (\`primary\`, \`secondary\`)
SELECT u1.id, u2.id
FROM users u1
JOIN users u2
WHERE u1.username = 'benutzer1@mailbox.tld'
  AND u2.username = 'benutzer2@mailbox.tld';
"

Das habe ich noch nicht probieren wollen. Das ist nicht mehr minimalinvasiv 😉

Ein schwacher Versuch ist die Grommunio REST API:
https://docs.grommunio.com/dev/api/operations/poststoreaccessuser/
Auch das habe ich noch nicht probiert, da für diesen Fall auf der Shell wieder andere Zugangsdaten (die des config admin) vorher eingeholt und genutzt werden müssen.

Ich bevorzuge grundsätzlich die dafür vorgesehen einfachen Wege mit den Gromunio CLI Befehlen. Wenn das aktuell damit (noch) nicht geht und die Not größer wird (Grommunio Neuinstallation / zu viele Änderungen), dann würde ich auf meiner Testinstallion doch mal testen müssen. Das wollte ich vermeiden :\

fxb

Hinweis für Andere und mich (später): ich habe das eben kurz getestet und das funktioniert.

Ich habe folgendes gemäß o.b. Beispiel ausgeführt:

mysql grommunio -e "
INSERT IGNORE INTO secondary_store_hints (\`primary\`, \`secondary\`) 
SELECT u1.id, u2.id FROM users u1 
JOIN users u2 
WHERE u1.username = 'user@meinedomain.de'  AND u2.username = 'info@meinedomain.de';
"

Vorausgesetzt der Grommunio Benutzer user@meinedomain.de hat Vollzugriff auf das Postfach des info@meinedomain.de, dann erscheint kurze Zeit später automatisch per Automap im Outlook (und nach einem Outlook Neustart) des user@meinedomain.de das Postfach info@meinedomain.de in der Ansicht.

Die Ansicht aller per Autodiscover so freigegebenen Postfächer kann auch erfolgen mit:

mysql grommunio -e "
SELECT p.username AS outlook_user, s.username AS attached_mailbox 
FROM secondary_store_hints h 
JOIN users p ON p.id = h.primary 
JOIN users s ON s.id = h.secondary;
"

Ergebnis wäre gem. Beispiel (wenn es nur ein solch freigegebenes Postfach auf dem Grommunio gäbe):

+------------------------+-----------------------+
| outlook_user           | attached_mailbox      |
+------------------------+-----------------------+
| user@meinedomain.de    | info@meinedomain.de   |
+------------------------+-----------------------+

WalterH

Freut mich, das es funktioniert.

fxb

WalterH Freut mich, das es funktioniert.

Danke, hat ein klein wenig Nerven gekostet und einiges an Zeit die Probleme die dadurch bei den letzten Installationen und Änderungen und überhaupt entstanden sind (alles per Skript eingerichtet um dann das wieder mit Geklicker zu entfernen und neu zu setzen) zu beheben. Wir behalten das bis auf Weiteres so bei.

Neues Problem evtl. in Folge dessen. Bevor ich nun einen neuen Thread aufmache (evtl. später) setze ich das erst einmal hier drunter.

Wenn ich die Testbenutzer auf dem System löschen will, dann geht das nicht. In der GUI kommt der Fehler:
The Server encountered an Error while processing the request.
Auf der Shell sieht das so aus:

root@mail:~# grommunio-admin user delete -y user@meinedomain.de
Deleting user 'user@meinedomain.de' (11)
Unloading store...[WARNING] (exmdb@default) ExmdbProtocolError('exmdb call failed: Dispatch error')
An error occurred: ExmdbProtocolError('exmdb call failed: Dispatch error').

Grommunio ist aktuell.

dpkg-query -Wf '${Package;-40}${Version;-30};${Maintainer}\n' ${1-} | awk -F\; '/(grommunio|gromox)/ {print $1}';
grommunio-admin-api                     1.20.7.mcafa3b7-1+9.1
grommunio-admin-common                  50.m7.63d8d12-1+2.1
grommunio-admin-web                     5.0.0.40.4ef2318-1+37.1
grommunio-common                        29.13-1+6.1
grommunio-dav                           1.6.24.84942ef-1
grommunio-dbconf                        1.1.2.4bbae9a-1+39.1
grommunio-error-pages                   1.0.10.bb2df37-1+38.1
grommunio-index                         1.6.6.gcc52131-1+1.1
grommunio-sync                          2.4.22.e31e33a-1
grommunio-web                           3.18.46.g9248468db-1+67.1
gromox                                  3.8.9.9df9502-1+4.1
libesedb1                               20240220-1+3.5
libexmdbpp0                             1.11.17.14d8ad1-1+304.1
libhx43                                 5.3-1+1.2
libolecf1                               20240427-1+2.5
libpff1                                 20231205-1+2.5
mapi-header-php                         2.1.28.8626d7e-1+12.1
nginx-module-vts                        0.2.5-1+1.2
python3-mattermostdriver                7.3.2-1+19.2
python3-pyexmdb                         1.11.17.14d8ad1-1+304.1
system-user-grommunio                   9-1
system-user-gromox                      9-1

Wurde dieses Problem anderswo schon beschrieben? Gibt es eine schnelle (hoffentlich einfache) Lösung?

crpb

systemctl restart gromox-http und noch mal probieren.

fxb

crpb systemctl restart gromox-http und noch mal probieren.

Keine Ahnung warum es jetzt - aber nur teilweise! - funktioniert.

Ich hatte die ganze Maschine vorhin schon einmal neu gestartet. Ungeachtet dessen dass der Dienstneustart jetzt (Stunden später) wenig bringen sollte habe ich auch das noch einmal gemacht - wider besseren Wissens.

Immerhin: 3 von 4 Benutzern ließen sich jetzt so problemlos löschen. Beim dem vierten ging es eben nach wie vor nicht, die Meldung bleibt.

Ich habe den Dienst jetzt noch 2x (!) neu gestartet (die Hoffnung stirbt zuletzt) und - oh Wunder: auch der letzte Testbenutzer liess sich so löschen.

Gibt es eine reale (für mich) nachvollziehbare Erklärung dafür?

crpb

fxb Gibt es eine reale (für mich) nachvollziehbare Erklärung dafür?

Also ich hatte bei dem problem nur die vermutung das noch zugriff von anderen personen/konten in dem moment bestehen. Aber auch nachdem die rechte (erst vollzugriff und später noch mal einzeln kalender) entfernt worden sind ging es dann den darauf folgenden oder sogar nach zwei tagen immer noch nicht. Also dachte ich das es evtl. noch irgend ein outlook gibt was schon seit tagen läuft und hab dann schließlich den dienst neu gestartet und konnte dann direkt das konto löschen. Habe es aber auch nicht weiter verfolgt oder versucht zu reproduzieren. Und die kiste wurde in der zeit auch täglich neu gestartet aus anderen gründen und somit war es das dann auch nicht.
Evtl. gibt es auch ein "lock" durch zugriff vom indexer... keine ahnung.

WalterH

Hatte ich vor ein par Tagen auch dieses Problem, am nächsten Tag war die Mailbox löschbar.

MichaelN

Ich hatte das gleiche Phänomen auf meiner Test-Maschine.
Als ich dem Test-Account die Vollberechtigung gegeben hatte und den mysql Eintrag von Hand
gemacht hatte, hat die Outlook-Geschichte funktioniert.

Aber ich konnte gestern den Account mit obiger Fehlermeldung nicht mehr löschen, obwohl Outlook geschlossen und das Grommunio neu gestartet wurde.

Erst heute morgen hat es dann irgendwann wie von Geisterhand funktioniert.
Es muß aber irgendwas mit der Vollberechtigung/Mysql-Eintrag zu tun haben. Andere Accounts konnte ich problemlos direkt löschen