Bug 905930 - Screen is locked immediately after an user auto-logs into guest via SSO from User Portal
Summary: Screen is locked immediately after an user auto-logs into guest via SSO from ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm
Version: 3.2.0
Hardware: Unspecified
OS: Linux
high
high
Target Milestone: ---
: 3.2.0
Assignee: Vinzenz Feenstra [evilissimo]
QA Contact: Jiri Belka
URL:
Whiteboard: virt
Depends On: 879352 913244
Blocks: 882239
TreeView+ depends on / blocked
 
Reported: 2013-01-30 13:57 UTC by Jiri Belka
Modified: 2022-07-09 05:55 UTC (History)
11 users (show)

Fixed In Version: vdsm-4.10.2-16.0.el6ev
Doc Type: Bug Fix
Doc Text:
Previously (in vdsm-4.10.2-4.0.el6ev.x86_64), when the guest agent was installed on a guest and you had configured authentication against directory services, using SSO (single sign-on) to log in to a user account through the User Portal delivered you into a desktop in which the screen was locked. In vdsm-4.10.2-16.0.el6ev.x86_64, SSO delivers you into a desktop in which the screen has not been locked.
Clone Of:
Environment:
Last Closed: 2013-06-10 20:40:03 UTC
oVirt Team: ---
Target Upstream Version:
Embargoed:
sgrinber: Triaged+


Attachments (Terms of Use)
engine.log, vdsm.log, ovirt-guest-agent.log (4.78 KB, application/x-tar)
2013-01-30 13:57 UTC, Jiri Belka
no flags Details
logs from windows guests (28.58 KB, application/x-tar)
2013-03-15 11:58 UTC, Jiri Belka
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHV-47046 0 None None None 2022-07-09 05:55:20 UTC
Red Hat Product Errata RHSA-2013:0886 0 normal SHIPPED_LIVE Moderate: rhev 3.2 - vdsm security and bug fix update 2013-06-11 00:25:02 UTC
oVirt gerrit 13798 0 None None None Never

Description Jiri Belka 2013-01-30 13:57:53 UTC
Created attachment 690389 [details]
engine.log, vdsm.log, ovirt-guest-agent.log

Description of problem:
Guest agent installed, authentication against directory services is configured and working in a guest. When a user tried to login from User Portal to this guest, SSO works but the desktop screen is immediately locked.

According to vfeenstr@, this is bug in vdsm/libvirt.

Part of vdsm.log right when I tried to do SSO:

