NIST SP 800-63-3B sets a recommendation to have password length upper bound limited in A.2:
https://pages.nist.gov/800-63-3/sp800-63b.html#appA
Users should be encouraged to make their passwords as lengthy as they
want, within reason. Since the size of a hashed password is independent
of its length, there is no reason not to permit the use of lengthy
passwords (or pass phrases) if the user wishes. Extremely long passwords
(perhaps megabytes in length) could conceivably require excessive
processing time to hash, so it is reasonable to have some limit.
FreeIPA already applied 256 characters limit for non-random passwords
set through ipa-getkeytab tool. The limit was not, however, enforced in
other places.
MIT Kerberos limits the length of the password to 1024 characters in its
tools. However, these tools (kpasswd and 'cpw' command of kadmin) do not
differentiate between a password larger than 1024 and a password of 1024
characters. As a result, longer passwords are silently cut off.
To prevent silent cut off for user passwords, use limit of 1000
characters.
Thus, this patch enforces common limit of 1000 characters everywhere:
- LDAP-based password changes
- LDAP password change control
- LDAP ADD and MOD operations on clear-text userPassword
- Keytab setting with ipa-getkeytab
- Kerberos password setting and changing
Fixes: https://pagure.io/freeipa/issue/8268
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-by: Simo Sorce <ssorce@redhat.com>
Reviewed-By: Simo Sorce <ssorce@redhat.com>
Password changes performed by cn=Directory Manager are excluded from
password policy checks according to [1]. This is correctly handled by
ipa-pwd-extop in case of a normal Kerberos principal in IPA. However,
non-kerberos accounts were not excluded from the check.
As result, password updates for PKI CA admin account in o=ipaca were
failing if a password policy does not allow a password reuse. We are
re-setting the password for PKI CA admin in ipa-replica-prepare in case
the original directory manager's password was updated since creation of
`cacert.p12`.
Do password policy check for non-Kerberos accounts only if it was set by
a regular user or admin. Changes performed by a cn=Directory Manager and
passsync managers should be excluded from the policy check.
Fixes: https://pagure.io/freeipa/issue/7181
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
[1] https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/user_account_management-managing_the_password_policy
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
With system-wide crypto policy in use, arcfour-hmac encryption type
might be removed from the list of permitted encryption types in the MIT
Kerberos library. Applications aren't prevented to use the arcfour-hmac
enctype if they operate on it directly.
Since FreeIPA supported and default encryption types stored in LDAP, on
the server side we don't directly use a set of permitted encryption
types provided by the MIT Kerberos library. However, this set will be
trimmed to disallow arcfour-hmac and other weaker types by default.
While the arcfour-hmac key can be generated and retrieved, MIT Kerberos
library will still not allow its use in Kerberos protocol if it is not
on the list of permitted encryption types. We only need this workaround
to allow setting up arcfour-hmac key for SMB services where arcfour-hmac
key is used to validate communication between a domain member and its
domain controller. Without this fix it will not be possible to request
setting up a machine account credential from the domain member side. The
latter is needed for Samba running on IPA client.
Thus, extend filtering facilities in ipa-pwd-extop plugin to explicitly
allow arcfour-hmac encryption type for SMB services (Kerberos principal
name starts with cifs/).
Reviewed-By: Christian Heimes <cheimes@redhat.com>
During an extend op password update, there is a test if the
user is changing the password is himself. It uses local Slapi_SDN
variable that are not freed
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
ipapwd_extop allows to update the password on a specific entry, identified by its DN.
It can be usefull to support virtual DN in the extop so that update of a virtual entry
would land into the proper real entry.
If a pre-extop sets the TARGET_DN, ipapwd_extop sets ORIGINAL_DN with the value
of TARGET_DN, instead of using the original one (in the ber req)
There is a dependency on slapi-nis >= 0.56-0.1 (https://fedorahosted.org/freeipa/ticket/5955)
https://fedorahosted.org/freeipa/ticket/5946
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Whe requesting a keytab the salt used is the NORMAL type (for backwards and AD
compatibility), however since we added alias support we need to search for the
krbCanonicalName in preference, hen nothing is specified, and for the requested
principal name when a getkeytab operation is performed. This is so that the
correct salt can be applied. (Windows AD uses some peculiar aliases for some
special accounts to generate the salt).
Signed-off-by: Simo Sorce <simo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
When retrieving keytab, it is useful to know what user was attempting
to fetch the keyts and failed. This is useful to debug one-way trust
where SSSD forks out a process of ipa-getkeytab and it might be using
a wrong credentials cache for authentication purposes.
Part of https://fedorahosted.org/freeipa/ticket/4959
Reviewed-By: Tomas Babej <tbabej@redhat.com>
This enables plugins to share authentication configuration cache code.
Additionally, update the caching mechanism to be declarative and faster.
Reviewed-By: Thierry Bordaz <tbordaz@redhat.com>
A mixture of implicit and explicit tagging was being used and this caused
a bug in retrieving the enctype number due to the way ber_scanf() loosely
treat sequences and explicit tagging.
The ASN.1 notation used to describe the getkeytab operation uses implicit
tagging, so by changing the code we simply follow to the specified encoding.
Resolves: https://fedorahosted.org/freeipa/ticket/4404
Signed-off-by: Simo Sorce <simo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
This new extended operation allow to create new keys or retrieve
existing ones. The new set of keys is returned as a ASN.1 structure
similar to the one that is passed in by the 'set keytab' extended
operation.
Access to the operation is regulated through a new special ACI that
allows 'retrieval' only if the user has access to an attribute named
ipaProtectedOperation postfixed by the subtypes 'read_keys' and
'write_keys' to distinguish between creation and retrieval operation.
For example for allowing retrieval by a specific user the following ACI
is set on cn=accounts:
(targetattr="ipaProtectedOperation;read_keys") ...
... userattr=ipaAllowedToPerform;read_keys#USERDN)
This ACI matches only if the service object hosts a new attribute named
ipaAllowedToPerform that holds the DN of the user attempting the
operation.
Resolves:
https://fedorahosted.org/freeipa/ticket/3859
Reviewed-By: Nathaniel McCallum <npmccallum@redhat.com>
Wrap the password change extop in a transaction.
Fix the case where a password is reset and then immediately used. If done
fast enough then the KDC may not detect that the password is expired and
grant access using the expired password rather than prompting for a reset.
https://fedorahosted.org/freeipa/ticket/1064
User always receives the same error message if he changes his password
via "ipa passwd" command and the new password fails configured
password policy. He then has to investigate on his own the actual
reason why was the policy violated. This patch improves our SLAPI PWD
plugins to provide a better error message explaining the violation
reason.
https://fedorahosted.org/freeipa/ticket/2067
Setting 0 will work as MIT KDCs assume the current master key when that is
found. But it is a legacy compatibility mode and we should instead set the
proper mkvno number on keys so changeing master key becomes possible w/o
having to do a dump reload and stopping the service. This is especially
important in replicated environments.
We have no visibility into whether an entry has a keytab or not so
krbLastPwdChange is used as a rough guide.
If this value exists during enrollment then it fails because the host
is considered already joined. This was getting set when a OTP was
added to a host that had already been enrolled (e.g. you enroll a host,
unenroll it, set a OTP, then try to re-enroll). The second enrollment
was failing because the enrollment plugin thought it was still
enrolled becaused krbLastPwdChange was set.
https://fedorahosted.org/freeipa/ticket/1357
Apparently we forgot to check OID consistency between the schema and the
extensions, and we got duplicates.
Technically the schema was done later but it is easier to change the extensions
OIDs than to change the schema of current beta2/rc1 installations.
The only side effect is that older ipa-getkeytab and ipa-join binaries will
fail. So all the admin/client tools must be upgraded at the same time as well
as all the masters (otherwise some will show/accept the new OID while others
won't).
Fixes: https://fedorahosted.org/freeipa/ticket/976
The situation is if during installation /etc/krb5.conf either doesn't
exist or configures no realms then 389-ds won't start up at all, causing
the installation to fail. This will let the server start up in a degraded
mode.
Also need to make the sub_dict in ldapupdate.py handle no realm otherwise
the installation will abort enabling the compat plugin.
ticket 606
Omiting return value of calloc in ipa_pwd_extop.c could lead to
memory access issues when memory is full. This patch adds return
value check.
https://fedorahosted.org/freeipa/ticket/717
The changes include:
* Change license blobs in source files to mention GPLv3+ not GPLv2 only
* Add GPLv3+ license text
* Package COPYING not LICENSE as the license blobs (even the old ones)
mention COPYING specifically, it is also more common, I think
https://fedorahosted.org/freeipa/ticket/239
Alexander Bokovoy
Rob Crittenden
Thierry Bordaz
Lukas Slebodnik
Simo Sorce
Nathaniel McCallum
Jan Cholasta
Martin Kosek
Krzysztof Klimonda
Sumit Bose
Simo Sorce
Yuri Chornoivan
Jakub Hrozek