IPA Client failed login after screen lock

[Boyd Ako]

So, I created a Red Hat ticket to assist and the support is pretty non-productive.

I have a RHEL 7 "Workstation" setup as an IPA client that most of the time works. However, there are occasions when the screen locks out due to inactivity that I can't log back in. Most of the time it occurs when I use smartcard x.509 to login; but it also occasionally happens I use password to login intially. It's not very consistent on the failures. The only way to login AFTER that is to annoyingly reboot or console in as root and start a kerberos session.

The IPA server is using an external CA. On the client, the CA certs on the smartcard are in /etc/pki/nssdb. The chain is Root CA -> ID Intermediate CA -> x.509 cert on token. All the CA's are external. The token cert did validate when using the Root Ca and ID CA certs tacked together for the CAfile in `openssl verify`. I added the following to the sssd.conf:

===============================
[domain/mydomain.com]
debug_level = 8
account_cache_expiration = 5
entry_cache_timeout = 28800

[pam]
debug_level = 8
offline_credentials_expiration = 5
===============================

"pam_cert_auth = True" is in the PAM sect. I did run the script from the `ipa-advise` client-smart_card_script.

[Sumit Bose]

On Fri, Jun 21, 2019 at 01:14:33AM -0000, Boyd Ako via FreeIPA-users wrote:
> So, I created a Red Hat ticket to assist and the support is pretty non-productive.
>
> I have a RHEL 7 "Workstation" setup as an IPA client that most of the time works. However, there are occasions when the screen locks out due to inactivity that I can't log back in. Most of the time it occurs when I use smartcard x.509 to login; but it also occasionally happens I use password to login intially. It's not very consistent on the failures. The only way to login AFTER that is to annoyingly reboot or console in as root and start a kerberos session.
>
> The IPA server is using an external CA. On the client, the CA certs on the smartcard are in /etc/pki/nssdb. The chain is Root CA -> ID Intermediate CA -> x.509 cert on token. All the CA's are external. The token cert did validate when using the Root Ca and ID CA certs tacked together for the CAfile in `openssl verify`. I added the following to the sssd.conf:
>
> ===============================
> [domain/mydomain.com]
> debug_level = 8
> account_cache_expiration = 5
> entry_cache_timeout = 28800
>
> [pam]
> debug_level = 8
> offline_credentials_expiration = 5
> ===============================

Hi,

did you add logs with debug_level=8 to the case you have mentioned? If
yes, please let me know the case number so that I can have a look. If
not, please send the logs. If you prefer to not share them on this list
feel free to send them to me directly.

bye,
Sumit
> "pam_cert_auth = True" is in the PAM sect. I did run the script from the `ipa-advise` client-smart_card_script.
> _______________________________________________
> FreeIPA-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/[e-mail]...

[Boyd Ako]

I’ll PM you the Case number. Please free to state informational information here for others to learn.
> On Jun 20, 2019, at 22:30, Sumit Bose via FreeIPA-users  wrote:
>
> On Fri, Jun 21, 2019 at 01:14:33AM -0000, Boyd Ako via FreeIPA-users wrote:
> > So, I created a Red Hat ticket to assist and the support is pretty non-productive.
> >
> > I have a RHEL 7 "Workstation" setup as an IPA client that most of the time works. However, there are occasions when the screen locks out due to inactivity that I can't log back in. Most of the time it occurs when I use smartcard x.509 to login; but it also occasionally happens I use password to login intially. It's not very consistent on the failures. The only way to login AFTER that is to annoyingly reboot or console in as root and start a kerberos session.
> >
> > The IPA server is using an external CA. On the client, the CA certs on the smartcard are in /etc/pki/nssdb. The chain is Root CA -> ID Intermediate CA -> x.509 cert on token. All the CA's are external. The token cert did validate when using the Root Ca and ID CA certs tacked together for the CAfile in `openssl verify`. I added the following to the sssd.conf:
> >
> > ===============================
> > [domain/mydomain.com]
> > debug_level = 8
> > account_cache_expiration = 5
> > entry_cache_timeout = 28800
> >
> > [pam]
> > debug_level = 8
> > offline_credentials_expiration = 5
> > ===============================
>
> Hi,
>
> did you add logs with debug_level=8 to the case you have mentioned? If
> yes, please let me know the case number so that I can have a look. If
> not, please send the logs. If you prefer to not share them on this list
> feel free to send them to me directly.
>
> bye,
> Sumit
> > "pam_cert_auth = True" is in the PAM sect. I did run the script from the `ipa-advise` client-smart_card_script.
> > _______________________________________________
> > FreeIPA-users mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: https://lists.fedorahosted.org/archives/list/[e-mail]...
>
> FreeIPA-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/[e-mail]...

