Bug 1464457

Summary:	REST API command logon fails
Product:	[oVirt] ovirt-engine	Reporter:	paul
Component:	AAA	Assignee:	Ravi Nori <rnori>
Status:	CLOSED DUPLICATE	QA Contact:	Gonza <grafuls>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	4.1.2.2	CC:	bugs, juan.hernandez
Target Milestone:	---	Keywords:	Regression
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-06-23 13:27:51 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description paul 2017-06-23 13:19:27 UTC

Description of problem:
The API command logon does not logon the user. The vm is set-up for SSO, this works without problems from portal. Output of the command states "status complete" without errors. On the console it shortly states: "sorry, that didn't work. Please try again"

Version-Release number of selected component (if applicable):


How reproducible:
always

Steps to Reproduce:
1. Create vm with SSO
2. Request API logon command
3.

Actual results:
no logon

Expected results:
login of user

Additional info:

commands used to logon:
curl \
--request POST \
--header 'Accept: application/xml' \
--header 'Content-type':'application/xml' \
--header 'Authorization':'Bearer xx' \
--header 'Filter':'true' \
--data '<action/>' \
https://engine.example.com/ovirt-engine/api/vms/{vmID}/logon

output of command:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<action>
    <job href="/ovirt-engine/api/jobs/a13ebea3-6832-4923-a816-c018ac38d528" id="a13ebea3-6832-4923-a816-c018ac38d528"/>
    <status>complete</status>
    <vm href="/ovirt-engine/api/vms/f8d59474-efcc-4f59-b662-c2617f0679b6" id="f8d59474-efcc-4f59-b662-c2617f0679b6">
        <actions>
            <link href="/ovirt-engine/api/vms/f8d59474-efcc-4f59-b662-c2617f0679b6/ticket" rel="ticket"/>
....
        <link href="/ovirt-engine/api/vms/f8d59474-efcc-4f59-b662-c2617f0679b6/statistics" rel="statistics"/>
    </vm>
</action>

Logs on the VM:
/var/log/secure
Jun 23 15:06:00 test01 gdm-ovirtcred]: pam_unix(gdm-ovirtcred:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=  user=test
Jun 23 15:06:00 test01 gdm-ovirtcred]: pam_sss(gdm-ovirtcred:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=test
Jun 23 15:06:00 test01 gdm-ovirtcred]: pam_sss(gdm-ovirtcred:auth): received for user test: 7 (Authentication failure)

/var/log/ovirt-guest-agent/ovirt-guest-agent.log 
Dummy-1::DEBUG::2017-06-23 15:05:59,349::OVirtAgentLogic::398::root::AgentLogicBase::sendUserInfo - cur_user = '(unknown)'
Dummy-2::INFO::2017-06-23 15:05:59,991::OVirtAgentLogic::321::root::Received an external command: login...
Dummy-2::DEBUG::2017-06-23 15:05:59,991::OVirtAgentLogic::355::root::User log-in (credentials = '\x00\x00\x00\x16test********\x00')
Dummy-2::INFO::2017-06-23 15:05:59,991::CredServer::208::root::The following users are allowed to connect: [0]
Dummy-2::DEBUG::2017-06-23 15:05:59,991::CredServer::273::root::Token: 897939
Dummy-2::INFO::2017-06-23 15:05:59,991::CredServer::274::root::Opening credentials channel...
Dummy-2::INFO::2017-06-23 15:05:59,992::CredServer::133::root::Emitting user authenticated signal (897939).
CredChannel::DEBUG::2017-06-23 15:06:00,075::CredServer::167::root::Receiving user's credential ret = 2 errno = 0
CredChannel::DEBUG::2017-06-23 15:06:00,075::CredServer::178::root::cmsgp: len=28 level=1 type=2
CredChannel::INFO::2017-06-23 15:06:00,076::CredServer::226::root::Incomming connection from user: 0 process: 4291
CredChannel::INFO::2017-06-23 15:06:00,076::CredServer::233::root::Sending user's credential (token: 897939)
Dummy-2::INFO::2017-06-23 15:06:00,076::CredServer::278::root::Credentials channel was closed.
Dummy-2::DEBUG::2017-06-23 15:06:00,076::OVirtAgentLogic::293::root::AgentLogicBase::doListen() - in loop before vio.read

Comment 1 paul 2017-06-23 13:21:53 UTC

PAM config might be usefull as well.

cat /etc/pam.d/password-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
#auth        [default=1 success=ok] pam_localuser.so
#auth        [success=done ignore=ignore default=die] pam_unix.so nullok try_first_pass
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_sss.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so sha512 shadow nis nullok try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     optional      pam_oddjob_mkhomedir.so umask=0077
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_sss.so

Comment 2 Juan Hernández 2017-06-23 13:27:51 UTC

This looks like a duplicate of bug 1463634. Please check and vote that bug. If you think it isn't a duplicate, then please re-open it.

*** This bug has been marked as a duplicate of bug 1463634 ***