NB: https://portal.smartertools.com/community/a95385/8538-issue-with-relative-url-paths.aspx talks about using SmarterMail with a Reverse proxy. That could be an idea, however, with Build 8538 it seems SmarterMail is not fully compliant with relative URLs.

How does one implement a Proxy on IIS and could this solve my AutoDiscover issue?

We are running it as a shared server and run 8538 currently with no issues in a std. MAPI environment.

To Brian Bjerring-Jensen: Are you doing Shared Hosting? If so how do you manage the multiple customer autodiscover FQDN as Outlook requires the customer FQDN to be listed in the Cert? I have +40 Domains so I can store all of that in one Cert.

I run seperate certificates for each domain in IIS.

To Brian Bjerring-Jensen:  Are you do this in an automated fashion or manual? Please elaborate in more detail if you desire.

I am guessing you are saying for the customer specific IIS Bindings you have a dedicated Certificate then pick that from the Certificate Store? I don't think I can do that with Certify the Web. Are you using ACME Certs or have you choose another method?

I use certificates from Digicert and the process is manual from our side.

It takes about 5 mins to install. You just need it as a .pfx file. Digicert has a utility to convert a .cer.

OK. I just tested this manually using Certify the Web Site by creating a standalone IIS Virtual Server for the customer FQDN. Then I went back to manually add customer FQDN back to the main IIS SmarterMail Virtual Server. It seems to work... I have more testing to do...

The bigger issue is late M365 (aka O365) Outlook does not like SmarterMail Build 8025.

We run Office 2021 LTSC on all our customers and not O365 for that reason and #gdpr as well.

We have disabled quite a lot of telemetry also.

We do shared hosting and certify the web (letsencrypt).  100 fqdn per cert.  

I do shared hosting and don't need to setup any of that.

I just have our main mail domain (mail.hostingcompany.com) and a SRV record for each customer domain...

MAPI autodiscover works fine with this.

We use the same setting as Ben for many different customers.

No issue reported.

Wont you get a certificate error doing it that way??

No certificate errors and everything works fine. Tested now with a random customer account on MY PC using Outlook 365.

NOTE: This is with my CLOUD server with SmarterMail 8451, I will upgrade this server in 10-15 days to SM 8538 if no new serious bugs are discovered…

Hmmm thats a game changer..... i always beleived we needed a certificate for autodiscovery on the server for any domain resident....

That changes things.....

Yep, I was told also you need autodiscover.<customer-fqdn> DNS record plus redirect from 

http[s]<customer-fqdn>/autodiscover/autodiscover.xml to SmarterMail.

Without the above Autodiscover DNS records and redirect you risk a credential leak. Are folks aware of the now 1.5 to 2 Year Autodiscover BUG? The Outlook Autodiscover has an FQDN “back-off” procedure. This “back-off” mechanism is the culprit of credential leak because it is always trying to resolve the Autodiscover portion of the domain and it will always try to “fail up,” so to speak trying at first: https://Autodiscover.example.com/Autodiscover/Autodiscover.xml, then http://Autodiscover.example.com/Autodiscover/Autodiscover.xml,

then https://example.com/Autodiscover/Autodiscover.xml,

then http://example.com/Autodiscover/Autodiscover.xml
and notice both https and http are attempted.

Worse yet, the credentials are sent from Outlook clients to the request URL with an HTTP Basic authentication header which includes the hapless user's Base64-encoded credentials. DUMB!

I'm not sure what the programmatic flow path for Outlook code to look at the DNS SRV record. Is that first or last?

Some are saying the M$ Code in Outlook was poor and then tried autodiscover.[tld] as well. Some hackers had purchased some of these domains. Over a year ago Microsoft had registered some 68 domains related to Autodiscover. It is NOT clear what Micrsoft has done to resolve the poor Autodiscover implementation in their Microsoft Outlook and Office 365 mail clients to resolve the issue further. 

Anyone know of a CVE assignment for this issue and its resolution?

The question becomes is what you are saying is a good idea or not relative to the security concern...  I will see if I take a current version of Outlook and capture its network traffic.

