Just tried to use password auth instead of smartcard and that works as expected, so this seems to be a smartcard specific thing.

With RHEL-8 your user-session will be running on VT2. So the reason you are getting the unlock screen when you switch to VT1 is because you are switching back to VT1, try switching to VT2 instead.

This will not fix the issue with the initial login, but it should help with the "if I change VT and then change back to gnome (ALT+F1)" case.

Ah yes, you're correct. I missed that. But why is there a GDM login session running on VT1, that's just confusing..? (bit offtopic here)

(In reply to tfolinux from comment #3)
> Ah yes, you're correct. I missed that. But why is there a GDM login session
> running on VT1, that's just confusing..? (bit offtopic here)

Because the X-server now runs as the user for which the session is started, rather then as root (for security reasons), so a separate X-server is started for the user-session on the first free VT.

Ok, thanks for info!

I can also add that when using password auth the files in /var/lib/AccountsService/users/ are created correctly (when using smartcard auth they are not created at all)

(OP here, but with another account)

When I login with smartcard, the $USERNAME/$USER env var is set to 'username.com', it should be just 'username'. So it seems that sssd passes the wrong data to pam in this regard. AccountsService may not accept that type of username?

Can i set something in sssd.conf to get sssd to pass on the 'correct' username to PAM? I've tried setting 'default_domain_suffix' and 'full_name_format', but no change in behaviour regarding $USERNAME.

Not much activity here - i'll add some sssd debug logs and hope for some attention. 

When I login (in gdm, with smartcard + PIN) pam outputs:

gdm-smartcard][3821]: pam_sss(gdm-smartcard:auth): authentication success; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=a001329.com
gdm-smartcard][3821]: pam_unix(gdm-smartcard:session): session opened for user a001329.com by (uid=0)

Notice the username format for my user (a001329). 
My gnome session is immediately locked. When I unlock it (with smartcard + PIN) pam outputs:

gdm-smartcard][3680]: pam_sss(gdm-smartcard:auth): authentication success; logname= uid=0 euid=0 tty=/dev/tty2 ruser= rhost= user=a001329

Notice that the 'user' attribute has changed. Don't know if this is at all relevant though...

Created attachment 1541399 [details]
sssd debug logs

Debug logs from GDM login (not including gnome session unlock)

can you post the output of

$ env

run from a terminal with in a session that was logged in the smart card ?

In particular I'm interested in the value of the PKSC11_LOGIN_TOKEN_NAME environment variable.

Also, does changing the value of use_fully_qualified_names in sssd.conf affect this bug?

Adam is on vacation so I will answer instead. Here is env:

XDG_MENU_PREFIX=gnome-
LANG=en_GB.UTF-8
GDM_LANG=en_GB.UTF-8
DISPLAY=:1
HISTTIMEFORMAT=%F %T 
COLORTERM=truecolor
USERNAME=a002107.com
XDG_VTNR=2
SSH_AUTH_SOCK=/run/user/66212/keyring/ssh
XDG_SESSION_ID=4
USER=a002107.com
DESKTOP_SESSION=gnome
GNOME_TERMINAL_SCREEN=/org/gnome/Terminal/screen/4850ff78_1cc3_4fe9_8652_fd70bc82e162
PWD=/home/a002107
HOME=/home/a002107
XDG_SESSION_TYPE=x11
KRB5CCNAME=KEYRING:persistent:66212
XDG_DATA_DIRS=/home/a002107/.local/share/flatpak/exports/share/:/var/lib/flatpak/exports/share/:/usr/local/share/:/usr/share/
XDG_SESSION_DESKTOP=gnome
GJS_DEBUG_OUTPUT=stderr
PKCS11_LOGIN_TOKEN_NAME=identification (Instant EID IP9)
WINDOWPATH=2
SHELL=/bin/bash
TERM=xterm-256color
VTE_VERSION=5202
QT_IM_MODULE=ibus
XMODIFIERS=@im=ibus
XDG_CURRENT_DESKTOP=GNOME
GNOME_TERMINAL_SERVICE=:1.80
XDG_SEAT=seat0
SHLVL=1
MANPATH=:/opt/puppetlabs/puppet/share/man
GDMSESSION=gnome
GNOME_DESKTOP_SESSION_ID=this-is-deprecated
LOGNAME=a002107.com
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/66212/bus
XDG_RUNTIME_DIR=/run/user/66212
XAUTHORITY=/run/user/66212/gdm/Xauthority
PATH=/home/a002107/.local/bin:/home/a002107/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/opt/puppetlabs/bin
GJS_DEBUG_TOPICS=JS ERROR;JS LOG
SESSION_MANAGER=local/unix:@/tmp/.ICE-unix/12875,unix/unix:/tmp/.ICE-unix/12875
LESSOPEN=||/usr/bin/lesspipe.sh %s
_=/usr/bin/env

I will try use_fully_qualified_names on friday when I am back at work. Man page says it is default false and we have not set it.

great thanks, can you also provide the output of

certutil -L -d /etc/pki/nssdb -h all

?

i wonder if this is a case where the token name changes depending on whether or not a pin code is used.

Here is certutil -L -d /etc/pki/nssdb -h all


Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

Enter Password or Pin for "identification (Instant EID IP9)":
identification (Instant EID IP9):a002107                     u,u,u
identification (Instant EID IP9):erso.adm                    u,u,u


I have also tried use_fully_qualified_names, both True and False. No changes in behaviour with locking after login and $USERNAME.

okay so to me, it looks like perhaps, pam_sss is setting PKCS11_LOGIN_TOKEN_NAME to the slot name instead of the token name, reassigning to sssd

Upon closer inspection, it appears that I misread the output in comment 13.  Reassigning to gnome-settings-daemon

*** Bug 1643255 has been marked as a duplicate of this bug. ***

So the problem is actually just a missing patch.  In RHEL 7 we have this patch:

From 0665bd86221d3c9012f0391d8e4939a2d12b6417 Mon Sep 17 00:00:00 2001•
From: Ray Strode <rstrode>•
Date: Fri, 9 Feb 2018 16:39:12 -0500•
Subject: [PATCH 1/2] smartcard: Wait until smartcards are inspected before•
 locking screen•
•
There's a race condition in the code where we check if the screen should•
be locked (because the smartcard is removed) before we necessarly check•
the smartcard's insertion status.•
•
This commit fixes the race by iterating through all smartcards at•
startup and checking their status explicitly.•
---•
 plugins/smartcard/gsd-smartcard-manager.c | 61 ++++++++++++++++++-----•
 1 file changed, 49 insertions(+), 12 deletions(-)•

but it's missing from RHEL 8.

So RHEL8.0 is released but this bug is still present. When is it expected to be resolved? Is there any workarounds?

This bug is currently, tentatively slated to be fixed in 8.1.  I don't know of any workaround at this time.

Could I install the version from RHEL7 instead?

Practically speaking, that may work, but it's not something that's supported.

Deepu, can you pass the build from the errata on to the customer to test in their environment?

(In reply to Ray Strode [halfline] from comment #32)
> Deepu, can you pass the build from the errata on to the customer to test in
> their environment?

Any feedback here?

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:3553