[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Substring Indexes on userPassword Attribute



On Mon, Jun 03, 2013 at 09:53:30AM -0700, Tim Gustafson wrote:

> At the very least, this ought to be an option. I can see not making a
> search index on userPassword by default, but as a system administrator
> I ought to be able to make that decision for myself. I don't need a
> person who has absolutely no context about my situation telling me
> that I can't use my copy of the software to do something I want to do
> with my data.

I can sympathise with that, though I would point out that allowing
indexes on userPassword would make an attack through the LDAP
protocol rather easier.

> Also, why are there some other things that can't be searched via
> substring (like homeDirectory)? What if I want to know which users are
> using bash because we're thinking about upgrading it and want to
> notify those users? Or what if I want to know which users are using
> /usr/local/bin/bash instead of /bin/bash so that I can update the
> database to be consistent?

In a word, 'history'. It all comes down to the schema, and the schema
evolved over time without ever really getting cleaned up and
rationalised. Taking userPassword as an example:

attributetype ( 2.5.4.35 NAME 'userPassword'
       DESC 'RFC2256/2307: password of user'
       EQUALITY octetStringMatch
       SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )

This actually goes right back to X.500(1988). The schema says that
you can do exact matches but no other sort. Worse still, it
completely ducks the character-set encoding issue.

Things like homedir and login shell come from RFC2307 and you get a
similar result:

attributetype ( 1.3.6.1.1.1.1.3 NAME 'homeDirectory'
        DESC 'The absolute path to the home directory'
        EQUALITY caseExactIA5Match
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

attributetype ( 1.3.6.1.1.1.1.4 NAME 'loginShell'
        DESC 'The path to the login shell'
        EQUALITY caseExactIA5Match
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

Even 2307bis does not give you substring search, though if you make a
case for it the authors might consider adding it...

Having said that, you still might be able to do substring searches on
some of these attributes by using 'matching rule assertion' rather
than 'attribute-value assertion' forms - see RFC4515.

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------