Configurando o RADIUS + LDAP para WPA2 no Ubuntu

Estou configurando uma rede sem fio para ~ 150 usuários. Em resumo, estou procurando um guia para configurar o servidor RADIUS para autenticar o WPA2 em um LDAP. No Ubuntu.

• Eu tenho um LDAP funcional, mas como ele não está em uso de produção, ele pode ser facilmente adaptado a quaisquer alterações que este projeto possa exigir.
• Eu estive olhando o FreeRADIUS, mas qualquer servidor RADIUS funcionará.
• Temos uma rede física separada apenas para WiFi, por isso não há muitas preocupações com a segurança nessa frente.
• Nossos APs são coisas empresariais de baixo custo da HP - eles parecem suportar tudo o que você pode imaginar.
• Todo o Ubuntu Server, baby!

E as más notícias:

• Agora, alguém com menos conhecimento que eu acabará assumindo a administração, de modo que a configuração deve ser o mais "trivial" possível.
• Até o momento, nossa configuração é baseada apenas no software dos repositórios Ubuntu, com exceção do aplicativo Web de administração LDAP e de alguns pequenos scripts especiais. Portanto, "não é possível buscar o pacote X, untar, ./configure"-coisas, se possível.

ATUALIZAÇÃO 18-08-2009:

Embora eu tenha encontrado vários recursos úteis, há um sério obstáculo:

Ignoring EAP-Type/tls because we do not have OpenSSL support.
Ignoring EAP-Type/ttls because we do not have OpenSSL support.
Ignoring EAP-Type/peap because we do not have OpenSSL support.

Basicamente, a versão Ubuntu do FreeRADIUS não suporta SSL ( bug 183840 ), o que torna inúteis todos os tipos de EAP seguros. Vadio.

Mas alguma documentação útil para qualquer pessoa interessada:

• http://vuksan.com/linux/dot1x/802-1x-LDAP.html
• http://tldp.org/HOWTO/html_single/8021X-HOWTO/#confradius

ATUALIZAÇÃO 19-08-2009:

Acabei compilando meu próprio pacote FreeRADIUS ontem à noite - há uma receita muito boa em http://www.linuxinsight.com/building-debian-freeradius-package-with-eap-tls-ttls-peap-support.html (consulte os comentários à postagem para obter instruções atualizadas).

Eu recebi um certificado em http://CACert.org (você provavelmente deve obter um certificado "real", se possível)

Então segui as instruções em http://vuksan.com/linux/dot1x/802-1x-LDAP.html . Isso está relacionado a http://tldp.org/HOWTO/html_single/8021X-HOWTO/ , que é uma leitura muito útil se você quiser saber como funciona a segurança do Wi-Fi.

ATUALIZAÇÃO 27-08-2009:

Depois de seguir o guia acima, consegui que o FreeRADIUS conversasse com o LDAP:

Eu criei um usuário de teste no LDAP, com a senha mr2Yx36M- isso fornece uma entrada LDAP aproximadamente de:

uid: testuser
sambaLMPassword: CF3D6F8A92967E0FE72C57EF50F76A05
sambaNTPassword: DA44187ECA97B7C14A22F29F52BEBD90
userPassword: {SSHA}Z0SwaKO5tuGxgxtceRDjiDGFy6bRL6ja

Ao usar radtest, eu posso conectar bem:

> radtest testuser "mr2Yx36N" sbhr.dk 0 radius-private-password
Sending Access-Request of id 215 to 130.225.235.6 port 1812
    User-Name = "msiebuhr"
    User-Password = "mr2Yx36N"
    NAS-IP-Address = 127.0.1.1
    NAS-Port = 0
rad_recv: Access-Accept packet from host 130.225.235.6 port 1812, id=215, length=20
> 

Mas quando eu tento pelo AP, ele não voa - enquanto confirma que descobre as senhas NT e LM:

...
rlm_ldap: sambaNTPassword -> NT-Password == 0x4441343431383745434139374237433134413232463239463532424542443930
rlm_ldap: sambaLMPassword -> LM-Password == 0x4346334436463841393239363745304645373243353745463530463736413035
[ldap] looking for reply items in directory...
WARNING: No "known good" password was found in LDAP.  Are you sure that the user is configured correctly?
[ldap] user testuser authorized to use remote access
rlm_ldap: ldap_release_conn: Release Id: 0
++[ldap] returns ok
++[expiration] returns noop
++[logintime] returns noop
[pap] Normalizing NT-Password from hex encoding
[pap] Normalizing LM-Password from hex encoding
...

