Serviço de Diretório

Um Diretório é como um banco de dados, mas tende a conter mais informações descritivas, baseadas em atributo e é organizado em forma de árvore, não de tabela. A informação em um Diretório é geralmente mais lida do que é escrita. Como conseqüência, Diretórios normalmente não são usados para implementar transações complexas, ou esquemas de consultas regulares em bancos de dados, transações estas que são usadas para fazer um grande volume de atualizações complexas. Atualizações em Diretórios são tipicamente simples ou nem são feitas.

Diretórios são preparados para dar resposta rápida a um grande volume de consultas ou operações de busca. Eles também podem ter a habilidade de replicar informações extensamente; isto é usado para acrescentar disponibilidade e confiabilidade, enquanto reduzem o tempo de resposta.

Existem várias maneiras diferentes para disponibilizar um serviço de Diretório. Métodos diferentes permitem que diferentes tipos de informações possam ser armazenadas no Diretório, colocando requerimentos diferentes, sobre como aquela informação poderá ser referenciada, requisitada e atualizada, como ela é protegida de acessos não autorizados, etc. Alguns serviços de Diretório são locais, fornecendo o serviço para um contexto restrito (exemplo: o serviço finger em uma máquina isolada). Outros serviços são globais, fornecendo o serviço para um contexto muito maior (por exemplo, a própria Internet).

Serviços globais normalmente são distribuídos (Figura 5-1), ou seja, cada servidor é responsável por uma parte apenas. O DNS (Domain Name System) é um exemplo, ele é um tipo de serviço de Diretório, embora bastante especializado.

Tipo de Informação

O modelo de serviço do Diretório LDAP é baseado em entradas. Uma entrada é um conjunto de atributos e é referenciada através de um nome distinto[1]. O DN é usado para referenciar uma entrada de forma não ambígua. Cada um dos atributos de entrada tem um tipo e um ou mais valores. Este tipos geralmente são palavras mnemônicas, como cn para nome comum, ou mail para endereço de correio eletrônico; existem RFCs (Request For Comments) que determinam estas palavras. Os valores dependem do tipo de atributo. Por exemplo, um atributo mail pode conter o valor <mari@marilia.br>. Um atributo photoJpeg irá conter uma fotografia.

Organizando a Informação

No LDAP, entradas de Diretório são organizadas em uma hierarquia de árvore invertida, semelhante em alguns aspectos à organização do DNS. A estrutura desta árvore geralmente reflete limites políticos, geográficos e/ou organizacionais. O nó mais alto (raiz) é tipicamente o componente nome de domínio dc[2] de uma companhia, estado ou organização. Abaixo ficam as entradas representando estados ou organizações nacionais. Abaixo elas podem ser entradas representando pessoas, unidades organizacionais, impressoras, documentos, ou qualquer outra coisa em que você possa pensar. A Figura 5-2 mostra um exemplo de um Diretório LDAP em árvore.

Apesar de termos entradas para países, o diretório não possui uma entidade centralizadora como, por exemplo, o root servers do DNS. A separação por países, por exemplo, pode ser útil para empresas multinacionais. A Figura 5-2 também ilustra uma outra vantagem de um serviço de Diretórios. Os ramos da árvore podem estar em máquinas diferentes. No caso da Figura 5-2, a entrada o=Brasil Ltda está em um outro computador. Note que esta característica também é típica do DNS.

Classes de Objetos

Já foi visto alguns tipos de atributos usados nas entradas em um serviço de Diretórios: mail, cn, telephoneNumber e outros. Pode-se criar qualquer tipo de atributo, mas isto não é recomendado. No LDAP existem diversas classes de objetos, e cada classe contém uma lista de atributos obrigatórios e opcionais. Essa lista é tipicamente definida em uma RFC, mas empresas ou organizações também podem criar suas próprias classes.

Por exemplo, a classe person é definida da seguinte maneira (definida na RFC2256):

objectclass ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL
  MUST ( sn $ cn )
  MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

