[SOGo] after upgrade to sogo5.4: [SOGoMailAccount]:0> Could not connect IMAP4 (but LDAP is used as SOGoUserSources, not IMAP)
Hello,
I just upgraded from sogo 4.3 to sogo 5.4 (latest nightly
5.4.0.20220106-1), and after the upgrade the SOGo webinterface
stopped working. I get "Request Failed" in the webinterface, and in
/var/log/sogo.log I see the following:
Jan 06 13:24:17 sogod [19461]: [ERROR]
<0x0x55817727ee20[NGImap4ConnectionManager]> IMAP4 login
failed:
host=127.0.0.1, user=sogo, pwd=yes
url="">
base=(null)
base-class=(null))
= <0x0x558177632fc0[NGImap4Client]: login=sogo(pwd)
address=<0x0x5581771bc730[NGInternetSocketAddress]:
host=127.0.0.1 port=143>>
Jan 06 13:24:17 sogod [19461]:
<0x5581773bb040[SOGoMailAccount]:0> renewing imap4 password
Jan 06 13:24:17 sogod [19461]: [ERROR]
<0x0x55817727ee20[NGImap4ConnectionManager]> IMAP4 login
failed:
host=127.0.0.1, user=sogo, pwd=yes
url="">
base=(null)
base-class=(null))
= <0x0x5581774a6100[NGImap4Client]: login=sogo(pwd)
address=<0x0x5581773e85f0[NGInternetSocketAddress]:
host=127.0.0.1 port=143>>
Jan 06 13:24:17 sogod [19461]: [ERROR]
<0x5581773bb040[SOGoMailAccount]:0> Could not connect IMAP4
Jan 06 13:24:17 sogod [19461]: 10.11.1.51 "POST
/SOGo/so/sogo/Mail/0/folderINBOX/changes HTTP/1.1" 500 36/126
0.005 - - 0 - 16
Jan 06 13:24:17 sogod [19461]: 10.11.1.51 "GET
/SOGo/so/sogo/Calendar/eventsblocks?ed=20220108=20220102=weekview
HTTP/1.1" 500 36/0 0.012 - - 0 - 16
I know about the change to add
"tlsVerifyMode=allowInsecureLocalhost" to the IMAP/SMTP/sieve
connection string: however, I do not use IMAP, SMTP, or Sieve at
all. My usersources are from an LDAP server, and for SMTP I use
sendmail. I could authenticate to my imap server, but the
username, and password would be different to the usernames and
passwords on the LDAP server.
Calendar, contacts work fine from Thunderbird/roundcube as before
(I can add/remove/edit calendar events, send out invites, etc).
However, the webinterface is now completely broken. I does not
show anything at all in the calendar view. The Contacts view
works, but does not show/find any contacts (although they work
from Thunderbird/roundcube). Also the administrative interface is
broken: it doesn't find any users anymore. I still can login, so
the authentification is still working via LDAP.
Is there a way to tell SOGo to ignore IMAP, and not query it, but
instead use LDAP just as it had been used in 4.3?
This is my /etc/sogo/sogo.conf:
{
/* * Main SOGo configuration file
**
*
*
* Since the content of this file is a dictionary in OpenStep
plist format, *
* the curly braces enclosing the body of the configuration are
mandatory. *
* See the Installation Guide for details on the
format. *
*
*
* C and C++ style comments are
supported. *
*
*
* This example configuration contains only a subset of all
available *
* configuration parameters. Please see the installation guide
more details. *
*
*
* ~sogo/GNUstep/Defaults/.GNUstepDefaults has precedence over
this file, *
* make sure to move it away to avoid unwanted parameter
overrides. *
*
*
*
**/
/* Database configuration (mysql:// or postgresql://) */
SOGoProfileURL =
"postgresql://sogo:XXX@localhost:5432/sogo/sogo_user_profile";
OCSFolderInfoURL =
"postgresql://sogo:XXX@localhost:5432/sogo/sogo_folder_info";
OCSSessionsFolderURL =
"postgresql://sogo:XXX@localhost:5432/sogo/sogo_sessions_folder";
/* Mail */
//SOGoDraftsFolderName = Drafts;
//SOGoSentFolderName = Sent;
//SOGoTrashFolderName = Trash;
//SOGoIMAPServer = localhost;
//SOGoIMAPServer =
"imap://127.0.0.1:143/?tls=YES=allowInsecureLocalhost";
//sogo5
//SOGoSieveServer = sieve://127.0.0.1:4190;
//SOGoSMTPServer = smtp.MYDOMAIN.org:587;
//SOGoSMTPServer =
"smtp://127.0.0.1:587/?tls=YES=allowInsecureLocalhost";
//sogo5
//SOGoMailDomain = acme.com;
SOGoMailDomain = MYDOMAIN.org;
[SOGo] sogo-tool: subscribe does not show the owner of the calendar
Hello, I want to share a personal calendar of a user to somebody else. I can do this via the webinterface as superuser. However, I cannot add the subscription for somebody else. For this, I can use the sogo tool e.g.: sudo -u sogo sogo-tool manage-acl subscribe owner-user Calendar/personal dest-user I also tried with "AuthorizedSubscriber": sudo -u sogo sogo-tool manage-acl subscribe owner-user Calendar/personal dest-user AuthorizedSubscriber The personal calendar of the owner shows up at the destination user, however it does not add the owner information. This means that the destination user has 2 calendars which are called the same "Personal Calendar". If the destination user searches and subscribes the calendar of the owner via the webinterface, the shared calendar shows up correctly with name. (however, I want that for users the new calendar shows up automatically, most users will not know how to find those calendars, even with the webinterface). Please find the example attached. (I'm using the latest 5.3 of 2 days ago). Can somebody explain me if this can be fixed with more complete/correct sogo-tool parameters? I would also like to know if there is more documentation (or more examples) available for sogo-tool? I didn't find anything, and I'm not sure I completely understand the different rights described here https://github.com/inverse-inc/sogo/blob/master/SoObjects/Appointments/product.plist or the general usage here https://github.com/inverse-inc/sogo/blob/master/Tools/SOGoToolManageACL.m Also via google I do find very little information on examples of other users using sogo-tool. thank you, and kind regards, -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] openLDAP and groups ACLs not working
Dear all,
I think I can answer my own question. The solution was to use
member and the dn with mail=... and not memberuid, and/or cn=
I just looked how iRedmail mailList do it (although it seems those
mailList only store the first subscriber, and otherwise use
another logic to manage members.
Because I didn't want to edit the ldap schema, groupOfNames work
best, as they already have the member attribute. I will
double-check with iRedmail if that does not interfere with
mailLists, or in any other way. But it seems groupOfNames are not
used by iRedmail, so that may be good news. Additionally, I think
I could just store them somewhere else then in ou=Groups, so to
make sure (maybe that would be the best idea?)
So in short, this is the SOGOUsersource for groups which works in
iRedmail for group ACLs:
{
// Used for groups
type = ldap;
id = groups;
canAuthenticate = YES;
isAddressBook = NO;
displayName = "LDAP Groups";
hostname = "ldap://127.0.0.1:389";
baseDN = "domainName=%d,o=domains,dc=MYDOMAIN,dc=net";
bindDN = "cn=vmail,dc=MYDOMAIN,dc=net";
bindPassword = "X";
filter = "objectClass=groupOfNames"; #<<-- NEW
filter
bindAsCurrentUser = YES;
// The algorithm used for password encryption when
changing
// passwords without Password Policies enabled.
// Possible values are: plain, crypt, md5-crypt, ssha,
ssha512.
userPasswordAlgorithm = ssha512;
GroupObjectClasses = (groupOfNames); #<<--- NEW
(maybe not needed?)
CNFieldName = cn;
IDFieldName = cn;
// value of UIDFieldName must be unique on entire
server
UIDFieldName = cn;
}
and this is a group resource which works:
# Entry 1: cn=grpnam...@mydomain.net,ou=Groups,domainName=...
dn:
cn=grpnam...@mydomain.net,ou=Groups,domainName=MYDOMAIN.net,o=domains,dc=MYDOMAIN,dc=net
cn: grpnam...@mydomain.net
member:
mail=i...@mydomain.net,ou=Users,domainName=MYDOMAIN.net,o=domains,dc=MYDOMAIN,dc=net
member:
mail=i...@mydomain.net,ou=Users,domainName=MYDOMAIN.net,o=domains,dc=MYDOMAIN,dc=net
objectclass: groupOfNames
objectclass: top
Together with the iRedadmin-Pro feature to enable/disable custom
services
(https://docs.iredmail.org/iredadmin-pro.custom.user.services.html)
I think the openLDAP backend could be used easily to also
fine-grain ACLs for other services outside of iRedmail/SOGo while
providing a central authentication service.
One problem which is left: if I add/remove new members to
a group in ldap, the ACLs/subscriptions are not updated in SOGo. I
think somehow this worked with AD groups. To update the ACLs of
the group members stored in SOGo, I need to remove the group, and
add it again to the resource. I had a look how to "refresh" the
ACLs/subscriptions in SOGo and reload the information from the
ldap server, but I didn't find anything. Is this happening
automatically, but I would need to wait longer, or is there a way
to "force" this do this via the command line?
On 12/8/21 19:43, Claus
(c3...@mail77.eu) wrote:
Hello,
here is the debug with LDAPDebugEnabled and SOGODebugRequest
enabled.
it seems to look for the members of the group, but at the end
it seems only to subscribe the group ("subscribeUsers?uids=testposixgro...@mydomain.net"),
not the members themselves. Is that the reason? When I subscribe
a user (not a group), I see the correct
subscribeusers?uids=it5@MYDOMAIN...)
kind regards
Dec 08 13:32:51 sogod [599764]: |SOGo| starting method 'GET' on
uri
'/SOGo/so/postmas...@mydomain.net/Calendar/924D3-61B0F880-1-39D7A0C0/acls'
Dec 08 13:32:51 sogod [599764]: |SOGo| request took 0.003679
seconds to execute
Dec 08 13:32:51 sogod [599764]: 141.94.27.175 "GET
/SOGo/so/postmas...@mydomain.net/Calendar/924D3-61B0F880-1-39D7A0C0/acls
HTTP/1.0" 200 115/0 0.005 - - 0 - 16
Dec 08 13:32:52 sogod [599764]: |SOGo| starting method 'GET' on
uri
'/SOGo/so/postmas...@mydomain.net/Calendar/924D3-61B0F880-1-39D7A0C0/UIxAclEditor'
Dec 08 13:32:52 sogod [599764]: |SOGo| request took 0.002767
seconds to execute
Dec 08
Re: [SOGo] openLDAP and groups ACLs not working
)))'
for attrs 'mail'
Dec 08 13:33:06 sogod [599768]:
<0x0x5621b5f39ff0[NGLdapConnection]> Using ldap_initialize
for LDAP URL: ldap://127.0.0.1:389
2021-12-08 13:33:06.444 sogod[599768:599768] -[NGLdapConnection
_searchAtBaseDN:qualifier:attributes:scope:]: search at base
'domainname=MYDOMAIN.net,o=domains,dc=MYDOMAIN,dc=net' filter
'(|(&(|(cn=i...@mydomain.net)(mail=i...@mydomain.net))(objectClass=posixGroup))(objectClass=groupOfNames))'
for attrs '*'
Dec 08 13:33:06 sogod [599768]:
<0x0x5621b6567200[NGLdapConnection]> Using ldap_initialize
for LDAP URL: ldap://127.0.0.1:389
2021-12-08 13:33:06.445 sogod[599768:599768] -[NGLdapConnection
_searchAtBaseDN:qualifier:attributes:scope:]: search at base
'domainname=MYDOMAIN.net,o=domains,dc=MYDOMAIN,dc=net' filter
'(cn=i...@mydomain.net)' for attrs '*'
Dec 08 13:33:06 sogod [599768]:
<0x0x5621b685e8e0[NGLdapConnection]> Using ldap_initialize
for LDAP URL: ldap://127.0.0.1:389
2021-12-08 13:33:06.446 sogod[599768:599768] -[NGLdapConnection
_searchAtBaseDN:qualifier:attributes:scope:]: search at base
'mail=i...@mydomain.net,ou=users,domainname=MYDOMAIN.net,o=domains,dc=MYDOMAIN,dc=net'
filter
'(&(&(enabledService=mail)(accountStatus=active)(enabledService=displayedInGlobalAddressBook))(|(&(objectClass=mailUser)(enabledService=sogo))(objectClass=mailList)(objectClass=mailAlias)))'
for attrs 'mail'
Dec 08 13:33:06 sogod [599768]:
<0x0x5621b668d2c0[NGLdapConnection]> Using ldap_initialize
for LDAP URL: ldap://127.0.0.1:389
2021-12-08 13:33:06.448 sogod[599768:599768] -[NGLdapConnection
_searchAtBaseDN:qualifier:attributes:scope:]: search at base
'domainname=MYDOMAIN.net,o=domains,dc=MYDOMAIN,dc=net' filter
'(|(&(|(cn=i...@mydomain.net)(mail=i...@mydomain.net))(objectClass=posixGroup))(objectClass=groupOfNames))'
for attrs '*'
Dec 08 13:33:06 sogod [599768]:
<0x0x5621b656ada0[NGLdapConnection]> Using ldap_initialize
for LDAP URL: ldap://127.0.0.1:389
2021-12-08 13:33:06.449 sogod[599768:599768] -[NGLdapConnection
_searchAtBaseDN:qualifier:attributes:scope:]: search at base
'domainname=MYDOMAIN.net,o=domains,dc=MYDOMAIN,dc=net' filter
'(cn=i...@mydomain.net)' for attrs '*'
Dec 08 13:33:06 sogod [599768]: |SOGo| request took 0.019323
seconds to execute
Dec 08 13:33:06 sogod [599768]: 141.94.27.175 "GET
/SOGo/so/postmas...@mydomain.net/Calendar/924D3-61B0F880-1-39D7A0C0/subscribeUsers?uids=testposixgro...@mydomain.net
HTTP/1.0" 204 0/0 0.021 - - 0 - 15
2021-12-08 13:33:06.545 sogod[599764:599764] SMTP: STARTTLS
successfully performed
2021-12-08 13:33:06.550 sogod[599764:599764] SMTP(RCPT TO) error:
5.1.1 : Recipient address
rejected: User unknown
Dec 08 13:33:06 sogod [599764]: [ERROR]
<0x0x5621b67f1550[SOGoMailer]> Could not connect to the SMTP
server
smtp://127.0.0.1:587/?tls=YES=allowInsecureLocalhost
Dec 08 13:33:06 sogod [599764]: |SOGo| request took 0.127090
seconds to execute
Dec 08 13:33:06 sogod [599764]: 141.94.27.175 "POST
/SOGo/so/postmas...@mydomain.net/Calendar/924D3-61B0F880-1-39D7A0C0/saveUserRights
HTTP/1.0" 200 0/408 0.129 - - 0 - 15
On 12/8/21 16:44, Claus
(c3...@mail77.eu) wrote:
Dear SOGo community,
I've installed SOGo 5.3.0 (@shiva2.inverse 202112070624) with
iRedmail-OpenLDAP, and I'm trying to get LDAP groups working (we
already use SOGo in combination with Active Directory and groups
work perfectly) - however, we are moving our mail + SOGo away from
AD.
So far, groups show up in SOGo for e.g. a resource to be shared
with. There is no error message in sogo.log. However, group
members are not subscribed, nor do they see the shared resource
when searching for resources of the sharer.
I suspect it is a mapping issue between how iRedmail identifies
"users"/mailboxes (mail=), and how SOGo can identify them by
the memberuid/member attribute (uid=, or cn= instead of
mail=... ?).
So something is missing here. Ideally, I can manage group ACLs
without touching the attributes of the iRedmail mailboxes/users,
so in case of updates/LDAP changes, the group memberships stay
active. E.g. by using posixGroup or groupOfNames objectClasses.
A) This is the SOGoUserSources to get the groups:
{
// Used for groups
type = ldap;
id = groups;
canAuthenticate = YES;
isAddressBook = NO;
displayName = "LDAP Authentication";
hostname = "ldap://127.0.0.1:389";
baseDN = "ou=Groups,domainName=%d,o=
[SOGo] openLDAP and groups ACLs not working
Dear SOGo community,
I've installed SOGo 5.3.0 (@shiva2.inverse 202112070624) with
iRedmail-OpenLDAP, and I'm trying to get LDAP groups working (we
already use SOGo in combination with Active Directory and groups
work perfectly) - however, we are moving our mail + SOGo away from
AD.
So far, groups show up in SOGo for e.g. a resource to be shared
with. There is no error message in sogo.log. However, group members
are not subscribed, nor do they see the shared resource when
searching for resources of the sharer.
I suspect it is a mapping issue between how iRedmail identifies
"users"/mailboxes (mail=), and how SOGo can identify them by the
memberuid/member attribute (uid=, or cn= instead of mail=...
?).
So something is missing here. Ideally, I can manage group ACLs
without touching the attributes of the iRedmail mailboxes/users, so
in case of updates/LDAP changes, the group memberships stay active.
E.g. by using posixGroup or groupOfNames objectClasses.
A) This is the SOGoUserSources to get the groups:
{
// Used for groups
type = ldap;
id = groups;
canAuthenticate = YES;
isAddressBook = NO;
displayName = "LDAP Authentication";
hostname = "ldap://127.0.0.1:389";
baseDN = "ou=Groups,domainName=%d,o=domains,dc=MYDOMAIN,dc=net";
bindDN = "cn=vmail,dc=MYDOMAIN,dc=net";
bindPassword = "";
filter = "objectClass=posixGroup OR objectClass=groupOfNames";
#scope = SUB;
// always keep binding to the LDAP server using the DN of the
// currently authenticated user. bindDN and bindPassword are still
// required to find DN of the user.
// Note: with default LDAP acl configured by iRedMail, user doesn't
// have privilege to query o=domains,dc=MYDOMAIN,dc=net.
// so this doesn't work.
bindAsCurrentUser = YES;
mapping = {
uid = ("mail");
};
// The algorithm used for password encryption when changing
// passwords without Password Policies enabled.
// Possible values are: plain, crypt, md5-crypt, ssha, ssha512.
userPasswordAlgorithm = ssha512;
#GroupObjectClasses = (posixGroup);
CNFieldName = cn;
IDFieldName = cn;
// value of UIDFieldName must be unique on entire server
UIDFieldName = cn;
}
B) these are example 2 LDAP groups which show up in SOGo as
groups, but resources are not shared to the members of those
groups:
# Entry 1 (posixGroup)
dn:
cn=posix6,ou=Groups,domainName=MYDOMAIN.net,o=domains,dc=MYDOMAIN,dc=net
cn: posix6
gidnumber: 500
mail: posix6
memberuid: it6
memberuid:
mail=i...@mydomain.net,ou=Users,domainName=MYDOMAIN.net,o=domains,dc=MYDOMAIN,dc=net
memberuid:
cn=i...@mydomain.net,ou=Users,domainName=MYDOMAIN.net,o=domains,dc=MYDOMAIN,dc=net
objectclass: posixGroup
objectclass: top
# Entry 1: groupOfNames
dn:
cn=grpnames2@localhost,ou=Groups,domainName=MYDOMAIN.net,o=domains,dc=MYDOMAIN,dc=net
cn: grpnames2@localhost
member:
cn=i...@mydomain.net,ou=Users,domainName=MYDOMAIN.net,o=domains,dc=MYDOMAIN,dc=net
member:
cn=i...@mydomain.net,ou=Users,domainName=MYDOMAIN.net,o=domains,dc=MYDOMAIN,dc=net
objectclass: groupOfNames
objectclass: top
C) this is how a mailbox/user is identified in iRedmail:
# Entry 1: mail=i...@mydomain.net,ou=Users,domainName=MYDOMAIN
dn:
mail=i...@mydomain.net,ou=Users,domainName=MYDOMAIN.net,o=domains,dc=MYDOMAIN,dc=net
accountstatus: active
amavislocal: TRUE
cn: IT6
enabledservice: sogo
enabledservice: imap
enabledservice: sievetls
enabledservice: sievesecured
enabledservice: lmtp
enabledservice: dsync
enabledservice: shadowaddress
enabledservice: indexer-worker
enabledservice: sieve
enabledservice: imaptls
enabledservice: senderbcc
enabledservice: managesievesecured
enabledservice: deliver
enabledservice: recipientbcc
enabledservice: mail
enabledservice: smtpsecured
enabledservice: lib-storage
enabledservice: sogoactivesync
enabledservice: smtp
enabledservice: sogowebmail
enabledservice: smtptls
enabledservice: lda
enabledservice: displayedInGlobalAddressBook
enabledservice: imapsecured
enabledservice: doveadm
enabledservice: forward
enabledservice: quota-status
enabledservice: sogocalendar
enabledservice: managesievetls
enabledservice: internal
enabledservice: managesieve
homedirectory: /var/vmail/vmail1/MYDOMAIN.net/i/t/6/it6-2021.
12.08.15.26.38/
mail: i...@mydomain.net
mailboxfolder: Maildir
mailboxformat: maildir
mailquota: 5368709120
objectclass: inetOrgPerson
objectclass:
