General discussion on installation and configuration of SOGo

Text archives Help

Re: [SOGo] Any way to backup and restore shared calendars?

Chronological Thread 
  • From: "Zhang Huangbin" ( ) < >
  • To:
  • Subject: Re: [SOGo] Any way to backup and restore shared calendars?
  • Date: Wed, 23 Aug 2017 00:45:37 +0800
  • Dmarc-filter: OpenDMARC Filter v1.2.0 52196BAA07A

> On Aug 22, 2017, at 11:28 PM, Christian Mack
> ( )
> < >
> wrote:
> Yes, a user has write privilege on his attributes including
> userPassword, but other users and Admin users don't.
> Backup is done with the admin user only, there is no bind for the user,
> as there is no user to type in the password.

OK, so SOGo queries LDAP server to get full DN of login user first,
then bind as user dn and login password for login authentication.
[Tested on a VM moment ago, after restarted memcached, it works
this way.]

Do i understand correctly that the bindDN queries only login user’s
LDAP dn, no other attributes? If yes, i’d like to create a new bind dn
with only ‘dn’ access for SOGo.

According to SOGo document, parameter “bindAsCurrentUser”
and “bindFields” are required to always bind as authenticated user,
but no sample setting for “bindFields”? "An array of fields to use when
doing indirect binds”, what kind of array?

Also, please consider implementing the placeholder support in
“baseDN”, “bindDN” and “filter” (used in sogo.conf) like requested in
bug report:

With placeholder support:

- It saves the first query used to get user dn - because we can use
user's full ldap dn with placeholders as bindDN. For example:


- It also helps implement per-domain global address book - if domain
accounts are stored in same ldap container, we can use it as baseDN.
For example:


I asked for paid development support days ago, but you guys were
too busy and no time to reply. :(

> I disagree here, and the data security laws in Germany alike.
> We have over 60 services on this LDAP.
> Every one has its own admin user and he can only access those attributes
> necessary for his service.
> With that a security breach on one service can be handled without
> changing all other services too.
> And a security breach on one service does never reveal all data of the user.

Thanks for sharing. i agree that different bind DNs with different ACL
is better for security.

Back to sogo backup data, are these Germany laws also applicable to
force applications (SOGo, in our case) not to store unnecessary data
(“userPassword” and other ldif data in our case) in backup file?

I want to understand why SOGo needs user’s full LDIF data in backup
file (no laws involved, just software design), because it doesn’t make
any sense to me — it should store only the login username (a unique
user id) instead of full LDIF data.

Zhang Huangbin, founder of iRedMail project:
Time zone: GMT+8 (China/Beijing).
Available on Telegram:

Archive powered by MHonArc 2.6.18.

Top of page