Microsoft has released security updates for vulnerabilities found in:
Exchange Server 2013
Exchange Server 2016
Exchange Server 2019
These updates are available for the following specific...
Updated May 05, 2021
Version 8.0
Blog Post
Update:
So I was apparently under the misconception we also installed the patch (it was planned but didn’t go through because of scheduling issues,apologies for the confusion).
This does explain some things, like the fact that OUR f/b is still visible to the other forests, whereas the other forests did do the patch and THEIR f/b is not working for us.
I created two test users, identical aside from one having a $ as last character in his samaccountname.
Testexfb to A and B Autodiscover link = Status 200 after auth
Testexfb$ to A and B Autodiscover link = Status 400 after auth
logging on to our owa with the testexfb$ account doesn't pose any issue, I'm going to ask the other forests to try this to see if they get an error or not.
So despite status 400 pointing to the client (us in this case) it’s imho not a matter of sending different data but rather of the domains (A and B) no longer being able to read /accept the data.
400 | Bad request | The Hypertext Transfer Protocol Stack (Http.sys) file blocks IIS 7.0 and later versions from processing the request because of a problem in the request. Typically, this HTTP status code means that the request contains characters or sequences that are not valid or that the request contradicts the security settings in the Http.sys file. |
ShaikeI think there was/is a misunderstanding. If I do test-autoconfig via outlook i get Status 200 on first try or second.
I can obvi be mistaken but I have the idea that autodiscover as a service is working and was always working, it's only when the impersonation comes in play that stuff stops working. Which again, would support the hypothesis of the servername$ problem.