Antw: Re: Trigger EDIR-Intruder Lockout in FR3

[Anja Ruckdaeschel]

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


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 freeradius.org> 08.09.2015 11:48 >>>

> On 8 Sep 2015, at 04:09, Anja Ruckdaeschel
<Anja.Ruckdaeschel at rz.uni-regensburg.de> 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'
		}
		ldap.authrorize
	}
}

> 
> 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
http://www.freeradius.org/list/users.html 

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

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