Users fail to login after enabling candid/rbac if they existed before

Bug #2024497 reported by Andre Ruiz
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
MAAS
Status tracked in 3.6
3.5
Won't Fix
Low
Unassigned
3.6
Triaged
Low
Unassigned

Bug Description

When you enable Candid/RBAC external authentication in maas, some users will fail to be able to login if another user with the same name existed before in the local database.

If you deploy MAAS and go straight to enabling rbac, everything works fine, all users work normally.

But if you first enable local authentication, create users locally, and later switch authentication mode to rbac, users in candid with the same name as previously existing users will fail to login in maas.

Maas will say "user not allowed" as if the user had no roles defined in rbac, even if the user does exist and has the roles set (does not matter if admin role or user role).

It is specially frustrating when you have a local user called "admin" and later move to rbac, trying to keep your account name. It's like maas does not clean everything during the switch. If this is a feature (intentional), it is not clearly documented and certainly not meeting normal expectations.

Note: this is valid for static users (with no domain) in candid. I have not tested but I imagine that users with a domain (user@domainname) will not suffer from this since they are always different by definition.

Ethan Myers (ethanmyers)
Changed in maas:
status: New → Confirmed
Revision history for this message
Ethan Myers (ethanmyers) wrote (last edit ):

I can confirm this behavior. It's not restricted to the user "admin" either, any users who previously registered with "normal" maas auth will not be able to also register with Candid. I'm guessing the behavior works in reverse, although I haven't tested it yet.

See this attached log for a MAAS error message complaining about non-unique pks:

https://pastebin.ubuntu.com/p/MbsHCKFCx7/

This seems to be a MAAS specific issue -- As Candid/canonical-rbac report a successful authentication.

To me, the correct behavior should be to remove any "old" auth methods after setting configauth in MAAS. Perhaps they can be backed up, but I think it would be reasonable to purge them entirely.

Revision history for this message
Andre Ruiz (andre-ruiz) wrote :

I think that maybe keeping users still there in case you revert back to internal backend makes sense (without having to restore a backup of users), but they should be completely dormant and not influence rbac while switched away.

Revision history for this message
Jerzy Husakowski (jhusakowski) wrote :

This may be a duplicate of LP:1887877 - is the email attribute configured in the same way in Candid as it is for the local user?

Revision history for this message
Andre Ruiz (andre-ruiz) wrote :

I'm not sure they are the same problem. Maybe the solution still applies, but the symptom is different.

In this case, user can login normally from candid side, rbac passes OK to maas, and maas does not allow the user to login because it thinks the user has no attribute configured (neither admin nor user). It's the same behavior as if I take all roles from a working account, it will stop logging in in maas with a message "User not allowed".

The email field is not the same. For the internal one I had something like "<email address hidden>" and for the rbac admin one I had something like "<email address hidden>", definitely not equal.

But we do see in the logs a message about key value unique constraint. My initial thought it was about the username being both in internal db and rbac, but it could be something else.

Revision history for this message
Alberto Donato (ack) wrote :

Currently, email has to be unique in MAAS. When enabling RBAC, local users are disabled but not removed, so if there's already a user with that email MAAS will fail to create a new one for the remote auth.

A workaround would be to remove the local user.

Changed in maas:
status: Confirmed → Triaged
Revision history for this message
Andre Ruiz (andre-ruiz) wrote :

Just to be clear, emails are not the same, what is the same is the username.

Maas is initialized with:

sudo maas createadmin --username admin --password adminpass --email <email address hidden> --ssh-import xxx

And when configuring candid, a "static" user is added with name "admin" but with a different email (specifically, <email address hidden>). It still triggers the issue.

No domain is set for those static users so login happens without the @domain part, making the username just "admin" for both cases.

I'm waiting for logs from the customer and will add them here shortly.

Revision history for this message
Alberto Donato (ack) wrote :

Username is also currently unique.

Revision history for this message
Andre Ruiz (andre-ruiz) wrote :

Understood. Thank you for confirming that.

Changed in maas:
milestone: none → 3.5.0
importance: Undecided → Medium
Changed in maas:
importance: Medium → Low
Changed in maas:
milestone: 3.5.0 → 3.5.x
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.