Versão PDF

Transcrição

Versão PDF

Campus Virtuais
CookBook para Instalação e Configuração do RADIATOR
Luís Guido
FCCN
Versão 0.21
05 de Dezembro de 2003
Instalação e Configuração do RADIATOR
Controlo de Versões
Versão Data
Status
Alterações
0.1
Draft
Primeiro Draft
21/Out/2003
Acrescentado mais um exemplo no tópico
“Parâmetros Adicionais“
0.2
12/Nov/2003
Draft
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.
0.21
05/Dez/2003
Draft
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
0.3
13/Dez/2004
Draft
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)
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 (http://www.open.com.au) 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.
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:
http://www.open.com.au/radiator/install.html .
Acerca das especificações do software:
http://www.open.com.au/radiator/technical.html
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 5.005 ou posterior
Módulo de Perl Digest-MD5 versão 2.12 ou posterior
Módulo de Perl Digest-MD4 (*)
OpenSSL versão 0.9.7 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
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.
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
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
AcctPort
LogDir
DbDir
DictionaryFile
PidFile
Trace
0
1812
1813
/var/log/radius
/etc/radius
%D/dictionary,%D/dictionary.ascend
/var/run/radiusd.pid
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:
http://www.open.com.au/radiator/ref.html#pgfId=358572
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:
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.vendor14122
-------------------dictionary.vendor14122-----#VENDOR WISPr 14122
#
# Standard attribute
#
VENDORATTR 14122 Location-ID 1
string
# WISPr
VENDORATTR 14122 Location-Name
2
string
VENDORATTR 14122 Logoff-URL 3
string
VENDORATTR 14122 Redirection-URL
4
string
VENDORATTR 14122 Bandwidth-Min-Up 5
integer
VENDORATTR 14122 Bandwidth-Min-Down
6
integer
VENDORATTR 14122 Bandwidth-Max-Up 7
integer
VENDORATTR 14122 Bandwidth-Max-Down
8
integer
VENDORATTR 14122 Session-Terminate-Time 9
string
VENDORATTR 14122 Session-Terminate-End-Of-Day 10
string
VENDORATTR 14122 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
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
</Client>
# Access Points da Instituição
#AP 1
<Client 192.168.0.1>
Secret hotspot-AP1
Identifier LocalUser
</Client>
#AP2
<Client 192.168.0.2>
Secret hotspot-AP2
</Client>
(…)
#APn
<Client 192.168.0.n>
Secret hotspot-APn
</Client>
# PROXY NACIONAL
<Client cv-radius.fccn.pt>
Secret hotspotfccn
Identifier 4ProxyServer
</Client>
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 .
<Realm>
O Realm é a parte do login que sucede uma ‘@’ ou seja, para um login [email protected] ,
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 AP’s
#######
# 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
</AuthBy>
</Handler>
# 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
#RewriteUsername s/^([^@]+).*/$1/
<AuthBy FILE>
Filename /etc/radius/users-peap
#Tipo de autenticacao "interna"
#Pode ser PAP, CHAP, MSCHAP, MSCHAP-V2, etc.
EAPType MSCHAP-V2
</AuthBy>
</Handler>
# 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
<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
</AuthBy>
</Handler>
# Neste handler sao desencapsulados
<Handler Realm = fccn.pt>
# Caso os Username estejam armazenados no formato ‘user’ e não
# ‘user@realm’ a linha seguinte deve ser utilizada
<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
</AuthBy>
</Handler>
# 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
</AuthBy>
</Handler>
Para mais informações sobre as opções possíveis nos Handlers consultar:
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
StripFromReply Tunnel-Type,Tunnel-Medium-Type,
Tunnel-Private-Group-ID,Filter-Id, cisco-avpair
NoIgnoreDuplicates Accounting-Request
</Client>
<Handler Realm=/^.+$/,Client-Identifier=/^(?!4LocalProxy$)/>
<AuthBy RADIUS>
Host
radius.instituicao.pt
Secret
polo1secret-to-proxyradius
AuthPort 1812
AcctPort 1813
Retries
0
</AuthBy>
</Handler>
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
</Client>
<Client radius.polo2.instituicao.pt >
Secret polo2secret-to-proxyradius
Identifier=Polo2
</Client>
# Acesso do Proxy Nacional ao Proxy Local
<Client cv-radius.fccn.pt>
Secret proxynacional-to-localproxysecret
Identifier=4ProxyServer
</Client>
# 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
</AuthBy>
</Handler>
# 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
</AuthBy>
</Handler>
<AuthBy RADIUS>
Host
cv-radius.fccn.pt
Secret
instituicao-to-proxynacionalsecret
AuthPort 1812
AcctPort 1813
Retries
0
</AuthBy>
</Handler>
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
# 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
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
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
AllowInReply :
Apenas permite os seguintes parâmetros à resposta de AccessAccepted (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,
Private-Group-ID,Filter-Id
AddToReply=Filter-Id=”e-U”
</AuthBy>
</Handler>
Tunnel-
NOTA : Existem outros comandos que permitem alterar a resposta mas não são
abordados neste documento.
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 192.168.1.1 e 192.168.1.2
• 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
AcctPort
LogDir
DbDir
DictionaryFile
PidFile
Trace
1812
1813
/var/log/radius
/etc/radius
%D/dictionary,%D/dictionary.ascend
/var/run/radiusd.pid
0
# Clientes autorizados
#AP 1
<Client 192.168.1.1>
Secret secret_do_accesspoint1
</Client>
#AP 2
<Client 192.168.1.2>
Secret secret_do_accesspoint2
</Client>
#Proxy Central
<Client 193.136.192.119>
Secret secret_para_accesso_ao_proxy_nacional
Identifier 4ProxyServer
</Client>
# 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
# (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 AP’s
<Handler User-Name=/^(administrador|root)$/, Client-Identifier=/^LocalUser$/>
<AuthBy FILE>
Filename /etc/radius/AP-logins
</AuthBy>
</Handler>
#Pedidos "internos", vindos de um túnel PEAP
<Handler TunnelledByPEAP=1>
RewriteUsername s/^([^@]+).*/$1/
<AuthBy FILE>
Filename /etc/radius/users
EAPType MSCHAP-V2
</AuthBy>
AuthLog localusers
</Handler>
#Pedidos internos enviados por túnel TTLS
<Handler TunnelledByTTLS=1>
<AuthBy FILE>
Filename /etc/radius/users
</AuthBy>
AuthLog localusers
</Handler>
# Handler para o domínio da instituição (inst.pt)
<Handler Realm = inst.pt>
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
</AuthBy>
</Handler>
#
#
#
#
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
<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
</AuthBy>
AuthLog roamingusers
</Handler>
Configuração (users)
utilizador1
utilizador2
(...)
Password = aminhapassword1
Cenário 2 (Mapeamento por Filter-Id fornecido pelo RADIATOR)
• os Access Points diferenciam os utilizadores através de Filter-Id que são
fornecidos pelo servidor de autenticação
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)
(...)
<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”
</AuthBy>
AuthLog roamingusers
</Handler>
# Este utilizador tem acesso com permissoes de “aluno”
utilizador1
Filter-Id = "aluno"
# Este utilizador tem acesso com permissoes de “professor”
utilizador2
Filter-Id = "professor"
Cenário 3 (Mapeamento de VLAN fornecida via RADIATOR)
• 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.
A configuração será semelhante à apresentada no cenário 1 com excepção do ficheiro de
users:
# coloca o utilizador na vlan 50
utilizador1
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
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.
Recursos adicionais:
Mais informação acerca do software RADIATOR em:
http://www.open.com.au/radiator
Mais Informações acerca da configuração do RADIATOR em:
http://www.open.com.au/radiator/ref.html
Módulos de Perl adicionais (necessários e/ou opcionais) em:
http://www.perl.com/CPAN/CPAN.html
Mais informação acerca do Projecto e-U
http://www.fccn.pt/projectos/campusvirtuais/?in_menu_option=91053

Versão PDF

Transcrição

Documentos relacionados

Como acessar rede UFPR de casa

CONEXÃO DOMÉSTICA – GOOGLE CHROME 1

Manual de Configuração de Proxy do Mozilla Firefox

Procedimentos para configurar o Proxy do CEFET

Configurar Chrome Proxy

Atenção: Antes de começar a configuração deste manual, você

Europass-Curriculum Vitae

Configuração do Proxy no Internet Explorer - Multiweb

condições

POLÍTICA DE PRIVACIDADE