[root@dell-r210ii-04 ~]# tail -F /var/log/vdsm/vdsm.log | grep 'graphics event phase'
libvirtEventLoop::DEBUG::2013-01-30 14:52:01,129::libvirtconnection::80::vm.Vm::(__eventCallback) vmId=`5a83bc7d-75c3-48a6-a3b3-0cea29b0cd74`::graphics event phase 0 localAddr {'node': '10.34.63.223', 'service': '', 'family': 0} remoteAddr {'node': '10.34.60.82', 'service': '', 'family': 0}authScheme  subject []
libvirtEventLoop::DEBUG::2013-01-30 14:52:01,132::libvirtconnection::80::vm.Vm::(__eventCallback) vmId=`5a83bc7d-75c3-48a6-a3b3-0cea29b0cd74`::graphics event phase 2 localAddr {'node': '10.34.63.223', 'service': '', 'family': 0} remoteAddr {'node': '10.34.60.82', 'service': '', 'family': 0}authScheme  subject []
libvirtEventLoop::DEBUG::2013-01-30 14:52:01,132::libvirtconnection::80::vm.Vm::(__eventCallback) vmId=`5a83bc7d-75c3-48a6-a3b3-0cea29b0cd74`::graphics event phase 0 localAddr {'node': '10.34.63.223', 'service': '', 'family': 0} remoteAddr {'node': '10.34.60.82', 'service': '', 'family': 0}authScheme  subject []
libvirtEventLoop::DEBUG::2013-01-30 14:52:01,160::libvirtconnection::80::vm.Vm::(__eventCallback) vmId=`5a83bc7d-75c3-48a6-a3b3-0cea29b0cd74`::graphics event phase 1 localAddr {'node': '10.34.63.223', 'service': '', 'family': 0} remoteAddr {'node': '10.34.60.82', 'service': '', 'family': 0}authScheme spice subject []
libvirtEventLoop::DEBUG::2013-01-30 14:52:01,235::libvirtconnection::80::vm.Vm::(__eventCallback) vmId=`5a83bc7d-75c3-48a6-a3b3-0cea29b0cd74`::graphics event phase 0 localAddr {'node': '10.34.63.223', 'service': '', 'family': 0} remoteAddr {'node': '10.34.60.82', 'service': '', 'family': 0}authScheme  subject []
libvirtEventLoop::DEBUG::2013-01-30 14:52:01,247::libvirtconnection::80::vm.Vm::(__eventCallback) vmId=`5a83bc7d-75c3-48a6-a3b3-0cea29b0cd74`::graphics event phase 2 localAddr {'node': '10.34.63.223', 'service': '', 'family': 0} remoteAddr {'node': '10.34.60.82', 'service': '', 'family': 0}authScheme  subject []
libvirtEventLoop::DEBUG::2013-01-30 14:52:01,249::libvirtconnection::80::vm.Vm::(__eventCallback) vmId=`5a83bc7d-75c3-48a6-a3b3-0cea29b0cd74`::graphics event phase 0 localAddr {'node': '10.34.63.223', 'service': '', 'family': 0} remoteAddr {'node': '10.34.60.82', 'service': '', 'family': 0}authScheme  subject []
libvirtEventLoop::DEBUG::2013-01-30 14:52:01,264::libvirtconnection::80::vm.Vm::(__eventCallback) vmId=`5a83bc7d-75c3-48a6-a3b3-0cea29b0cd74`::graphics event phase 1 localAddr {'node': '10.34.63.223', 'service': '', 'family': 0} remoteAddr {'node': '10.34.60.82', 'service': '', 'family': 0}authScheme spice subject []
libvirtEventLoop::DEBUG::2013-01-30 14:52:01,496::libvirtconnection::80::vm.Vm::(__eventCallback) vmId=`5a83bc7d-75c3-48a6-a3b3-0cea29b0cd74`::graphics event phase 0 localAddr {'node': '10.34.63.223', 'service': '', 'family': 0} remoteAddr {'node': '10.34.60.82', 'service': '', 'family': 0}authScheme  subject []
libvirtEventLoop::DEBUG::2013-01-30 14:52:01,496::libvirtconnection::80::vm.Vm::(__eventCallback) vmId=`5a83bc7d-75c3-48a6-a3b3-0cea29b0cd74`::graphics event phase 0 localAddr {'node': '10.34.63.223', 'service': '', 'family': 0} remoteAddr {'node': '10.34.60.82', 'service': '', 'family': 0}authScheme  subject []
libvirtEventLoop::DEBUG::2013-01-30 14:52:01,513::libvirtconnection::80::vm.Vm::(__eventCallback) vmId=`5a83bc7d-75c3-48a6-a3b3-0cea29b0cd74`::graphics event phase 2 localAddr {'node': '10.34.63.223', 'service': '', 'family': 0} remoteAddr {'node': '10.34.60.82', 'service': '', 'family': 0}authScheme  subject []
libvirtEventLoop::DEBUG::2013-01-30 14:52:01,514::libvirtconnection::80::vm.Vm::(__eventCallback) vmId=`5a83bc7d-75c3-48a6-a3b3-0cea29b0cd74`::graphics event phase 2 localAddr {'node': '10.34.63.223', 'service': '', 'family': 0} remoteAddr {'node': '10.34.60.82', 'service': '', 'family': 0}authScheme  subject []
libvirtEventLoop::DEBUG::2013-01-30 14:52:01,844::libvirtconnection::80::vm.Vm::(__eventCallback) vmId=`5a83bc7d-75c3-48a6-a3b3-0cea29b0cd74`::graphics event phase 0 localAddr {'node': '10.34.63.223', 'service': '', 'family': 0} remoteAddr {'node': '10.34.60.82', 'service': '', 'family': 0}authScheme  subject []
libvirtEventLoop::DEBUG::2013-01-30 14:52:01,844::libvirtconnection::80::vm.Vm::(__eventCallback) vmId=`5a83bc7d-75c3-48a6-a3b3-0cea29b0cd74`::graphics event phase 0 localAddr {'node': '10.34.63.223', 'service': '', 'family': 0} remoteAddr {'node': '10.34.60.82', 'service': '', 'family': 0}authScheme  subject []
libvirtEventLoop::DEBUG::2013-01-30 14:52:01,910::libvirtconnection::80::vm.Vm::(__eventCallback) vmId=`5a83bc7d-75c3-48a6-a3b3-0cea29b0cd74`::graphics event phase 1 localAddr {'node': '10.34.63.223', 'service': '', 'family': 0} remoteAddr {'node': '10.34.60.82', 'service': '', 'family': 0}authScheme spice subject []
libvirtEventLoop::DEBUG::2013-01-30 14:52:01,910::libvirtconnection::80::vm.Vm::(__eventCallback) vmId=`5a83bc7d-75c3-48a6-a3b3-0cea29b0cd74`::graphics event phase 1 localAddr {'node': '10.34.63.223', 'service': '', 'family': 0} remoteAddr {'node': '10.34.60.82', 'service': '', 'family': 0}authScheme spice subject []

