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