FreeRadius MSCHAP Authentication With Realm Fails

Question

I have FreeRadius 2.0 server with AD as user store. Authenticating using EAP-PEAP-MSCHAP2.Local realm is defined in proxy.conf. Authentications works fine without realm added to the username. As soon as I authenticate using username with realm, i.e. [email protected], authentication fails. The reason for failure is clear, it fails because radius server mschap module creates challenge hash with username which includes realm. I need the radius mschap module to create hash from stripped username, i.e. which doesn't include the realm. Any ideas? Please see radius debug log below:

rad_recv: Access-Request packet from host 192.168.1.254 port 55769, id=138, length=376
    Service-Type = Framed-User
    Framed-MTU = 1400
    User-Name = "[email protected]"
    State = 0x3ce95d9d3fed44ec4019661d07f2a324
    NAS-Port-Id = "wlan1"
    NAS-Port-Type = Wireless-802.11
    Calling-Station-Id = "5C-3C-27-29-AE-0B"
    Called-Station-Id = "D4-CA-6D-A6-53-7B:eduroam test"
    EAP-Message = 0x020400d01980000000c61603010086100000820080791cc56766422be7f48414f5942dda519afd607aea2fae890f9236e8af61cf71c66f4f80a5d427672d7f949a3fa163b959f0f1957f382f533a3f9c23d576dafcb5d36ca04dc7d0002203513a23b9394b75cf98f241a6c585583593f6622829a39a736160f0f83b567fa7bbc253558191630071d1889827f6118f366040f69d8814030100010116030100307173492977a9f772a302c0ecb7d2612700f9433dce8e08ff0e74b84dbc62de5fe5a95921f364f8c68dd38484550022ae
    Message-Authenticator = 0x9a61469cb26792ebd980f294bd9a64c9
    NAS-Identifier = "MikroTik"
    NAS-IP-Address = 192.168.1.254
# Executing section authorize from file /etc/raddb/sites-enabled/default
+- entering group authorize {...}
++[preprocess] returns ok
[auth_log]  expand: /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d -> /var/log/radius/radacct/192.168.1.254/auth-detail-20140313
[auth_log] /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /var/log/radius/radacct/192.168.1.254/auth-detail-20140313
[auth_log]  expand: %t -> Thu Mar 13 16:17:17 2014
++[auth_log] returns ok
++[mschap] returns noop
[suffix] Looking up realm "contoso.local" for User-Name = "[email protected]"
[suffix] Found realm "contoso.local"
[suffix] Adding Stripped-User-Name = "user5"
[suffix] Adding Realm = "contoso.local"
[suffix] Authentication realm is LOCAL.
++[suffix] returns ok
[eap] EAP packet type response id 4 length 208
[eap] Continuing tunnel setup.
++[eap] returns ok
Found Auth-Type = EAP
# Executing group from file /etc/raddb/sites-enabled/default
+- entering group authenticate {...}
[eap] Request found, released from the list
[eap] EAP/peap
[eap] processing type peap
[peap] processing EAP-TLS
  TLS Length 198
[peap] Length Included
[peap] eaptls_verify returned 11 
[peap] <<< TLS 1.0 Handshake [length 0086], ClientKeyExchange  
[peap]     TLS_accept: SSLv3 read client key exchange A
[peap] <<< TLS 1.0 ChangeCipherSpec [length 0001]  
[peap] <<< TLS 1.0 Handshake [length 0010], Finished  
[peap]     TLS_accept: SSLv3 read finished A
[peap] >>> TLS 1.0 ChangeCipherSpec [length 0001]  
[peap]     TLS_accept: SSLv3 write change cipher spec A
[peap] >>> TLS 1.0 Handshake [length 0010], Finished  
[peap]     TLS_accept: SSLv3 write finished A
[peap]     TLS_accept: SSLv3 flush data
[peap]     (other): SSL negotiation finished successfully
SSL Connection Established 
[peap] eaptls_process returned 13 
[peap] EAPTLS_HANDLED

Solution

The problem was that inner-tunnel virtual server did not stripped the realm. To fix it I have specified suffix command in the inner-tunnel as follows:

server inner-tunnel {
   authorize {
     ...
     suffix
     ...
   }
}

Comments

[Gazel]

The problem was that inner-tunnel virtual server did not stripped the realm. To fix it I have specified suffix command in the inner-tunnel as follows: server inner-tunnel { authorize { ... suffix ... } }