Bug 1133137

Summary:	[RFE][AAA] Password delegation to VM and newer AAA implementations
Product:	[oVirt] ovirt-engine	Reporter:	Alon Bar-Lev <alonbl>
Component:	AAA	Assignee:	Martin Perina <mperina>
Status:	CLOSED DEFERRED	QA Contact:	Pavel Stehlik <pstehlik>
Severity:	medium	Docs Contact:
Priority:	low
Version:	3.5.0	CC:	audgiri, bazulay, bugs, dossow, dpal, jpazdziora, mgoldboi, michal.skrivanek, mperina, oourfali, pdwyer, rbalakri, rhodain, srevivo, vfeenstr, ykaul
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---	Flags:	oourfali: ovirt-future? ylavi: planning_ack? ylavi: devel_ack? ylavi: testing_ack?
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:
Clones:	1153635 (view as bug list)		Environment:
Last Closed:	2017-07-27 09:06:41 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:
Bug Depends On:
Bug Blocks:	1076964, 1153635

Description Alon Bar-Lev 2014-08-22 21:01:02 UTC

CURRENT IMPLEMENTATION

The user that is sent to VM is the current logged on user, if it does not contain '@' the "domain" name is appended.

PROBLEMS IN CURRENT IMPLEMENTATION

0. Password delegation is bad practice and should not have been used, proper solution is listed at [1], but it is irrelevant now.

1. In legacy implementation, user did not include '@' in name, so result was always user@domain.

2. In legacy implementation domain had been the name of the directory, which was sufficient for some cases, as multi-domain setup was not supported.

3. After the aaa rewrite the domain name is the authz extension name, which can be any string, it can also be the profile name which can also be any string.

4. Even if one of the authz extension name of profile name matches something usable, the name of principal can contain implementation specific name, for example: per new ldap provider, which supports multi domain setup, the name of principal will be DOMAIN\user (aka sam account name), this will currently be sent to VM as DOMAIN\user@xxx which will not be usable.

5. Even if we string the @xxx suffix from (4), we left with DOMAIN\user which will probably work within Windows VMs, but won't work within *NIX VMs.

NEW IMPLEMENTATION

I could not find one that can work with all configuration, especially multi-domain setup within Windows and *NIX.

We cannot assume anything about user name, and we cannot assume anything about the name of the profile or the name of the authz extension.

The best solution I can think of is having a set of regular expressions per cluster or group of VMs, which can transform the principal name and authz name to a user to be sent into VM.

For example:

DOMAIN1\user1@profile1
if windows: -> DOMAIN1\user1
if *nix: -> user1

user2@profile2
if windows: -> DOMAIN1\user2
if *nix: -> user2

Any other options?

[1] http://www.ovirt.org/Features/SSO

Comment 1 Alon Bar-Lev 2014-08-26 19:41:50 UTC

CURRENT IMPLEMENTATION

1. windows - transformation to domain\user

domain == authz name
user == principal name

in many cases within new implementation the assumption that authz name is netbios name of active directory and user is plain user name is incorrect.

2. unix

if user exists in nss (local security) then domain is ignored, otherwise pam is fed with user@domain

PROBLEMS IN CURRENT IMPLEMENTATION

way too many assumptions and heuristics while guessing what user is and what domain means and to what operating system.

although it will continue to work with legacy providers (kerberosldap).

new extension names are unrelated to any physical resource, and may also be unrelated to the destination host authentication mechanism.

NEW IMPLEMENTATION

new extension service (not part of aaa) to transform state into usable domain and user.

input:
1. target os
2. target vm name
3. profile name
4. authz name
5. user name

output:
1. domain
2. user

provide a simple implementation based on regular expression.

behavior if no extension is installed:
domain = authz name
user = principal name

Comment 2 Oved Ourfali 2014-09-11 05:12:29 UTC

Will it make it to 3.5.0?
If not, please set the target release to 3.6.0.

Comment 3 Alon Bar-Lev 2014-09-11 05:58:52 UTC

(In reply to Oved Ourfali from comment #2)
> Will it make it to 3.5.0?
> If not, please set the target release to 3.6.0.

got no answer from managers.

Comment 4 Dmitri Pal 2014-09-25 17:14:01 UTC

Alon,

I think this can be addressed by relying on SSSD. SSSD does all this name transformation and canonicalization. It supports users from AD in multiple different formats. Leveraging mods for authentication and identity lookup as described here [1] would  resolve user to his full name. I do not know if there is an option to return the resolved canonical name from SSSD back to the caller but this can be easily added to SSSD and modules.

[1] http://www.freeipa.org/page/Web_App_Authentication

Comment 5 Alon Bar-Lev 2014-09-25 18:45:23 UTC

(In reply to Dmitri Pal from comment #4)
> Alon,
> 
> I think this can be addressed by relying on SSSD. SSSD does all this name
> transformation and canonicalization. It supports users from AD in multiple
> different formats. Leveraging mods for authentication and identity lookup as
> described here [1] would  resolve user to his full name. I do not know if
> there is an option to return the resolved canonical name from SSSD back to
> the caller but this can be easily added to SSSD and modules.
> 
> [1] http://www.freeipa.org/page/Web_App_Authentication

Relaying on sssd for core feature is not something I would like to have.

The password delegation is also to be used in situations that are not supported by sssd such as internal user repository, so I am unsure how it be integrated.

As I suggested at comment#1, having an extension to do this will enable to implement sssd based extension to resolve user.

Thanks,
Alon

Comment 6 Alon Bar-Lev 2014-11-04 09:22:06 UTC

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

Comment 7 Alon Bar-Lev 2014-12-10 18:04:09 UTC

workaround: have authz name to match the kerberos domain name.

Comment 8 Red Hat Bugzilla Rules Engine 2015-10-19 10:52:24 UTC

Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

Comment 11 Martin Perina 2017-07-27 09:06:41 UTC

This solution would require huge engineering effort and I don't see big complains from customers about current solution. So I'm closing this as deferred, but feel free to reopen it and please describe the issue with current solution