Tried to reconfigure Octopus Deploy Server today to authenticate against our AD instead. We’ve been using for 3-4 months now with approx. 20-30 users. However when reconfigured octopus, using the admin tool, to use windows authentication, we are prompted for username/password when we request the page. No AD credentials work!
Facts
The machine hosting Octopus is a member of the AD
After configuring octopus, the IIS authentication looks ok
Even though we are logged in as a AD user on the machine, we are still prompted for u/p
No u/p work
The octopus service is run under an AD user
Prior to reconfiguring, we updated to version 1.3.5.1564
I’ve tried to uninstall octopus and reinstall with no luck. We’ve reverted back to local db users again, however Ops really want this working. Any ideas?
Go to your install folder (such as C:\Program Files (x86)\Octopus\Portal) and check the web.config manually. Make sure you have <authentication mode=“Windows”>
Check the IIS settings on the Octopus site (Windows Auth ON and ALL others OFF)
Mine has worked against our AD right out of the box, so I’m not sure what you have going on there.
If this still doesn’t work. Make yourself an empty HTML file (that will not run under the .NET runtime) under the octopus root folder and see if that prompts you for authentication. If so, your problem is probably not Octopus related.
If that doesn’t work change the service to run under ‘Local system’. If that fixes it, then your AD user you are running the service as does not have the correct permissions to authenticate against the AD directory (obviously).
If that doesn’t work then what sort of App Pool are you running it under (Classic or Integrated)? And what version of .NET is it set to use?
You can also check that Windows Authentication feature is installed and enabled for IIS by going to the IIS add features screen in Windows. Also ensure Basic and Anonymous authentication are disabled - only Windows authentication should be enabled.
So I did some trouble shooting tonight and it seems that it was actually working all along. However some requests (like login, initial request to octopus) takes forever to complete (like 4-8 min). So maybe there’s some kind of error with this particular machine in regards to the AD. Very hard to troubleshoot and I’m forced to revert.
What happens if a username is created, while in local user storage mode, and when switching to windows authentication an AD with the same username tries to login? Do I need to delete the existing users?
Well, first thing I would say is to do some of the steps above again
Place a plain html file in the Octopus web root and try that. If it still takes ages to authenticate the problem isn’t in octopus.
You might also try right clicking on the ‘Windows Authentication’ in the ‘Authentication’ part of the IIS screen and checking out the provider options. Try turning off negotiate and leaving NTLM on its own or whatever.
My issue is a little similar. Win 2008 R2 server connected to AD. Octopus installed to port 8075 but using other defaults (i’m pretty sure). Using ApplicationPoolIdentity, Integrated pipeline mode, Windows Authentication using kernel mode. Providers are Kerberos and NTLM in that order.
Can browse the site fine when RDC to server using it’s version of IE 9. Get 401 error when browsing from remote machine using IE 10.
Interestingly, change the AppPool to use NetworkService and I can browse http://server:8075 just fine from remote. Change back to ApplicationPoolIdentity and get 401 error.
After some research, finally trusted the computer for delegation to any service and viola it’s working.
Turned off trusted delegation and curiously it’s still working though did ask for login credentials. Rebooted the server and local machine and it’s still working. I’m sure I haven’t changed anything else so this is a little weird. Perhaps it may help someone else.
Thanks for following up on my question. Our ops team finally found the problem, in the firewall between vlans and one of the AD servers. A single symptom was enough to rule out the Octopus configuration, since I could not connect via RDP to the machine with my AD user. After the firewall was reconfigured to allow (a port I guess), everything was smooth.