#7502 Authentication to UI with client cert fails after password reset
Closed: wontfix 5 years ago Opened 5 years ago by megatonnage.

Possible Issue

Testing shows that if a user is required to change their password on next login (after a password reset for example), then authenticating to the UI with a certificate will fail.

Steps to Reproduce

  1. Perform a password reset for <user>
  2. From a machine with <user>'s certificate imported into Firefox, attempt to log in to the UI using certificate - fails
  3. kinit <user>
    # set a new password
  4. Attempt login to UI with certificate again - succeeds

Actual behavior

Login fails

Expected behavior

Login succeeds

Version/Release/Distribution

$ rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server
package freeipa-server is not installed
package freeipa-client is not installed
ipa-server-4.5.0-20.el7.x86_64
ipa-client-4.5.0-20.el7.x86_64
389-ds-base-1.3.6.1-16.el7.x86_64
pki-ca-10.4.1-10.el7.noarch
krb5-server-1.15.1-8.el7.x86_64

I wanted to know whether this was by design as I would have thought that the password login and certificate login methods should operate independently.


Metadata Update from @fbarreto:
- Issue priority set to: normal

5 years ago

From a Kerberos perspective, what's happening here is that the principal has the +needchange flag set. The historical meaning of this flag is that the principal will be locked out of authenticating to all services except kadmin/changepw, which allows it to change its password.

Kerberos sort of expects that either users will use a password (e.g., with encrypted timestamp or SPAKE) or they will use a certificate (pkinit). We're therefore disinclined to change this behavior since we don't expect users to encounter it, and the necessity for change of password is considered "high priority".

What happens here is that we are handling client authentication with the help of mod_nss (mod_ssl in Fedora 28), then perform protocol transition from TLS client auth to Kerberos in mod_auth_gssapi. However, the latter (S4U2Self) is not a PKINIT authentication and thus is not allowed if +needchange flag is set on the Kerberos principal account. S4U2Self is an operation to allow a trusted Kerberos service to obtain a ticket to itself on behalf of a user: e.g. HTTP/ipa.master to obtain a ticket to HTTP/ipa.master on behalf of a user foo, without having access to the TGT krbtgt/REALM@REALM ticket of the user foo.

Since when +needchange flag is set on the user account you only can use PKINIT to obtain krbtgt/REALM@REALM ticket or use user's password to obtain a kadmin/changepw ticket, any other ticket request is denied. Thus, protocol transition is denied.

The only suggestion we can give is to set random passwords on the accounts of users who are required to use PKINIT only. You can achieve this by running the following command sequence on IPA master as root. It is important to run it on the IPA master and as root because it bypasses IPA framework here and talks directly to LDAP server over LDAPI protocol which allows to map the operation to Directory Manager and thus don't set +needchange flag.

# ipa -e in_server=True user-mod some-user --random
....

After this operation, some-user will have a random password set by the Directory Manager and there will be no +needchange flag on the account.

So I assume the same event (+needchange) happens on password expiry?

Would the guidance for environments using smart cards be to set a random complex password and disable password expiry?

That's one possibility, yes. Password expiration is basically the same story here.

Yes, essentially mirror the -randkey kadmin flag, then disable expiration.

Metadata Update from @rcritten:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1609872

5 years ago

This has been converted into a documentation bug. I'm going to close this part of the issue.

Metadata Update from @rcritten:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

5 years ago

Login to comment on this ticket.

Metadata