Description of problem: By default, the 'ovirt-engine-extension-aaa-ldap-setup' script assumes that the user is not going to use 'Single Sing-On for Virtual Machines' feature. If the user changes his mind in the future there is no easy way to modify the configuration to make it work. There are two options: 1. Remove all the permissions of domain users in 'Administration Portal', rename the authorization extension with upstream tool 'ovirt-engine-kerbldap-migration-authz-rename'. Reassign the user's permissions in 'Administration Portal'. 2. Make the changes manually in profile config files and directly into the database (undocumented and not recommended of course). As there is no functional impact I believe we should use 'Yes' as the default answer to the question 'Are you going to use Single Sing-On for Virtual Machines?', at least until we had a better implementation. Version-Release number of selected component (if applicable): All How reproducible: Always Steps to Reproduce: 1. Run 'ovirt-engine-extension-aaa-ldap-setup' 2. Choose the default answer of 'Are you going to use Single Sing-On for Virtual Machines?' Actual results: Virtual Machine SSO in user portal not working Expected results: Virtual Machine SSO in user portal working Additional info:
Fix is contained is going to be delivered in ovirt-engine-extension-aaa-ldap-1.3.3
Verified with: ovirt-engine-extension-aaa-ldap-setup-1.3.3-1.el7ev.noarch "Are you going to use Single Sign-On for Virtual Machines (Yes, No) [Yes]: "
Retargeting to 4.1.6 as we need to withdraw release of ovirt-engine-extension-aaa-ldap-setup-1.3.3 and fix critical bug in this release
Fix is included in ovirt-engine-extension-aaa-ldap-1.3.4
Verified with: ovirt-engine-extension-aaa-ldap-setup-1.3.5-0.0.master.git7230cd9.el7.centos.noarch ... Are you going to use Single Sign-On for Virtual Machines (Yes, No) [Yes]: ...