EAP-PEAP (mschapv2) & ssid restriction

[Phil Mayers]

Sergey Velikanov wrote:
> Hi
> 
> I've implemented wi-fi access (EAP-PEAP with ms-chap v2), it works fine, 
> now I want that users from one ssid
> could not connect to another ssid, my AP can include this infrmation in 
> Access-Request packet
> 
> rad_recv: Access-Request packet from host 192.168.232.3:1645, id=215, 
> length=274
>         User-Name = "user1"
>         Framed-MTU = 1400
>         Called-Station-Id = "0013.1a4b.ae50"
>         Calling-Station-Id = "0002.2d37.249f"
>         Cisco-AVPair = "ssid=is_client"
> 
> in my raddb/users I've changed
> 
> user1              User-Password == "123456"
> to
> user1           Cisco-AVPair =~ "ssid=is_client",       User-Password == 
> "123456"

This should be:

user1 Cisco-AVPair =~ "ssid=is_client", User-Password := "123456"

Note := instead of ==, though I think FreeRadius fixes that for you. 
Anyway, you then say:

> 
> it works fine with EAP-TLS, but it fails with EAP-PEAP (it uses mschap),
> 
> 
>   rad_check_password:  Found Auth-Type EAP
> auth: type "EAP"
>   Processing the authenticate section of radiusd.conf
> modcall: entering group authenticate for request 18
>   rlm_eap: Request found, released from the list
>   rlm_eap: EAP/mschapv2
>   rlm_eap: processing type mschapv2
>   Processing the authenticate section of radiusd.conf
> modcall: entering group Auth-Type for request 18
>   rlm_mschap: No User-Password configured.  Cannot create LM-Password.
>   rlm_mschap: No User-Password configured.  Cannot create NT-Password.
>   rlm_mschap: Told to do MS-CHAPv2 for user1 with NT-Password
>   rlm_mschap: FAILED: No NT/LM-Password.  Cannot perform authentication.
>   rlm_mschap: FAILED: MS-CHAP2-Response is incorrect
> 
> It seems that rlm_mschap do not include Cisco-AVPair = "ssid=is_client" 
> in its auth request
> 
> How can I solve this situation?
> 

You haven't put enough of the debug log to be certain, but that sounds 
like a reasonable supposition:

try:

eap {
  peap {
    copy_request_to_tunnel = yes
    # other things here
  }
}


PEAP (and in fact TTLS) make a "fake" Radius request from the inner auth 
(e.g. MSCHAP) proxied to 127.0.0.1. That request by default only has a 
small number of AVPs. The copy_request_to_tunnel tells FreeRadius to 
copy the AVPs from the original to the new request.