Description of problem: At present users are required to login using their UPN format login ids. Request for the usernames to be used for login purposes too.
With a little change into the /etc/ovirt-engine/extensions.d/ad.properties file the users can use the SAM account name to login. ################################################################### vars.default_domain = AD-W2K12R2 sequence.ad-resolve-user.010.description = add default domain prefix sequence.ad-resolve-user.010.type = regex sequence.ad-resolve-user.010.regex.value = ${seq:PrincipalRecord_PRINCIPAL} sequence.ad-resolve-user.010.regex.pattern = ^[^\\\\]*$ sequence.ad-resolve-user.010.regex.replacement.PrincipalRecord_PRINCIPAL = ${global:vars.default_domain}\\\\${seq:PrincipalRecord_PRINCIPAL} sequence.resolve-principal.010.type = regex sequence.resolve-principal.010.regex.value = ${seq:PrincipalRecord_PRINCIPAL} sequence.resolve-principal.010.regex.pattern = ^(?<domain>.*?)(?<backslash>\\\\)(?<user>.*?)$ sequence.resolve-principal.010.regex.replacement.PrincipalRecord_PRINCIPAL = ${user} search.ad-resolve-upn.search-request.filter = &(sAMAccountName=${seq:PrincipalRecord_PRINCIPAL}) ################################################################### Please note that variable 'vars.default_domain' specify default domain name, please be sure to change it to proper name. If AD is mutli-domain setup, users from different domains should use domain prefix before SAM account name, something like this: SUBDOMAIN.DOMAIN.COM\mysamaccount Please note that we didn't test Virtual Machine SSO, so please test properly.
Moved to ON_QA as this fix doesn't require any code changes on aaa-ldap side, but we have never tested using samAccountName so before releasing to customer as supported configuration we should test it (basic authentication/authorization flows and I'd suggest to test also VM SSO).
(In reply to Ondra Machacek from comment #2) > With a little change into the /etc/ovirt-engine/extensions.d/ad.properties > file the users can use the SAM account name to login. Just a small correction: the above path is specific for the customer, but generally users should edit relevant file in /etc/ovirt-engine/aaa/<PROFILE_NAME>.properties. For example if you use template from /usr/share/ovirt-engine-extension-aaa-ldap/examples/ad then you should edit /etc/ovirt-engine/aaa/profile1.properties
Verified with: ovirt-engine-extension-aaa-ldap-1.3.1-0.0.master.20170115190508.gitda48d9d.el7.noarch # ovirt-engine-extensions-tool aaa login-user --profile=ad-w2k12r2 --user-name=AD-W2K12R2\\user_sam ... 2017-02-06 12:35:31 INFO API: -->Authz.InvokeCommands.FETCH_PRINCIPAL_RECORD principal='AD-W2K12R2\user_sam' 2017-02-06 12:35:31 INFO API: <--Authz.InvokeCommands.FETCH_PRINCIPAL_RECORD status=SUCCESS ...
@Martin Perina, #5 So there is a method that we can use to be successful with this? is there something I could give the customer now?
(In reply to Troy Dash from comment #7) > @Martin Perina, #5 > > So there is a method that we can use to be successful with this? is there > something I could give the customer now? Yes, customer needs to update relevant /etc/ovirt-engine/aaa/<PROFILE>.properties file(s) as described in Comment 2 and Comment 3.
Is there a document to set it up other than the bz? I am trying to set it up in my environment with no luck. Appreciate any guidance
Just want to clarify i am able to connect using following command but it does not work with ovirt web portal. ovirt-engine-extensions-tool aaa login-user --profile=mydomain --user-name=mydomain\\userid
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days