I’ve been trying (and failed) to find up-to-date, detailed but accessible info regarding the current rights model and functionalities (without SQL queries or the like, we consider the cloud version of Passbolt and have no ability to understand or implement that sort of things).
And in the details, I have some questions :
How does “ownership” of Passbolt account work ? Can we be at least 2 (or more) owners of the account, to avoid unilateral deletion by a rogue or careless employee ? When the/an owner quits the org, is there a way to transfer ownership ?
In past discussions prior 2020 or 2019, it was said that an admin cannot even know the existence of passwords not shared with him (at leasts those assigned to groups). Is there a role that can (1) know the existence of ; (2) access and manage, all passwords of all groups ?
Granted this is opensource, but since you propose paid SaaS on cloud, the documentation should in my opinion reach a minimal level of completeness and precision. It seems to me far from that at the moment.
A user account in Passbolt is linked to an email address and a private GPG key. To share an account with another user, you must share the private key of this account, and grant an access to the email address. So it is possible for example to setup an email for the shared email box of your IT department. Only administrators can create or delete users. There is no option to prevent a rogue administrator to delete a user at the moment.
Indeed there is currently no role or option who can know the existence and manage all passwords or groups of the organization. This is one of the design choice of passbolt. This allows people to store personal passwords in passbolt, or make sure the legal department passwords are not accessible by the IT department for example. As a workaround it is possible to train your users and make sure that you have a rule within your organization to share passwords with a “master account”. Unfortunately it is not something you can enforce via the administration settings at the moment.
We are aware of the lack of documentation on some parts of the product but we improve it every day. Feel free to make us a list of the documentation aspects you were looking for, we’ll make sure to add it to help the community as a whole.
As you are a passbolt customer, if you need more informations about Passbolt, you can also write us to firstname.lastname@example.org. We would be be happy to schedule a demo meeting to answer your questions and get you up to speed with the current capabilities, best practices and the roadmap.
Hi @_jc many thanks again for the detailed and prompt answer !
(actually, we are not yet Passbolt clients : precisely, I’m in charge of examining existing solutions to make a proposal so that we migrate to a password management app)
Regarding your answer related to the “ownership” : I am not sure that I understand correctly. Is it that there is no overall “organization’s ownership” as such ? Your reply deals with specific services, which are only sub-parts of the org. But, basically, there must be one (unique) Passbolt account for the organization, to which admins, group managers and users accounts are related ? no ? Do I miss something to the architecture of Passbolt ?
Regarding the lacking documentation : in my opinion, it should be top priority that you provide an up-to-date and complete doc on these two (somewhat related, obviously) points :
all features (present and, why not, also lacking) for sharing, groups, etc. with screen captures, as in your blog posts
a concise but complete and clear explanation of (all) the roles, covering the articulation between :
the organization and the overall “ownership” of the org’s account > the admins > the groups managers > the users
Hello, for all passbolt instances (CE, Pro, Cloud) you have a first admin that creates the organization (the same that install the software, or create the organization workspace on the cloud). From there they can invite other administrators and/or create regular users.
For the cloud (and pro), there is an additionally the concept of billing contacts. These contacts are not listed in passbolt UI, but in the billing and support systems. The first billing contact is created with the information you provided when you pay. These contacts can decide to change payment details, and/or the delete the organization workspace by contacting sales, or letting the subscription expires, etc. This is done by contacting the sales team.
Thank you for your feedback on the documentation, we’ll improve it in the next few weeks.
I have begun our 14-day trial.
I created the org and thus I am admin.
I have created several users, and a group.
I have assigned a non-admin colleague as the group manager.
But I nonetheless can’t remove myself from the group.
It seems to me that it directly contradicts what you explained ?
The use case is that our Passbolt admins should not necessarily be able to access the accounting deparment passwords. So being an admin, once I have created the group, how can I remove myself ? can an admin be prevented from putting himself as any group’s member ?
Ok, understood. I should have created the group while assigning myself as “group manager”, to then be able to remove myself. But I assigned myself as sole “member”. Anyway, I have seen that once my colleague was “group manager”, he could remove me, and then I couldn’t put myself back in the group. So it works as intended, fine !
We use Passbolt at my company and I think I have solution for one of your problems - master account sharing.
We have 2 Passbolt servers (for High Availability) and each of them has an accessible RDP console. You can log in with a shared admin account, which has the “master account” profile in it’s browser and from which everything is managed. I think this is the ideal solution to this problem and has been working for us rather well.
I’d be happy to provide assistance on how to set something like this up!
I’m sorry but I don’t clearly understand the architecture you put in place. At the very least because I don’t understand at all what this sentence means : “We have 2 Passbolt (for HA) and each of them has an accessible RDP console.” Not understanding that one, I am very unsure I understand correctly what’s next.
Please could you provide more details ? (please in non-technical language, as far as is possible / relevant ; I am not at all sysadmin or whatever, just a communication officer with some geeky orientation, in charge of the password management question, since we have no IT department or colleague…)
I apologize, the word “servers” has slipped out of my message (I have edited the message to be easier to understand somewhat).
What I meant is that I have a standalone administrator account, with its own private and public key, which is only accessible from those 2 Passbolt servers using a browser after connecting to them through Remote Desktop.