Host binding issue on version

Since applying the latest patch I’ve tried adding in a new web portal binding simply named http://octopus, prior to this patch I just had an IIS redirect with the same binding which redirected to http://servername:89 which worked fine.

There were two problems, the first was the service kept crashing due to the fact I forgot to remove the IIS binding, so there was a host/port conflict, it would be nice if Octopus was able to catch this rather than having to check event logs. This wasn’t a big issue and easy to fix, but thought it may be worth mentioning.

The bigger issue is that authentication using http://octopus just doesn’t seem to work. If I access the site using http://octopus it presents the login screen, I then login using my AD credentials, it successfully logs in but then shows a screen where I have no permissions to anything. If I then login using the URL http://servername:89 it logs in correctly with all the right permissions.

Hi Ian,

It is a bit of a stretch of logic, but here’s my guess at the cause here:

  1. Version 1020 fixes a case sensitivity issue on the Username index
  2. When you configured the server, somehow duplicate entries differing only by case were created for your username
  3. The old URL corresponds to a valid auth cookie in your browser that matches your “real” admin account
  4. The new URL has no such cookie associated and so authentication is required, which picks up the “other” duplicate with no permissions

The way to fix this is to go to [Your Username] > Profile, when logged in with the “good” account, and take note of your username (casing etc).

Then go to Configuration > Users, find the duplicate User record with different Username case, and delete it.

If you get stuck at any point in the process, running:

Octopus.Server.exe service --stop

Octopus.Server.exe admin --username=YOURUSERNAME

Octopus.Server.exe service --start

…will get your admin account back in action.


Thanks for that, it was a little more weird than that as my account did exist twice, but both were completely identical, even down to the case. One had an ID of 1 and another of 129, so I took a stab and deleted the 129 one, unfortunately that locked me out so I’m glad you provided the script above.

Using the script above it created ID 130 with once again the exact same details so I deleted ID 1 and everything seems ok now.

Thanks for your help.

Ah! Great to hear it is sorted out :slight_smile: … I’m not sure what was going on with the duplicate - perhaps applying the index change with duplicates already in the database caused something odd. Thanks for following up!


Here is a powershell script I use to detect duplicate binding conflicts prior to deploying the package…
Make sure that your getting the correct StepName for the octopus parameters.

Write-Host “Checking for Binding Conflicts”
$bindings = $OctopusParameters[“Octopus.Action[STEPNAME].IISWebSite.Bindings”]
$site = $OctopusParameters[“Octopus.Action[STEPNAME].IISWebSite.WebSiteName”]

#verify that these bindings do not conflict with any other sites.
import-module WebAdministration

$hasBindings = $false
$bindings -split “|” | foreach-object { $match = [regex]::match($_, "^([^\/]+)\/([^\:]+)\:([^\:]+)\:([^\/]*)(\/.*)$") $protocol = $match.Groups[1].Value $ip = $match.Groups[2].Value $port = $match.Groups[3].Value $hostname = $match.Groups[4].Value.ToLower() $hasBindings = $true Write-Host "Check Binding: $protocol -> $ip:$port:$hostname" get-childitem "IIS:\Sites" | foreach-object
$sn = $.Name
if ($sn -ne $site) #Skip same site name (redeployment)
$hasSiteBindings = $false
.Bindings.Collection | where { $_.protocol -match “^https?$” } | foreach-object { $sb_protocol = $_.protocol $sb_match = [regex]::match($_.bindingInformation, "^([^\:]+)\:([^\:]+)\:(.*)$") $sb_ip = $sb_match.Groups[1].Value $sb_port = $sb_match.Groups[2].Value $sb_host = $sb_match.Groups[3].Value.ToLower() Write-Host (" - Checking ""$sn"": $sb_protocol -> $sb_ip:$sb_port`:$sb_host")
$hasSiteBindings = $true

			if ($sb_port -eq $port -and $sb_host -eq $hostname -and ($ip -eq $sb_ip -or $ip -eq "*" -or $sb_ip -eq "*"))
				throw "An Existing Site: ""$sn"" already has binding for $protocol`: $ip`:$port`:$hostname - please correct the bindings for deployment or manually fix the existing site bindings."
		if (!$hasSiteBindings) { Write-Host " - No bindings for site: $sn"}

if (!$hasBindings) { Write-Host " - No bindings for deployment site."}