This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 905930 - Screen is locked immediately after an user auto-logs into guest via SSO from User Portal
Screen is locked immediately after an user auto-logs into guest via SSO from ...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm (Show other bugs)
3.2.0
Unspecified Linux
high Severity high
: ---
: 3.2.0
Assigned To: Vinzenz Feenstra [evilissimo]
Jiri Belka
virt
: Regression, TestBlocker
Depends On: 879352 913244
Blocks: 882239
  Show dependency treegraph
 
Reported: 2013-01-30 08:57 EST by Jiri Belka
Modified: 2015-09-22 09 EDT (History)
11 users (show)

See Also:
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 16:40:03 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
sgrinber: Triaged+


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


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 13798 None None None Never

  None (edit)
Description Jiri Belka 2013-01-30 08:57:53 EST
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 09:14:59 EST
Of course this impacts SSO for Windows guest as well.
Comment 3 Michal Skrivanek 2013-02-21 03:55:43 EST
let's pick up 913244 asap
Comment 4 Jiri Belka 2013-03-15 07:58:14 EDT
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 06:46:30 EDT
Merged u/s to master branch:
gerrit.ovirt.org/gitweb?p=vdsm.git;a=commit;h=ac961b71de7da403ac09ce7d067e41e01dd018ad
Comment 9 Michal Skrivanek 2013-04-17 06:58:30 EDT
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 10:38:23 EDT
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 16:40:03 EDT
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.