Autenticação FreeRadius MSCHAP com falha do domínio

1

Eu tenho o servidor FreeRadius 2.0 com o AD como repositório de usuários. Autenticar usando o EAP-PEAP-MSCHAP2.Local é definido no proxy.conf. Autenticações funciona bem sem reino adicionado ao nome de usuário. Assim que eu autentico usando o nome de usuário com o domínio, ou seja, [email protected], a autenticação falha. O motivo da falha é claro, ele falha porque o módulo mschap do servidor radius cria um hash de desafio com o nome de usuário que inclui o domínio. Eu preciso do módulo mschap radius para criar o hash do nome de usuário separado, ou seja, que não inclui o domínio. Alguma ideia? Por favor, veja o log de depuração do raio abaixo:

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
    
por Gazel 14.03.2014 / 09:53

1 resposta

1

O problema foi que o servidor virtual de túnel interno não removeu o domínio. Para corrigi-lo eu especifiquei o comando suffix no túnel interno da seguinte forma:

server inner-tunnel {
   authorize {
     ...
     suffix
     ...
   }
}
    
por 17.03.2014 / 10:46