==== REQUIRED BASIC INFO OF YOUR IREDMAIL SERVER ====
- iRedMail version (check /etc/iredmail-release): 1.4.2
- Deployed with iRedMail Easy or the downloadable installer? downloadable
- Linux/BSD distribution name and version: ubuntu 20.04
- Store mail accounts in which backend (LDAP/MySQL/PGSQL): LDAP
- Web server (Apache or Nginx):nginx
- Manage mail accounts with iRedAdmin-Pro? yes
- [IMPORTANT] Related original log or error message is required if you're experiencing an issue.
====
I'm not sure if that has been posted already (I only found https://forum.iredmail.org/post11173.html#p11173 and https://forum.iredmail.org/topic3059-ir … oups.html) so in case not, this is how I got LDAP-group based ACL for SOGo resources (e.g calendar) to work. Together with the authentication of external services (https://docs.iredmail.org/iredadmin-pro … vices.html) I think OpenLDAP based iRedmail is a great authentication service for other apps which usually use group ACLs (e.g. we use Nextcloud and rely heavily on AD groups). I hope I haven't overseen anything, as I'm quite new to iRedmail, and openLDAP.
Therefore, **I would also like to know if this approach is safe?** E.g. the ldap resource will not disappear/cause problems with iRedmail updates, etc? Maybe it is better to not use ou=Groups (where iRedmail stores mailLists), but a separate ou (e.g. ou=customgroups) to store the group ACLs?
There are 2 things needed:
1) another SOGoUserSource to get the groups (to not interfere with the user-authentication)
{
// 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 = "XXXXX";
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;
}
2) a openldap resource for group membership (I used phpldapadmin to create it):
# Entry 1: cn=grpnames4@MYDOMAIN.net,ou=Groups,domainName=...
dn: cn=grpnames4@MYDOMAIN.net,ou=Groups,domainName=MYDOMAIN.net,o=domains,dc=MYDOMAINonal,dc=net
cn: grpnames4@MYDOMAIN.net
member: mail=it7@MYDOMAIN.net,ou=Users,domainName=MYDOMAIN.net,o=domains,dc=MYDOMAIN,dc=net
member: mail=it5@MYDOMAIN.net,ou=Users,domainName=MYDOMAIN.net,o=domains,dc=MYDOMAIN,dc=net
objectclass: groupOfNames
objectclass: top
After restart of SOGo, you should be able to search for the group-name when sharing resources, and upon adding ACLs and subscribing, the group members should see the resources.
If you add another group member in openLDAP later on, you need to additionally subscribe the user (but that was the same when using AD groups, and can be done via the sogo-tool). If you remove a user, it will take a couple of minutes until the resource disappears for this user.
Regarding SOGo, and SuperUsers: does it matter which user I add in "SOGoSuperUsernames" ? Should it be the postmaster, or can it be any other user?