Hello Warning, this is a bit long :-)
First you have to grasp the principle of authentication sources.Authentication sources are Files or databases or LDAP/ActiveDirectory servers providing information used to authenticate an user. Usually they contain a unique identifier commonly called "user name" and some sort to authenticate like password and/or certificate and/or TOTP secret. They also store additional information used to grant access privileges for that user on a per service base.
Dovecot and SOGo are two distinct services. They have nothing in common, and don't know anything about each other.That is fine, as they provide their services via interfaces which are standardized internationally.
SOGo is a user interface provides via HTTP or (better) HTTPS.It stores user provided information like sessions, settings, calendars + events and address books + address cards in a relational database. It uses internally e.g. IMAP in order to access postboxes of users on any IMAP capable postbox server.
Dovecot is such an IMAP capable postbox server.In your scenario you want to use your SOGo service only with your dovecot service.
Therefore they have to use the same authentication source.But they need different additional information from that authentication source, in order to provide their service.
You use a MySQL database as authentication source. That has to provide the informations for both services.You have to set that information for every user in that database, before that user can login to either service.
When that information is provided, then the user can successfully login to SOGo. SOGo will initialize the informations for that user in SOGo, like create its personal calendar and adress book and store its initial settings. Then it also will contact the configured IMAP server, and will authenticate to it with the given credentials.
As That IMAP server is your dovecot, and they share the same authentication source, the user will login successfully the first time into dovecot. dovecot will then initiate the postbox of that user with the information given to it from the authentication source and its configuration.
In order to access the matching information from the "storage_keys" database, there has to be a connetcion between the user in the authentication source "users" Table and the user_id.
Hope that helps a bit. Kind regards, Christian Mack Am 27.07.22 um 16:32 schrieb Serveria Support ([email protected]):
Hey guys,I'm looking to setup a mail server with encrypted storage. I'm planning to use Dovecot mailserver + crypt or trees plugin for per-user encryption + SOGO for webmail/groupware. Encryption plugins need to store some additional data like password hash algo, salt etc. (see example scheme below) in SQL:CREATE TABLE `storage_keys` ( `id` int(11) NOT NULL AUTO_INCREMENT, `enabled` tinyint(4) DEFAULT '1', `version` tinyint(4) DEFAULT '1', `public_key` text, `pwhash_algo` tinyint(4) DEFAULT '1', `pwhash_opslimit` int(11) DEFAULT NULL, `pwhash_memlimit` int(11) DEFAULT NULL, `pwhash_salt` varchar(255) DEFAULT NULL, `sk_nonce` varchar(255) DEFAULT NULL, `locked_secretbox` text, `user_id` int(11) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT DEFAULTHow can I make it work with SOGO? So far, at a first glance, there's a table named 'users' in SOGO db which contains usernames, passwords etc of SOGO users. However, it's not very clear how Dovecot is communicating with SOGO? Dovecot users = SOGO users? Or SOGO grabs Dovecot users and copies them into this 'users' table? Perhaps someone here can guide me on how it works and how to connect SOGO with Dovecot crypt plugins properly?BR, Paul serveria.com
-- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung, Lehre, Infrastruktur 78457 Konstanz +49 7531 88-4416
smime.p7s
Description: S/MIME Cryptographic Signature
