In server-like context we use LDAPI connection with auto-binding to LDAP
object based on the UID of the process connecting to LDAPI UNIX domain
socket. This means context.principal is not set and we cannot use it.
When processing certificate issuance requests a care has to be done to
match operations done as LDAP auto-bind to actual principals for
validation. This is a tough one as we have no principal to match for
cn=Directory Manager. Use fake principal to fail validation here and
rely on LDAP ACIs instead.
Fixes: https://pagure.io/freeipa/issue/9583
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Thomas Woerner <twoerner@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rafael Guterres Jeffman <rjeffman@redhat.com>
We only get to this code path when running in the server context. At
that point _bindings_installed will be defined. Pylint cannot track this
and always fails with this check.
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Thomas Woerner <twoerner@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rafael Guterres Jeffman <rjeffman@redhat.com>
In server-like context we use LDAPI connection with auto-binding to LDAP
object based on the UID of the process connecting to LDAPI UNIX domain
socket. This means context.principal is not set and we cannot use it.
Make sure to reject requests unless we are operating as a Directory
Manager in such cases.
Fixes: https://pagure.io/freeipa/issue/9583
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Thomas Woerner <twoerner@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rafael Guterres Jeffman <rjeffman@redhat.com>
In server-like context we use LDAPI connection with auto-binding to LDAP
object based on the UID of the process connecting to LDAPI UNIX domain
socket. This means context.principal is not set and we cannot use it.
Make sure to reject requests unless we are operating as a Directory
Manager in such cases.
Fixes: https://pagure.io/freeipa/issue/9583
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Thomas Woerner <twoerner@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rafael Guterres Jeffman <rjeffman@redhat.com>
In server-like context we use LDAPI connection with auto-binding to LDAP
object based on the UID of the process connecting to LDAPI UNIX domain
socket. This means context.principal is not set and we cannot use it.
Make sure to reject requests unless we are operating as a Directory
Manager in such cases.
Fixes: https://pagure.io/freeipa/issue/9583
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Thomas Woerner <twoerner@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rafael Guterres Jeffman <rjeffman@redhat.com>
When batch runs under server context, we have no context.principal set
because we talk directly to LDAPI endpoint and authenticate using
auto-binding, not GSSAPI. Account to that in the logger.
Fixes: https://pagure.io/freeipa/issue/9583
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Thomas Woerner <twoerner@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rafael Guterres Jeffman <rjeffman@redhat.com>
In server-like context we use LDAPI connection with auto-binding to LDAP
object based on the UID of the process connecting to LDAPI UNIX domain
socket. This means context.principal is not set and we cannot use it.
In principal_has_privilege() we can take None principal object as a sign
that currently bound LDAP DN has to be checked for the privilege. This
allows to match any type of account to the privilege, with exception of
the cn=Directory Manager which is never added to privileges explicitly.
cn=Directory Manager will be allowed any privilege because it already
can write to any LDAP entry.
Fixes: https://pagure.io/freeipa/issue/9583
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Thomas Woerner <twoerner@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rafael Guterres Jeffman <rjeffman@redhat.com>
SID anchors are only resolvable on servers with DCERPC bindings
installed. On non agent replica these bindings are not installed and
therefore group and role management if there are AD user idoverride
members.
If there is an ipaUserOverride for the anchor, the ipaoriginaluid is
returned.
Fixes: https://pagure.io/freeipa/issue/9544
Signed-off-by: Thomas Woerner <twoerner@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
A previous change made it not possible to remove the admin
user. This also included disabling the admin user. The user can
be disabled, just not deleted because it is required.
Move the test test_ipa_cacert_manage_prune to the end of the
class because it changes time which can break replication.
Fixes: https://pagure.io/freeipa/issue/9489
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
The current filter in principal_has_privilege is only working for normal
IPA users where krbprincipalname is matching the principal. An idoverride
user (for example from AD) is not found with this filter.
A new filter for the principal as an ipaOriginalUid has been added as a
second try if a match with krbprincipalname was not found.
principal_has_privilege is used in the replica connection check. The
additional check enables to deploy replicas using an AD user/administrator
that has been added to the "admins" group.
Fixes: https://pagure.io/freeipa/issue/9542
Signed-off-by: Thomas Woerner <twoerner@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
The ipa tool has nearly since epoch returned 2 for the case of
entry not found.
The certificate processing raises a separate error,
CertificateOperationsError, when something goes wrong.
This returns 1.
With the introduction of the JSON API most requests will get
a proper HTTP return code representing what went wrong. In this
case we can use 404 to determine if the request resulted in
a NotFound therefore can eventually return a 2 and be
consistent in return values.
Related: https://pagure.io/freeipa/issue/9562
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
SIDGEN plugin only uses local ID ranges and thus a restart is really
needed only when a local range is added, modified or removed.
Also fix the SSSD warning because removal of any range requires restart
everywhere, not just on a specific server.
Fixes: https://pagure.io/freeipa/issue/9558
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
After the addition of a new idrange, the sidgen plugin is not
immediately aware of the new idrange and a restart of 389ds is
required. Otherwise the creation of new user/group with a uid/gid
inside the new range fails to grant a SID to the user/group.
Fixes: https://pagure.io/freeipa/issue/9558
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
When authentication indicators were introduced in 2016, ipa-pwd-extop
plugin gained ability to reject LDAP BIND when an LDAP client insists
the authentication must use an OTP token. This is used by ipa-otpd to
ensure Kerberos authentication using OTP method is done with at least
two factors (the token and the password).
This enfrocement is only possible when an LDAP client sends the LDAP
control. There are cases when LDAP clients cannot be configured to send
a custom LDAP control during BIND operation. For these clients an LDAP
BIND against an account that only has password and no valid token would
succeed even if admins intend it to fail.
Ability to do LDAP BIND without a token was added to allow users to add
their own OTP tokens securely. If administrators require full
enforcement over LDAP BIND, it is cannot be achieved with LDAP without
sending the LDAP control to do so.
Add IPA configuration string, EnforceLDAPOTP, to allow administrators to
prevent LDAP BIND with a password only if user is required to have OTP
tokens. With this configuration enabled, it will be not possible for
users to add OTP token if one is missing, thus ensuring no user can
authenticate without OTP and admins will have to add initial OTP tokens
to users explicitly.
Fixes: https://pagure.io/freeipa/issue/5169
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
If a vault operation fails, the error message just says "InternalError". This commit
improves error handling of key archival and retrieval calls by catching the PKIException
error and raising it as an IPA error.
Related: https://pagure.io/freeipa/issue/9191
Signed-off-by: Francisco Trivino <ftrivino@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Cryptography 42.0.0 introduced two new abstract properties
`not_valid_before_utc` and `not_valid_after_utc`, which are non-naive UTC
variants of the `not_valid_before` and `not_valid_after` properties.
The old properties are deprecated. The changeset also modifies code and
tests to use the new `_utc` variants.
Fixes: https://pagure.io/freeipa/issue/9518
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Since commit 5c0e7a5fb4, a new extended
operation to get a keytab is supposed to be used. This keytab
setting/retrieval extended operation checks access rights of the bound
DN to write to a virtual attribute 'ipaProtectedOperation;write_keys'.
If the write isn't allowed, the operation is rejected and ipa-getkeytab
tool falls back to an older code that generates the keytab on the client
and forcibly sets to the LDAP entry. For the latter, a check is done to
make sure the bound DN is allowed to write to 'krbPrincipalKey' attribute.
This fallback should never happen for newer deployments. When enrollemnt
operation is delegated to non-administrative user with the help of 'Host
Enrollment' role, a host can be pre-created or created at enrollment
time, if this non-administrative user has 'Host Administrators' role. In
the latter case a system permission 'System: Manage Host Keytab' grants
write access to 'krbPrincipalKey' attribute but lacks any access to the
virtual attributes expected by the new extended operation.
There is a second virtual attribute, 'ipaProtectedOperation;read_keys',
that allows to retrieve existing keys for a host. However, during
initial enrollment we do not allow to retrieve and reuse existing
Kerberos key: while 'ipa-getkeytab -r' would give ability to retrieve
the existing key, 'ipa-join' has no way to trigger that operation.
Hence, permission 'System: Manage Host Keytab' will not grant the right
to read the Kerberos key via extended operation used by 'ipa-getkeytab
-r'. Such operation can be done later by utilizing 'ipa
service/host-allow-retrieve-keytab' commands.
Fix 'System: Manage Host Keytab' permission and extend a permission test
to see that we do not fallback to the old extended operation.
Fixes: https://pagure.io/freeipa/issue/9496
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Fix the following errors:
I0021(useless-suppression)
R1710(inconsistent-return-statements)
E1101(no-member)
Ignore the following errors:
E0601(used-before-assignment)
The variable is imported when the code is run in_server.
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
hbactest does a number of internal searches, one of which
can exceed the configured sizelimit: hbacrule-find
Collect any messages returned from thsi call and display them
to the user on the cli.
Fixes: https://pagure.io/freeipa/issue/9486
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
This is a side-effect of adding the libpwquality options. It
imposes its own hardcoded minimum password length so some care
was needed to ensure that it isn't set too low.
So if there are no libpwquality options used then it's fine to
have no minlength in the policy.
Fixes: https://pagure.io/freeipa/issue/9297
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
The ipaidpuser objectclass is required for the attribute ipaidpsub.
When a user is created or modified with --idp-user-id, the operation
must ensure that the objectclass is added if missing.
Add a test for user creation and user modification with --idp-user-id.
Fixes: https://pagure.io/freeipa/issue/9433
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The XML API is already deprecated and will be removed in some
future release.
All but the updateCRL API has an equivalent in REST. The upstream
dogtag project documents most of the API at
https://github.com/dogtagpki/pki/wiki/REST-API . I say most
because not every API includes sample input/output. The
pki ca-cert command is a good substitute for seeing how the API
is used by their own tooling.
This changes no pre-existing conventions. All serial numbers are
converted to decimal prior to transmission and are treated as
strings to avoid previous limitations with sizing (which would
have been exacerbated by random serial numbers).
Fixes: https://pagure.io/freeipa/issue/9345
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
An attempt to do this was already coded but the wrong
argument was used. It was passing in the location name and
not the map name so the map wouldn't be completely removed.
Include a test to verify that the map is gone after removing
it by calling automountlocation-tofiles which will fail if the
map wasn't properly removed.
Fixes: https://pagure.io/freeipa/issue/9397
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
admin is required for trust operations
Note that testing for removing the last member is now
irrelevant because admin must always exist so the test
for it was removed, but the code check remains. It is done
after the protected member check.
Fixes: https://pagure.io/freeipa/issue/8878
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Use of 'ipa idp-add --provider' was supposed to allow override scope and
other IdP options. The defaults are provided by the IdP template and
were actually not overridden. Fix this.
Fixes: https://pagure.io/freeipa/issue/9421
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
The user and stageuser commands return the following error
when the user is created/updated with a non existing idp:
$ ipa user-add testuser --first test --last user --idp dummy
ipa: ERROR: no such entry
The error is not descriptive enough and has been modified to
display instead:
$ ipa user-add testuser --first test --last user --idp dummy
ipa: ERROR: External IdP configuration dummy not found
Fixes: https://pagure.io/freeipa/issue/9416
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
A host uses Location (nshostlocation) as an optional hint where
a host may phsyically be located (e.g. Lab 2). This will result in
an attribute in the host entry like:
nshostlocation: Lab 2
A server uses location (ipalocation) to identify which DNS location
the server is part of (e.g. prague). This will result in an attribute
in the server entry like:
ipalocation: idnsname=prague,cn=locations,cn=etc,dc=example,dc=test
They are completely different animals.
https://pagure.io/freeipa/issue/9317
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rafael Guterres Jeffman <rjeffman@redhat.com>
There are 2 possible methods to rename users and groups:
- either use ipa user|group-mod oldname --rename newname
- or use settattr:
ipa user-mod oldname --setattr uid=newname
ipa group-mod oldname --setattr cn=newname
The first method validates the new name but the second method
doesn't. Add a validation to make both methods consistent
Fixes: https://pagure.io/freeipa/issue/9396
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
cert-find is a rather complex beast because it not only
looks for certificates in the optional CA but within the
IPA LDAP database as well. It has a process to deduplicate
the certificates since any PKI issued certificates will
also be associated with an IPA record.
In order to obtain the data to deduplicate the certificates
the cert from LDAP must be parser for issuer and serial number.
ipaldap has automation to determine the datatype of an
attribute and will use the ipalib.x509 IPACertificate class to
decode a certificate automatically if you access
entry['usercertificate'].
The downside is that this is comparatively slow. Here is the
parse time in microseconds:
cryptography 0.0081
OpenSSL.crypto 0.2271
ipalib.x509 2.6814
Since only issuer and subject are required there is no need to
make the expensive IPACertificate call.
The IPACertificate parsing time is fine if you're parsing one
certificate but if the LDAP search returns a lot of certificates,
say in the thousands, then those microseconds add up quickly.
In testing it took ~17 seconds to parse 5k certificates (excluding
transmission overhead, etc).
cert-find when there are a lot of certificates has been
historically slow. It isn't related to the CA which returns
large sets (well, 5k anyway) in a second or two. It was the
LDAP comparision adding tens of seconds to the runtime.
When searching with the default sizelimit of 100 the time is
~10s without this patch. With it the time is 1.5s.
CLI times from before and after searching for all certs:
original:
-------------------------------
Number of entries returned 5038
-------------------------------
real 0m15.507s
user 0m0.828s
sys 0m0.241s
using cryptography:
real 0m4.037s
user 0m0.816s
sys 0m0.193s
Fixes: https://pagure.io/freeipa/issue/9331
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
This reverts commit 1f30cc6527.
The problem isn't with python-cryptography, it is with the
IPACertificate class which does way more work on a certificate
than is necessary in cert-find.
Related: https://pagure.io/freeipa/issue/9331
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
This reverts commit 191880bc9f.
The problem isn't with python-cryptography, it is with the
IPACertificate class which does way more work on a certificate
than is necessary in cert-find.
Related: https://pagure.io/freeipa/issue/9331
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
The passkey is a long string and not user-friendly.
Instead of showing the whole passkey in the webui, only show
the id part and a string for discoverable or server-side passkey.
Related: https://pagure.io/freeipa/issue/9261
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Apart from server-side credentials passkey should also register
discoverable credentials.
ipa user-add-passkey --register now supports an additional option,
--cred-type server-side|discoverable
that is propagated to passkey_child command.
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
This condition was checked in group-add but not in group-mod.
This evaluation is done later in the pre_callback so that all
the other machinations about posix are already done to make
it easier to tell whether this condition is true or not.
Fixes: https://pagure.io/freeipa/issue/8990
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
The commands ipa user-add or ipa group-add validate the
format of the user/group name and display the following
message when it does not conform to the expectations:
invalid 'login': may only include letters, numbers, _, -, . and $
The format is more complex, for instance '1234567' is an invalid
user name but the failure is inconsistent with the error message.
Modify the error message to point to ipa help user/group and add
more details in the help message.
Same change for idoverrideuser and idoverridegroup:
The user/group name must follow these rules:
- cannot contain only numbers
- must start with a letter, a number, _ or .
- may contain letters, numbers, _, ., or -
- may end with a letter, a number, _, ., - or $
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2150217
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rafael Guterres Jeffman <rjeffman@redhat.com>
Reviewed-By: Alexander Bokovoy <abbra@users.noreply.github.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
If a cert-find fails on the CA side we get a Message tag
containing a string describing the failure plus the java stack
trace. Pull out the first part of the message as defined by the
first colon and include that in the error message returned to
the user.
The new message will appear as:
$ ipa cert-find
ipa: ERROR: Certificate operation cannot be completed: Unable to search for certificates (500)
vs the old generic message:
ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (500)
This can be reproduced by setting nssizelimit to 100 on the
pkidbuser. The internal PKI search returns err=4 but the CA
tries to convert all values into certificates and it fails. The
value needs to be high enough that the CA can start but low
enough that you don't have to create hundreds of certificates
to demonstrate the issue.
https://pagure.io/freeipa/issue/9369
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
The command ipa idview-show NAME has a post callback
method that replaces the ID override anchor with the corresponding
user name.
For instance the anchor
ipaanchoruuid=:SID:S-1-5-21-3951964782-819614989-3867706637-1114
is replaced with the name of the ad user aduser@ad.test.
The method loops on all the anchors and for each one performs the
resolution, which can be a costly operation if the anchor is for
a trusted user. Instead of doing a search for each anchor, it is
possible to read the 'ipaOriginalUid' value from the ID override
entry.
Fixes: https://pagure.io/freeipa/issue/9372
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Alexander Bokovoy
Rob Crittenden
Thomas Woerner
Florence Blanc-Renaud
Francisco Trivino
Christian Heimes