LDAP (POSIX attibutes) password expiry

Fajar A. Nugraha list at fajar.net
Wed Feb 29 04:46:18 CET 2012


On Wed, Feb 29, 2012 at 8:37 AM,  <up at 3.am> wrote:
>> On Wed, Feb 29, 2012 at 4:16 AM,  <up at 3.am> wrote:
>>> Our LDAP attributes use the following POSIX attributes to determine expiry:
>>>
>>> shadowMax: 90
>>> shadowLastChange: 15215
>>>
>>> With the first being the maximum age of the password and the second being the
>>> number of days since the Epoch.  I will post the obligatory debug output below
>>> (with sensitive or irrelevant stuff snipped out) for a successful authentication
>>> for an expired password that shouldn't have succeeded.  If anybody has an idea
>>> how
>>> to fix this with the minimal of messing around with our LDAP config itself, I'd
>>> greatly appreciate it...or, if that's unrealistic, what should be done.  TIA!
>>
>> IIRC the Expiration attribute requires the format of "01 Jan 2011
>> 01:00:00" (or something like that, other format might work, test it
>> first). From the two LDAP attributes, you should be able to process
>> them and present it as a new attribute.
>>
>> I see no easy way to do that without additional module though. You
>> COULD use something like this on ldap.attrmap:
>>
>> checkItem       Tmp-Integer-0                      shadowMax
>> checkItem       Tmp-Integer-1                      shadowLastChange
>>
>> ... then convert it to expiration with rlm_perl/rlm_sql/whatever. If
>> you already have a mysql instance (e.g. for accounting), you could
>> probably use it to do the processing. Something like this (see
>> http://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html):
>>
>> update control {
>>   Expiration := "%{sql: SELECT FROM_UNIXTIME( ( %{Tmp-Integer-0} +
>> %{Tmp-Integer-1} ) * 86400, '%d %b %Y %H:%i%s' )}"
>> }
>
> Fajar, thanks for taking the time with this reply.  No, I'm not running MySQL for
> accounting...just the standard flat files on separate remote server and of course
> for auth, LDAP.  I'll have to take a look and see what rlm_perl can do for us.  I
> don't see a problem getting the attributes using perl (even if it just invokes
> shell commands), but how to process it back to FreeRADIUS without interfering with
> anything else.

Rlm_exec should be straight forward: http://wiki.freeradius.org/Rlm_exec
However it may incur performance penalty on busy sites.

Rlm_perl should be cleaner, basically you just work with %RAD_CHECK:
http://wiki.freeradius.org/Rlm_perl

rlm_sql is an easy one-liner solution. It should work even if you're
not usiing it for auth/acct, as long as it's instantiated (manually if
necessary, see radiusd.conf). But in your case it might be awkward as
you're basically only using it as a programming languange :P

-- 
Fajar




More information about the Freeradius-Users mailing list