The Active Directory instance which our Octopus is integrated to for authentication recently was updated to change all usernames from lowercase to all-caps. After this change, some users were unable to log in with either a generic 500 error or a “This username has already been taken by someone else. Please use a different username.” message.
Reports from users didn’t indicate any other information in the browser console related to the 500 when encountered. There were no corresponding messages in the OctopusServer.log
Octopus server version 2020.1.10
Same behavior was confirmed in different browsers for affected users (Chrome, Firefox); the issue seems to come up specifically to individual users, although we haven’t been able to isolate which users would be affected.
Any thoughts as to why changing Active Directory usernames from lowercase to all-caps would cause some users to no longer be able to log in?
The change to make Active Directory usernames all-caps was on May 27, first user that reported they could not log in was June 3 (a week later). Not of all our users use Octopus often, and we’re reliant on self-reporting.
Unfortunately Active Directory is used for many other integrations, so changing the username by adding/removing characters isn’t possible; this would break other workflows.
The workaround we’ve found is to delete the Octopus user entry, have the user log in using AD credentials which will then recreate the Octopus user from AD now with an all-caps username, and re-add teams memberships.
We have moving to using Active Directory groups for authorization soon in our backlog, at which point we could recreate all users with no impact; it’s the secondary step of re-adding teams membership that makes the workaround slightly painful.
If there’s not an obvious “smoking gun”, we may just prioritize AD groups for authorization higher.
Thank you for getting back to me. I know it isn’t ideal, but I’m glad to hear you have a workaround.
For context, Octopus will recognize an AD account as the same if it matches 2 out of 3 on SAM/UPN/Email. Both AD and Octopus usernames are not case sensitive. However, this almost seems as though Octopus saw the case change (as AD is case “aware”), recognizing it as “different”, then attempted to automatically create a new user only to be denied since usernames are not case sensitive. I’m not sure what the differentiating factor is between some users being affected and not others.
I want to apologize as this is obviously not expected behavior. I will raise this issue with our dev team to have them look into this further.
If you have any more questions, please do not hesitate to ask.