Bug 905930

Summary: Screen is locked immediately after an user auto-logs into guest via SSO from User Portal
Product: Red Hat Enterprise Virtualization Manager Reporter: Jiri Belka <jbelka>
Component: vdsmAssignee: Vinzenz Feenstra [evilissimo] <vfeenstr>
Status: CLOSED ERRATA QA Contact: Jiri Belka <jbelka>
Severity: high Docs Contact:
Priority: high    
Version: 3.2.0CC: acathrow, bazulay, hateya, iheim, lpeer, michal.skrivanek, ofrenkel, pstehlik, sgrinber, ykaul, zdover
Target Milestone: ---Keywords: Regression, TestBlocker
Target Release: 3.2.0Flags: sgrinber: Triaged+
Hardware: Unspecified   
OS: Linux   
Whiteboard: virt
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.
 Story Points: ---
Clone Of: Environment:
Last Closed: 2013-06-10 20:40:03 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:
Embargoed:
Bug Depends On: 879352, 913244    
Bug Blocks: 882239    
Attachments:
Description Flags
engine.log, vdsm.log, ovirt-guest-agent.log
none
logs from windows guests none

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