> I'm not sure what the programmatic flow path for Outlook code to look at the DNS SRV 

I assume Outlook is working more or less like the Microsoft Remote Connectivty Analyzer. The steps outlined in the test are:

So youre saying that the ones only using SRV records in their way of handling autodiscovery would potentially leak all the MAPI users passwords since SRV records are served as the last option?

I have read the article from Guardicore and some other publications. It's not clear if the findings of Guardicore are true. I have seen contradicting evidence by some other people. The fact that there is no CVE for this seems to indicate that this "back-off" is not a problem. It could be that some non microsoft implementations of autodiscover did try to connect to such "back-off" domains, but it seems that Microsoft is not one of them.

You can follow the way it checks for connectivity here...

https://testconnectivity.microsoft.com/tests/Ola/input

then it will tell you in what order it tries to connect.

Yes, the Connectivity Analyzer show more or less how it works. But there might be Outlook versions that did it different and there have been other vendor implementations that did it different and wrong (for example old Samsung Phones and Apple Mail on iOS).

I'm not sure how big of a deal this is though - generally for shared hosting, the admin of the website has admin access to the mail service anyway so nothing is going to be leaked.

The only way this seems that it could be an issue is if different people look after the website and mail services. In which case the web guy could capture the domain.com/autodiscover traffic. But then I don't see the way around that.

If it was solely the autodiscover.domain that was the problem, that could be protected by the website people not having DNS access.

If understand correctly the leak occurs when the autodiscover.xml is accessed because Outlook passes the credentials on each try which maybe in the clear as well.

This also means if you have hosting separation between the corporate web site and SmarterMail then the corporate web site could proxy or simply capture the XML data interchange thus get the credentials. Another thing is we know that corporate web sites can be accessed improperly then hackers can and do insert code for any number of nefarious purposes.

Since nobody made a CVE about and neither did Microsoft the issue has faded into the background and we don't know what has happened unless we test.

What we need to do is come up with a community standard that promotes best practices and some kind of codebase to automate this process.

I add this to every users registry before setting up the account to avoid leaking credentials.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\AutoDiscover]
"ExcludeExplicitO365Endpoint"=dword:00000001
"ExcludeHttpRedirect"=dword:00000001
"ExcludeHttpsRootDomain"=dword:00000001
"ExcludeScpLookup"=dword:00000001

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\AutoDiscover\RedirectServers]
"smartermail.cloudpros.dk"=hex(0):

Here is a good tool to test Autodiscovery if anyone might need it.
https://www.priasoft.com/autodiscover-testing-tool/ It also has the advance options to create the Registry entries mentioned above and then some.

I appreciate the RegEdit, however, I'm sure how helpful that is when you are trying to deploy to end customer's Windows PCs that you don't have administrate rights. Sometimes I do have access and most times I do not.

For https://www.priasoft.com/autodiscover-testing-tool/; do we know anything about the Priasoft, Inc of Tempe, AZ. I have to look at this tool, however, do we trust them because I assume you have to provide username and password to test the eMail Server?

Also, I've done more research and the number of bindings allowed when using kernel-mode authentication has a limit is 64 bindings per Virtual Web Site. If you add 65 or more bindings, IIS will show “401.2 Unauthorized: Logon Failed Due to Server Configuration with No Authentication” error even though the credentials you submit are correct. I believe anonymous authentication, used with IIS APP POOL, counts toward this limit.

Anyone have any more than 64 bindings?

I already have 24 Bindings for old and new style DNS names for webmail, imap, smtp, and pop plus you need both http and https. Then going with a proper autodiscover setup for MAPI each client will require four bindings autodiscover.<customer-domain> and webmail.<customer-domain> depending on what you want to call it for both http and https.

The reason for adding the imap, smtp, and pop is so that I can use ACME to manage my Certs. I simply copy over the certs when they change to the cert folder referenced in SmarterMail Bindings.

I think it is time that SmarterMail add to the road-map management of the Certificates. First I would like to see full support of ACME Certs. This is not only an issue for the Web Server, however, also for xmpp, imap, smtp, and pop.