É claro que as senhas NT e LM diferem das anteriores, mas a mensagem [ldap] user testuser authorized to use remote access- e o usuário é posteriormente rejeitado ...

Vou tentar responder à pergunta LDAP aqui.

Aqui está a resposta curta: certifique-se o ldapmódulo é removido da authenticateseção, e certifique-se o mschapmódulo está presente tanto na authorizeea authenticateseção. E apenas ignore a senha 'Não conhecida ".

E agora aqui está a (muito) longa resposta.

Como o módulo ldap funciona?

Quando você ativa o ldapmódulo na authorizeseção, é isso que faz quando um pacote RADIUS é recebido pelo FreeRADIUS:

1. ele tenta se conectar ao servidor LDAP (como usuário convidado ou usando a identidade fornecida, se houver um configurado ldap.conf)
2. ele procura a entrada de DN do usuário usando o filtro sob o DN base (configurado em ldap.conf).
3. busca todos os atributos LDAP nos quais está configurado ldap.attrmape os converte em atributos RADIUS.
4. ele adiciona esses atributos à lista de itens de verificação do pacote RADIUS.

Quando você ativa o ldapmódulo na authenticateseção, é isso que o FreeRADIUS faz:

1. ele tenta se conectar ao servidor LDAP como usuário .
2. se ele puder se vincular, será uma autenticação bem-sucedida e um Radius-Acceptpacote será enviado de volta ao cliente; caso contrário, será uma falha que levará a um Radius-Rejectpacote.

Então, como posso configurar o FreeRADIUS para fazer o PEAP / MS-CHAP-v2 funcionar com 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 recebido. Esse é apenas o caso quando 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 ao TTLS / PAP, é necessário que eles instalem um software suplicante TTLS, o que raramente é uma opção. Na maioria das vezes, ao implantar o WiFi com segurança 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 ldapmódulo da authenticateseção e, na verdade, você deve: vincular, pois o usuário não funcionará.

Se o seu teste funcionar quando você o usar radtest, provavelmente significa que o ldapmódulo está ativado na authenticateseção: ele tentará vincular-se como usuário e, como o radtest usa a autenticação PAP, será bem-sucedido. Mas falhará se você tentar se conectar através do ponto de acesso, pois está usando o PEAP / MS-CHAP-v2.

O que você deve fazer é remover o ldapmódulo da authenticateseção, e certifique-se de ativar o mschapmódulo, tanto na authorizeea authenticateseção. O que acontecerá é que o mschapmódulo cuidará da autenticação usando o NT-Passwordatributo que é recuperado do servidor LDAP durante a authorizefase.

Aqui está a sites-enabled/defaultaparência do seu arquivo (sem todos os comentários):

    ...
    authorize {
        preprocess
        suffix
        eap {
            ok = return
        }
        expiration
        logintime
    }
    authenticate {
        eap
    }
    ...

E aqui está a sites-enabled/inner-tunnelaparência do seu arquivo:

    ...
    authorize {
        mschap
        suffix
        update control {
               Proxy-To-Realm := LOCAL
        }
        eap {
            ok = return
        }
        ldap
        expiration
        logintime
    }
    authenticate {
        Auth-Type MS-CHAP {
            mschap
        }
        eap
    }
    ...

E o aviso 'Nenhuma senha "conhecida como" boa ""?

Bem, você pode ignorá-lo com segurança. Está lá porque o ldapmódulo não pôde encontrar um UserPasswordatributo ao buscar os detalhes do usuário no servidor LDAP durante a authorizefase. No seu caso, você tem o NT-Passwordatributo, e isso é perfeitamente adequado para PEAP/MS-CHAP-v2autenticação.

Acho que o aviso existe porque, quando o ldapmódulo foi projetado, PEAP/MS-CHAP-v2ainda não existia, a única coisa que parecia fazer sentido na época era recuperar o atributo UserPassword do servidor LDAP, para usar PAP, CHAP, EAP / MD5 ou esses métodos de autenticação.

