We have our OD server configured for windows auth and I want to add a new user. Each time they try to authenticate the server returns with 400 Bad Request and zero content. I haven’t been able to find any relevant error logs from the server. I tried to add them as a user and use the invite link as well. The invite link worked, until they signed out and signed in again. I have also tried enabling the form to get the credentials verified on the server but this also has not worked.
This is our current config:
Loading plugins from: C:\Program Files\Octopus Deploy\Octopus\BuiltInExtensions
Loading BuiltIn extension: AzureAD (2.0.4.0)
Loading BuiltIn extension: Directory Services (2.0.7.0)
Loading BuiltIn extension: GoogleApps (2.0.4.0)
Loading BuiltIn extension: Guest (2.0.1.0)
Loading BuiltIn extension: UsernamePassword (2.0.1.0)
Octopus Deploy: Server version 3.8.1 (3.8.1+Branch.master.Sha.610895b305d7e6d73d6dcd9b7d5bfa6e216ee4e2) instance Default
Environment Information:
OperatingSystem: Microsoft Windows NT 6.2.9200.0
OsBitVersion: x64
Is64BitProcess: True
CurrentUser: [Me]
MachineName: [ODServerName]
ProcessorCount: 2
CurrentDirectory: C:\Program Files\Octopus Deploy\Octopus
TempDirectory: C:\Users[Me]\AppData\Local\Temp
HostProcessName: Octopus.Server
<?xml version="1.0" encoding="utf-8"?>
False
/api/users/authenticatedToken/AzureAD
10943
False
/api/users/authenticatedToken/GoogleApps
C:\Octopus
20
[OurDataConnectionString]
[ODServerName]
0
true
true
False
True
True
True
IntegratedWindowsAuthentication
False
False
False
https://localhost/
False
The server is also running under a domain account.
Hi Rory,
Thanks for getting in touch! Sorry to hear you’re experiencing this issue with creating users, if I can get some more information on a couple of things we should hopefully be able to get it resolved for you.
Thank you also for including the configuration settings, that’s a great first step and it all looks correct for a typical AD installation. For the next step of troubleshooting, we’ll need to look a bit more at your specific AD and server setup.
Just to confirm your process, the user’s are seeing these errors on login after you’ve already created them through the UI? With AD Octopus Deploy will also automatically create new users if they can authenticate successfully, so if you don’t create them in advance do you see the same errors? Would you be able to check the entries in the User table in the DB after they’ve tried to authenticate?
Sometimes if you’re creating users in advance and the username has been defined as just username and not domain\username then Octopus can confuse them as a new user when they log in (setting their email will prevent this as it’ll then recognize who they are).
Are the users members of the same domain the Octopus Deploy server is joined to? Are they in the standard Users container in AD?
Chrome and IE both include Developer Tool that can show you the network traffic, are you able to see any details of the 400 response in the Developer Tools? Sometimes there will be more specific error information in there that we don’t surface through the UI.
You mentioned that you couldn’t find any relevant error logs, I just wanted to check that you were able to find other log entries from the server? Sometimes when the service account gets set on the Octopus Deploy windows service it doesn’t have write access to the Octopus instance folder and the server has issues because of that.
Apologies for the number of questions, AD configuration can be complicated so we have to try to hone in on where the configuration isn’t right for your environment.
Regards
Shannon
Hi Shannon,
Thank you for the follow up.
I did get him to try to sign in first with his domain account. This failed with the 400. I then tried adding him manually and also by using an invite. All these failed to get him in and I subsequently removed the manual accounts.
Currently this user is not in the users table.
The users account is in the same domain as the OD server service account.
I’ll have to wait until my network admin is around for me to check what OU the user is in.
We had a look at both IE and Chrome dev tools the other day. There is no content returned and nothing in the response headers other than 400 bad request.
The OD server service account does have write access to C:\Octopus\Logs and is writing log data there. The following is the only reference to this user in the server logs:
2017-01-24 11:34:35.6607 128 INFO External groups invalidated for user: [USERNAMEHERE]
There are no other logs for 10 minutes either side of that entry.
Cheers,
Rory
Just to confirm then, you have other users who can authenticate? I.e. it’s just this one new user who is having trouble?
I’ve seen the integrated challenge come back with what looks like a blank page to the user, which I think is a 400 under the hood, if you cancel the login if the browser pops up a challenge dialog. It’s possibly environmental on that user’s machine, we issue the challenge first and then the browser should come back to the same endpoint again with the credentials, and we wouldn’t log unless we got into that second part and something failed. What could be causing the challenge to fail I’m not certain of yet.
It’s interesting that the forms authentication is also failing, that’s there so the machine doesn’t have to be on the doman, the user just has to be able to give us their username and password. That process uses an API call, which does an authentication call into AD and has much more logging, so I’d expect to see more detail from that one on a failure. Would you be able to get the user to try that method of logging in again and double check the logs and the browser response content on the /users/login API call?
The “External groups invalidated” log entry is the server recording that the user has explicitly logged out, when they do we delete our knowledge of which AD groups they are in (ie External groups).
Regards
Shannon
All the users are in the same OU in AD.
I got him to try the form again and this time it worked. He then signed out and tried the challenge and it again failed with Bad Request.
That log entry was probably from when he could get in via the invite and I got him to sign out.
Current state is that using the form on IE11 works fine. IE11 does not work when using challenge.
Firefox works with both form and challenge.
Have confirmed the same on my machine for my own account. IE11 fails on challenge, passes on forms. I use chrome on my machine and both form and challenge work fine. Seems to be just an IE11 issue.
Interesting. I wonder if IE thinks that Octopus isn’t in a trusted zone and therefore it’s disabling Integrated Windows Authentication? You should be able to check that in the Settings for Integrated Windows Authentication, it may require adding the Octopus URL to a Trusted Zone.
Regards
Shannon
Ughh. I’m getting totally inconsistent results.
I’ve added the uri to the trusted sites. Challenge failed like the password was wrong, tried again and got the 400. I go back and start the challenge and now I’m in without the prompt.
I tried an in-private session in IE11. First doing rounds of 400’s using the domain on the username. I then try without the domain name and I then get in.
The other user’s machine while using IE11 doesn’t allow him to specify a username without the domain. This is because his machine is domain joined and mine is not.
We added the uri to his trusted sites but he still has the same 400 response.
So it looks like the common scenario here is that a challenge where the response is a username including the domain on IE11 does not work. I can use just a username on the challenge but he can’t. Forms auth with domain credentials on IE11 does work (irrespective of trusted sites).
So basically, don’t use IE. 
I’ve checked in a test environment we have set up and IE11 can definitely work with the integrated link (Integrated Windows Authentication is enabled on that test machine, per attached screenshot). If you have the same setting there then I think it would have to come down to the Octopus Deploy site not being in the Local Intranet Sites on the Security tab.
I’ve aligned my browser config to that but still no joy. We have enough workaround in place that this no longer blocks us. I doubt we will be able to convince IE11 to play ball. Not using it is just easier.
Thanks for the help.
No problems.
Happy deployments!
Shannon
