Bug 1399160

Summary: User fails to login trough ssh when password have been reset
Product: Red Hat Enterprise Linux 7 Reporter: Kim Borup <kborup>
Component: ipaAssignee: IPA Maintainers <ipa-maint>
Status: CLOSED INSUFFICIENT_DATA QA Contact: ipa-qe <ipa-qe>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.3CC: dpal, dwojewod, grajaiya, jhrozek, kborup, ldelouw, lslebodn, mkosek, mzidek, pbrezina, pkis, pvoborni, rcritten, rharwood, sbose, tscherf
Target Milestone: rc   
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: 2017-09-01 21:32:48 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1420851    

Description Kim Borup 2016-11-28 12:57:04 UTC 
Description of problem:
IPA with AD trust. 

when a IPA user gets reset, he can not login trough ssh and change the password,  (he wont be prompted) , he then have to login to the ipa gui first to change password and then login with ssh. 



Version-Release number of selected component (if applicable):
current release

How reproducible:
All the time

Steps to Reproduce:
1. Create a IPA-AD trust
2. Create IPA user.
3. Try and login trough ssh with password
4. change password in gui
5. login again

Actual results:
Failed login attempt

Expected results:
login to server being asked to change password

Additional info:
Log files attached.
Comment 2 Jakub Hrozek 2016-11-28 14:23:31 UTC 
This seems to be more of an sssd issue so I'm 'stealing' the bug.
Comment 3 Sumit Bose 2016-11-28 15:10:11 UTC 
It looks like it is related to 'krb5_use_enterprise_principal = True' or the automatic setting of it in the 7.3 version of SSSD.

If the enterprise principal feature is not needed for the AD users the setting 'krb5_use_enterprise_principal = False' in the [domain/...] section of sssd.conf would be a work-around.
Comment 4 Sumit Bose 2016-11-28 15:33:26 UTC 
To reproduce this outside of SSSD you can call

    KRB5_TRACE=/dev/stdout kinit -E -C ipauser -S 'kadmin/changepw'

Assigning to krb5 to get feedback what it the expected behavior here, i.e. requesting 'kadmin/changepw' ticket to change an expired password with an enterprise principal.