1

Topic: iRedAdmin-PRO LDAP 5.1: Cross domain aliases.

==== REQUIRED BASIC INFO OF YOUR IREDMAIL SERVER ====
- iRedMail version (check /etc/iredmail-release): 1.5.1
- Deployed with iRedMail Easy or the downloadable installer?: installer
- Linux/BSD distribution name and version: Debian Bullseye
- 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.
====

Hi! The org I work for has recently (last week on friday) acquired a license for iRedAdmin-PRO. We're migrating our old Zimbra installation to iRedAdmin-PRO.

We have a lot of cross domain alias addresses (which also allow login), where a real account has addresses in multiple domains. Unfortunately there is no straightforward way via the UI to manage this.
From what I can see it looks like the LDAP queries would just work as well with aliases that cross domain boundaries.

Can you enable setting alias address across domain boundaries in a future version? For our install I'll simply disable the checks that would hinder this, but it's preferable for me to not have to maintain a patchset in the future.

----

Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team.

2

Re: iRedAdmin-PRO LDAP 5.1: Cross domain aliases.

Oh, in case anyone ever needs to allow users to login via their aliases (shadowAddress) when using LDAP, iRedMail already sets up correctly dovecot & postfix.

SOGo needs a oneline change:
In the SOGoUserSources dict change bindFields = (mail); to bindFields = (mail, shadowAddress);

3

Re: iRedAdmin-PRO LDAP 5.1: Cross domain aliases.

iRedAdmin-Pro has an option for cross-domain alias addresses, but it's disabled by default:

# Allow to assign per-user alias address under different domains.
USER_ALIAS_CROSS_ALL_DOMAINS = False

You can find default setting in /opt/www/iredadmin/libs/default_settings.py, please copy the parameter you want to modify to /opt/www/iredadmin/settings.py and set a proper value, then restart iredadmin service.

4

Re: iRedAdmin-PRO LDAP 5.1: Cross domain aliases.

Awesome thanks!

5

Re: iRedAdmin-PRO LDAP 5.1: Cross domain aliases.

Oh, I see that it is listed in the "# MySQL/PostgreSQL backends related settings." section, does that mean it will not take effect for us on OpenLDAP backend?

As a quick workaround for our usecase I've just commented out the domain check on line 1732 in libs/ldaplib/user.py
This works for us. Users can login with shadowaddresses cross domain and they receive e-mail on their addresses.

I guess more elegant would be to modify the query that gives available domains so that it would return any domain that the currently logged in admin may manage.

6

Re: iRedAdmin-PRO LDAP 5.1: Cross domain aliases.

gpeskens2 wrote:

Oh, I see that it is listed in the "# MySQL/PostgreSQL backends related settings." section, does that mean it will not take effect for us on OpenLDAP backend?

It doesn't work with LDAP backend. Sorry i didn't realize you're using LDAP.

7

Re: iRedAdmin-PRO LDAP 5.1: Cross domain aliases.

Is this something you can put on the roadmap for a future version?

The ldap queries for postfix/dovecot seem to just work.

8

Re: iRedAdmin-PRO LDAP 5.1: Cross domain aliases.

Do i understand correctly that you want to allow global admin (NOT normal admin) to assign per-user alias addresses (use ldap attribute shadowAddress) cross all domains hosted on iRedMail server?

9

Re: iRedAdmin-PRO LDAP 5.1: Cross domain aliases.

ZhangHuangbin wrote:

Do i understand correctly that you want to allow global admin (NOT normal admin) to assign per-user alias addresses (use ldap attribute shadowAddress) cross all domains hosted on iRedMail server?

Yes, global admin would be enough for our use case. I don't see us needing to have domain admins that require this capability.

Ideally also for the other alias type. As I do see us requiring alias lists (that are not full blown mailing lists) in the future that have members across domains.

It's just an unfortunate side effect of how this particular mail migration from Zimbra has been structured.

In the Zimbra installation most accounts have been created under domain A, and some of those accounts have aliases in domains B till Z. And some of those domains have also accounts.

I've been able to replicate by manual insertion into LDAP, but I don't see us moving away from this structure (there is no need "don't fix what isn't broken"), so being able to manage via interface the existing structure would be nice.