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@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@freeradius.org> 08.09.2015 11:48 >>>
On 8 Sep 2015, at 04:09, Anja Ruckdaeschel <Anja.Ruckdaeschel@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@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