LDAP (POSIX attibutes) password expiry

[up at 3.am]

> 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>
          }
        }

The above allows us to define two LDAP servers in radiusd.conf.

Debug shows this error:

/usr/etc/raddb/sites-enabled/default[76]: redundant sections cannot contain a
"update" statement
/usr/etc/raddb/sites-enabled/default[62]: Errors parsing authorize section.

I see in man unlang that "redundant" can only contain a list of modules.  If
that's the case, either these two things won't work together, or I am trying to
put it in the wrong place.  If I try to uncomment the "ldap" module further down
in the authorize section I get "Failed to load module "ldap" (can post entire
debug if necessary).