If you check back on that forum post I did state you should not need to allow that through the firewall as what you were seeing in your event viewer was to do with extension metadata and should not be required for Azure AD integration.
Thanks for getting back to me, unfortunately that is a bit of a red herring when it comes to this issue, from the event log I can see that is failing to access our octopus.com website to get the dynamic extension metadata.
This is just for automatic upgrades via the Octopus UI so it does not need to be whitelisted in order to get the https://login.microsoftonline.com URL working.
I have absolutely no idea why unblocking octopus.com:443 worked for you though, it makes no sense but we will take the win!
However, as soon as you let that through it started working for you so there must be something specific to your network that requires that to be allowed through the firewall. No other customer has reported they needed to allow that through and I have never had to allow it through when setting up any of my test instances through Azure but as mentioned, as soon as you let that through for your dev instance it started working.
So unfortunately I cannot say it is a requirement, however, we spent a fair amount of time troubleshooting this on your dev instance and the only thing that got it working was you letting octopus:443 through the firewall.
The best thing to do would have it as a temporary rule, then try connecting to Azure AD again, if it works you know you need to have that setup as a rule, if it does not work let us know but I would try running through what we mentioned previously on the other forum post as that is what we would do again so its best to try everything we mentioned last time and then get back to us so we are not going over the same suggestions for you.
I know that’s not the best answer but it did not make any sense last time that it only started working when you let octopus:443 through the firewall, but that was the only thing that got it working and the logs you showed us for your prod instance are showing the exact same timeout errors that your dev instance was showing just before you let octopus:443 through the firewall, as soon as you did that it started working.
I would let that through temporarily just to rule that out, you can always delete the rule if it does not work. All that will do is allow telemetry through and allow access to your instance to octopus.com to get things like plugin and Octopus Server updates so its not giving your instance access to the whole internet.
Hopefully that helps alleviate any concerns you had moving forward as I do realise letting that through on a production instance needs a bit more caution but you do need to try that in order to rule it out, since that’s what fixed the issue last time we are unable to troubleshoot this until you rule that out just to save a bit of back and forth when we know that was the issue last time.