Hi, we just got a new team member, which is having problem authenticating with Octopus Deploy (Self-hosted).
We’ve set up Azure AD Auth, allowing user creation on first sign-in. However, after successful authentication with AAD, the user is redirected to /api/users/authenticatedToken/AzureAD, and is greeted with the error “Display Name is required”. And at times this message is replaced by an error saying “Missing State Hash Cookie…”. I’ve tried creating the user in Octopus Deploy manually, with the same ID/email as the AAD account, but login still fails with the same error(s)
I’ve looked at the requests getting passed to the authenticatedToken/AzureAD endpoint, and the fields in the id-token in the request data are identical to when I log in. So I think the problem comes when Octopus parses the data it gets from AAD after exchanging the auth code. Could you help me find out what Octopus Deploy is looking for to find “Display Name”? So I can see if there’s something wrong with how the user is set up in AAD. As far as I can see everything is identical to my user - which works.
I found a couple of threads in this forum on what seemed like the same problem, but they were all closed before resolution due to lack of response.
As mentioned in my issue, I compared the id-tokens in the payload from Azure to the authenticatedToken/Azure endpoint, and they are identical, apart from the values. They both include (among others) unique_name, upn, sub, oid.
Our engineers have got back to me and would like to know when creating the user account manually in Octopus in the external login section of the user, is the Display Name field populated?
It would also help if you could send a screenshot of the manually created user account, and if an the account is auto created a screenshot of that too.
I just created a manual user for the person, which I also tried initially. However, this time it worked as expected.
Not sure if something has been fixed in a release in between, or if I did something different this time, but my problem is resolved. We’ll see if the next person also requires manual user creation, or if this was just something weird with this person’s AD account.