Octopus admin user has no permissions after DB restore

Hi,
We have to restore an Octopus prod database from our on-prem instance to an Octopus instance in MS Azure.

We are seeing an issue with the admin user we have added to the new Octopus instance. The admin user does not have any permissions so we are unable to do any of the configuration setup we need to do and this is impacting us at the moment. The user is a member of the Octopus Administrators group.

The process I follow is that we export the DB in bacpac format and then import that DB into MS Azure SQL Server.

This has worked for us many times in the past and we are following the same process but for some reason we are getting the below screen when we login to Octopus.

We are currently on version 2022.2.6971

I am also seeing the same in another instance of Octopus we are running. The user octopus26410_admin_87512457 is part of the Octopus Administrators team, but when I log in with the user I get the same error.

Kind Regards,
Micheál Power

Hi @mikepower79,

Thanks for reaching out on our community forum. I’m sorry you’re having trouble with your admin account access. Luckily, you can reset the admin account using the Octo Server command line exe and then log in with the reset account to get your settings back to the way you’d like.

Follow this doc page to reset your Octo Admin account for the instance.

Let me know if you have any questions.

Best,
Brent

Hi @brent_kinney,
We are using Linux containers to run Octopus.
At the moment we are trying to reset the admin account and will update you with our progress soon.

Kind Regards,
Micheál Power

1 Like

Sounds good.

Hi @brent_kinney,
We have tried to reset the admin user but still not working.

Also we didn’t see this issue before we upgraded to version 2022.2.6971. As its happening on both of our Octopus instances, any chance its an issue with the version?

The admin user (Users-3381) is a member of the Octopus Administrators.

Kind Regards,
Micheál Power

Hey @mikepower79,

Was the ‘octopus2_admin’ a new user? If it wasn’t, you would probably want to try that command with a username that doesn’t already exist instead of trying to overwrite an existing user.

Best,
Brent

Hi @brent_kinney,
Yes Octopus2_admin is a new user we created.

Kind Regards,
Micheál Power

Were you using AD in your instance? With AD auth, sometimes the Username and PW auth can be turned off. You may need to re-enable it. This article has the commands to do that - Active Directory authentication - Octopus Deploy

Its also possible that the Admin user role had the permissions stripped. That could explain why the users show as in the admin group but have no permissions. You could check the UserRole db table to see what is listed under the System administrator row. Below is the JSON columns data from my local instance Admin role so you can compare.

{
    "Description": "System administrators can do everything at the system level.",
    "GrantedSpacePermissions": [],
    "GrantedSystemPermissions": [
        "AdministerSystem",
        "ConfigureServer",
        "EventView",
        "TeamCreate",
        "TeamView",
        "TeamEdit",
        "TeamDelete",
        "TaskView",
        "TaskCreate",
        "TaskCancel",
        "TaskEdit",
        "SpaceView",
        "SpaceEdit",
        "SpaceCreate",
        "SpaceDelete",
        "UserView",
        "UserInvite",
        "UserRoleView",
        "UserRoleEdit",
        "UserEdit",
        "TelemetryView"
    ],
    "CanBeDeleted": false
}

Best,
Brent

Hi @brent_kinney,
AD is used in the on-prem DB before we restore it. We disable AD in Octopus DB before we run our YAML pipeline which creates the Octopus namespace and spins up the Octopus pods.
We use Okta and Azure AD to login to Octopus after the restore is complete.

We have done the import process multiple times without any issues, this is the only time we have encountered the issue.

The user role looks ok as you can see below.

Kind Regards,
Micheál Power

Hey @mikepower79,

Thanks for the clarification. I’m glad your admin user role is intact. I think your best path forward would be to try that forms auth command from the article linked in my last message.

You could also try restoring the DB into a fresh Azure VM and pointing your octo server at the new SQL instance to rule out any wonkiness with your latest import.

Let me know if you can try either or both of those options and how they go.

Best,
Brent

1 Like

Hi @brent_kinney,
The Octopus Admin user in version 2022.2.6971 can login but still has no permissions.

The admin user can login to our on-prem version 2021.3.12372 and has permissions. So we configured AAD login on that version and upgraded to 2022.2.6971 and this way we could login with our AAD account and configure Octopus.

The reason on-prem version is behind is that we will be migrating all the user from -on-prem Octopus to Octopus hosted in an ITAAG in Azure.

So when we are doing a restore of the on-prem DB to SQL Server in Azure, we run into this issue.
We are restoring the DB so the on-prem users can do some testing before they migrate.

This is probably a unique situation in what we are doing, can you rule out that this is an Octopus issue?

Kind Regards,
Micheál Power

Hey @mikepower79,

I’m not sure we can rule out Octopus just yet. I think your scenario might benefit from a zoom call so we can try to figure out what is going on. Do you have any availability today, tomorrow, or next week? If you do, what times work for you, and what time zone are you in?

Best,
Brent

Hi @brent_kinney,
Ya a call will be good and I am available tomorrow. I am in Dublin, Ireland.
My hours of work will be 9am - 5pm.

Kind Regards,
Micheál Power

Hey @mikepower79,

Let’s meet tomorrow at 330 PM your time. I will DM you the meeting info.

Brent

Hi @brent_kinney,
Any update on this issue.

Kind Regards,
Micheál Power

Hey @mikepower79,

I have prodded the engineers again for you to see if they have an update, when they respond I will let you know.

Kind Regards,

Clare

1 Like

Hi @mikepower79,

Just stepping in with a quick update from the engineers!

They’d just like to clarify if the user you are creating, octopus2_admin also exists in the on-prem instance or if it was created after you completed the DB restore?

Would you be able to please send through a JSON export of the Octopus Administrators Team, as well as the JSON user data of the created user, octopus2_admin?

If you could also please send through the Octopus Server logs which cover the user creation and login attempt?

That should give us everything we need to track down exactly what’s going on, however a potential workaround if the user isn’t being assigned the correct permissions, could be to add the user to the Octopus Managers Team as well.

You should be able to upload any files securely here, let us know how you get on or if you have any questions!

Best Regards,

Hi @finnian.dempsey,
The octopus2_admin user is created after we complete the DB restore.

I have uploaded the json files for team and user data.

I added the user to the Octopus Managers team, but still getting the same issue.

Kind regards,
Micheál Power

Hey @mikepower79,

Thank you for those logs! I will get those to the engineers so they can take a look at them.

I am sorry adding the user to the Octopus Managers Team did not work for you too, that would have been a nice easy win workaround whilst we got the initial issue fixed.

I got the json file too so will pass that on, thank you for your patience whilst we continue to work on this issue.

Kind Regards,

Clare

1 Like

Hey @mikepower79,

The engineers have got the logs and are going to start really digging into them today, but they have a question I hope you could answer for them.

They would like to know what happens if you setup a fresh instance of octopus server on one of your pods, and create an admin user on that fresh instance. Does that still fail? The engineers are trying to figure out whether something is broken in the product vs something breaking from the migration.

I look forward to hearing from you,

Kind Regards,

Clare