On 28/02/12 21:16, up@3.am wrote:
Hi:
We've been running various versions of FreeRadius for years, currently 2.1.10 in this application. A while ago, we switched from PAM (unix) auth to LDAP auth. Everything worked fine after the switch...POSIX attributes for group membership correctly allocated the right ippools, etc.
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