O servidor LDAP pode ser configurado para verificar as classes (através da opção schemacheck) e forçar o uso correto dos atributos. Isto geralmente é uma boa idéia; com a verificação das classes habilitada, será obrigatória a inserção dos atributos objectClass, sn e cn, por exemplo. Quando for definido que uma entrada do Diretório é da classe person, um atributo description será opcional. Entradas em Diretórios podem ter várias classes diferentes, basta apenas observar os requisitos de atributos de cada classe.

Referenciando a Informação

Uma entrada é referenciada pelo seu nome distinto DN. O DN é único e na sua construção utiliza o caminho inteiro, desde a entrada até o topo do Diretório. Por exemplo, na Figura 5-2, DN="cn=Maria A Silva,o=U de M,c=BR". As entradas também podem ser referenciadas através de um RDN (Relative Distinguished Name). Ainda neste exemplo o RDN é cn=Maria A. Silva. Pode-se fazer uma comparação com hostname (RDN) e FQDN (DN).

Acessando a Informação

O LDAP define operações para consultar e atualizar o Diretório. Operações são fornecidas para adição e remoção de uma entrada do Diretório, modificação de uma entrada existente e modificação do nome de uma entrada. A operação LDAP de busca pode abranger a árvore toda (uma busca com escopo subtree) ou apenas um ramo, sem descer ou subir para os demais. Além de especificar com filtros quais entradas se deseja encontrar, também é possível especificar quais atributos destas entradas estão sendo procurados. Se os atributos não forem especificados, todos serão retornados.

Por exemplo, na Figura 5-2 você pode querer pesquisar toda a sub-árvore de Diretório abaixo da Universidade de Marília, procurando por pessoas com o nome de Maria Silva, recuperando o endereço de correio eletrônico para cada entrada encontrada. O LDAP permite que você faça isto facilmente. Ou você pode querer buscar as entradas diretamente abaixo do c=BR, entrada para organizações com a palavra "Brasil" no seu nome, e que tenham um número de telefone. O LDAP permite que você faça isto também. A próxima seção descreve com mais detalhes o que você pode fazer com LDAP e como isto poderá ser útil.

Proteção Contra Acessos Não Autorizados

Alguns serviços de Diretório não fornecem proteção, permitindo que qualquer um possa ver as informações. O LDAP fornece um método para autenticação de um cliente, ou prova sua identidade para um servidor de Diretório, pavimentando o caminho para um rico controle de acesso, protegendo as informações contidas no servidor.

Funcionamento do LDAP

O serviço de Diretório LDAP é baseado em um modelo cliente-servidor. Um ou mais servidores LDAP contêm os dados criando a árvore de Diretório LDAP. Um cliente LDAP conecta-se a um servidor e faz uma requisição. O servidor responde com a requisição, ou exibe um ponteiro para um local onde o cliente pode conseguir a informação (tipicamente, outro servidor LDAP). Pode-se fazer novamente uma comparação com o DNS, a diferença é que o servidor LDAP não faz buscas recursivas, ou seja, em nome do cliente. O cliente é encarregado de procurar pelo servidor até encontrar a informação desejada.

Conceito e Utilização do slapd

O slapd é um servidor de Diretório LDAP que pode ser executado em diferentes plataformas Linux. Você pode usá-lo para fornecer o seu próprio serviço de Diretório. Seu Diretório pode conter qualquer coisa que você queira colocar. Você pode conectá-lo a um serviço de Diretório LDAP global, ou executar o serviço para você mesmo. Algumas das características e potencialidades mais interessantes do slapd incluem:

Escolha do banco de dados: O slapd vem com quatro tipos diferentes de banco de dados que você pode escolher. São eles: LDBM, um banco de dados baseado em disco de alta performance; SHELL, uma interface de banco de dados para comandos arbitrários do Linux ou scripts de linha de comando e PASSWD, um banco de dados simples de um arquivo de senhas. A partir da versão 2.1 do OPENLDAP também existe a opção de usar BDB[3] como backend que é o padrão.