Domo,

Boyd H. Ako

[e-mail]
[phone]
https://www.boydhanaleiako.me

“Coming together is a beginning. Keeping together is progress. Working together is success.” -Henry Ford

PGP/GPG Public Key: https://sks-keyservers.net/pks/lookup?op=get&search=0xC58073B21618F134

[Boyd Ako]

Hey Sumit,

Can you take a gander at the ticket again? I have till the end of the month
to get this fixed or the whole thing gets ditched. Then we'll have to stick
to having to remember a boat load of logins and what not.

Do you know if it's possible to hand off the ticket to someone else? No
offense to the current guy. But, I think this might be out of knowledge. I
have a feeling he's more familiar with server side rather than workstation
client side.

------------------------------
Thank you for your time,

Boyd H. Ako

[e-mail]
https://www.boydhanaleiako.me

PGP/GPG Public Key:
https://sks-keyservers.net/pks/lookup?op=get&search=0xC58073B21618F134
------------------------------

On Thu, Jun 20, 2019 at 11:28 PM Boyd Ako 
wrote:
> I’ll PM you the Case number. Please free to state informational
> information here for others to learn.
> > On Jun 20, 2019, at 22:30, Sumit Bose via FreeIPA-users <
>
> [e-mail]> wrote:
> > On Fri, Jun 21, 2019 at 01:14:33AM -0000, Boyd Ako via FreeIPA-users
>
> wrote:
> > > So, I created a Red Hat ticket to assist and the support is pretty
>
> non-productive.
> > > I have a RHEL 7 "Workstation" setup as an IPA client that most of the
>
> time works. However, there are occasions when the screen locks out due to
> inactivity that I can't log back in. Most of the time it occurs when I use
> smartcard x.509 to login; but it also occasionally happens I use password
> to login intially. It's not very consistent on the failures. The only way
> to login AFTER that is to annoyingly reboot or console in as root and start
> a kerberos session.
> > > The IPA server is using an external CA. On the client, the CA certs on
>
> the smartcard are in /etc/pki/nssdb. The chain is Root CA -> ID
> Intermediate CA -> x.509 cert on token. All the CA's are external. The
> token cert did validate when using the Root Ca and ID CA certs tacked
> together for the CAfile in `openssl verify`. I added the following to the
> sssd.conf:
> > > ===============================
> > > [domain/mydomain.com]
> > > debug_level = 8
> > > account_cache_expiration = 5
> > > entry_cache_timeout = 28800
> > >
> > > [pam]
> > > debug_level = 8
> > > offline_credentials_expiration = 5
> > > ===============================
> >
> > Hi,
> >
> > did you add logs with debug_level=8 to the case you have mentioned? If
> > yes, please let me know the case number so that I can have a look. If
> > not, please send the logs. If you prefer to not share them on this list
> > feel free to send them to me directly.
> >
> > bye,
> > Sumit
> > > "pam_cert_auth = True" is in the PAM sect. I did run the script from
>
> the `ipa-advise` client-smart_card_script.
> > > FreeIPA-users mailing list -- [e-mail]
> > > To unsubscribe send an email to
>
> [e-mail]
> > > Fedora Code of Conduct:
>
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
>
> https://lists.fedorahosted.org/archives/list/[e-mail]...
> > FreeIPA-users mailing list -- [e-mail]
> > To unsubscribe send an email to
>
> [e-mail]
> > Fedora Code of Conduct:
>
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
>
> https://lists.fedorahosted.org/archives/list/[e-mail]...
>
> Domo,
>
> Boyd H. Ako
>
> [e-mail]
> [phone]
> https://www.boydhanaleiako.me
>
> “Coming together is a beginning. Keeping together is progress. Working
> together is success.” -Henry Ford
>
> PGP/GPG Public Key:
> https://sks-keyservers.net/pks/lookup?op=get&search=0xC58073B21618F134

[Boyd Ako]

ALCON,

I believe the issue was resolved.

SOLUTION:
Add "certificate_verification = no_ocsp" to the SSSD section of sssd.conf.

REASON:
I think GDM was hiccuping out on the fact that the system wasn't able to reach the OCSP servers stated in the cert.