Plus SmarterMail can easily test all of the autodiscover options and then generate the Certs for ACME like it does for DKIM. By using ACME's Web Authentication via .well-known you don't need DNS integration which is difficult given the dozens of DNS implementations.

Also, with the limit of 64 Bindings you also have the issue with 100 Alternative Subject Names for ACME and this another limit from approaching the max limit of SmarterMail licenses. I have 250 eMailbox license and we are moving more and more folks over to MAPI for lots of good reasons -- one is better security. We want to drop IMAP and POP plus MAPI is superior to IMAP.

The one way to solve all of these scaling issues is with some kind of Proxy or multiple bindings that all point to the MRS Folder. Microsoft has offered up YARP 2.0 (Yet Another Reverse Proxy) Engine which is Open Source and might be a viable solution. Here you could create a Proxy per client that needs MAPI. Each Client's proxy would have four entires: autodiscover.<customer-domain> and webmail.<customer-domain> depending on what you want to call it for both http and https. You likely would want to redirect non-https requests to https.

Anyway, I am thinking ahead. Also, you have other limits like the number of Virtual Web Sites which defaults to 100 for the number of web sites after which immediate activation is disabled and dynamic activation is enforced. You can change this default, however, with more and more MAPI usage folks are going to need to have a cluster of SmarterMail Servers some running just MRS to implement MAPI and ActiveSync.

SmarterMail already supports for this kinda of concept with  https://help.smartertools.com/smartermail/current/topics/systemadmin/misc/gateways.aspx, however, we need to consider doing the same thing for MAPI and ActiveSync.

PS: I was able to get CertifyTheWeb 6.0.4.0 to generate a separate Cert and assign it to autodiscover.<customer-domain> and webmail.<customer-domain> depending on what you want to call it for https. I am going to test this for a few domains and see if this works satisfactory.

Hi All!

I'm just using the same FQDN for autodiscover for ALL my clients...

Let's say SmarterMail's primary FQDN is "smartermail.provider.com", I add an SRV record pointing to "smartermail.provider.com" to each of my clients' domain DNS, and so far it's worked great.

This allows me to maintain ONLY ONE fqdn and only one certificate with Certify the Web.

Examples:

record for domain "customer01.it":

SRV _autodiscover._tcp.customer01.it. 0 0 443 smartemail.provider.com.

record for domain "customer02.com":

SRV _autodiscover._tcp.customer02.com. 0 0 443 smartemail.provider.com.

records for domain "customer03.de":

SRV _autodiscover._tcp.customer03.de. 0 0 443 smartemail.provider.com.

Right! That is what I used to do as well. However, as I understand it Outlook will try all of these other Autodiscover request in order of is programming while it "falls backs" thus you are exposing the username and password to these other Autodiscover access points.  Without doing custom domains then you are assuming that the hackers won't take advantage of Outlook Autodiscover trying these other URLs first. Certainly, this is not an issue until someone wants to target you. I'll have to do some packet capture to see what is going on.

I've searched high and low for documentation that states that Outlook sends credentials while running the Autodiscover sequence.

From what I understand, Outlook does NOT send plaintext credentials during the Autodiscover sequence.

From the documentation I found (e.g. here: https://support.microsoft.com/en-us/topic/outlook-2016-implementation-of-autodiscover-0d7b2709-958a-7249-1c87-434d257b9087), AND IF I HAVE READ CAREFULLY... Outlook is simply trying to find a responding server with a valid Autodiscover payload.

Once it has found a server that gives a valid response, then (and only then) try logging in with the credentials provided by the user.

So I think your concerns are unjustified (unless you have other information to the contrary, of course).…

Sure, the problem remains with 365 taking over if by any chance the domain was registered with them in the past...

According to various articles on this topic Microsoft sends User Credentials encoded in Base64 as of late 2021.

This article from Bleeping Computer has a very good run down of the security hole. The concern is no public CVE that I can find describes this issue and what remediation if any that Microsoft implemented.

https://www.bleepingcomputer.com/news/microsoft/microsoft-exchange-autodiscover-bugs-leak-100k-windows-credentials/