Múltiplas instâncias dos bancos de dados: O slapd fornece uma rica e poderosa facilidade no controle de acesso, permitindo a você controlar o acesso a informação em seu(s) banco(s) de dados. Você pode controlar o acesso às entradas baseadas em informação de autenticação LDAP, endereço IP, nome do domínio e outros critérios.

Gerenciamento de processos: O slapd utiliza vários processos para ter uma alta performance. Um único sub-processo slapd manuseia todas as requisições vindas, reduzindo a quantidade requisitada de recursos do sistema. O slapd irá automaticamente selecionar o melhor suporte a vários processos para a sua plataforma.

Replicação: O slapd pode ser configurado para usar réplicas. Este esquema de replicação mestre/escravo é vital em ambientes de grande volume, onde um único slapd não pode fornecer a disponibilidade ou a confiabilidade necessárias.

Facilidade de configuração: O slapd é altamente configurável. Através de um único arquivo de configuração ele permite mudar simplesmente tudo, sempre que você quiser alterar. As opções de configuração têm padrões razoáveis, tornando o seu trabalho muito mais fácil.

As características do openldap-2.1.x são:

LDAPv2 e LDAPv3: O slapd suporta as versões 2 e 3 do LDAP. Ele fornece suporte para as últimas características enquanto mantém interoperabilidade com os clientes existentes. O slapd tem suporte somente ao IPv4. Por padrão, apenas o LDAPv3 está habilitado.

Autenticação SASL: O slapd tem suporte a serviços de autenticação diferenciados através do uso de SASL. A implementação SASL do slapd utiliza o software Cyrus SASL com suporte a vários mecanismos, incluindo DIGEST-MD5 e CRAM-MD5.

Camada de Transporte Segura: O slapd fornece proteções de privacidade e integridade através do uso de TLS. A implementação TLS do slapd utiliza o software OpenSSL[4].

Internacionalização: O slapd suporta Unicode e tags de linguagem.

LDAP e o X.500

O LDAP foi originalmente desenvolvido como um cliente para o X.500, o serviço de Diretório OSI. O X.500 define o Protocolo de Acesso a Diretório (DAP[5]) para os clientes usarem quando estiverem em contato com servidores de Diretório. O DAP é um protocolo pesado, que roda sobre uma camada OSI completa, e precisa de uma quantidade significante de recursos computacionais para ser executado. O LDAP roda diretamente sobre o TCP e fornece a maioria das funcionalidades do DAP, a um custo muito menor.

Este uso do LDAP torna fácil acessar o Diretório X.500, mas ainda exige um serviço X.500 completo, para tornar os dados disponíveis aos vários clientes LDAP que estão sendo desenvolvidos.

Se você já está executando um serviço X.500 e quer continuar a fazer isto, você provavelmente pode parar de ler este capítulo, ele é todo sobre como executar o LDAP via slapd, sem utilizar o X.500. Se você não está usando o X.500, quer parar de usar o X.500 ou não tem planos imediatos para executar o X.500, continue lendo.

É possível replicar dados de um servidor de Diretório slapd para um DAP X.500; isto permite que sua organização torne seus dados disponíveis como parte de um serviço de Diretório X.500 global em uma base somente para leitura.

Um outro caminho para tornar os dados em um servidor slapd disponíveis para a comunidade X.500 seria usando um DAP X.500 para porta de entrada do LDAP.

Replicação

O slurpd é um servidor para Linux que auxilia o slapd, provendo a replicação do banco de dados. Ele é responsável pela distribuição das mudanças ocorridas no servidor master para o servidor slave (a réplica). Veja a Figura 5-3.

