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