LDAP (POSIX attibutes) password expiry
Phil Mayers
p.mayers at imperial.ac.uk
Tue Mar 6 10:29:41 CET 2012
On 03/06/2012 02:10 AM, up at 3.am wrote:
>> On 28/02/12 21:16, up at 3.am wrote:
>
>>> However, we just noticed that password expiry isn't working. I suspect this is
> because we are still using all the original POSIX attributes and none of them look
>>> like good for mapping to the ones supplied by FreeRADIUS. I see: checkItem
> Expiration radiusExpiration Our LDAP attributes use the
> following POSIX attributes to determine expiry: shadowMax: 90
>>> shadowLastChange: 15215
>>
>> Other replies should have convinced you that there's no built-in support for
> this. You will need to either:
>>
>> 1. Arrange for a FreeRADIUS-ready "radiusExpiration" attribute to be
>> set in LDAP alongside the POSIX/shadow schemas
>>
>> 2. Synthesize an Expiration attribute, or otherwise locally check the
>> POSIX/shadow attributes.
>>
>>
>> One way you might accomplish the 2nd is as follows:
>>
>> == Create some local RADIUS attributes for the shadow values ==
>>
>> /etc/raddb/dictionary:
>>
>> ATTRIBUTE Shadow-Max-Age 3000 integer
>> ATTRIBUTE Shadow-Last-Change 3001 integer
>> ATTRIBUTE Shadow-Expires 3002 integer
>> ATTRIBUTE Shadow-Current 3003 integer
>>
>> /etc/raddb/ldap.attrmap:
>>
>> checkItem Shadow-Max-Age shadowMax
>> checkItem Shadow-Last-Change shadowLastChange
>>
>> == Read these attributes from LDAP, then perform some maths ==
>>
>> /etc/raddb/sites-enabled/<server>:
>>
>> authorize {
>> ...
>> ldap
>> update control {
>> Shadow-Expires := "%{expr:%{control:Shadow-Last-Change} +
>> %{control:Shadow-Max-Age}}"
>> Shadow-Current := "%{expr:%l / 86400}"
>> }
>> if (control:Shadow-Current> control:Shadow-Expires) {
>> reject
>> }
>> ...
>> }
>>
>> Hopefully it's clear what this does, but basically:
>>
>> 1. Pulls last-change& max-age from LDAP
>> 2. Adds them together, to get expiry (in days since epoch)
>> 3. Divides %l (epoch) by 86400 to get today, in days since epoch 4. Compares
> them
>> -
>
> It looks to me like it should do all of those things swimmingly...however, I am
> running into an issue that looks like it might be because we run redundant LDAP
> servers. I put your 'update control' here, in the authorize :
>
> redundant LDAP{
> ldap1
> ldap2
> update control {<ETC>
> }
> }
Ok, so do:
redundant {
ldap1
ldap2
}
update control {
..
}
More information about the Freeradius-Users
mailing list