O slapd e o slurpd se comunicam através de um simples arquivo texto, que é usado para registrar as mudanças. A sintaxe deste arquivo lembra um pouco a sintaxe dos arquivos resultantes do diff, no sentido de que estão descritas as entradas ou atributos que devem ser removidos, adicionados ou modificados. O slurpd irá se encarregar de aplicar estas mudanças ao servidor da réplica. Durante este processo, a réplica e o master ficarão diferentes.

Autenticação com OpenLDAP-2.1.X

Uma das questões mais importantes do pacote openldap é sem dúvida a autenticação. Isto é necessário para que a implementação estivesse em conformidade com o protocolo LDAPv3, que exige algum tipo de autenticação forte. Há basicamente dois mecanismos de autenticação:

• suporte a SSL nativo em todas as conexões (sem necessidade de programas como Stunnel);

• suporte a Simple Authentication and Security Layer, também conhecido com SASL, definido da RFC2222. A autenticação SASL também pode ser usada por outros servidores, como versões recentes do MTA Sendmail.

Ambos os mecanismos permitem a autenticação segura, pois as senhas não trafegarão mais em texto claro (clear text), sendo imunes a sniffers de rede. Prós e contras de cada um dos mecanismos serão apresentados para que o administrador possa escolher a melhor solução para a sua rede.

Jun 23 13:44:14 kepler slapd[13336]: conn=365 op=1 BIND dn="" 
 method=128 
Jun 23 13:44:14 kepler slapd[13336]: conn=365 op=1 RESULT tag=97
 err=0 text= 
Jun 23 13:44:14 kepler slapd[13463]: conn=365 op=2 SRCH
 base="o=minhaorganizacao,c=br" scope=2 filter="(uid=usuario)" 
Jun 23 13:44:14 kepler slapd[13463]: conn=365 op=2 SEARCH RESULT
 tag=101 err=0 text= 
Jun 23 14:07:53 kepler slapd[13337]: conn=365 op=3 UNBIND

Jun 25 10:03:34 kepler slapd[2016]: conn=10 op=1 BIND
dn="UID=USUARIO,OU=PEOPLE,O=MINHAORGANIZACAO,C=BR" method=128
 
Jun 25 10:03:34 kepler slapd[2016]: conn=10 op=1 RESULT tag=97 err=0 
 text= 
Jun 25 10:03:34 kepler slapd[2012]: conn=10 op=2 SRCH
base="o=minhaorganizacao,c=br" scope=2 filter="(uid=usuario)"
 
Jun 25 10:03:34 kepler slapd[2012]: conn=10 op=2 ENTRY
dn="uid=usuario,ou=People,o=minhaorganizacao,c=br" 

Jun 25 10:03:34 kepler slapd[2012]: conn=10 op=2 SEARCH RESULT 
tag=101 err=0 text= 

Jun 25 10:03:34 kepler slapd[2016]: conn=10 op=3 UNBIND

# ldapsearch -h host -x -b ¨¨ -s base supportedSASLMechanisms

Pré-requisitos

Para executar a configuração sugerida por este guia para a implementação de um servidor LDAP, é necessário verificar os seguintes requisitos:

• É importante, mas não obrigatório, que o Netscape Communicator® esteja instalado, para a execução de testes.

• Levantamento dos dados que serão armazenados no servidor: verificação da necessidade de replicação de dados, definição da hierarquia de servidores, entre outros necessários antes de instalar o servidor.

Instalação

Para instalação do servidor LDAP, será utilizado o OpenLDAP. Execute o Synaptic e selecione os seguintes pacotes para a instalação:

• openldap

• openldap-server

• openldap-client

• nss_ldap

• pam_ldap

• migrationtools-common

• migrationtools-offline

ou utilize o comando apt-get:

# apt-get install openldap openldap-server openldap-client
# apt-get install migrationtools-offline
# apt-get install nss_ldap pam_ldap

Configuração do Servidor

