Active directory users cannot log in after 1.6 to 2.0 migration

[nblumhardt]

No description provided.

[nblumhardt]

This might be because 1.0 uses the Windows username, while 2.0 uses the UPN. If so, we can append a domain to usernames when migrating.

[nblumhardt]

Case sensitivity in UPNs has also been reported: http://help.octopusdeploy.com/discussions/problems/15087-octopus-20-ravendb-16-import-error-ensure-unique-constraint-violated-for-fields-username

[nblumhardt]

When migrating from Octopus 1.6, we'll now use the currently connected domain to derive the UPN.

A different UPN suffix can be specified by migrating with the command-line:

Octopus.Server migrate --upn-suffix=mycompany.com ...

[plukevdh]

I'm still having issues here, possibly because of a strange setup in our system. I'm using an account on one domain controller to gain access to our AD instance on a separate domain. There is a trust between the two so that either domain should work (mysite.com vs mysite.inside).

Certain infrastructure trusts mysite.local creds, but the initial AD query is made by mysite.inside creds because you have to authenticate with a trusted DC first… This is mostly an attempt to isolate our corp auth system from our developer network which is a bit more volatile. But there is a two-way trust between both forests.

The fail looks like post-migration having tried to use the --upn-suffix flag:

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you think you've found a related issue, please contact our support team so we can triage your issue, and make sure it's handled appropriately.