Bug 1609872

Summary:	Authentication to UI with client cert fails after password reset
Product:	Red Hat Enterprise Linux 7	Reporter:	Rob Crittenden <rcritten>
Component:	doc-Linux_Domain_Identity_Management_Guide	Assignee:	Marc Muehlfeld <mmuehlfe>
Status:	CLOSED CURRENTRELEASE	QA Contact:	ipa-qe <ipa-qe>
Severity:	unspecified	Docs Contact:
Priority:	medium
Version:	7.4	CC:	pvoborni, rcritten, rhel-docs, tscherf
Target Milestone:	rc	Keywords:	Documentation, EasyFix
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-04-09 10:32:40 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Rob Crittenden 2018-07-30 17:08:31 UTC

This bug is created as a clone of upstream ticket:
https://pagure.io/freeipa/issue/7502

### 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.

Comment 2 Rob Crittenden 2018-07-30 17:10:44 UTC

Creating a doc bug out of an issue reported upstream. The jist is:

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".

Comment 4 Marc Muehlfeld 2019-04-09 10:32:40 UTC

Windows Integration Guide, Linux Domain Identity, Authentication, and Policy Guide und System-Level Authentication Guide sind live

Comment 5 Marc Muehlfeld 2019-04-09 10:35:39 UTC

The update is now available on the Customer Portal.