Antw: Re: Trigger EDIR-Intruder Lockout in FR3
Anja Ruckdaeschel
Anja.Ruckdaeschel at rz.uni-regensburg.de
Tue Sep 8 17:00:00 CEST 2015
Hi Arran,
sorry, i forgot, that in FR2 I did this in inner-tunnel:
post-auth {
reply_log
#named bind as login-user to consume grace logins, check
expirations, etc.
ldap
Post-Auth-Type REJECT {
#was not entered
}
}
}
So, if that is AFTER authenticate you cannot disturb the bad login counter.
In FR3 I now tried the same, but always ended up with this in post-auth:
) ldap: EXPAND Authenticated at %S
Tue Sep 8 16:34:27 2015 : Debug: (8) ldap: --> Authenticated at 2015-09-08
16:34:27
Tue Sep 8 16:34:27 2015 : Debug: rlm_ldap (ldap): Reserved connection (1)
Tue Sep 8 16:34:27 2015 : Debug: (8) ldap: Using user DN from request
"cn=mycn,ou=myou,o=myo,c=de"
Tue Sep 8 16:34:27 2015 : Debug: (8) ldap: Modifying object with DN
"cn=mycn,ou=myou,o=myo,c=de"
Tue Sep 8 16:34:27 2015 : Debug: (8) ldap: Waiting for modify result...
Tue Sep 8 16:34:27 2015 : ERROR: (8) ldap: Failed modifying object:
Insufficient access. Check the identity and password configuration directiv
es
Tue Sep 8 16:34:27 2015 : ERROR: (8) ldap: (null)
Tue Sep 8 16:34:27 2015 : Debug: rlm_ldap (ldap): Released connection (1):
Tue Sep 8 16:34:27 2015 : Debug: (8) modsingle[post-auth]: returned
from ldap (rlm_ldap) for request 8
Tue Sep 8 16:34:27 2015 : Debug: (8) [ldap] = fail
Tue Sep 8 16:34:27 2015 : Debug: (8) } # post-auth = fail
Tue Sep 8 16:34:27 2015 : Debug: (8) Using Post-Auth-Type Reject
I wasn't aware of ldap.authorize and ldap.authenticate (I thought you meant
"some instance name").
Now I do:
ldap:
#DELE: edir_autz=yes
#no named bind happens after Universal Password Retrieval.
inner-tunnel (do a "good" password bind only if mschap is okay, else trigger
Bad Login Counter):
#does not need all this stuff anymore
Auth-Type MS-CHAP {
mschap
}
....
post-auth {
reply_log
#named bind as login-user to consume grace logins, check
expirations, etc.
ldap.authorize
Post-Auth-Type REJECT {
update request {
User-Password := 'junk'
}
#named bind with bad password to trigger bad
login counter
ldap.authenticate
}
}
and it works now. Is that the correct usage for FR3?
Thank you
Ciao Anja
>>> "Anja Ruckdaeschel" <Anja.Ruckdaeschel at rz.uni-regensburg.de> 08.09.2015
13:13 >>>
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
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
More information about the Freeradius-Users
mailing list