1. Edite o arquivo /etc/openldap/slapd.conf e modifique as seguintes opções:

   suffix "o=minhaorganizacao, c=br" rootdn "cn=manager, o=minhaorganizacao, c=br" rootpw minha-senha ... # For Netscape Roaming support, each user gets a roaming # profile for which they have write access to access to dn=".*,ou=Roaming,o=minhaorganizacao,c=br" by dnattr=owner write # The userPassword by default can be changed by the # entry owning it if they are authenticated. # Others should not be able to see it, except the # admin entry below access to attr=userPassword by dn="cn=manager,o=minhaorganizacao,c=br" write by anonymous auth by self write by * none # Full rights to the admin access to * by dn="cn=manager,o=minhaorganizacao,c=br" write by * read

   suffix: a raiz, a base do seu Diretório.

   rootdn: o login do administrador.

   rootpw: a senha do administrador; pode ser colocada criptografada. Consulte a página de manual do slapd.conf (man slapd.conf) para mais informações.

   Os três últimos blocos definem Controles de Acesso a características e permissões para o servidor LDAP.

As outras opções já estão configuradas com os valores padrão.

# configuration file for the ldap startup script

# change to "yes" if you want the ldap server (slapd) to
# also listen on the ldaps (636) port. Otherwise, encryption
# will only be possible via START-TLS
LDAPS=no

# You may define an user and group here if you want to. The ldap
# server will then be started using the user and group specified
# here. Be aware that you will also have to change permissions
# on the database if you use this! And some authentication methods,
# specially those using SASL, may fail if they can't access
# /etc/shadow or something like that. You may want to check
# the use of SASL's pwcheck method in that case.
USER=ldap
GROUP=ldap

ssl start_tls

ssl on

ssl off

$DEFAULT_MAIL_DOMAIN = "minhaorganizacao.com.br";

$DEFAULT_BASE = "o=minhaorganizacao,c=br";

$EXTENDED_SCHEMA = 0;

# cd /usr/share/openldap/migration/
# ./migrate_all_offline.sh
Creating naming context entries...  
Migrating aliases...
Migrating groups...
Migrating hosts...  
Migrating networks...
Migrating users...
Migrating protocols...
Migrating rpcs...
Migrating netgroups...
Importing into LDAP... 
Migrating netgroups (by user)...
Migrating netgroups (by host)...  
Preparing LDAP database...
# chown ldap.ldap /var/lib/openldap-data/*

BASE o=minhaorganizacao,c=br
URI ldap://servidor.ldap.minhaorganizacao

# service ldap start

ALL: localhost

Testando a configuração

Abra um terminal e utilize os seguintes comandos:

• para verificar tudo que existe no Diretório:

  $ ldapsearch "objectclass=*" -x version: 2 # # filter: objectclass=* # requesting: ALL # # minhaorganizacao, br dn: o=minhaorganizacao,c=br dc: minhaorganizacao objectClass: top objectClass: domain # People, minhaorganizacao, br dn: ou=People,o=minhaorganizacao,c=br ou: People objectClass: top objectClass: organizationalUnit ...

• para verificar se os usuários foram inseridos:

  $ ldapsearch uid=usuario -x version: 2 # # filter: uid=usuario # requesting: ALL # usuario, People, minhaorganizacao, br dn: uid=usuario,ou=People,o=minhaorganizacao,c=br uid: usuario cn: usuario objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount shadowLastChange: 11725 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 501 gidNumber: 501 homeDirectory: /home/usuario # numResponses: 2 # numEntries: 1

• para verificar se as senhas foram inseridas usando a senha do administrador do Diretório:

  $ ldapsearch -D cn=manager,o=minhaorganizacao,c=BR \ -W uid=usuario -x -ZZ Enter LDAP Password: version: 2 # # filter: uid=usuario # requesting: ALL # # usuario, People, minhaorganizacao, br uid=usuario,ou=People,o=minhaorganizacao,c=br uid=usuario cn=usuario sn=usuario mail=usuario@minhaorganizacao.com.br objectclass=person objectclass=organizationalPerson objectclass=inetOrgPerson objectclass=account objectclass=posixAccount objectclass=top objectclass=kerberosSecurityObject userpassword={crypt}VazDY6ytbW/YI krbname=usuario@MINHAORGANIZACAO.COM.BR loginshell=/bin/bash uidnumber=500 gidnumber=500 homedirectory=/home/usuario # numResponses: 2 # numEntries: 1

  De acordo com as ACLs, o administrador sempre tem acesso a todos os atributos.

