IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
While nowadays, most entries should be just 'x', there can also still
be legacy entries with 'x!u2f', 'x!yubico' and base32 encoded secrets.
For example, some users might be syncing them from LDAP.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
this file is installed by a sub-dir Makefile, it does not exist in
src/PVE/API2.
the error is not fatal, but printed during build:
install: cannot stat 'RealmSync.pm': No such file or directory
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
else it's not actually possible to define ACLs on them, which means they are
effectively root only instead of allowing their intended permission scheme.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
/pools is not an allowed ACL path, so this would add a bogus entry into the
effective permissions in case something got propagated from /.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Removes the dreaded DN regex, instead introducing a optional
connect/bind check on creation/update, aligning it with the way PBS does
it.
Additionally, it has the benefit that instead of letting a sync fail on
the first try due to e.g. bad bind credentials, it gives the user some
direct feedback when trying to add/update a LDAP realm, if enabled.
Should be rather a corner case, but it's the easiest way for us to
accomodate and the most versatile for users needing this.
This is part of the result of a previous discussion [0], and the same
approach is already implemented for PBS [1].
[0] https://lists.proxmox.com/pipermail/pve-devel/2023-May/056839.html
[1] https://lists.proxmox.com/pipermail/pbs-devel/2023-June/006237.html
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Previously, if one tried to only update e.g. the bind password for an
LDAP realm, it would fail with an rather unhelpful error message:
# pveum realm modify ldap -password foo
update auth server failed: no options specified
The root cause was that the `password` parameter was removed early from
the parameter object, which than would fail the check whether it is
empty or not.
Thus, additionally check if only `password` was specified and if so,
allow it.
Reported-by: Friedrich Weber <f.weber@proxmox.com>
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Before 0f3d14d6 ("auth: tfa: read tfa.cfg also if the user.cfg entry
has no "x" marker"), `user_get_tfa` failed if the realm required TFA,
but the user's `keys` attribute was empty. Since 0f3d14d6,
`user_get_tfa` fails if the realm requires TFA, but neither user.cfg
nor tfa.cfg define any second factors for that user.
However, both before and after 0f3d14d6, a realm that requires TOTP
allows a user to login without a second factor if they have at least
one configured factor in tfa.cfg and all factors are disabled -- for
example if they have only a disabled TOTP factor. This behavior is
unwanted, as users can then circumvent the realm-mandated TFA
requirement by disabling their own TOTP factor.
This happens because a user with a disabled TOTP factor in tfa.cfg
passes the check in `user_get_tfa`. Hence, `authenticate_2nd_new_do`
proceeds to call `authentication_challenge`, which does not generate a
challenge (and returns undef) because the user has no enabled factors.
Consequently, `authenticate_2nd_new_do` returns undef and allows login
without a second factor.
Note that this does not happen for realms that require Yubico TFA,
because for these realms, `authenticate_2nd_new_do` does not call
`authentication_challenge` and instead generates a challenge in any
case, regardless of whether the user has enabled Yubico factors or
not.
This patch fixes the issue by moving the check out of `user_get_tfa`,
and instead letting `authenticate_2nd_new_do` fail if the realm
requires TFA but `authentication_challenge` generates no challenge
(returns undef). This also saves a call to `api_list_user_tfa` that
was introduced in 0f3d14d6.
This patch still allows users to login with a recovery key to a realm
that requires TFA , which is the intended behavior.
Suggested-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
Alternatively we could potentially move the realm-tfa check to after
`authentication_challenge`.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Previously, `user_get_tfa` read the `keys` user attribute from
user.cfg to determine whether a user has second factors configured.
`keys` could contain TOTP secrets or Yubico key IDs (for realms that
require TFA), or the marker "x" to signify that second factors are
defined in tfa.cfg, in which case `user_get_tfa` would additionally
read tfa.cfg.
However, syncing an LDAP realm with `remove-vanished=properties`
erases the `keys` attribute, and thus the "x" marker (unless custom
`sync_attributes` with a mapping for `keys` are defined). This would
allow TFA-enabled users to log in without a second factor after a
realm sync. This issue was first reported in the forum [1].
To fix this issue, `user_get_tfa` now reads tfa.cfg unconditionally,
and thus independently of the value of `keys`. In other words, the "x"
marker is now irrelevant for authentication. The reasoning for this
change is that most current setups define second factors in tfa.cfg
anyway.
Special care is needed to avoid breaking realms that require TFA: In
that case, `user_get_tfa` must fail authentication if neither user.cfg
nor tfa.cfg define any second factors.
This patch changes the behavior of a hypothetical (and not officially
supported) LDAP realm setup in which `sync_attributes: keys=attr` and
`remove-vanished=properties` is used to maintain `keys` in the LDAP
directory. In such a setup, an admin could enable/disable TFA for a
user who has an enabled second factor in tfa.cfg by editing their LDAP
entry and switching between "x" and "". With this patch, TFA is always
enabled for that user.
This patch makes the "x" marker irrelevant for authentication, but PVE
still *writes* it if the user has second factors configured in
tfa.cfg. This behavior is kept for now to avoid issues in cluster
upgrade scenarios, where some nodes that still rely on the "x" marker
could allow logins without a second factor.
[1] https://forum.proxmox.com/threads/130440/
Suggested-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
All nodes should be new enough, especially as this is understood
since pve-manager 7.0-15 and users must upgrade to 7.4 before
upgrading to Proxmox VE 8
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The `allowtoken` property is a total, unconditional block on using
API tokens on an endpoint. We reserve those only for a limited set of
security critical endpoints like changing passwords or second
factors, or creating a (cookie) ticket, which are exempt from this
limitations, so require to have limited access to them too.
Anyhow, listing and getting TFA entries for users, where the API
token has the correct permissions granted, is not critical, as the
API token cannot gain more permissions than they have from that
info, so drop the total block on those GET methods.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
makes our reasoning when adding new top-level privileges way easier
in the future.
We already had two major upgrades with role additions where we had to
add special checks in the upgrade script and breaking changes, so
let's reserve any role starting with PVE (case-insensitive to avoid
confusion potential) and forbid creating those via API.
We might also think about letting the config parser choke on that, as
otherwise one could still create them via editing the config
manually.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
uses the privileges:
Mapping.Use
Mapping.Modify
Mapping.Audit
on /mapping/{TYPE}/{id}
so that we can assign privileges on resource level
this will generate new roles (PVEMappingUser, PVEMappingAdmin,
PVEMappingAuditor)
note that every user with Permissions.Modify on '/' and propagate can add these
new roles to themselves
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
there are currently three possibilities to modify ACLs without the
'Permissions.Modify' privilege in PVE::RPCEnvironment::check_perm_modify:
if ($path =~ m|^/storage/.+$|) {
push @$testperms, 'Datastore.Allocate';
} elsif ($path =~ m|^/vms/.+$|) {
push @$testperms, 'VM.Allocate';
} elsif ($path =~ m|^/pool/.+$|) {
push @$testperms, 'Pool.Allocate';
}
lock those down by only allowing the currently authenticated user to hand out a
subset of their own privileges, never more.
for example, this still allows a PVEVMAdmin to create ACLs for other
users/tokens with PVEVMUser (on '/vm/XXX'), but not with Administrator or
PVEPermAdmin.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
to reduce the chances of accidentally handing out privilege modification
privileges. the old default setup of having Permissions.Modify in PVESysAdmin
and PVEAdmin weakened the distinction between those roles and Administrator.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
it isn't mounted in PVE::API2::AccessControl and it doesn't lives
anywhere in /access, so using that is just confusing.
Both, API and backend could simply move to manager, but as we already
got an api package here and it does somewhat fits into the topic lets
keep it here for now.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
to be able to define automated jobs that sync ldap/ad
The jobs plugin contains special handling when no node is given, since
we only want it to run on a single node when that triggers. For that,
we save a statefile in /etc/pve/priv/jobs/ which contains the
node/time/upid of the node that runs the job. The first node that
is able to lock the realm (via cfs_lock_domain) "wins" and may
sync from the ldap.
in case a specific node was selected, this is omitted and the Jobs
handling will not let it run on other nodes anyway
the API part is our usual sectionconfig CRUD api, but specialized
for the specific type of job.
the api will be at /cluster/jobs/realm-sync
(this must be done in pve-manager)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
[ T: resolve merge conflict due to packaging/source split ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
