Campus Virtuais. CookBook para Instalação e Configuração do RADIATOR. Luís Guido FCCN

Transcrição

1 Campus Virtuais CookBook para Instalação e Configuração do RADIATOR Luís Guido FCCN Versão de Dezembro de 2003

2 Instalação e Configuração do RADIATOR Controlo de Versões Versão Data Status Alterações /Out/2003 Draft Primeiro Draft /Nov/2003 Draft /Dez/2003 Draft /Dez/2004 Draft Acrescentado mais um exemplo no tópico Parâmetros Adicionais Mais um cenário de configuração: Cenário 3: Atribuição de VLAN via RADIUS Acrescentada a descrição a cada um dos cenários de configuração. Corrigido os módulos de Perl referenciados para a instalação do RADIATOR (Perl Digest-MD para Perl Digest-MD5) Alterada a referência (*) da mesma página para o Perl Digest-MD4 necessária para autenticação MS-CHAP e MS-CHAPv2 O FreeRadius passa a ser o software utilizado nos Campus Virtual. O Radiator apresenta-se como uma alternativa comercial Actualização geral das configurações para os Proxy s Central e Local (retirar atributos considerados perigosos)

3 Introdução A rede e-u é destinada exclusivamente a utilizadores autorizados. Desta foram, um mecanismo de controlo de acesso à rede e-u é necessário. Em cada Campus deverá existir pelo menos um servidor de autenticação, que será responsável pela validação das credenciais apresentadas por cada utilizador que se pretenda ligar à rede e-u. Este documento trata O RADIATOR da Open System Consultants ( apresenta-se como uma alternativa comercial à solução FreeRadius, que foi a adoptada pelo projecto Campus Virtual. Este documento tem como objectivo fornecer um ponto de partida para a configuração do servidor de autenticação e accounting. Em primeiro lugar é descrita a forma de instalação do software para plataformas Unix onde são fornecidos links para informação adicional, para por exemplo instalar o software RADIATOR noutras plataformas ou obter mais informação acerca da instalação. Posteriormente é detalhada tanto quanto possível a configuração básica para permitir utilizar o RADIATOR como servidor de autenticação 802.1x (PEAP e TTLS). Na configuração são apresentados os dois modelos considerados possíveis de instalar nos Campus Virtuais: servidor único e hierarquia de servidores. Finalmente é disponibilizado um cenário de partida com os respectivos ficheiros de configuração.

4 1. Instalação O RADITATOR é compatível Unix, Windows e MAC. No entanto, neste documento a solução de instalação apresentada é baseada em Unix (Linux). O processo de instalação deverá ser compatível com outras versões de Unix. Para obter informações de como instalar o RADIATOR em plataformas não Unix consultar: Acerca das especificações do software: A configuração apresentada deverá ser compatível para todas as plataformas suportadas pelo RADIATOR. Antes de proceder à instalação do software RADIATOR deve ser verificada se a seguinte lista de requisitos (instale o software que não se encontre instalado no sistema): Pré-requisitos para instalação Unix: Perl 5 versão ou posterior Módulo de Perl Digest-MD5 versão 2.12 ou posterior Módulo de Perl Digest-MD4 (*) OpenSSL versão ou posterior (**) Módulo de Perl Net_SSLeay versão 0.22 ou posterior (**) Módulo de Perl Digest-HMAC versão 1.01 ou posterior (**) Módulo de Perl Digest-SHA1 versão 2.01 ou posterior (**) Dependendo do tipo de instalação, poderão ser necessários outros módulos de Perl adicionais (ex: LDAP; SQL; etc.) Consultar o local onde efectuou a aquisição do software RADIATOR para patches relevantes para a instalação. (*) Necessário para utilizar MS-CHAP ou MS-CHAPv2 (**) Requisitos para autenticação 802.1x Instalação do RADITATOR Após instalação do software adicional necessário para a instalação do RADIATOR, devem ser executados os comandos seguintes: 1. Descomprimir o software (Unix) a. Crie uma directoria para descomprimir / compilar o software b. Coloque o pacote de software na directoria. c. Corra o comando tar xzf Radiator-<versao>.tgz 2. Aplicar patches (caso existam patches relevantes para instalar): a. Verifique se os últimos patches / alerta de bugs são relevantes para a instalação que pretende

5 b. Coloque o(s) patche(s) na directoria raiz do software RADIATOR c. Mude para a directoria raiz do software RADIATOR.1 Correr o comando tar zxf <ficheiro_patche>.2 Repita o ponto anterior para cada um dos patches a aplicar 3. Compilar o RADIATOR a. Mude para a directoria raiz do software RADIATOR b. Corra os comandos.1 perl Makefile.pl.2 make test (deverão ter todos resultado ok ).3 efectuar os testes finais correr um servidor de testes com : perl radiusd -config_file goodies/simple.cfg numa outra janela executar: perl radpwtst -user fred -password fred ; o resultado deverá ser OK correr novamente com uma password errada perl radpwtst - user fred -password wrong ; o resultado deverá ser Rejected 4. Instalar o software RADIATOR a. Caso todos os testes tenham sido bem sucedidos, corra o comando make install ; o software RADIATOR será instalado no sistema: módulos de perl para o Radius na estrutura perl de sistema e os binários na directoria local de binários.

6 2. Configuração Para permitir a mobilidade entre campus universitários, é mandatório que todos os usernames utilizados sejam do tipo <utilizador>@<dominio_instituicao>. Ao utilizar o domínio da instituição; denominado por REALM; como parte integrante do username, o servidor RADIUS local sabe através do username, se deve ou não autenticar o utilizador localmente. Caso o domínio seja o seu, o utilizador é autenticado pelo RADIUS baseado nas credenciais apresentadas. Caso o utilizador apresente um domínio diferente do domínio local, o pedido de autenticação será encaminhado para o próximo servidor RADIUS da hierarquia (RADIUS Nacional por exemplo). Esta abordagem não invalida o servidor RADIUS fale com outros servidores RADIUS na hierarquia que não o Nacional. Existem essencialmente dois cenários possíveis nas Instituições: Servidor único na Instituição

7 Hierarquia de servidores na Instituição Por exemplo: uma Instituição tem dois polos próximos com dois REALM s distintos e cada um com um servidor RADIUS: O RADIUS do polo1 autentica o REALM polo1.instituição.pt ; O RADIUS do polo2 autentica o REALM polo2.instituição.pt Uma vez que é comum os alunos deslocarem-se entre polos, a instituição poderá ter interesse em que os servidores RADIUS comuniquem directamente entre si ou através de um proxy na instituição central e não via servidor RADIUS Nacional. Poderão inclusivamente ser definidos protocolos entre instituições para a implementação de cenários idênticos. Ficheiro de Configuração Formato dos comentários no ficheiro de configuração Os comentários são precedidos por um cardinal # que deverá ser o primeiro caracter não espaço na linha. Caso exista um cardinal após a declaração de qualquer parâmetro, o cardinal é tido como literal e fará parte da própria configuração do parâmetro. Configuração genérica do RADIATOR # A configura ªo seguinte define os par metros gerais do RADIATOR, # tais como portos para autentica ªo e accounting; localiza ªo do # log, etc AuthPort 1812 AcctPort 1813 LogDir /var/log/radius DbDir /etc/radius DictionaryFile %D/dictionary,%D/dictionary.ascend PidFile /var/run/radiusd.pid Trace 0 Logging O RADIATOR disponibiliza um vasto leque de possibilidades para os mais variados cenários de logging. Desde log consolidado num único ficheiro; logging por handler (Handler; Realm; User-Name; Método EAP; etc.); log para um servidor SQL; log para o syslog; etc. No caso descrito apenas se considera a opção utilizada por omissão no RADIATOR (ficheiro com nome logfile colocado na LogDir configurada). Para mais informações acerca das diversas possibilidades de logging consultar: A opção Trace acima de 3 é desaconselhada em ambientes de produção por implicar uma carga significativa no servidor, bem como efectuar logging de informação apenas relevante para debugging. Para mais informações acerca do nível de trace consultar e outros parâmetros globais:

8 Dicionários Alguns Access Points enviam parâmetros (atributos) para os servidores de RADIUS (normalmente em records de accounting) que não fazem parte do dicionário standard, denominados por vendor specific attributes. Se esse for o caso do(s) AP s do campus, podem ser carregados outros dicionários além dos fornecidos pelo RADIATOR. Eis um exemplo de um dicionário criado especificamente para um access point que envia vendor specific attributes : No ficheiro de log surgiram linhas com a seguinte informação: <date>: ERR: Attribute number 1 (vendor 14122) is not defined in your dictionary <date>: ERR: Attribute number 2 (vendor 14122) is not defined in your dictionary Foi efectuada uma pesquisa acerca do vendor 14122, foram descobertos quais os atributos para o vendor em questão, construído o dicionário em falta, e foi acrescentado na configuração do radiator (ficheiro radius.cfg) a referência ao novo dicionário. Alteração no radius.cfg DictionaryFile %D/dictionary,%D/dictionary.ascend,%D/dictionary.vendor dictionary.vendor #VENDOR WISPr # # Standard attribute # VENDORATTR Location-ID 1 string # WISPr VENDORATTR Location-Name 2 string VENDORATTR Logoff-URL 3 string VENDORATTR Redirection-URL 4 string VENDORATTR Bandwidth-Min-Up 5 integer VENDORATTR Bandwidth-Min-Down 6 integer VENDORATTR Bandwidth-Max-Up 7 integer VENDORATTR Bandwidth-Max-Down 8 integer VENDORATTR Session-Terminate-Time 9 string VENDORATTR Session-Terminate-End-Of-Day 10 string VENDORATTR Billing-Class-Of-Service 11 string Clientes (<Client>) São considerados clientes todas máquinas para os quais o servidor aceitará perdidos. Poderão ser definidos por IP ou por nome (é necessário que exista resolução a partir da máquina onde está instalado o RADIATOR). A menos que o cliente especial DEFAULT seja definido, todos os pedidos de clientes não implicitamente configurados serão ignorados. São clientes tanto os AP s como outros servidores RADIUS que

9 utilizem o servidor para efectuar pedidos de autenticação/accounting, estejam abaixo ou acima na hierarquia. Exemplo de configuração de clientes: #PARA TESTES DE LOOPBACK, radpwtst - loopback test <Client IP_LOCAL> Secret hotspot-local Identifier LoopbackTests DupInterval 0 # Access Points da Institui ªo #AP 1 <Client > Secret hotspot-ap1 Identifier LocalUser #AP2 <Client > Secret hotspot-ap2 Identifier LocalUser () #APn <Client n> Secret hotspot-apn Identifier LocalUser # PROXY NACIONAL <Client cv-radius.fccn.pt> Secret hotspotfccn Identifier 4ProxyServer NOTA1: A chave (Secret) é uma chave partilhada utilizada para decifrar as mensagens provenientes de um cliente. Cada cliente diferente deve ter uma chave única por questões de segurança. A mesma chave deve estar definida do lado do Cliente (AP ou outro servidor de RADIUS) que está a utilizar este servidor para autenticar. Não existe um valor por omissão, portanto a chave tem sempre de ser definida. Também por questões de segurança a chave deve ser composta por pelo menos 16 caracteres alfanuméricos (símbolos, maiúsculas/minúsculas, números) aleatórios. O Identifier serve como label para o cliente em questão. Poderá ser útil para por exemplo ter autenticação baseada no cliente de onde o pedido é proveniente. NOTA2: O identificador (Identifier) utilizado na definição do cliente Proxy Nacional vai ser utilizado mais à frente para evitar loops de pedidos. Apenas pedidos que não tenham o identificador 4ProxyServer (ou seja não são pedidos vindos do próprio Proxy Nacional), serão reencaminhados para o Proxy Nacional.

10 <Realm> O Realm é a parte do login que sucede ou seja, para um login user@fccn.pt, fccn.pt é o Realm. O Realm especial DEFAULT será utilizado para tratar de todos os pedidos que não foram tratados por outras cláusulas Realm. Como a cláusula Realm é mais restrita que a cláusula Handler, e como com a cláusula do tipo <Handler Realm=fccn.pt> se produz o mesmo resultado que <Realm fccn.pt> não se utilizou a cláusula Realm na configuração. Para mais informações acerca da cláusula <Realm> consultar: <Handler> Nos Handler s são definidos métodos de autenticação. Os Handlers são baseados num conjunto arbitrário de atributos que têm de ser todos verdadeiros para que o pedido seja tratado por esse Handler. O algoritmo de selecção do Handler ou Realm é o seguinte: 1. Procurar uma cláusula Realm exactamente igual ao reaml name (realm do login) 2. Procurar uma cláusula Realm com expressão regular que efectue match 3. Procurar o Realm DEFAULT 4. Procurar um Handler por ordem de definição no ficheiro de configuração em que todos os atributos sejam verdadeiros para o pedido 5. Ignorar o pedido (não responde) O exemplo seguinte define os Handlers necessários para permitir autenticação 802.1x com PEAP e EAP-TTLS, bem como um Handler para tratamento de um utilizador especial (para configuração dos AP s por exemplo). Define-se por último o Handler que tratará de enviar os pedidos para o próximo servidor de RADIUS para Proxy (Proxy Nacional no exemplo). ####### # Acesso aos APs ####### # O Handler apenas Ø accionado com os UserNames: admin e root, e # apenas provenientes de clientes (definidos anteriormente) com # Identificador LocalUser. # A autenti ªo Ø efectuada com os dados provenientes no ficheiro # /etc/radius/ap-logins <Handler User-Name=/^(admin root)$/, Client-Identifier=LocalUser> # Aqui, a autenticacao esta a ser efectuada localmente # substitituir pelo tipo de BD desejada <AuthBy FILE> Filename /etc/radius/ap-logins # Pedidos "internos, vindos de um tœnel PEAP (2) <Handler TunnelledByPEAP=1> # Caso os Username estejam armazenados no formato user e # nªo user@realm a linha seguinte deve ser utilizada para # remover tudo para alem da arroba inclusive

11 #RewriteUsername # Aqui, a autenticacao esta a ser efectuada localmente # substitituir pelo tipo de BD desejada <AuthBy FILE> Filename /etc/radius/users-peap #Tipo de autenticacao "interna" #Pode ser PAP, CHAP, MSCHAP, MSCHAP-V2, etc. EAPType MSCHAP-V2 # Pedidos internos enviados por tœnel TTLS # Neste Handler devem residir todos pormenores referentes a # autentica ªo EAP-TTLS <Handler TunnelledByTTLS=1> # Caso os Username estejam armazenados no formato user e # nªo user@realm a linha seguinte deve ser utilizada para # remover tudo para alem da arroba inclusive #RewriteUsername s/^([^@]+).*/$1/ # Aqui, a autenticacao esta a ser efectuada localmente # substitituir pelo tipo de BD desejada <AuthBy FILE> Filename /etc/radius/users-ttls # A linha seguinte retorna para o autenticador a real # identidade do cliente # Caso o AP suporte o fornecimento de AVPairs provenientes # do RADIUS a linha seguinte permite ao AP saber a # verdadeira identidade do cliente (proveniente da # autentica ªo interna e nªo externa) para que o # accounting seja efectuado com o username real e nao com o # anonimo AddToReply User-Name=%u # Neste handler sao desencapsulados <Handler Realm = fccn.pt> # Aqui, a autenticacao esta a ser efectuada localmente # substitituir pelo tipo de BD desejada # Caso os Username estejam armazenados no formato user e nªo # user@realm a linha seguinte deve ser utilizada #RewriteUsername s/^([^@]+).*/$1/ <AuthBy FILE> #Filename /etc/radius/users #Tipo de EAPType PEAP, TTLS EAPTLS_CAFile /etc/radius/cert/democa/cacert.pem EAPTLS_CertificateFile /etc/radius/cert/cert-srv.pem EAPTLS_CertificateType PEM EAPTLS_PrivateKeyFile /etc/radius/cert/cert-srv.pem EAPTLS_PrivateKeyPassword whatever EAPTLS_MaxFragmentSize 1000 AutoMPPEKeys SSLeayTrace 4

12 # Proxy de pedidos para o Radius Nacional # Para os pedidos serem encaminhados para o Proxy o Realm nªo pode ser # vazio e nªo podem ter sido pedidos do pr prio proxy <Handler Realm=/^.+$/,Client-Identifier=/^(?!4ProxyServer$)/> <AuthBy RADIUS> Host cv-radius.fccn.pt Secret secret_to_proxynacional AuthPort 1812 AcctPort 1813 Retries 0 Para mais informações sobre as opções possíveis nos Handlers consultar:

13 Alterações para Implementação de Proxy de Radius Local Em alguns casos faz sentido que a Instituição também disponha de um Proxy Local de RADIUS. Um exemplo é existirem vários polos cada um com um Realm (ex: polo1.instituicao.pt; polo2.instituicao.pt; etc.) e optar-se por instalar um servidor de RADIUS para cada polo. Um servidor adicional, ou em alternativa um dos servidores do polo, deverá servir de Proxy Local para a instituição, sendo este depois o ponto de saída da Instituição para o servidor Radius Nacional. As alterações a efectuar nos servidores locais são apenas a de alterar o servidor de Proxy para o servidor Proxy Local: # PROXY LOCAL <Client radius.instituicao.pt> Secret proxysecret-to-polo1 Identifier 4LocalProxy Tunnel-Private-Group-ID,Filter-Id, cisco-avpair NoIgnoreDuplicates Accounting-Request <Handler Realm=/^.+$/,Client-Identifier=/^(?!4LocalProxy$)/> <AuthBy RADIUS> Host radius.instituicao.pt Secret polo1secret-to-proxyradius AuthPort 1812 AcctPort 1813 Retries 0 Tunnel-Private-Group-ID,Filter-Id, cisco-avpair O servidor Proxy Local terá uma configuração semelhante à seguinte: # Acesso dos Polos ao Proxy Local <Client radius.polo1.instituicao.pt> Secret polo1secret-to-proxyradius Identifier=Polo1 Tunnel-Private-Group-ID,Filter-Id, cisco-avpair NoIgnoreDuplicates Accounting-Request <Client radius.polo2.instituicao.pt > Secret polo2secret-to-proxyradius Identifier=Polo2 Tunnel-Private-Group-ID,Filter-Id, cisco-avpair NoIgnoreDuplicates Accounting-Request # Acesso do Proxy Nacional ao Proxy Local <Client cv-radius.fccn.pt> Secret proxynacional-to-localproxysecret Identifier=4ProxyServer

14 Tunnel-Private-Group-ID,Filter-Id, cisco-avpair NoIgnoreDuplicates Accounting-Request # Proxy de pedidos para o Polo1 <Handler Realm= polo1.instituicao.pt,client-identifier=/^(?!polo1$)/> <AuthBy RADIUS> Host radius.polo1.instituicao.pt Secret proxysecret-to-polo1 AuthPort 1812 AcctPort 1813 Retries 0 Tunnel-Private-Group-ID,Filter-Id, cisco-avpair # Proxy de pedidos para o Polo2 <Handler Realm= polo2.instituicao.pt,,client-identifier=/^(?!polo2$)/> <AuthBy RADIUS> Host radius.polo2.instituicao.pt Secret proxysecret-to-polo2 AuthPort 1812 AcctPort 1813 Retries 0 Tunnel-Private-Group-ID,Filter-Id, cisco-avpair <Handler Realm=/^.+$/,Client-Identifier=/^(?!4ProxyServer$)/> <AuthBy RADIUS> Host cv-radius.fccn.pt Secret instituicao-to-proxynacionalsecret AuthPort 1812 AcctPort 1813 Retries 0 Tunnel-Private-Group-ID,Filter-Id, cisco-avpair NOTA: também são possíveis de implementar cenários em que se estabelecem protocolos entre Instituições para troca directa de pedidos sem recurso ao servidor Nacional. Parâmetros Adicionais (na resposta de autenticação aceite) Por Utilizador (adicionar parâmetros) Podem ser atribuídos parâmetros especiais para cada utilizador. A forma apresentada é baseada em autenticação por ficheiro de utilizadores mas deverá ser válido para qualquer outro tipo de autenticação. # Mapeamento de Filter-Id por utilizador

15 # Utilizado na solu ªo EnterAsys utilizador1 Password= aminhapassword Filter-Id = "e-u" # Mapeamento de VLAN por utilizador via RADIATOR(vlanid = 16) # Utilizado na solu ªo Cisco utilizador1 Password= aminhapassword Tunnel-Type = 1:VLAN Tunnel-Medium-Type = 1:Ether_802 Tunnel-Private-Group-ID = 1:16 # Mapeamento de VLAN por utilizador via RADIATOR(vlanid = 4) # Utilizado na solu ªo 3Com (atribui ªo da vlan em formato octal) utilizador1 Password= aminhapassword Tunnel-Type = VLAN Tunnel-Medium-Type = Ether_802 Tunnel-Private-Group-ID = \004 Por Handler (adicionar/remover parâmetros) Quando um utilizador é autenticado, na reposta Access-Accepted podem ser retornados atributos dirigidos ao AP onde esse utilizador se associou. Esses atributos podem ser dos mais variados tipos, desde parâmetros de filtragem, parâmetros de rede, etc. O adicionar e remover parâmetros torna-se tanto mais importante quando se tratam de utilizadores em roaming, isto porque o servidor que autentica o utilizador (instalado na instituição de origem do utilizador) desconhece o cenário físico e/ou lógico da instituição onde se encontra o utilizador que acabou de autenticar. O facto de existirem várias soluções possíveis para diferenciação dos utilizadores (ex: diferenciação por SSID-VLAN ou por Filter-Id) faz com que seja obrigatória a adição e/ou remoção de atributos vindos do autenticador (servidor que conhece o utilizador). Por exemplo, no caso da VLAN ser determinado pelo servidor de autenticação e sabendo que a VLAN fornecida pelo servidor de autenticação tem prioridade sobre a definida no equipamento, faz com que um utilizador que se autentique fora da sua instituição, veja o seu servidor devolver o parâmetro VLAN errado no cenário onde se encontra. As implicações poderão ser a de ficar numa rede inexistente ou ainda pior, ter acesso a uma rede à qual não deveria aceder. Outro exemplo é a solução de diferenciar os utilizadores através do parâmetro Filter-Id. Na instituição o utilizador utiliza o Filter-Id de Professor mas numa outra instituição apenas poderá ser Convidado por exemplo. Uma vez que o servidor que autentica o utilizador fornece o Filter-Id= Professor, fica do lado do servidor de autenticação local (da instituição onde se liga fisicamente o utilizador), a responsabilidade de retirar da informação considerada perigosa (Filter-Id= Professor ) e colocar a informação segura (Filter-Id= Convidado ). Os comandos que permitem efectuar estas operações são: AddToReply : Adiciona parâmetros à resposta de Access-Accepted StripFromReply : Remove parâmetros à resposta de Access-Accepted

16 AllowInReply : Apenas permite os seguintes parâmetros à resposta de Access- Accepted (Utilizar com precaução pois corre-se o risco de se remover atributos necessários à própria autenticação) Estes comandos são utilizados dentro de Handlers ou Realms e são aplicados pela ordem em que são definidos/atingidos. Ex: # Retirar a informa ªo de VLAN e Filter-Id proveniente de outro # servidor e adicionar o Filter-Id=e-U <Handler XXXX> <AuthBy XXXX>... StripFromReply Tunnel-Type, Tunnel-Medium-Type, Tunnel- Private-Group-ID,Filter-Id AddToReply=Filter-Id=e-U NOTA : Existem outros comandos que permitem alterar a resposta mas não são abordados neste documento.

17 Exemplo de Configuração: NOTA: O exemplo seguinte contemplam sempre a autenticação num ficheiro simples (plain text file). Cenário 1 (Mapeamento por Múltiplas VLAN s Múltiplos SSID s) 2 Access Points com os endereços e os Access Points diferenciam os utilizadores através de múltiplas VLAN s/ssid s que são configuradas no equipamento 1 Servidor RADIATOR com routing para a internet (para acesso ao proxy) Configuração (radius.cfg) AuthPort 1812 AcctPort 1813 LogDir /var/log/radius DbDir /etc/radius DictionaryFile %D/dictionary,%D/dictionary.ascend PidFile /var/run/radiusd.pid Trace 0 # Clientes autorizados #AP 1 <Client > Secret secret_do_accesspoint1 Identifier LocalUser #AP 2 <Client > Secret secret_do_accesspoint2 Identifier LocalUser #Proxy Central <Client > Secret secret_para_accesso_ao_proxy_nacional Identifier 4ProxyServer Tunnel-Private-Group-ID,Filter-Id, cisco-avpair NoIgnoreDuplicates Accounting-Request # Efectuar logging dos acessos dos utilizadores pertencentes # institui ªo sem o REALM uma vez que Ø sempre o mesmo. <AuthLog FILE> Identifier localusers Filename %L/localusers.log SuccessFormat %l:%t from %U at %N:OK FailureFormat %l:%t from %U at %N:FAIL LogSuccess 1 LogFailure 1 </AuthLog> # Efectuar logging dos acessos dos utilizadores em roaming na # institui ªo (externos) apenas as credenciais exteriores

18 # (tipicamente anonymouns) serªo vis veis, mas o log Ø efectuado com o # REALM para se saber de que institui ªo Ø o utilizador <AuthLog FILE> Identifier roamingusers Filename %L/roamingusers.log SuccessFormat %l:%t from %u at %N:OK FailureFormat %l:%t from %u at %N:FAIL LogSuccess 1 LogFailure 1 </AuthLog> # Exemplo para Autentica ªo do accesso aos APs <Handler User-Name=/^(administrador root)$/, Client-Identifier=/^LocalUser$/> <AuthBy FILE> Filename /etc/radius/ap-logins #Pedidos "internos", vindos de um tœnel PEAP <Handler TunnelledByPEAP=1> RewriteUsername s/^([^@]+).*/$1/ <AuthBy FILE> RewriteUsername s/^([^@]+).*/$1/ Filename /etc/radius/users EAPType MSCHAP-V2 AddToReply User-Name=%u AuthLog localusers #Pedidos internos enviados por tœnel TTLS <Handler TunnelledByTTLS=1> RewriteUsername s/^([^@]+).*/$1/ <AuthBy FILE> Filename /etc/radius/users AddToReply User-Name=%u AuthLog localusers # Handler para o dom nio da institui ªo (inst.pt) <Handler Realm = inst.pt> RewriteUsername s/^([^@]+).*/$1/ MaxSessions 1 <AuthBy FILE> EAPType PEAP, TTLS, TLS EAPTLS_CAFile /etc/radius/cert/democa/cacert.pem EAPTLS_CertificateFile /etc/radius/cert/cert-srv.pem EAPTLS_CertificateType PEM EAPTLS_PrivateKeyFile /etc/radius/cert/cert-srv.pem EAPTLS_PrivateKeyPassword whatever EAPTLS_MaxFragmentSize 1000 AutoMPPEKeys SSLeayTrace 4 # Efectua proxy de outros pedidos # O Client-Identifier evita loop s de pedidos que chegaram do proxy # server possam ser reenviados para o proxy server novamente # Tambem so sao enviados pedidos com REALM nao vazio

19 <Handler Realm=/^.+$/,Client-Identifier=/^(?!4ProxyServer$)/> <AuthBy RADIUS> Host cv-radius.fccn.pt Secret secret_to_proxynacional AuthPort 1812 AcctPort 1813 Retries 0 Tunnel-Private-Group-ID, Filter-Id, cisco-avpair AuthLog roamingusers Configuração (users) utilizador1 utilizador2 (...) Password = aminhapassword1 Password = aminhapassword2 Cenário 2 (Mapeamento por Filter-Id fornecido pelo RADIATOR) 2 Access Points com os endereços e os Access Points diferenciam os utilizadores através de Filter-Id que são fornecidos pelo servidor de autenticação 1 Servidor RADIATOR com routing para a internet (para acesso ao proxy) A configuração será semelhante à apresentada no cenário 1 com excepção do Handler que define o Proxy de pedidos para o exterior e do ficheiro de users: Configuração (radius.cfg) (...) <Handler Realm=/^.+$/,Client-Identifier=/^(?!4ProxyServer$)/> <AuthBy RADIUS> Host cv-radius.fccn.pt Secret secret_to_proxynacional AuthPort 1812 AcctPort 1813 Retries 0 Tunnel-Private-Group-ID, Filter-Id, cisco-avpair # Este utilizador tem acesso com permissoes de e-u AddToReply Filter-Id = e-u AuthLog roamingusers Configuração (users) # Este utilizador tem acesso com permissoes de aluno utilizador1 Password = aminhapassword1 Filter-Id = "aluno" # Este utilizador tem acesso com permissoes de professor utilizador2 Password = aminhapassword2

20 Filter-Id = "professor" Cenário 3 (Mapeamento de VLAN fornecida via RADIATOR) 2 Access Points com os endereços e os Access Points têm configurados dois SSID s cada um com uma VLAN para cada SSID. Recebem do RADIATOR no final da autenticação a VLAN a atribuir ao utilizador que se acaba de autenticar. 1 Servidor RADIATOR com routing para a internet (para acesso ao proxy) A configuração será semelhante à apresentada no cenário 1 com excepção do ficheiro de users: Configuração (users) # coloca o utilizador na vlan 50 utilizador1 Password = aminhapassword1 Tunnel-Type = "1:VLAN" Tunnel-Medium-Type = "1:Ether_802" Tunnel-Private-Group-ID = "1:50" # Versªo para equipamento 3Com (vlanid deve ser atribuida em octal sem # o tag 1:) # coloca o utilizador na vlan 50 (decimal 50 = octal 62) utilizador2 Password = aminhapassword2 Tunnel-Type = "VLAN" Tunnel-Medium-Type = "Ether_802" Tunnel-Private-Group-ID = "\062" (...) NOTA: Para equipamento Cisco as VLAN s fornecidas pelo RADIATOR TÊM de estar configuradas no equipamento. A falta da configuração no equipamento da VLAN enviada pelo RADIATOR o AP utiliza a VLAN associada ao SSID a que o utilizador se associou.

21 Recursos adicionais: Mais informação acerca do software RADIATOR em: Mais Informações acerca da configuração do RADIATOR em: Módulos de Perl adicionais (necessários e/ou opcionais) em: Mais informação acerca do Projecto e-u