Antw: Re: Trigger EDIR-Intruder Lockout in FR3

Anja Ruckdaeschel Anja.Ruckdaeschel at
Tue Sep 8 13:13:36 CEST 2015

Hi Arran,

thank you. But the solution is not so simple:

In inner-tunnel authenticate I do (insce FR2) something similar you recommened
in your answerr:

Auth-Type MS-CHAP {
                 mschap {
                 	 ok = 1
                 	 reject = 1
                 if(ok) {
                 	update {
                 		&reply:My-Log-Message += "IT:MS-CHAP-PW MATCHED
/ "
                 elsif(reject) {
                        if (User-Name =~  /^(\.*)([a-zA-Z]{3}[0-9]{5})/ ) {
                        	update {
                        		&control:Auth-Type := LDAP
                        		&request:User-Password := "junk"
                        else {
		update {
			&reply:My-Log-Message += "IT:MS-CHAP-PW DID NOT MATCH
for %{Stripped-User-Name}/ "

It is in authenticate because in FR2 Post-Auth-Type REJECT in inner-tunnel was
not entered ,
and in FR3 calling the ldap-Module (main instance) in Post-Auth-Type REJECT
tries to modify the user's object via LDAP.

This mechanism is working in FR3 to produce a bad login. Fine.

But the real problem is, how edir Intruder Lockout works:
Say, we have a Bad Login Counter of 6, which means, the user has to login 6
times in a row to reach the state Intruder Lockout=True in eDir.

Since edir_autz=yes in FR3 now does a named Ldap bind with the login-user and
uses the retrieved cleartext-password to
check expiration and so on (see b,), there is always a login with a "good"
password, before the later "bad" password login is triggered.

So, the user logs in with a bad password (mschap fails), we first have a
"good" login (step b,), than a triggered bad login (step c,). -> Bad Login
Counter = 1
The next login does the same: Step b, sets the Bad Login Counter back to 0,
step c, sets it to 1 again.
You never reach a situation, where you have 6 bad logins in a row, although
the user gives a "bad password" 6 times in a row.

Setting edir_autz=yes to edir_autz=no works around this: The bad login count
can be incremented with every radius login.
But then you have the problem, that a user which for example has a good but
expired password and no grace logins remaning can get Access-Accept.

That is what I mean with "I only manage to get a and b OR a and c running."

In FR2 it seemed to me, that the User, who retrieved the Universal Password
did the checks of step b, (execpt for grace login consumation of course),

So, I´m searching a workaround to restore the behaviour of FR2 for step b,

Thank you.

Ciao Anja

>>> Arran Cudbard-Bell <a.cudbardb at> 08.09.2015 11:48 >>>

> On 8 Sep 2015, at 04:09, Anja Ruckdaeschel
<Anja.Ruckdaeschel at> wrote:
> Hi there,
> I wonder what is the designated way in FR 3.0.9 to trigger an
eDirectory-Intruder Lockout
> with edir_autz=yes in addition?
> I want to use
> a, universal password retrieval
> b, grace login consumation, account expire check, password expire check,
login time restrictions check, attribute checks, etc.
> c, intruder lockout trigger (I do a named ldap bind with the login-user with
a password which is bad, if mschap rejects)

I guess something like this:

post-auth {
	Post-Auth-Type REJECT {
		update request {
			User-Password := 'junk'

> in one radius config for PEAP/MSCHAPv2 with eDIR.
> So far, I only manage to get a and b OR a and c running.
> Perhaps you can give me a hint?
> Thank you for your time.
> Ciao Anja
> -
> List info/subscribe/unsubscribe? See 

Arran Cudbard-Bell <a.cudbardb at>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

More information about the Freeradius-Users mailing list