Bug 1403316

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