Add a accounts plugin (accounts class) that defines
variables and methods common to 'users' and 'stageuser'.
accounts is a superclass of users/stageuser
Add the stageuser plugin, with support of stageuser-add verb.
Reviewed By: David Kupka, Martin Basti, Jan Cholasta
https://fedorahosted.org/freeipa/ticket/3813
Reviewed-By: Jan Cholasta <jcholast@redhat.com>
Reviewed-By: David Kupka <dkupka@redhat.com>
`--hosts` and `--hostgroup` options added to:
* service-allow-create-keytab
* service-allow-retrieve-keytab
* service-disallow-create-keytab
* service-disallow-retrieve-keytab
* host-allow-create-keytab
* host-allow-retrieve-keytab
* host-disallow-create-keytab
* host-disallow-retrieve-keytab
in order to allow hosts to retrieve keytab of their services or related hosts as described on http://www.freeipa.org/page/V4/Keytab_Retrieval design page
https://fedorahosted.org/freeipa/ticket/4777
Reviewed-By: Jan Cholasta <jcholast@redhat.com>
This is possible because python-qrcode's output now fits in a standard
terminal. Also, update ipa-otp-import and otptoken-add-yubikey to
disable QR code output as it doesn't make sense in these contexts.
https://fedorahosted.org/freeipa/ticket/4703
Reviewed-By: Petr Vobornik <pvoborni@redhat.com>
Adds new API:
ipa host-allow-retrieve-keytab HOSTNAME --users=STR --groups STR
ipa host-disallow-retrieve-keytab HOSTNAME --users=STR --groups STR
ipa host-allow-create-keytab HOSTNAME --users=STR --groups STR
ipa host-disallow-create-keytab HOSTNAME --users=STR --groups STR
ipa service-allow-retrieve-keytab PRINCIPAL --users=STR --groups STR
ipa service-disallow-retrieve-keytab PRINCIPAL --users=STR --groups STR
ipa service-allow-create-keytab PRINCIPAL --users=STR --groups STR
ipa service-disallow-create-keytab PRINCIPAL --users=STR --groups STR
these methods add or remove user or group DNs in `ipaallowedtoperform` attr with
`read_keys` and `write_keys` subtypes.
service|host-mod|show outputs these attrs only with --all option as:
Users allowed to retrieve keytab: user1
Groups allowed to retrieve keytab: group1
Users allowed to create keytab: user1
Groups allowed to create keytab: group1
Adding of object class is implemented as a reusable method since this code is
used on many places and most likely will be also used in new features. Older
code may be refactored later.
https://fedorahosted.org/freeipa/ticket/4419
Reviewed-By: Jan Cholasta <jcholast@redhat.com>
These defaults are pretty useless and cause more confusion than
they are worth. The serial default never worked anyway. And now
that we are displaying the token type separately, there is no
reason to doubly record these data points.
Reviewed-By: Petr Vobornik <pvoborni@redhat.com>
Option --name-server is changing only SOA MNAME, this option has no more
effect to NS records
Option --ip-addres is just ignored
A warning message is sent after use these options
Part of ticket: https://fedorahosted.org/freeipa/ticket/4149
Reviewed-By: Petr Spacek <pspacek@redhat.com>
For ipatokennotbefore and ipatokennotafter attributes use DateTime
parameter class instead of Str, since these are represented as
LDAP Generalized Time in LDAP.
Reviewed-By: Jan Cholasta <jcholast@redhat.com>
This command behaves almost exactly like otptoken-add except:
1. The new token data is written directly to a YubiKey
2. The vendor/model/serial fields are populated from the YubiKey
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
This also constitutes a rethinking of the token ACIs after the introduction
of SELFDN support.
Admins, as before, have full access to all token permissions.
Normal users have read/search/compare access to all of the non-secret data
for tokens assigned to them, whether managed by them or not. Users can add
tokens if, and only if, they will also manage this token.
Managers can also read/search/compare tokens they manage. Additionally,
they can write non-secret data to their managed tokens and delete them.
When a normal user self-creates a token (the default behavior), then
managedBy is automatically set. When an admin creates a token for another
user (or no owner is assigned at all), then managed by is not set. In this
second case, the token is effectively read-only for the assigned owner.
This behavior enables two important other behaviors. First, an admin can
create a hardware token and assign it to the user as a read-only token.
Second, when the user is deleted, only his self-managed tokens are deleted.
All other (read-only) tokens are instead orphaned. This permits the same
token object to be reasigned to another user without loss of any counter
data.
https://fedorahosted.org/freeipa/ticket/4228https://fedorahosted.org/freeipa/ticket/4259
Reviewed-By: Jan Cholasta <jcholast@redhat.com>
* Zone is stored as an absolute name (ipa never support relative
* zonenames)
* compatible with relative zone names as was before
* PTR target can be relative domain name
Part of ticket:
IPA should allow internationalized domain names
https://fedorahosted.org/freeipa/ticket/3169
Reviewed-By: Jan Cholasta <jcholast@redhat.com>
Thierry bordaz (tbordaz)
Martin Basti
Gabe
Nathaniel McCallum
Tomas Babej
Petr Vobornik
Jan Cholasta
Alexander Bokovoy
David Kupka
Petr Viktorin