Say I have a backup administrator and a delegated admin with a more restricted role.
They can define credentials which I am not allowed to see as backup admin for some reason. However, as an admin, I can see (and edit) their jobs if need be. But if I do, it will reset credentials to default (apparently default behavior since I cannot see those used in the first place).
Conversely, delegated user faces same challenge: If I create my own set of credentials and use it in what is actually their job (maybe just to get it working again), they will override it to default on their next edit, potentially not realizing this, and the job will again fail.
This is apparently "by design", however, at least, safer handling/warnings to prevent accidental breakage is required
E.g. not overwrite credentials if currently defined credentials are out of scope for the user currently editing.
(Case # 08122374)
-
jeronimo
- Influencer
- Posts: 21
- Liked: 2 times
- Joined: May 04, 2026 12:34 pm
- Contact:
-
HannesK
- Product Manager
- Posts: 16428
- Liked: 3768 times
- Joined: Sep 01, 2014 11:46 am
- Full Name: Hannes Kasparick
- Location: Austria
- Contact:
Re: RBAC credential visibility
Hello,
I cannot follow the steps... can you maybe describe step by step what the admin and the restricted user do? In general, nobody can see credentials (also not admin his own). They are always hidden and one can only verify for example encryption passwords by typing them in and click "verify".
Best regards
Hannes
I cannot follow the steps... can you maybe describe step by step what the admin and the restricted user do? In general, nobody can see credentials (also not admin his own). They are always hidden and one can only verify for example encryption passwords by typing them in and click "verify".
Best regards
Hannes
-
jeronimo
- Influencer
- Posts: 21
- Liked: 2 times
- Joined: May 04, 2026 12:34 pm
- Contact:
Re: RBAC credential visibility
Hello,
With credentials I mean actual visibility of accounts, notably those used for guest processing.
Say datacenter credential was created by user X and used in user X's job, but user Y tries to modify the job.
In 13.1.1 there seems to have been a change such that at least one cannot corrupt another user's job.
Previously, account used for guest processing was just reset to null/nothing if user Y edited it but had no visibility on the account and as a result job failed on next run.
But I'm not sure the real issue here is solved. This seems like a crude workaround. Actually it's worse than before, because if you were careful and did not go to Guest Processing tab of job configuration, then it did not get overwritten.
Also, documentation still states: "If a user does not have permission to view certain credentials, those credentials do not appear in the backup wizard when editing a job. However, the credentials remain configured in the job." (https://helpcenter.veeam.com/docs/vbr/u ... imitations)
That would indeed be the desired behavior. However, now, access to the job is simply denied.
The goal here is, in case that is not clear: have different kinds of backup administrators but only one of them is the real Veeam administrator.
All of these users/groups should be able to backup and restore (they already can) but also be able to change each other's jobs if necessary, preferably including guest credentials (which they do not need to be able to edit, but at least use).
Thanks.
With credentials I mean actual visibility of accounts, notably those used for guest processing.
Say datacenter credential was created by user X and used in user X's job, but user Y tries to modify the job.
In 13.1.1 there seems to have been a change such that at least one cannot corrupt another user's job.
Previously, account used for guest processing was just reset to null/nothing if user Y edited it but had no visibility on the account and as a result job failed on next run.
But I'm not sure the real issue here is solved. This seems like a crude workaround. Actually it's worse than before, because if you were careful and did not go to Guest Processing tab of job configuration, then it did not get overwritten.
Also, documentation still states: "If a user does not have permission to view certain credentials, those credentials do not appear in the backup wizard when editing a job. However, the credentials remain configured in the job." (https://helpcenter.veeam.com/docs/vbr/u ... imitations)
That would indeed be the desired behavior. However, now, access to the job is simply denied.
The goal here is, in case that is not clear: have different kinds of backup administrators but only one of them is the real Veeam administrator.
All of these users/groups should be able to backup and restore (they already can) but also be able to change each other's jobs if necessary, preferably including guest credentials (which they do not need to be able to edit, but at least use).
Thanks.
Who is online
Users browsing this forum: No registered users and 268 guests