Repository navigation
Fail2Ban banning IPs because of unavailable LDAP server #7509
Description
Contribution guidelines
- I've read the contribution guidelines and wholeheartedly agree
Checklist prior issue creation
- I understand that failure to follow below instructions may cause this issue to be closed.
- I understand that vague, incomplete or inaccurate information may cause this issue to be closed.
- I understand that this form is intended solely for reporting software bugs and not for support-related inquiries.
- I understand that all responses are voluntary and community-driven, and do not constitute commercial support.
- I confirm that I have reviewed previous issues to ensure this matter has not already been addressed.
- I confirm that my environment meets all prerequisite requirements as specified in the official documentation.
Description
Our mailcow-server ist hosted externally (that's why I can't provide every detail about the system below).
For authentication, we use LDAP (Active Directory) hosted in our own internal network.
Recently, we had an internet outage, so our internal LDAP-server could not be reached by our mailcow-server.
We observed that accounts got blocked by fail2ban because mailcow could not reach our LDAP-server and validate the user account.
In a quick experiment I was able to reproduce this issue:
First try is with wrong password. On the second try, I disabled the firewall-rule for the mailcow-LDAP-connection, making our LDAP-server unavailable to mailcow. Last try was again wrong password and working LDAP-connection.
It looks like Fail2Ban does not differentiate between a user entering a wrong password and a login-attempt that failed because mailcow wasn't able to reach the LDAP server.
I also disabled the LDAP-connection a second time on purpose, for about 3 minutes, just to observe what happens. Immediately I see log entrys like this in Netfilter-Log:
XXX.XXX.240.210 matched rule id 3 (warning: unknown[XXX.XXX.240.210]: SASL LOGIN authentication failed: (reason unavailable), sasl_username=xxx@xxxx.eu)
XXX.XXX.167.132 matched rule id 7 (auth: lua(anotheruser@xxxxx.eu,XXX.XXX.167.132,<1ELj51VXXXXZ9qeE>): unknown user (SHA1 of given password: 985XXX))
XXX.XXX.220.64 matched rule id 7 (auth: lua(yetanotheruser@xxxxx.eu,XXX.XXX.220.64,<4ajl6FVXXXXZ7txA>): unknown user (SHA1 of given password: bb7a3e))
Log lines like these stop appearing as soon as I enable the connection to LDAP again.
Because this test-disconnection only lasted a few minutes I guess these are mail-clients of other users trying to connect unsuccessfully. That would mean, not only users of the Web-GUI getting banned when the LDAP-server is unavailable, but also users of mail clients. So even if the LDAP-server would be offline in the middle of the night, we still would block some harmless and innocent IPs/users.
It's obvious that the simplest solution would be to make sure our LDAP-server is always available. But our LDAP-server is not redundant, and our internet provider sometimes has outages (it is what it is, happened in the past and will happen again...), so we will for sure have this situation again in the future, where our mailcow-server cannot reach our LDAP-server. Additionally, sometimes we need to do maintainance work and updates and need to shutdown/reboot our LDAP-server for that, too.
Maybe there is a way for mailcow to differentiate between failed logins because of wrong passwords and failed logins because of an unavailable LDAP-server? I think it's obvious why banning IPs doesn't make sense in the second case.
Ofcourse maybe this is currently technically impossible and this problem cannot be avoided. I guess it depends on how detailled the logs analyzed by fail2ban are...
I checked if someone reported something like this before, but I wasn't able to find any similar issue or thread in the support forum. I also checked the changelogs to see if anything in that direction was modified in the last versions, but I could not find any hint.
Steps to reproduce:
- Setup Mailcow with LDAP authentication
- Try to login with wrong password
- Temporarily block connection to LDAP-Server
- Try login again
- Check Netfilter-Logs: Both failed logins are classified as attempts with invalid password
Logs:
see log-lines above...
Which branch are you using?
master (stable)
Which architecture are you using?
x86_64
Operating System:
unknown
Server/VM specifications:
unknown
Is Apparmor, SELinux or similar active?
unknown
Virtualization technology:
unknown
Docker version:
unknown
docker-compose version or docker compose version:
unknown
mailcow version:
2026-07
Reverse proxy:
none
Logs of git diff:
Logs of iptables -L -vn:
no access
Logs of ip6tables -L -vn:
no access
Logs of iptables -L -vn -t nat:
no access
Logs of ip6tables -L -vn -t nat:
no access
DNS check:
no access
Activity