Vou tentar responder a questão do LDAP aqui.
Veja a resposta resumida: verifique se o módulo ldap foi removido da seção authenticate e certifique-se de que o módulo mschap esteja presente na seção authorize e authenticate . E apenas ignore a "senha" "boa não conhecida".
E agora aqui está a resposta (muito) longa.
Como funciona o módulo ldap?
Quando você ativa o módulo ldap na seção authorize , isso é o que acontece quando um pacote RADIUS é recebido pelo FreeRADIUS:
- ele tenta ligar-se ao servidor LDAP (como um usuário convidado ou usando a identidade fornecida, se houver um configurado em
ldap.conf) - ele procura a entrada DN do usuário usando o filtro sob o DN base (configurado em
ldap.conf). - ele busca todos os atributos LDAP que pode obter entre aqueles configurados em
ldap.attrmape os converte em atributos RADIUS. - adiciona esses atributos à lista de itens de verificação do pacote RADIUS.
Quando você ativa o módulo ldap na seção authenticate , isso é o que o FreeRADIUS faz:
- ele tenta se ligar ao servidor LDAP como o usuário .
- se puder ser vinculado, será uma autenticação bem-sucedida e um pacote
Radius-Acceptserá enviado de volta ao cliente ou, então, será uma falha, levando a um pacoteRadius-Reject.
Então, como eu posso configurar o FreeRADIUS para fazer o PEAP / MS-CHAP-v2 funcionar com o LDAP?
O ponto importante aqui é que a ligação como usuário só funcionará se o servidor FreeRADIUS puder recuperar a senha de texto não criptografado do usuário do pacote RADIUS que recebeu. Este é apenas o caso quando os métodos de autenticação PAP ou TTLS / PAP são usados (e possivelmente também EAP / GTC). Somente o método TTLS / PAP é realmente seguro e não está disponível por padrão no Windows. Se você deseja que seus usuários se conectem com o TTLS / PAP, é necessário que eles instalem um software de solicitante TTLS, o que raramente é uma opção. Na maioria das vezes, ao implantar o WiFi com a segurança do WPA Enterprise, o PEAP / MS-CHAP-v2 é a única opção razoável.
Portanto, a linha inferior é: a menos que você esteja usando PAP ou TTLS / PAP, você pode remover com segurança o módulo ldap da seção authenticate e, na verdade, você deve: ligação como o usuário não funcionará. / p>
Se o seu teste funcionar quando você usa radtest , provavelmente significa que o módulo ldap está ativado na seção authenticate : ele tentará se ligar como usuário e, como o radtest usa a autenticação PAP, ele será ter sucesso. Mas ele falhará se você tentar se conectar através do ponto de acesso, já que você está usando o PEAP / MS-CHAP-v2.
O que você deve fazer é remover o módulo ldap da seção authenticate e certificar-se de ativar o módulo mschap na seção authorize e authenticate . O que acontecerá é que o módulo mschap cuidará da autenticação usando o atributo NT-Password que é recuperado do servidor LDAP durante a fase authorize .
Aqui está como seu arquivo sites-enabled/default deve ficar (sem todos os comentários):
...
authorize {
preprocess
suffix
eap {
ok = return
}
expiration
logintime
}
authenticate {
eap
}
...
E aqui está como seu arquivo sites-enabled/inner-tunnel deve ser:
...
authorize {
mschap
suffix
update control {
Proxy-To-Realm := LOCAL
}
eap {
ok = return
}
ldap
expiration
logintime
}
authenticate {
Auth-Type MS-CHAP {
mschap
}
eap
}
...
E quanto ao aviso "Não" de "senha" válida?
Bem, você pode seguramente ignorá-lo. Ele está lá porque o módulo ldap não encontrou um atributo UserPassword quando buscou os detalhes do usuário do servidor LDAP durante a fase authorize . No seu caso, você tem o atributo NT-Password , e isso é perfeitamente aceitável para a autenticação PEAP/MS-CHAP-v2 .
Eu acho que o aviso existe porque quando o módulo ldap foi projetado, PEAP/MS-CHAP-v2 ainda não existia, então a única coisa que parecia fazer sentido no momento era recuperar o atributo UserPassword do servidor LDAP, em para usar o PAP, CHAP, EAP / MD5 ou tais métodos de autenticação.