Vou tentar responder à pergunta do OpenSSL aqui: a resposta curta é usar o FreeRADIUS 2.1.8 ou superior, que inclui o OpenSSL . Está disponível nos backports Ubuntu Lucid e Debian Lenny (e provavelmente acabará também nos backports Ubuntu Karmic).

Aqui está a resposta longa:

Infelizmente, a licença OpenSSL costumava ser (um pouco) incompatível com a licença FreeRADIUS. Portanto, o pessoal do Ubuntu optou por fornecer um binário FreeRADIUS não vinculado ao OpenSSL. Se você queria EAP / TLS, PEAP ou TTLS, precisava obter as fontes e compilá-las com a --with-opensslopção (como explica a receita usada).

Mas, recentemente, o problema de licenciamento foi corrigido . O FreeRADIUS versões 2.1.8 ou superior pode ser compilado e distribuído com o OpenSSL. A má notícia é que a distribuição estável mais recente do Ubuntu (Karmic Koala) inclui apenas o FreeRADIUS 2.1.0, sem o OpenSSL (o mesmo vale para o Debian, pois o Lenny contém apenas o FreeRADIUS 2.0.4). Eu verifiquei o Karmic-backports, mas parece que o FreeRADIUS 2.1.8 ou superior ainda não foi carregado lá (ainda pode ser adicionado em breve, confira aqui)) Portanto, por enquanto, você deve mudar para o Ubuntu Lucid (que inclui o FreeRADIUS 2.1.8) ou seguir a compilação. Para usuários do Debian, as coisas são um pouco melhores: os backports Lenny incluem o FreeRADIUS 2.1.8. Portanto, se você deseja algo muito estável e fácil de instalar e manter, sugiro que implante um servidor com o Debian Lenny e instale o pacote FreeRADIUS com backport (também oferece a possibilidade de escrever módulos python gratuitamente, sem precisar recompilar com todos os módulos experimentais).

Eu recebi um certificado em http://CACert.org (você provavelmente deve obter um certificado "real", se possível)

Há uma "pegadinha" com certificados "reais" (em oposição aos certificados autoassinados).

Eu usei um assinado por Thawte. Funciona bem, e os usuários veem um belo certificado "válido" chamado algo como www.my-web-site.com. Quando o usuário aceita o certificado, seu computador realmente entende que todos os certificados emitidos pela mesma autoridade de certificação devem ser confiáveis (eu testei isso com o Windows Vista e o MacOSX Snow Leopard)! Portanto, no meu caso, se um hacker possui um certificado para, digamos, www.some-other-web-site.comtambém assinado por Thawte, ele pode executar um ataque de intermediário com facilidade, sem que nenhum aviso seja exibido no computador do usuário!

A solução para isso está profundamente na configuração de rede do computador do usuário, para especificar especificamente que apenas "www.my-web-site.com" deve ser confiável. Leva apenas um minuto, mas a maioria dos usuários não sabe onde configurá-lo, a menos que você dê a eles um procedimento claro e verifique se todos os usuários o seguem. Ainda uso certificados "válidos", mas, francamente, é decepcionante ver que o Windows e o MacOSX compartilham esse "bug": confiar na Autoridade de Certificação em vez do certificado específico. Ai ...

De acordo com o relatório de erros, uma simples reconstrução do FreeRADIUS deve corrigir o problema de suporte do OpenSSH. Só precisa ser feito uma vez.

Não sei ao certo qual facilidade de administração tem a ver com a instalação. Freqüentemente, quanto mais envolvida e detalhada a instalação, mais fácil é administrar, porque a instalação abrangeu todas as bases. Você quer dizer que a configuração também deve ser descartada em outros servidores facilmente? Quantas LANs sem fio você está configurando?

Uma vez configurada, a Administração deve se limitar às inclusões, exclusões e modificações do usuário LDAP. Isso deve ser fácil o suficiente para script com ldapmodify (et al) ou encontrar um front end gráfico LDAP decente e documentar os processos com capturas de tela.

Eu tive o mesmo problema. Eu tive que baixar as fontes RADIUS e compilá-las eu mesmo.

Você pode usar o FreeRADIUS2 (com OpenSSL) + EAP-TLS + WPA2-Enterprice. Aqui está muito detalhado COMO FAZER . O Windows XP SP3 possui suporte nativo, assim como o Windows 7, Android 2.3, iPhone, Symbian. Mas eu não sei sobre a compatibilidade com o SLDAP em tal esquema.