Bug 1266123 - User must have posixAccount within rfc2307 profile
User must have posixAccount within rfc2307 profile
Status: CLOSED NOTABUG
Product: ovirt-engine-extension-aaa-ldap
Classification: oVirt
Component: Profile.rfc2307 (Show other bugs)
1.0.2
noarch Linux
unspecified Severity unspecified (vote)
: ---
: ---
Assigned To: Alon Bar-Lev
Ondra Machacek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-24 10:24 EDT by nicolas
Modified: 2016-01-04 00:41 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-09-24 13:41:20 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?


Attachments (Terms of Use)
Trace log from a LDAP search (50.56 KB, text/plain)
2015-09-24 10:44 EDT, nicolas
no flags Details

  None (edit)
Description nicolas 2015-09-24 10:24:58 EDT
Description of problem:

Using version 1.0.2-1.el7 of ovirt-engine-extension-aaa-ldap, along with ovirt-engine 3.5.3.1. LDAP authentication is configured in the following way:

aaa/mydomain.properties
=======================
include = <rfc2307-openldap.properties>
vars.server = openldap.domain.com
vars.user =
vars.password =
pool.default.serverset.srvrecord.service = ldaps
pool.default.serverset.srvrecord.protocol = tcp
pool.default.serverset.single.server = ${global:vars.server}
pool.default.auth.simple.bindDN = ${global:vars.user}
pool.default.auth.simple.password = ${global:vars.password}
pool.default.ssl.startTLS = false
sequence-init.init.100-my-basedn-init-vars = my-basedn-init-vars
sequence.my-basedn-init-vars.010.description = set baseDN
sequence.my-basedn-init-vars.010.type = var-set
sequence.my-basedn-init-vars.010.var-set.variable = simple_baseDN
sequence.my-basedn-init-vars.010.var-set.value = cn=Users,dc=mydomain,dc=com
search.default.search-request.derefPolicy = ALWAYS
Version-Release number of selected component (if applicable):

extensions.d/mydomain-authn.properties
======================================
ovirt.engine.extension.name = mydomain-authn
ovirt.engine.extension.bindings.method = jbossmodule
ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine-extensions.aaa.ldap
ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engineextensions.aaa.ldap.AuthnExtension
ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authn
ovirt.engine.aaa.authn.profile.name = mydomain
ovirt.engine.aaa.authn.authz.plugin = mydomain-authz
config.profile.file.1 = ../aaa/mydomain.properties

extensions.d/mydomain-authz.properties
======================================
ovirt.engine.extension.name = mydomain-authz
ovirt.engine.extension.bindings.method = jbossmodule
ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine-extensions.aaa.ldap
ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engineextensions.aaa.ldap.AuthzExtension
ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authz
config.profile.file.1 = ../aaa/mydomain.properties

We have all users under the same cn (cn=Users). Our users were all in the format uid=XXXYYYYYYYYYY, where X are letters and Y are numbers (e.g.: uid=bbb101234567,cn=Users,dc=mydomain,dc=com). In this case it works just fine. 

But recently we had to add some special users whose uid are just numbers (e.g.: uid=101234567,cn=Users,dc=mydomain,dc=com). In that case, the LDAP search in the ovirt manager will try to find the user and return no results, although the user indeed exists.

How reproducible:
Always if the uid is in only-numbers format.

Steps to Reproduce:
1. Go to tab 'Permissions'
2. Click on 'Add'
3. Select the base DN, and enter an uid formed of numbers to be added (for example 101234567) in the search box
4) Click on 'GO'

Actual results:
No result is returned, although the user exists in the LDAP database.

Expected results:
The existing user.
Comment 1 Alon Bar-Lev 2015-09-24 10:29:03 EDT
Please attach debug log[1] that includes a search attempt for such user.

[1] https://gerrit.ovirt.org/gitweb?p=ovirt-engine-extension-aaa-ldap.git;a=blob;f=README;hb=ovirt-engine-extension-aaa-ldap-1.0#l377
Comment 2 nicolas 2015-09-24 10:44 EDT
Created attachment 1076576 [details]
Trace log from a LDAP search
Comment 3 Alon Bar-Lev 2015-09-24 11:06:24 EDT
2015-09-24 15:38:48,928 DEBUG [org.ovirt.engineextensions.aaa.ldap.Framework] (ajp--127.0.0.1-8702-7) SearchRequest: SearchRequest(baseDN='cn=Users,dc=mydomain,dc=com', scope=SUB, deref=ALWAYS, sizeLimit=0, timeLimit=0, filter='&(objectClass=posixAccount)(uid=*)(|(givenName=44444444)(sn=44444444)(displayName=44444444)(uid=44444444))', attrs={entryUUID, uid, displayName, department, givenName, sn, title, mail}, controls={SimplePagedResultsControl(pageSize=500, isCritical=false)})
2015-09-24 15:38:50,840 DEBUG [org.ovirt.engineextensions.aaa.ldap.Framework] (ajp--127.0.0.1-8702-7) SearchResult: SearchResult(resultCode=0 (success), messageID=2, entriesReturned=0, referencesReturned=0, responseControls={SimplePagedResultsControl(pageSize=0, isCritical=false)})

please try this search manually using ldapsearch, this query looks ok and no results.

ldapsearch -H ldap://xxx -x -D ... -b 'cn=Users,dc=mydomain,dc=com' '(&(objectClass=posixAccount)(uid=*)(|(givenName=44444444)(sn=44444444)(displayName=44444444)(uid=44444444)))' entryUUID uid displayName department givenName sn title mail
Comment 4 nicolas 2015-09-24 11:29:05 EDT
Got it. Seems these special accounts don't have the 'objectClass=posixAccount' attribute yet, so indeed this isn't a bug.

However, is there a way to modify the filter that is applied to LDAP searches currently?
Comment 5 Alon Bar-Lev 2015-09-24 11:33:51 EDT
(In reply to nicolas from comment #4)
> Got it. Seems these special accounts don't have the
> 'objectClass=posixAccount' attribute yet, so indeed this isn't a bug.
> 
> However, is there a way to modify the filter that is applied to LDAP
> searches currently?

technically, yes... but then you violate rfc2307, most probably other attributes will be missing.
Comment 6 nicolas 2015-09-24 13:26:58 EDT
Ok, we'll better make sure these people have a posixAccount instead, as the RFC says. As far as I'm concerned, you can close the report if you want. Thanks!

Note You need to log in before you can comment on or make changes to this bug.