I am not an IIS user, but I believe that the "401 0 0" status on those failed /adm/index.php access attempts shown in the log are indicating "the executing PHP code decided to return this HTTP status." i.e. There hasn't been "an actual error" like Win32 ERROR_ACCESS_DENIED for NTFS permissions or ERROR_PATH_NOT_FOUND for missing folders or paths; nor a sub-status indicating that IIS itself detected some kind of configuration reason to return 401. Yet the 401 status has been set for return anyway "even though there was no error" from IIS' perspective.softpronick wrote: ↑Wed Oct 09, 2019 2:37 pm2019-10-09 14:26:28 192.168.3.4 GET /adm/index.php - 443 - 184.108.40.206 Mozilla/5.0+(Windows+NT+10.0;+WOW64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/77.0.3865.90+Safari/537.36 - 401 0 0 203
2019-10-09 14:26:30 192.168.3.4 GET /adm/ - 443 - 220.127.116.11 Mozilla/5.0+(Windows+NT+10.0;+WOW64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/77.0.3865.90+Safari/537.36 - 401 0 0 171
phpBB does indeed set a 401 status in cases where you're trying to access a phpBB module that requires authentication you don't already hold. But its also usually followed by a redirect -- to the root index or to a login -- and the redirect ultimately returns 302 status instead of the 401.
Not that this "pinpoints" any particular cause; but just wanted to point out that the failures logged here seem like they could be evidence that /adm/index.php is being executed, but has decided itself to return 401. As opposed to if the IIS web service process had declared this 401; in which case we would have also seen a sub-status and potentially a Win32 status involved in why IIS had decided it needed to declare the 401 status, without ever executing any PHP code.
Clearly "something changed", but still no idea what. Is something preventing phpBB from issuing the 302 redirect now? Or is some new condition causing phpBB to take some previously non-traveled code path that ends in a 401 without a redirect? Is there a non-default authentication mechanism configured which phpBB is trying to invoke, but can't and is stopping at a 401 failure instead?
Ensuring the /adm folder itself is complete and has the same file system permissions as the rest of the board is of course good. But these mechanisms that evaluate authentication, handle redirects and deal with exceptions are all in the /includes, /phpbb and /vendor folders. So you might want to also compare the current server against a clean copy of the phpBB installation set for all of these folders; if just to confirm and rule out the existence of any intentional or unintentional differences.
edit: Perhaps the .htaccess or IIS web.config files, if they had rules to return 401 under some condition, would also show as "no error" for the 401 status in the IIS log? Not being an IIS user, I don't know if IIS would have a specific substatus for those. Even if you didn't edit those files, you might need to review them to see if an existing rule's conditions are perhaps just suddenly now being satisfied, due to some other external change.