mailcow-dockerized
mailcow-dockerized copied to clipboard
mailcow
EAS/ActiveSync (app) password returns 401 Forbidden when TFA is enabled
Contribution guidelines
- [X] I've read the contribution guidelines and wholeheartedly agree
I've found a bug and checked that ...
- [X] ... I understand that not following the below instructions will result in immediate closure and/or deletion of my issue.
- [X] ... I have understood that this bug report is dedicated for bugs, and not for support-related inquiries.
- [X] ... I have understood that answers are voluntary and community-driven, and not commercial support.
- [X] ... I have verified that my issue has not been already answered in the past. I also checked previous issues.
Description
Since updating to 2022-07 EAS/ActiveSync seems to be broken with an app password and TFA on user level set.
Logs
x.x.x.x - [email protected] [19/Jul/2022:09:29:46 +0200] "OPTIONS /Microsoft-Server-ActiveSync HTTP/1.1" 401 172 "-" "Android-Mail/2022.06.26.459604605.Release"
Steps to reproduce
- Make new user
- Set TFA for user
- Make app password for only protocol EAS/ActiveSync
- Restart SoGo
- Signin on Android phone with Gmail client with Exchange protocol.
- Get error in Gmail client and get 401 in access logs.
System information
| Question | Answer |
|---|---|
| My operating system | Debian Bullseye |
| Is Apparmor, SELinux or similar active? | No |
| Virtualization technology (KVM, VMware, Xen, etc - LXC and OpenVZ are not supported | No |
| Server/VM specifications (Memory, CPU Cores) | 6Gb, 4 cores |
Docker version (docker version) |
20.10.17 |
docker-compose version (docker-compose version) |
2.6.1 |
mailcow version (git describe --tags `git rev-list --tags --max-count=1` ) |
2022-07 |
| Reverse proxy (custom solution) | Nginx, per documentation example |
Output of git diff origin/master, any other changes to the code? If so, please post them:
Other certs & no ipv6nat-mailcow (switched with update.sh)
All third-party firewalls and custom iptables rules are unsupported. Please check the Docker docs about how to use Docker with your own ruleset. Nevertheless, iptabels output can help us to help you: iptables -L -vn:
No alterations
ip6tables -L -vn:
No alterations
iptables -L -vn -t nat:
No alterations
ip6tables -L -vn -t nat:
No alterations
DNS problems? Please run docker exec -it $(docker ps -qf name=acme-mailcow) dig +short stackoverflow.com @172.22.1.254 (set the IP accordingly, if you changed the internal mailcow network) and post the output:
151.101.193.69
151.101.129.69
151.101.65.69
151.101.1.69
I am having a similar issue regarding dav within SOGo. It stops working when TFA is enabled (nginx returns 401: Unauthorized). I was going to open a separate issue but it seems to be related to this.
vdirsyncer -vdebug discover contacts
debug: Using 1 maximal workers.
debug: Fetching value for password.fetch with command strategy.
Discovering collections for pair contacts
contacts_local:
- "MAIL_DOMAIN"
- "personal"
debug: ====================
debug: PROPFIND https://MAILCOW_HOSTNAME/SOGo/dav/
debug: {'User-Agent': 'vdirsyncer/0.18.1.dev0+g3191886.d20211204', 'Content-Type': 'application/xml; charset=UTF-8', 'Depth': '1'}
debug: b'\n <propfind xmlns="DAV:">\n <prop>\n <resourcetype />\n </prop>\n </propfind>\n '
debug: Sending request...
debug: 401
debug: {'Server': 'nginx', 'Date': 'Sun, 24 Jul 2022 17:46:18 GMT', 'Content-Type': 'text/html; charset=utf-8', 'Content-Length': '172', 'Connection': 'keep-alive', 'X-Frame-Options': 'SAMEORIGIN', 'Strict-Transport-Security': 'max-age=63072000; includeSubDomains; preload'}
debug: b'<html>\r\n<head><title>401 Authorization Required</title></head>\r\n<body>\r\n<center><h1>401 Authorization Required</h1></center>\r\n<hr><center>nginx</center>\r\n</body>\r\n</html>\r\n'
debug: Given URL is not a homeset URL
debug: ====================
debug: PROPFIND https://MAILCOW_HOSTNAME/SOGo/dav/
debug: {'User-Agent': 'vdirsyncer/0.18.1.dev0+g3191886.d20211204', 'Content-Type': 'application/xml; charset=UTF-8', 'Depth': '0'}
debug: b'\n <propfind xmlns="DAV:">\n <prop>\n <current-user-principal />\n </prop>\n </propfind>\n '
debug: Sending request...
debug: 401
debug: {'Server': 'nginx', 'Date': 'Sun, 24 Jul 2022 17:46:18 GMT', 'Content-Type': 'text/html; charset=utf-8', 'Content-Length': '172', 'Connection': 'keep-alive', 'X-Frame-Options': 'SAMEORIGIN', 'Strict-Transport-Security': 'max-age=63072000; includeSubDomains; preload'}
debug: b'<html>\r\n<head><title>401 Authorization Required</title></head>\r\n<body>\r\n<center><h1>401 Authorization Required</h1></center>\r\n<hr><center>nginx</center>\r\n</body>\r\n</html>\r\n'
debug: Trying out well-known URI
debug: ====================
debug: PROPFIND https://MAILCOW_HOSTNAME/.well-known/carddav
debug: {'User-Agent': 'vdirsyncer/0.18.1.dev0+g3191886.d20211204', 'Content-Type': 'application/xml; charset=UTF-8', 'Depth': '0'}
debug: b'\n <propfind xmlns="DAV:">\n <prop>\n <current-user-principal />\n </prop>\n </propfind>\n '
debug: Sending request...
debug: Rewriting status code from 301 to 307
debug: 401
debug: {'Server': 'nginx', 'Date': 'Sun, 24 Jul 2022 17:46:18 GMT', 'Content-Type': 'text/html; charset=utf-8', 'Content-Length': '172', 'Connection': 'keep-alive', 'X-Frame-Options': 'SAMEORIGIN', 'Strict-Transport-Security': 'max-age=63072000; includeSubDomains; preload'}
debug: b'<html>\r\n<head><title>401 Authorization Required</title></head>\r\n<body>\r\n<center><h1>401 Authorization Required</h1></center>\r\n<hr><center>nginx</center>\r\n</body>\r\n</html>\r\n'
I can open a separate issue if necessary.
Thanks for your awesome work!
Good you found the actual root cause @Venem . I could not replicate when it happened. I think this issue is fine. I will change the title.
@FreddleSpl0it this is linked to the new TFA flow where you can set TFA @ user level. Maybe you could take a look?
Yes this was my mistake as i did not see the connection with app passwords. Also there are oauth clients that will also fail with enabled TFA for users. As long as TFA is disabled for a mailbox user everything works fine.
This PR should fix the issue https://github.com/mailcow/mailcow-dockerized/pull/4685. I excluded app passwords and oauth clients from TFA. The Question is, does all of this even make sense if app passwords and oauth clients are excluded from TFA.
The Question is, does all of this even make sense if app passwords and oauth clients are excluded from TFA.
For app passwords: yes. These passwords will not be saved in password managers/memorized and re-used to login with unsecure devices. TFA will save you whenever you 'leak' your main password to login to the UI. Also: because app passwords are more fine-grained, they will be replaced whenever a device is lost/replaced and only allow for certain protocols (if configured correctly) which helps against non-targeted attacks.
Thanks for the PR, I will test it in the next release!
Out of curiosity shouldn't IMAP & SMTP also only work with app passwords if 2FA is enabled on the user account? Because currently it still works with the regular user password when 2fa is enabled.....
you can remove imap and smtp access for a mailbox and force using app passwords for such access. If you login as a user in the mailcow ui you will see at the top
This mailbox user has direct, external access to the following protocols and applications. This setting is controlled by your administrator. App passwords can be created to grant access to individual protocols and applications.
The "Login to webmail" button provides single-sign-on to SOGo and is always available.
I would like to add that this bug also affects the DAV protocol under the same conditions (TFA on Mailcow UI + App Password). I also get error 401.
I'll close this since https://github.com/mailcow/mailcow-dockerized/pull/4685 got merged and available in the latest update (2022-08)
