On Wed, Feb 29, 2012 at 8:37 AM, <u...@3.am> wrote: >> On Wed, Feb 29, 2012 at 4:16 AM, <u...@3.am> wrote: >>> Our LDAP attributes use the following POSIX attributes to determine expiry: >>> >>> shadowMax: 90 >>> shadowLastChange: 15215 >>> >>> With the first being the maximum age of the password and the second being >>> the >>> number of days since the Epoch. I will post the obligatory debug output >>> below >>> (with sensitive or irrelevant stuff snipped out) for a successful >>> authentication >>> for an expired password that shouldn't have succeeded. If anybody has an >>> idea >>> how >>> to fix this with the minimal of messing around with our LDAP config itself, >>> I'd >>> greatly appreciate it...or, if that's unrealistic, what should be done. >>> TIA! >> >> IIRC the Expiration attribute requires the format of "01 Jan 2011 >> 01:00:00" (or something like that, other format might work, test it >> first). From the two LDAP attributes, you should be able to process >> them and present it as a new attribute. >> >> I see no easy way to do that without additional module though. You >> COULD use something like this on ldap.attrmap: >> >> checkItem Tmp-Integer-0 shadowMax >> checkItem Tmp-Integer-1 shadowLastChange >> >> ... then convert it to expiration with rlm_perl/rlm_sql/whatever. If >> you already have a mysql instance (e.g. for accounting), you could >> probably use it to do the processing. Something like this (see >> http://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html): >> >> update control { >> Expiration := "%{sql: SELECT FROM_UNIXTIME( ( %{Tmp-Integer-0} + >> %{Tmp-Integer-1} ) * 86400, '%d %b %Y %H:%i%s' )}" >> } > > Fajar, thanks for taking the time with this reply. No, I'm not running MySQL > for > accounting...just the standard flat files on separate remote server and of > course > for auth, LDAP. I'll have to take a look and see what rlm_perl can do for > us. I > don't see a problem getting the attributes using perl (even if it just invokes > shell commands), but how to process it back to FreeRADIUS without interfering > with > anything else.
Rlm_exec should be straight forward: http://wiki.freeradius.org/Rlm_exec However it may incur performance penalty on busy sites. Rlm_perl should be cleaner, basically you just work with %RAD_CHECK: http://wiki.freeradius.org/Rlm_perl rlm_sql is an easy one-liner solution. It should work even if you're not usiing it for auth/acct, as long as it's instantiated (manually if necessary, see radiusd.conf). But in your case it might be awkward as you're basically only using it as a programming languange :P -- Fajar - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
