How to setup IIS Basic Authentication to secure mail?

Question asked by tunafish24 - 9/28/2026 at 8:37 AM

Unanswered

I don't like that anyone can access login page of smartermail and attempt to login. So looking to use IIS Basic Authentication to add a layer of protection. After spending couple of hours, I couldn't get it working, because when you add SmarterMail as an IIS website, IIS acts as reverseproxy and that somehow breaks things.

I know my IIS settings are correct because I was able to secure a static website using same procedure, just not the SmarterMail website.

Has anyone been able to successfully secure their SmarterMail IIS site using IIS Basic Authentication?

5 Replies

Reply to Thread

XT Replied

9/29/2026 at 10:44 PM

Enabling 2FA, filtering logins by country and tuning IDs rules can work better than using windows authentication. All these features are already included inside SmarterMail and this way you will not deal with complicated tasks every time you need to do an update. (Automated SSL renewals just to mention 1)

tunafish24 Replied

9/30/2026 at 7:28 AM

I'm trying to prevent potential attacker from even knowing which mail software/tool I'm using. So there is a reduced chance of zero-day attack.

Douglas Foster Replied

10/5/2026 at 11:28 AM

I don't think you can accomplish what you want to do. We have consistently failed when trying to put a WAF login in front of the Webmail login. Below is my understanding of the obstacle:

If you examine the API, you will note that the authentication token is passed in as header data, not as HTML data. By inference, if you use IIS login, it will also create (and replace) a header entry that represents the IIS login token. Whatever the details, the two tokens interfere with each other and nothing works.

We have recently managed to create a firewall trick that provides an initial login to access the webmail IP address. Once it is set, the firewall gets out of the way, and the user is able to log into webmail. Login is connected to Active Directory group so that only certain accounts can be used for login.

I don't know the implementation details because I did not do the firewall work. The developer was able to make the IP filter specific to the current session, complete with inactivity limits and maximum connect time limits, so it finally accomplished what we have been wanting to do for a long time. Whether you can do the same depends on your firewall capabilities, and the creativity of your firewall experts.

This is in addition to country blocking and hostile-IP blocking, which are also implemented at the firewall.

Thomas Sangster Replied

10/9/2026 at 5:58 AM

I would not recommend adding IIS Basic Authentication directly to the SmarterMail webmail site when IIS is acting as a reverse proxy. SmarterMail handles its own authentication, and enabling Basic Authentication at the IIS layer can interfere with the authentication headers, cookies, and requests required by the application. It may also cause authentication prompts or prevent users from logging in correctly.

A better solution is to restrict access to the SmarterMail login page without breaking its authentication process.

Here are the options I would recommend:

Restrict access by IP address: If users connect from known office IP addresses or through a VPN, configure IIS IP Address and Domain Restrictions to allow only trusted addresses. Make sure this restriction does not unintentionally block remote users or required services.
Use a VPN: For an organization where webmail is intended only for employees, restricting access to the webmail interface through a VPN is generally a stronger approach than adding a second login prompt.
Use a separate reverse proxy or access gateway: If you need an additional authentication layer, use a proxy or identity-aware gateway that explicitly supports SmarterMail's authentication flow, WebSockets if required, and all necessary application paths. Test the complete login, logout, session renewal, and mailbox access workflows before deploying it.
Keep IIS Basic Authentication separate from the application: If you still want to test Basic Authentication, use a separate test site or staging environment first. Do not assume that enabling it on a static website proves it will work with SmarterMail. A reverse proxy may forward authentication headers differently, and the application may not support the extra authentication challenge.
Strengthen SmarterMail's own security: Keep SmarterMail updated, use HTTPS, enforce strong passwords and multifactor authentication where supported, and configure appropriate account lockout or brute-force protection.

Important: IIS Basic Authentication alone does not necessarily secure the login page as intended. It uses HTTP authentication credentials, so HTTPS is essential. Also, do not enable it across the entire site without testing because it could block access to resources or endpoints that SmarterMail needs.

For a precise configuration, the key detail is whether IIS is using URL Rewrite with Application Request Routing (ARR) to proxy requests to SmarterMail, and which SmarterMail version you are running. Those details determine whether an IIS-level authentication layer can be implemented safely in your setup.

Douglas Foster Replied

10/9/2026 at 8:09 AM

For those of us who are not hosting services, the available solutions are not adequate. We want to use Active Directory authentication, which does not play with 2-factor authentication. We do not want to require 2-factor authentication when users are internal to our network. We have department-level generic accounts that are accessed by multiple users, so 2-factor authentication does not work well for those.

We do want to restrict most accounts to only be usable when in the office, so we want to distinguish between external and internal access, and we want to control which users are allowed to log in remotely. Then we need 2-factor enforced when those allowed users connect remotely.

This is important for PCI DSS compliance, because their rules are pretty clear: all remote access must be protected with 2-factor authentication. I see no basis for arguing that webmail access should be exempted. The only justification I an offer is that I don't know how to make this happen across all protocols.

I was thrilled when my boss figured out the firewall trick that we rolled out a few weeks ago, which requires an account enabled for remote access and then requires 2-factor to get past the firewall to the SmarterMail login page.

Any secure solution design gets more complicated when you consider that an attack can come against Webmail, EAS, MAPI, EWS, IMAP, POP, or Authenticated SMTP. We reduce our attack service by only allowing the port 443 protocols through the firewall, but not everyone can do that. MAPI, EAS, and EWS all share port 443 with webmail, which make things even harder. IIS rules can be used to block MAPI, EAS, and/or EWS for all external users, if any of those are not required. Currently, we use IIS path filter rules to block external access using MAPI. EWS and EAS are allowed using one-factor login, and of course EAS is restricted to specific users by licensing.

Hosting service clients might like this same capability, but the setup becomes much harder because the client's definition of "internal" is different for each client and all of them are different from SmarterMail's internal network.

So the ideal solution would:

allow definition of internal vs external connections on a per-domain basis,
provide the ability to enforce 2FA for external connections, and
provide the ability to restrict external access to specific domain users.

Back to Community Threads

Reply to Thread

Enter the verification text