On Mon, Feb 22, 2021 at 03:38:48PM +0000, Winberg Adam wrote: > Does sssd use the local cache to decide if the correct certificate is used > for unlocking a gnome session? And if so, will clearing that cache make it > impossible to unlock the session?
Hi, SSSD uses the same mechanism established by pam_pkcs11 and gdm where an environment variable KCS11_LOGIN_TOKEN_NAME is used to store the token name of the Smartcard used during login. To unlock the session a Smartcard with the same token name is needed together with all the other checks. Feel free to send my the SSSD logs with 'debug_level = 9' in the [pam] and [domain/...] section covering the unlocking attempts. bye, Sumit > > Trying to figure out why I still can't unlock even though i reverted to the > pkcs11 lib used to login to my session. I did do a 'sssctl cache-remove' > while debugging. > > //Adam > ________________________________ > From: [email protected] <[email protected]> on behalf of > Winberg Adam <[email protected]> > Sent: 22 February 2021 16:21:18 > To: [email protected] > Subject: [SSSD-users] Re: session unlock with smartcard stops working when > updating shared library > > > Yes, good idea - removed the new lib and installed the old one, but still > unable to unlock my session. > > > The token name and key id are exactly the same between the two versions in > the debug logs. There is however a slight difference in the uri's - one > version contains > > library-version=68.0 > > and the other has > > library-version=6.8 > > > Could that be the problem? > > > //Adam > > > ________________________________ > From: Sumit Bose <[email protected]> > Sent: 22 February 2021 14:38 > To: [email protected] > Subject: [SSSD-users] Re: session unlock with smartcard stops working when > updating shared library > > On Mon, Feb 22, 2021 at 07:17:34AM +0000, Winberg Adam wrote: > > We're using a third party shared library for communication with our > > smartcards, using RHEL 8.3. SSSD uses p11 to communicate with the cards, > > this works fine. > > > > > > But, when I update the third party lib file to a new version, I can no > > longer unlock my Gnome session with the smart card. Debug logs shows the > > following in p11_child.log: > > > > > > (2021-02-22 7:55:07): [p11_child[3059726]] [main] (0x0010): --module_name, > > --token_name and --key_id must be given for authentication > > (2021-02-22 7:55:07): [p11_child[3059726]] [main] (0x0020): p11_child > > failed! > > Hi, > > the names and key id is read from the card in the pre-auth step and are > then used during authentication to make sure the right certificate is > selected. My first guess would be the either the token name or the key > id are not returned by the new library or return in some unexpected > format. > > Can you compare the debug output of the pre-auth step of the old and new > library? > > bye, > Sumit > > > > > > > > > And in sssd_pam.log: > > > > (2021-02-22 7:55:07): [pam] [parse_p11_child_response] (0x1000): No > > certificate found. > > (2021-02-22 7:55:07): [pam] [pam_forwarder_cert_cb] (0x0020): No > > certificate returned, authentication failed. > > > > I can use the smartcard for other actions, like sudo and logging in to a > > new session, but not to unlock the existing session. It's like some session > > specific data no longer is available or no longer matches when the lib file > > has changed on disk. > > > > > > This makes it really hard to update the lib file on our users computers, > > seeing as doing so will effectively lock them out of their sessions. Does > > anyone recognize this behaviour and is there anything I can do to avoid it? > > > > > > Regards > > > > Adam Winberg > > > > > _______________________________________________ > > sssd-users mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > 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/[email protected] > > Do not reply to spam on the list, report it: > > https://pagure.io/fedora-infrastructure > _______________________________________________ > sssd-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > _______________________________________________ > sssd-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
