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
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
Will it make it to 3.5.0? If not, please set the target release to 3.6.0.
(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.
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
(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
*** Bug 1153635 has been marked as a duplicate of this bug. ***
workaround: have authz name to match the kerberos domain name.
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.
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