Version-Release number of selected component (if applicable):
* sf4
* libvirt-0.10.2-13.el6.x86_64
* libvirt-python-0.10.2-13.el6.x86_64
* qemu-kvm-rhev-0.12.1.2-2.348.el6.x86_64
* vdsm-4.10.2-4.0.el6ev.x86_64
* vdsm-python-4.10.2-4.0.el6ev.x86_64
* rhevm-guest-agent-gdm-plugin-1.0.7-3.el6ev.x86_64
* rhevm-guest-agent-common-1.0.7-3.el6ev.noarch
* rhevm-guest-agent-pam-module-1.0.7-3.el6ev.x86_64

How reproducible:
100%

Steps to Reproduce:
1. have setup with same rpm packages version
2. directory (like AD here) authentication working in the guest
3. try SSO from User Portal
  
Actual results:
right after SSO, the screen is immediately locked

Expected results:
ready desktop inside guest so a user can work

Additional info:
whole logs for this issue in attachment.

Comment 1 Jiri Belka 2013-01-30 14:14:59 UTC
Of course this impacts SSO for Windows guest as well.

Comment 3 Michal Skrivanek 2013-02-21 08:55:43 UTC
let's pick up 913244 asap

Comment 4 Jiri Belka 2013-03-15 11:58:14 UTC
Created attachment 710604 [details]
logs from windows guests

Any news? Still not working with 3.2.4 tools.

Comment 7 Vinzenz Feenstra [evilissimo] 2013-04-17 10:46:30 UTC
Merged u/s to master branch:
gerrit.ovirt.org/gitweb?p=vdsm.git;a=commit;h=ac961b71de7da403ac09ce7d067e41e01dd018ad

Comment 9 Michal Skrivanek 2013-04-17 10:58:30 UTC
note this is an ugly hack solution on vdsm side
A proper solution should be implemented in bug 879352 and bug 913244

Comment 11 Jiri Belka 2013-04-25 14:38:23 UTC
ok, sf13.1 and vdsm-4.10.2-16.0.el6ev.x86_64, with rhevm-guest-agent-common-1.0.7-4.el6ev.noarch and rhevm-guest-agent-common-1.0.7-3.el6ev.noarch, and windows GA from 3.2.5 (sf13.1) iso.

rhevm-guest-agent-common-1.0.7-5.el6ev.noarch.rpm is broken, but there's another BZ922398.

Comment 14 errata-xmlrpc 2013-06-10 20:40:03 UTC
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.

http://rhn.redhat.com/errata/RHSA-2013-0886.html


Note You need to log in before you can comment on or make changes to this bug.