On Fri, May 31, 2013 at 10:13:12AM -0700, Tim Gustafson wrote:

slapd.conf: line 82: substr index of attribute "userPassword" disallowed

And quite right too! You really don't want to make it any easier for an attacker to search for weak passwords.

Why is that? How can I do a search that would tell me which of my users is using an SHA-hashed password?

You don't need to modify the Slapd setup for that: just work with an LDIF backup of the data (e.g. from slapcat). Use grep to extract the userPassword attributes. You will then need a script to convert the values from Base-64 encoding to text, and a regular expression to extract the encoding scheme from the front of the text string.

That will let you count the number of users for each scheme. (e.g. using sort and uniq).

If you really want to know which users use which scheme then replace grep with an LDIF parser and extract both userPassword and uid at the same time. The LDIF parser will take care of the Base-64 for you as well.

You should be able to do the whole job in less than 20 lines of Perl or Python.

Andrew

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

On 06/03/13 10:49 -0700, Tim Gustafson wrote:

...

This actually goes right back to X.500(1988). The schema says that you can do exact matches but no other sort.

Again, I'm fine with strict interpretations of the RFCs being applied *by default* but there should be some way for me to override those interpretations.

Why are these parts of the LDAP schema hard-coded? Is there no way to specify the entire schema in a configurable format so that I could change this behavior for just my installation if I deem it appropriate?

You could replace the objectclasses containing userPassword, homeDirectory, etc, with your own custom defined schema, along with your own userPassword definitions.

That would likely require a slapcat, edit, and slapadd of your database, but ultimately gives you more control of your data, and leaves you with portable data.

You could replace the objectclasses containing userPassword, homeDirectory, etc, with your own custom defined schema, along with your own userPassword definitions.

Actually, I don't believe you can. userPassword is marked as a "system" attribute in the core.schema file. It's actually commented out there. You can't modify it; it's included in the OpenLDAP server code itself.

--

Tim Gustafson tjg@ucsc.edu 831-459-5354 Baskin Engineering, Room 313A