• para verificar a senha do seu usuário usando sua própria senha:

  $ ldapsearch -D uid=usuario,ou=people,o=minhaorganizacao,c=br \ -W uid=usuario -x -ZZ Enter LDAP Password: version: 2 # # filter: uid=usuario # requesting: ALL # # usuario, People, minhaorganizacao, br uid=usuario,ou=People,o=minhaorganizacao,c=br uid=usuario cn=usuario sn=usuario mail=usuario@minhaorganizacao.com.br objectclass=person objectclass=organizationalPerson objectclass=inetOrgPerson objectclass=account objectclass=posixAccount objectclass=top objectclass=kerberosSecurityObject userpassword={crypt}VazDY6ytbW/YI krbname=usuario@MINHAORGANIZACAO.COM.BR loginshell=/bin/bash uidnumber=500 gidnumber=500 homedirectory=/home/usuario # numResponses: 2 # numEntries: 1

  Note que as ACLSs deverão estar elaboradas de tal forma, que o atributo userpassword possa ser lido somente pelo próprio usuário e pelo usuário root.

ldap[s]://<maq><:porta>/<base>?<atrib>?<escopo>?<Filtro>

NSS com o LDAP

Seu servidor LDAP pode autenticar usuários, usando um mecanismo chamado PAM[6] (Módulos de Autenticação Plugáveis). Desde o princípio do Linux, a autenticação de um usuário foi feita através da entrada de uma senha pelo usuário, e o sistema verificando se a senha digitada corresponde à senha oficial criptografada, que fica armazenada no arquivo /etc/passwd. Isto foi apenas no início. Desde então, um número de novos caminhos para a autenticação de usuários vem se tornando popular, incluindo substituições mais complicadas, como por exemplo para o arquivo /etc/passwd e dispositivos de hardware chamados de Smart Cards.

O problema é que a cada vez que um novo esquema de autenticação é desenvolvido, requer que todos os programas necessários (login, ftpd, etc.) sejam reescritos para suportar este novo esquema. O PAM fornece um caminho para desenvolver programas que são independentes do esquema de autenticação. Estes programas precisam de módulos de autenticação, anexados a eles em tempo de execução, para que possam funcionar.

A seguir será visto como configurar o seu sistema para fazer a autenticação via LDAP.

No diretório /usr/share/doc/pam_ldap-XX, onde XX é a versão do módulo instalado, você encontrará o diretório pam.d.conectiva que é a recomendação da Conectiva para o conteúdo do diretório /etc/pam.d. Faça um backup do seu diretório /etc/pam.d original e copie o novo diretório recomendado para o mesmo local:

# mv /etc/pam.d /etc/pam.d.org 
# cp -R /usr/share/doc/pam_ldapXX/pam.d.conectiva /etc/pam.d

Edite o arquivo /etc/ldap.conf e altere as linhas HOST e BASE como já foi feito para o arquivo /etc/openldap/ldap.conf. Altere também o arquivo /etc/nsswitch.conf para o seguinte conteúdo:

passwd:     files ldap nis nisplus
shadow:     files ldap nis nisplus
group:      files ldap nis nisplus

Para testar a autenticação e o NSS, faça uma cópia do seu /etc/passwd:

# cp /etc/passwd /etc/passwd.org

Remova deste arquivo um usuário com o comando userdel nome-do-usuário, para ter certeza de que ele não será encontrado no /etc/passwd. Em seguida, experimente:

$ id  usuario_removido

Será possível visualizar o nome do usuário. Experimente também acessar o Conectiva Linux com o usuário que havia no arquivo /etc/passwd.

