"Kerberos principal expiration" is set in UTC and when server is in
different timezone, the time difference between timezone is respected by
the IPA server/client for Kerberos authentication.
The problem is due to mktime() assuming default time zone but since we
parse the time using Zulu (UTC+0) timezone, mktime() forces current time
zone offset added.
The method is using mktime() and comparing to the current time obtained
with time(NULL). According to its man page, mktime is considering the
time as local time:
The mktime() function converts a broken-down time structure, expressed
as local time, to calendar time representation.
Instead mktime() we should use timegm(). The problem is that it is
non-standard GNU extension and it is recommended (in the man page for
timegm(3)) to avoid its use. An alternative is to set TZ=UTC, call
mktime(), unset TZ, but since we are running in a multi-threaded
environment this is problematic.
On the other hand, we already rely on GNU extensions and enable them
with -D_DEFAULT_SOURCE=1, so use of timegm() is enabled already.
The fix, therefore, is to use timegm() instead of mktime() in
daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c in two places where we
first do 'strptime()' with Zulu time zone (in ipapwd_pre_bind() and
ipapwd_write_krb_keys()).
Fixes: https://pagure.io/freeipa/issue/8362
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-by: Simo Sorce <simo@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
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>
In 2012, ldbm backend in 389-ds started checking entry modification
after running betxnpreop plugins by comparing a number of modifications
before and after. If that number didn't change, it is considered that
plugins didn't modify the list.
ipa-pwd-extop actually removed and re-added modification to ipaNTHash if
it contained 'MagicRegen' value. This did not work since commit
https://pagure.io/389-ds-base/c/6c17ec56076d34540929acbcf2f3e65534060a43
but we were lucky nothing in FreeIPA code actually relied on that except
some code paths in ipasam Samba passdb driver. However, Samba didn't
reach the point where the code was triggered -- until now.
With support to run Samba as a domain member in IPA domain, that code
path is triggered for Kerberos service principals of domain members
(cifs/client.example.test, ...) and NT hash extraction from Kerberos
keys does not work.
Fix ipa-pwd-extop to follow recommendations in
https://pagure.io/389-ds-base/issue/387#comment-120145 and
https://pagure.io/389-ds-base/issue/50369#comment-570696
Fixes: https://pagure.io/freeipa/issue/7953
Reviewed-By: Christian Heimes <cheimes@redhat.com>
When making ipa-pwd-extop TXN aware, some callbacks are call twice.
Particularily
ipapwd_pre_add is called during PRE_ADD and TXN_PRE_ADD
ipapwd_pre_mod is called during PRE_MOD and TXN_PRE_MOD
ipapwd_post_modadd is called during POST_ADD and TXN_POST_ADD
ipapwd_post_modadd is called during POST_MOD and TXN_POST_MOD
It is not the expected behavior and it results on some skipped updates krbPasswordExpiration
and krbLastPwdChange
https://pagure.io/freeipa/issue/7601
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Use a helper function to perform operations on dates in LDAP attributes.
Related to #2795
Signed-off-by: Simo Sorce <simo@redhat.com>
Reviewed-by: David Kupka <dkupka@redhat.com>
Before this patch, if the user was configured for either OTP or password
it was possible to do a 1FA authentication through ipa-otpd. Because this
correctly respected the configuration, it is not a security error.
However, once we begin to insert authentication indicators into the
Kerberos tickets, we cannot allow 1FA authentications through this
code path. Otherwise the ticket would contain a 2FA indicator when
only 1FA was actually performed.
To solve this problem, we have ipa-otpd send a critical control during
the bind operation which informs the LDAP server that it *MUST* validate
an OTP token for authentication to be successful. Next, we implement
support for this control in the ipa-pwd-extop plugin. The end result is
that the bind operation will always fail if the control is present and
no OTP is validated.
https://fedorahosted.org/freeipa/ticket/433
Reviewed-By: Sumit Bose <sbose@redhat.com>
This gives us a place to handle all OTP related controls. Also,
genericize otpctrl_present() so that the OID can be specified as an
argument to the function call.
These changes are preparatory for the subsequent patches.
https://fedorahosted.org/freeipa/ticket/433
Reviewed-By: Sumit Bose <sbose@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>
This patch is related to this defect reported by covscan in FreeIPA code:
"""
Error: MISSING_BREAK (CWE-484):
/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c:631: unterminated_case: The
case for value "2" is not terminated by a 'break' statement.
/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c:638: fallthrough: The above
case falls through to this one.
"""
Added a comment informing about intentional falltrough in this place, so that
future generations reading the code don't get confused.
The patch is the part of a series related to
https://fedorahosted.org/freeipa/ticket/4795
Reviewed-By: Alexander Bokovoy <abokovoy@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>
There are no major changes in this commit other than changing filenames
and symbols to have consistent namespaces. This prepares for larger
changes to come in subsequent commits.
Reviewed-By: Thierry Bordaz <tbordaz@redhat.com>
Before this patch users could log in using only the OTP value. This
arose because ipapwd_authentication() successfully determined that
an empty password was invalid, but 389 itself would see this as an
anonymous bind. An anonymous bind would never even get this far in
this code, so we simply deny requests with empty passwords.
This patch resolves CVE-2014-7828.
https://fedorahosted.org/freeipa/ticket/4690
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
This change has two motivations:
1. Clients don't have to parse the string.
2. Future token types may have new formats.
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
This reverts commit bfdbd3b6ad.
Forceful validation of password expiration date in a BIND pre-callback
breaks LDAP password change extended operation as the password change
is only allowed via authenticated (bound) channel. Passwords could be
only changed via kadmin protocol. This change would thus break
LDAP-only clients and Web UI password change hook.
This patch will need to be revisited so that unauthenicated corner
cases are also revisited.
https://fedorahosted.org/freeipa/ticket/1539
Adds a check for krbprincipalexpiration attribute to pre_bind operation
in ipa-pwd-extop dirsrv plugin. If the principal is expired, auth is
denied and LDAP_UNWILLING_TO_PERFORM along with the error message is
sent back to the client. Since krbprincipalexpiration attribute is not
mandatory, if there is no value set, the check is passed.
https://fedorahosted.org/freeipa/ticket/3305
Reviewed-By: Simo Sorce <simo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
There is a special mode to set the ipaNTHash attribute if a RC4 Kerberos
key is available for the corresponding user. This is typically triggered
by samba via the ipa_sam passdb plugin. The principal used by samba to
connect to the IPA directory server has the right to modify ipaNTHash
but no other password attribute. This means that the current check on
the userPassword attribute is too strict for this case and leads to a
failure of the whole operation.
With this patch the access right on ipaNTHash are checked if no other
password operations are requested.
Alexander Bokovoy
Christian Heimes
Thierry Bordaz
Simo Sorce
David Kupka
Nathaniel McCallum
Martin Babinsky
Martin Kosek
Tomas Babej
Sumit Bose