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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
It seems that servers associate the client-cert/key with an account, so
doing an explicit anonymous bind then 'logs out' the already verified
user, limiting the search results in some cases
before refactoring to PVE::LDAP, we did not do '$ldap->bind' at all when
there was no bind_dn, but it is not really clear if Net::LDAP does this
automatically when searching (other libraries do this), so leave the
anonymous bind (for compatibility with PMG) but skip it when a client
certificate and key is given.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Allows a user to straight forward delete TFS over CLI, easier as
telling them to edit some config files, and the API is already there.
Short circuit most params of that API call to undef, as they do not
make sense to expose.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
keep variable names aligned with the params the relate to, "write"
was quite ambiguous too (write what?)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
instead of having only a 'secure' flag which switches between
ldap/ldaps we now have a mode which also contains 'ldap+starttls'
our connection code in PVE::LDAP can handle this already (used in pmg)
so that is no problem
if we want to really remove the 'secure' flag, e.g. in 7.0
we'd either have to rewrite the config or have it as an error
in a pve6to7 script
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
we want the api options to be optional, but only as long as there are
default values set in the realm config
since they are all marked as optional (else they would be required in
the api) this check did not work as intended
instead, set the result to the value of:
* the parameter
* the set default in the config
* the api default
in this order
if it is undef after this, raise a parameter exception
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Allows us to add it in the gui, until now the admin needed to create
the file themself.
Mirrored after credential handling from CIFS and PBS in their
pve-storage plugins
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
[Thomas: don't differ from storage one unnecessarily, keep comments
and behavior]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Initially the config may not even exist, and so the first token
create would give one then a ugly warning like:
> Use of uninitialized value $raw in split at ..
Handle that case, empty config (where we get '') was fine already, so
explicitly check for definedness, not truthiness.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
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>
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>
we may potentially also sync something else over this in the future,
for example PAM users from a specific group, so use a more general
name.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
instead of dropping ACLs and group membership for missing users,
simply warn and leave it in the config
for users that get removed via the api this happens explicitely
this is to prevent that a 'faulty' ldapsync removes users temporarily
and with it all acls that the admin created
we still have a 'purge' flag for the sync where ACLs get removed
explicitly for users removed from ldap
also adapt the tests
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
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
also add this command to pveum
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
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'
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
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)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
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.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
for user and token commands, and some pretty-printing for regular text
output, since the returned nested hash/dict is not very readable.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
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>
and related helper, to dump permissions + propagate info for
- a specific, given path
- generic top-level + user.cfg-referenced paths, including pools
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
this information is already available, but not exposed. we need it for
dumping an effective permission tree of a given user/token.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
non-privsep tokens will always return the roles/permissions of their
associated users. privsep tokens will return unfiltered roles, but
filtered permissions.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