# mv /etc/passwd.org /etc/passwd

O Cliente de LDAP GQ

O GQ é um cliente LDAP para o ambiente X, com uma interface simples escrito para o Gnome, sendo possível executá-lo em outros gerenciadores de janela também. Instale-o utilizando o Synaptic e selecionando o pacote gq para a instalação.

Como usuário normal, inicialize o programa com o comando gq. Sua configuração também é simples, bastando adicionar o servidor LDAP que você gostaria de usar, e a Base DN do diretório. Um recurso interessante deste aplicativo é o modo de navegação, sendo possível observar o diretório em árvore e ter uma visão completa de todos os dados do diretório.

$ gq

Para adicionar uma base, dirija-se ao menu File -> Preferences e selecione a aba Servers, pressionando o botão New para adicionar as configurações sobre o servidor LDAP.

Você já pode efetuar consultas. Vá para a aba Search, na janela principal, e proceda sua busca, selecionando o servidor. Em seguida, clique em Find, e o gq irá fazer a busca no servidor, mostrando os dados em caso de sucesso, ou mostrando uma mensagem No entries found caso os dados não estejam no servidor.

Veja na Figura 5-6 um exemplo de conexão:

Em seguida, serão mostradas as informações sobre o usuário teste.

Pré-requisitos

São necessários os seguintes pré-requisitos para a implementação deste serviço:

• no mínimo 1 (um) modem;

• opcionalmente uma placa multiserial para permitir um maior número de conexões;

• o servidor pppd corretamente configurado para aceitar conexões.

Instalação

Execute o Synaptic e instale os seguintes pacotes necessários para um servidor de autenticação com Radius e Portslave:

• radiusd-cistron

• portslave

• linuxconf-radiusconf

ou utilize o apt-get para a instalação:

# apt-get install radiusd-cistron portslave 
# apt-get install linuxconf-radiusconf

Configuração

Primeiramente, será feita a configuração do Radius, e para isso execute o Linuxconf e dirija-se ao menu Configuração -> Rede -> Tarefas de servidor -> Configurador Radius. Esta configuração é dividida em três partes:

Em seguida, execute o servidor Radius (radiusd) no menu Controle -> Painel de Controle -> Controle de atividade de serviços.

O próximo passo é a configuração do Portslave. Para isso, dirija-se ao menu Configuração -> Rede ->Tarefas de Servidor -> Configurador Portslave. Existem duas opções:

Além destas configurações, você deve editar o arquivo /etc/inittab e adicionar uma linha para cada linha dialin que você tenha configurado. As linhas devem se parecer com:

T0:23:respawn:/usr/bin/portslave 0

Testes de Configuração

• Pode-se testar a configuração do Radius através do comando radtest. Primeiro teste com um usuário que realmente esteja cadastrado em seu sistema, ou seja, que deve receber permissão de acesso. Por exemplo, vamos supor que queiramos testar uma tentativa do usuário "teste" para conectar-se à porta 21 com sua senha "senha123". A requisição vem do servidor de acesso kepler.minhaorganizacao:

  # radtest teste senha123 kepler.minhaorganizacao 21 123chave Sending request. radrecv: Reply from host 127.0.0.1 code=2, id=26, length=20

  O usuário pode conectar-se.

• Teste novamente a autenticação com o comando radtest mas informe uma senha incorreta:

  # radtest teste senhaerrada kepler.minhaorganizacao 123chave Sending request. radrecv: Reply from host 127.0.0.1 code=3, id=60, length=20 Access denied.

  O servidor de autenticação não irá permitir o acesso.

• Uma outra possibilidade é a do servidor de acesso enviar uma chave de criptografia errada ao servidor Radius:

  # radtest teste senha123 kepler.minhaorganizacao chave123 Sending request. Warning: Received invalid reply digest from server radrecv: Reply from host 127.0.0.1 code=3, id=60, length=20 Access denied.