Thomas Lamprecht [Sat, 21 Mar 2020 15:01:56 +0000 (16:01 +0100)]
realm: add default-sync-options to config
This allows us to have a convenient way to set the desired default
sync options, and thus not forcing users to pass always all options
when they want to trigger a sync.
We still die when an option is neither specified in the domains
(realm) config nor as API/CLI parameter.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thomas Lamprecht [Sat, 21 Mar 2020 14:56:51 +0000 (15:56 +0100)]
api: realm sync: move out group and user update to separate methods
keep the api call way smaller and clearer
On moving out some minor adaptions where made, e.g., we do not print
"remove user X" if we know that we'd add it again, but just print a
single "update user X" for that. Same for groups.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Dominik Csapak [Fri, 13 Mar 2020 12:18:47 +0000 (13:18 +0100)]
api: domains: add user/group sync API enpoint
this api call syncs the users and groups from LDAP/AD to the
user.cfg
it also implements a 'full' mode where we first delete all
users/groups from the config and sync them again
the parameter 'enable' controls if newly synced users are 'enabled'
(if no sync parameter handles that)
the parameter 'purge' controls if ACLs get removed for users/groups
that do not exists anymore after
Dominik Csapak [Fri, 13 Mar 2020 12:18:46 +0000 (13:18 +0100)]
Auth/AD: make PVE::Auth::AD a subclass of PVE::Auth::LDAP
this makes it much easier to reuse the sync code from LDAP in AD.
The 'authenticate_user' sub is still the same, but we now
can still use the get_users and get_groups functionality of LDAP
in the case of AD, the user_attr is optional in the config
(would have been a breaking change) but we set it
to default to 'sAMAccountName'
Dominik Csapak [Fri, 13 Mar 2020 12:18:45 +0000 (13:18 +0100)]
Auth/LDAP: add get_{users, groups} subs for syncing
this adds the subs which actually query the LDAP for users/groups
and returns the value in format which makes it easy to insert
in our parsed user.cfg
when we find a user/groupname which cannot be in our config,
we warn the verification error
for groups, we append "-$realm" to the groupname, to lower the chance of
accidental overwriting of existing groups (this will be documented
in the api call since it technically does not prevent overwriting, just
makes it more unlikely)
Dominik Csapak [Fri, 13 Mar 2020 12:18:44 +0000 (13:18 +0100)]
Auth/LDAP: add necessary options for syncing
for syncing users/groups from ldap, we need some more options
so that the users can adapt it to their LDAP setup, which are very
different accross systems.
sensible defaults are documented
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com> Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
we do the same for missing users, groups and tokens, and just like
groups, roles with an empty privilege set are explicitly allowed so
pre-generating placeholders is possible.
Thomas Lamprecht [Wed, 29 Jan 2020 19:21:10 +0000 (20:21 +0100)]
pveum token: rename 'update' subcommand to 'modify' for consistency
While the 1:1 mapping from API call names is not bad it was now the
unique "PUT" (modify) command having a different name here. Avoid
that for consistency.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
non-privsep tokens will always return the roles/permissions of their
associated users. privsep tokens will return unfiltered roles, but
filtered permissions.
which checks that the user and token exist and are not expired, and then
generates the string to be matched with the pmxcfs-stored token shadow
config file.
token definitions/references in user.cfg always use the full form of the
token id, consisting of:
USER@REALM!TOKENID
token definitions are represented by their own lines prefixed with
'token', which need to come after the corresponding user definition, but
before any ACLs referencing them.
parsed representation in a user config hash is inside a new 'tokens'
element of the corresponding user object, using the unique-per-user
token id as key.
only token metadata is stored inside user.cfg / accessible via the
parsed user config hash. the actual token values will be stored
root-readable only in a separate (shadow) file.
'comment' and 'expire' have the same semantics as for users.
'privsep' determines whether an API token gets the full privileges of
the corresponding user, or just the intersection of privileges of the
corresponding user and those of the API token itself.
it was useful for test-cases to verify the behaviour when pools where
introduced, but it is not used anywhere else in the code base and those
tests can also just check on permission-level.
instead of parsing corosync.conf, and avoid coupling the access-control
API with PVE::Corosync. if corosync.conf and pmxcfs don't agree on how
the cluster is called, there is a bigger issue anyway..
parse_user_cfg: correctly parse group names in ACLs
usernames are allowed to start with '@', so adding a user '@test@pve'
and adding it to an ACL should work, instead of ignoring that part of
the ACL entry.
So use verify_groupname to additionally enforce that the group name we
extracted does not include an additional @, as then it cannot be a
group.
note: there is no potential for user and group to be confused, since a
username must end with '@REALM', and a group reference in an ACL can
only contain one '@' (as first character).
we cannot fully close this window, and don't need to anyway since we
apply +-300s when calculating ticket age ranges, but documenting where
mtime is used and what we expect seems like a good idea for future
readers.
to shrink the window between the two file_set_contents calls. we don't
need the mtimes to line up exactly since we have 300s of uncertainty
anyway, but generating an RSA key could take a while ;)
tfa: realm required TFA should lock out users without TFA
This changed with the previous TFA changes.
In the long term, the plan is to let the user get into the
half-logged-in state and open the TFA configuration window
on the UI to allow them to finish their TFA setup, but for
now we restore the previous behavior.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
as it was binary data, which can contain everything, including '\0',
and this was cut off, making it impossible to login after
registration, as a borked publicKey got saved in tfa.cfg
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
verify_ticket: allow general non-challenge tfa to be run as two step call
This allows for doing OTP TFA in two steps, first login with normal
credentials and get the half-logged-in ticket, then send the OTP
verification for full login, same as with u2f was already possible.
This allows for a nicer UI, as OTP fields can be shown on demand, and
do not need to be visible by default.
The old way of sending the OTP code immediately with the initial
credentials request still works for backward compatibility and as
some API user may prefer it.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com> Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
projects / pve-access-control.git / log