Octopus to Azure AD Integration Failing

We are facing an issue with Azure AD integration. I have followed the Octopus Guide on Azure AD integration.

We also have a Web proxy which filters all the requests going over the Azure AD (Internet).

Octopus ==> Zscaler Web proxy ==> Azure AD (Internet).

In Octopus Logs I am getting below error:

023-09-25 17:02:08.9408 3752 22 INFO “HTTP” “POST” to “localhost:9093"”/users/authenticate/AzureAD" completed with 400 in 00:01:40.0224305 (100022ms) by “”.

In the following post I am also attaching the other configuration details.

Please help in getting this issue resolved.

Attaching are the configuration settings we have used for octopus.
Octopus-AD-Integration-25thSept_v0.1.docx (253.6 KB)

Hi @rahul.bhoyar,

Thanks for reaching out, and I’m sorry to hear the Azure AD integration with Octopus isn’t working as expected.

First, may I ask which version of Octopus server you’re using? I’ll use this information to see if there are any known or open issues associated with your version.

If you’re willing to provide me with a copy of your Octopus Server Log, I can review that for further details and context on my end. You can use the following link to upload this to me securely:

rahul.bhoyar | Octopus Support

I’m looking forward to hearing back from you.


Octopus V2022.3 (Build 10437)

The logs are also attached. The logs could have overwhelming information which you may not need. Hence, you can focus on the logs around below line:
“HTTP” “POST” to “prod-octopus.t1cs.cloud1.bfsiplatform.co.uk”“/users/authenticate/AzureAD” completed with 400 in 00:01:40.0267261 (100026ms) by “rbhoyar”


Hey @rahul.bhoyar,

Jumping in for Patrick who will be online later as part of our US based support team, I recall you having a lot of Azure AD authentication issues with another one of your instances on other tickets, the one below looks very similar to what you are seeing here but that was on your dev instance whereas this one looks like its on a prod instance:


I am just confirming you have let this URL through the firewall as that was the issue last time:

The issue got resolved. The issue had indeed caused due to octopus:443 call from octopus deploy. I had to get this port open and the issue got resolved.

I can see this in your logs before the Azure AD 400 error:

2023-09-26 09:52:28.5833   3752     77 ERROR  The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing.
System.Threading.Tasks.TaskCanceledException: The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing.

Last time in the previous issue you mentioned:

However, I am 100% sure that this issue is due to the fact that octopus is calling octopus.com:443 and is not able to reach the octopus.com:443 as in the windows event viewer log the request is getting timed out after 100 seconds… ALso, this is exactly shown in the octopus logs as well…where it suggests that the response took more than 100 seconds and timed out.

Can you give that old forum post a look and see if you can see the same kind of errors in event viewer you mentioned:

If you are getting the same errors from Event viewer are you able to follow the same proceedure you followed last time with letting octopus:443 through the firewall.

Let me know if that does not fix the issue but that old forum post has a lot of the troubleshooting steps we would go through here so it may be worth giving some of those a try on your production instance to see if they get you to a resolution.

I look forward to hearing if the firewall port open works,
Kind Regards,

Hi Clare,
Thanks for the suggestion.

Could you please confirm whether this connectivity (octopus:443) is absolutely required to resolve this issue? Certain documentation, etc., apart from the referred post.

I am asking this because, considering this is a production environment, our security team will only allow only if there is a recommendation from product team (Octopus) with a relevant explanation.


Hey @rahul.bhoyar,

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.

Kind Regards,


Thanks for your help so far on this issue.

Since it is a production environment, until I have a solid justification on allowing this communication “octopus:443” , it would be difficult that will be approved by security.
However, I appreciate your suggestion, considering as far as my experience with Dev environment is concerned it worked fine.

However, I now wish to approach this issue with the understanding of how octopus works. Hence, for now I am ruling out allowing octopus:443.

In such case, I will try to do below things tomorrow:

i) I have octopus running with a service account (sv-octopus) . hence, I will update the proxy configuration of my windows server by logging into the same with the same service account(sv-octopus).
ii) Also, I will try to hit the open id url “Sign in to your account” using the same login (sv-octopus).

I will get back to you with my findings on this.


1 Like


We have been able to move forward with the AD integration, after setting up the web proxy by using the user (service account) which is being used to run the Octopus service.

So, we did not have to open the firewall communication to octopus.com:443.

I will keep you updated with the further progres.


Hey @rahul.bhoyar,

Great news thanks for letting us know, for any more help with this issue if you can email us over at support@octopus.com as we have discontinued our official support on the forums as per our notification on the top of the forum page.

I do not want this issue to get missed if you do have further need for us to investigate this so if you do run into any more issues can you email us and quote this forum post and we can carry on the discussions over our official support email channel.

Kind Regards,

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.