Replying to myself - here comes a possible resolution for this 'EAP- Type restriction per user/group' thread: A possible solution is to restrict EAP-Type but by using a different operator (man 5 users): "EAP-Type += <method>" where method is one of <PEAP, EAP-TTLS> (instead of ":=" for tunneled methods ; for non tunneled methods I think both should be fine). I tested it: with a MySQL backend, a user configured as EAP-Type += PEAP could use PEAP-MSChapv2 but not TTLS-PAP, while a user configured EAP-Type += EAP-TTLS could use TTLS-PAP but not PEAP. rlm/ eap - freeradius correctly reported "client wants to ttls, while we require peap, rejecting the user" (or vice versa). Not sure it is the intended way, so I hope the behaviour won't change in the next release. But it works. Greetings and thanks artur On 23 Jul 2007, at 13:14, Artur Hecker wrote:
Hi
On 23 Jul 2007, at 11:21, Phil Mayers wrote:
On Mon, 2007-07-23 at 10:20 +0200, Artur Hecker wrote:
Hello
In the default configuration, if a User-Password is defined for a user, the user can be authenticated by all applicable authentication types. That is the sense and the beauty of the default configuration :-)
However, in a practical deployment, a serious security policy is likely to state the contrary: every user (or usergroup) should be authenticated by exactly one authentication method.
Why?
Surely a method is either secure (in which case you'd let people use it) or insecure (in which case you'd let no-one use it)?
I would consider our deployment "practical" (>20k users, almost 400 APs) and we don't care what method they use, as long as it's secure and generates keys.
As I said, it is the matter of security policy, I cannot discuss it, for it is not an opinion :-)
What you say does make sense to me, but on the other hand I still do not see why it should be possible to authenticate a user by more than one method. From what you are saying, one would conclude that only one method should be used for all users. But very often it depends on the security level of the user group and the trust you have in user capabilities (-> security policy...)
I can give you real-world examples, which will certainly lead to further discussions.
Case 1: To accelerate deployment, company A considers that PEAP- MSCHAPv2 should be used by all users not having a certificate. It had the advantage to work immediately (say against internal AD with NTLM or SQL, etc). However, user certificates are being issued over the time period - for the same user identity. The point thus is to prevent users who have obtained the certificates from keeping on using old style password auth.
Case 2: some "important users" still use TTLS-PAP but everybody should use PEAP-MSCHAP-v2. You cannot deactivate TTLS-PAP even if you consider it not good enough. You don't want others to use it though.
Case 3: different backends are available, each storing a part of users with password in clear and in hash forms. Needless to say, some users are stored in both... Wireless admins have no power on these. Thus, TTLS-PAP and PEAP-MSCHAPv2 are used interchangeably, in some times by the same user, even if you feel like TTLS-PAP is less secure.
And it goes on and on, even with EAP-MD5 in wired... Just don't take the examples literally. What I am saying is that, very often, such situations are linked to internal company processes, to compatibility concerns, etc., sometimes you cannot deactivate an authentication method for administrative reasons but you would like to restrain its use as far as possible, etc.
What is the "right" (recommended) way to do it? Could not find anything on that in Wiki. (Would be glad to add it, when finished).
Do you want to restrict everyone to a single EAP type, or different people/groups to different EAP types?
an EAP type per group and/or user.
Background: I used to restrict users by explicitly setting for them (their group) EAP-Type := something, according to the user profile. However, as of 1.1.6, my wireless PEAP(-MSCHAPv2) user authentication does not work anymore as before: the inner PEAP authentication fails with "cannot tunnel TLS in TLS", most probably since the authorize module (sql) sets EAP-Type := PEAP. It *may* be just me though.
Yeah, don't do that. Have something like:
authorize { preprocess eap files }
in "users":
# group "foo" must use PEAP DEFAULT My-Group == "foo", EAP-Type != PEAP, Auth-Type := Reject
# group "bar" must use TTLS DEFAULT My-Group == "bar", EAP-Type != TTLS, Auth-Type := Reject
That's my problem - I think this cannot work with tunneled methods.
I think that with this config the user will be rejected whenever the inner method has to check the password (the type is not PEAP -> Reject).
I'm not sure since this explicit reject does not work with an SQL backend. But I already tried the inverse logics "EAP-Type == PEAP" instead. SQL starts by saying "no matching entry in the database [...]", I guess since it does not find EAP-Type set to PEAP in the first request. In the given situation (PEAP by default), that's fine for the tunnel to start. It even finds the matching rows during the requests in between. But, as I said, it fails when it comes to the inner MSCHAPv2 check of the received response: it repeats "no matching entry in the database" and concludes "no User-Password" - because the type in the inner method is set to EAP-MSCHAPv2. I have no idea how to OR these two (EAP-Type == PEAP OR EAP-MSCHAPv2), but even that would not be satisfactory since it would allow to use brute EAP-MSCHAPv2 without a tunnel.
If I'm not mistaken, it would be nice to have two different attributes like EAP-Type and EAP-Inner-Type or something OR we need different SQL queries for the inner and the outer methods configurable... Am I wrong?
artur
My-Group might be populated using rlm_passwd, or you might use SQL- Group or LDAP-Group or whatever.
However, this only restricts the outer EAP type, *AND* relies on the outer ID being the same as the inner ID i.e. you get no anonymous outer ID.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/ users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/ users.html