4

We run B2B multi-tenanted application on Azure. Each tenant has a subdomain on tennant1.example.com, tenant2.example.com, etc. Only login page is available to a world, everything else of the application is behind a login. Only a limited number of tenants with a pretty big contract to sign before you can get a login.

For a while our logs indicated that every so often (30-40 hits a day) we get 404 generated by https://autodiscover.example.com/autodiscover/autodiscover.json?Email=realemail%40example.com&Protocol=autodiscoverv1&RedirectCount=1

We don't have a tenant named autodiscover and no such file to serve the requested query, so obviously goes to 404. However, as part of the query it provides an email address which is our real support email address.

Search for autodiscover.json did not reveal how to deal with this and what causes it (no Referrer header on the requests), other than this is something to do with Office365 and MS Outlook.

Now my question - should I be concerned with this? Is somebody trying to configure Outlook client and slowly attempting different passwords? If this is a service, who should I contact to stop this? Is this something I should be providing as part of the appliacation? Is this part of Office365 configuration that somebody started but have not finished (the domain name is pretty old). Should I just redirect them to Ten Hours of Fun?

3
  • Question: Have you actively configured the "autodiscover." DNS sub-domain? Why? (Or are you using wildcard DNS?) Commented Mar 20, 2018 at 11:24
  • @StackzOfZtuff it is a wildcard sub-domain. Have not configured it explicitly
    – trailmax
    Commented Mar 20, 2018 at 11:24
  • 2
    Do we have a canonical question explaining how to not get frightened by random bots trying random URLs on your webserver? If not we should really create one.
    – Philipp
    Commented Mar 21, 2018 at 14:20

1 Answer 1

4

Microsoft Exchange ActiveSync clients use that URL for finding the ActiveSync endpoint. The link says that they look for autodiscover.xml, but I bet newer clients look for the .json file (this GitHub comment says it's not documented). It's probably coming from a client set up by one of your employees who has access to that email. It is possible that they tried to setup their email client and failed, but it intermittently tries to discover the correct URL. In any case, it's not an attack, just a misconfigured client.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .