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