> On 28/02/12 21:16, u...@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). - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html