Configurando o RADIUS + LDAP para WPA2 no Ubuntu

16

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:

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 ...

ubuntu openldap radius wpa Morten Siebuhr
fonte
As senhas NT e LM são armazenadas criptografadas, portanto, não é óbvio se elas diferem ou não. Você precisa determinar qual senha está sendo usada pelo ponto de acesso e, se estiver sendo passada de maneira clara, um MD5 está sendo passado em seu lugar ou ... outra coisa. Os clientes RADIUS podem usar qualquer número de atributos RADIUS para senha ou autenticação semelhante a senha. Além disso, tente preencher o atributo de expiração.
kmarsh

Respostas:

12

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.

MiniQuark
fonte
3

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 ...

MiniQuark
fonte
1

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.

kmarsh
fonte
Primeiro, você precisa recompilar o pacote toda vez que uma atualização é fornecida (inveja do pessoal do Gentoo aqui :)). Por outras partes, concordo plenamente - se a instalação cobrir todas as bases, meu sucessor terá menos trabalho a fazer (e menos hacks para fazer engenharia reversa).
Morten Siebuhr
0

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

Aaron C. de Bruyn
fonte
-1

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.

BBK
fonte