Hi,
I have a need to find out how many of my users are using different password hashing methods, so I went and tried to do this search:
ldapsearch -D uid=tjg,ou=People,dc=com -W -b ou=People,dc=com 'userPassword={SHA}*'
But that didn't return anything. So I figured maybe I needed to create a substr index on that attribute. When I did that, slapindex returned:
slapd.conf: line 82: substr index of attribute "userPassword" disallowed
Why is that? How can I do a search that would tell me which of my users is using an SHA-hashed password?
--
Tim Gustafson tjg@ucsc.edu 831-459-5354 Baskin Engineering, Room 313A
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
And quite right too! You really don't want to make it any easier for an attacker to search for weak passwords.
*sigh*
I dislike misguided attempts at making things harder for attackers. If an attacker already has access to your userPassword field, then they can do exactly the same procedure that you proposed I do to extract that information. This sort of "security feature" doesn't make it substantively harder for attackers. It makes it irritating for systems administrators. Yes, I *could* write a script to do what you propose. But, I have a database engine that I ought to be able to query to give me the information I need, and I don't want to have to write a script every time I need to query information from a handful of special attributes while not having to do so to search by last name or whatever.
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.
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?
--
Tim Gustafson tjg@ucsc.edu 831-459-5354 Baskin Engineering, Room 313A
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
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?
--
Tim Gustafson tjg@ucsc.edu 831-459-5354 Baskin Engineering, Room 313A
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.
On Tue, Jun 04, 2013 at 08:21:56AM -0500, Dan White wrote:
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.
It would probably defeat the object of using LDAP too! As far as I know, OpenLDAP will only authenticate against the userPassword attribute (unless you write an overlay to do something different of course).
Andrew
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
Dan White wrote:
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.
No, 'userPassword' is defined during compile time in schema_prep.c
Ciao, Michael.
openldap-technical@openldap.org
-
Andrew Findlay -
Dan White -
Michael Ströder -
Tim Gustafson