OpenLDAP – Uma abordagem integrada

Archive for the 'BIND9' Category

Instalação e Configuração do Samba4

clodonil October 7th, 2009

by: Diego Pereira Grassato

Instalação Samba4

Em janeiro de 2006 foi lançando a primeira versão beta do samba4. Mesmo antes desta data várias informações já eram dadas sobre as características do novo "servidor de arquivos". Uma das informações que mais chama a nossa atenção era sobre a integração do SAMBA com o AD.

Agora com a versão ALPHA 9 já podemos testar e verificar as principais características do SAMBA4.

Softwares utilizados:

· Linux: Slackware 12.2 – Current Version

ftp://ftp.slackware.no/pub/linux/ISO-images/slackware/Current-ISO-build/

· PhpLDAPadmin 1.1.0.7

http://phpldapadmin.sourceforge.net/

· Samba 4 Alpha9

Via Git: "git clone git://git.samba.org/samba.git samba-master; cd samba-master && git checkout -b master origin/master; cd .."

· Heimdal Kerberos

http://www.h5l.org/dist/src/heimdal-1.2.1.tar.gz

· Bind 9

ftp://ftp.isc.org/isc/bind9/9.5.2/bind-9.5.2.tar.gz

Dependências de Outros softwares para o perfeito funcionamento

Para o perfeito funcionamento do Samba4 depois de vários testes foi visto que o DNS é um dos requisito primordiais para seu funcionamento adequado e reconhecimento de algumas diretivas impostas pelo samba4. Por isso recopilaremos o BIND com suporte a Heimdal Kerberos, existem duas implementações de código aberto do Kerberos: Heimdal e MIT Kerberos. Heimdal é uma implementação do protocolo Kerberos implementada pela KTH (Royal Institute of Technology, em Estocolmo), enquanto MIT Kerberos é fornecido pelo MIT (Massachussets Institute of Technology), como diz seu nome.

Autenticação Kerberos é um protocolo de rede. Foi concebido para fornecer autenticação forte para o cliente/servidores de aplicativos usando criptografia de chaves secretas, então um cliente pode provar a sua identidade para um servidor (e vice-versa) em uma conexão de rede insegura.

Em nosso caso utilizaremos BIND com suporte ao Heimdal Kerberos por causa do GSS-TSIG algoritmo de serviço de segurança genérico para autenticação de transação com chave secreta de DNS (GSS-TSIG) este mecanismo é utilizado para estabelecer relações TSIG para autenticação do tipo Kerberos, necessário para interagir BIND com Samba4, com essas credenciais o DNS aceita atualizações GSS-TSIG assinadas e verifica as credenciais de correspondentes com as credencias cadastradas no Samba4, isso permite aos usuários descarregar o DNS dos usuários do Microsoft Windows sem ter a segurança comprometida.

Compilação e Instalação

Começaremos pelo Heimdal:

#tar –zxvf heimdal-1.2.1.tar.gz

#cd heimdal-1.2.1

#./configure –prefix=/usr –libdir=/usr/lib \
–sysconfdir=/etc –localstatedir=/var \
–mandir=/usr/man –with-openssl=/usr –bindir=/usr/bin/ \
–sbindir=/usr/sbin/ –enable-kcm

#make && make install

Criaremos o usuário e o grupo responsável pelo "Bind", e efetuaremos a compilação:

# groupadd named && useradd named –g named
#tar –zxvf bind-9.5.2.tar.gz
#cd bind-9.5.2
#./configure   –prefix=/usr   –libdir=/usr/lib \
–sysconfdir=/etc –localstatedir=/var   –with-libtool   \
–mandir=/usr/man   –enable-shared   –disable-static   \
–enable-threads –with-openssl=/usr –with-gssapi=/usr/include/gssapi –bindir=/usr/bin/ –sbindir=/usr/sbin/

#make && make install

Adicione seu host em "/etc/hosts", para ajudar na resolução de nomes, em meu caso ficou deste modo:

#vi /etc/hosts

127.0.0.1 localhost
192.168.11.1 dtux.org dtux

Testando o funcionamento do "Bind":

#named –u named -g
25-Sep-2009 11:00:21.348 zone dtux.org/IN: loaded serial 2009091112
25-Sep-2009 11:00:21.350 running
25-Sep-2009 11:00:21.350 zone dtux.org/IN: sending notifies (serial 2009091112)

Compilação

Após fazer o download, foi criado um diretório chamando samba-master. Os fontes do SAMBA4 ficaram dentro do diretório source4, criaremos um link simbólico apontando para source.

# cd samba-master/
# ln –s source4 source
# cd source
#./autogen.sh

#./configure –prefix=/usr/local/samba –sysconfdir=/etc/ –localstatedir=/var –mandir=/usr/man/ –enable-fhs –enable-debug –bindir=/usr/bin –sbindir=/usr/sbin –libdir=/lib –enable-developer

# make && make install

Após a instalação rode o utilitário "provision" para a criação do domínio e do usuário administrator e sua respectiva senha:

#./setup/provision –realm=DTUX.ORG –domain=DTUX –admin=anna –server-role=’domain controller’

O parâmetro "–realm" é para definir o domínio do servidor Kerberos e o "domain" para o domínio SAMBA.

O SAMBA4 trás embutido os protocolos:

DNS – ( Bind )
SMB-( Samba 3 )
LDAP( OpenLdap )
KERBEROS( Heimdal )
MS-RPC – ( GPO )

Credenciais Utilizando base SamDB

… que são responsáveis pela autenticação Active Directory.

O diretório “/usr/local/samba” é gerado pela compilação do SAMBA e tem os seguintes subdiretórios:

· /usr/bin: Programas para gerenciamento do samba, tais como smbstatus, net, etc.
· /usr/sbin: Programa responsável por inicializar o samba.
· /etc/samba: Neste diretório fica o arquivo de configuração smb.conf
· /usr/lib: Todas as libs compiladas do samba
· /var/lib/samba/private: Exemplos de arquivos de configuração

Configuração do Bind

Após a instalação, configuramos o servidor DNS para trabalhar juntamente com o KERBEROS e KERBERO com BIND. Utilize os arquivos exemplos gerados pelo próprio SAMBA que estão dentro do diretório "/var/lib/samba/private". Edite o arquivo "/etc/named/named.conf" adicione as seguintes linhas:

#vi /etc/named/named.conf

Na sessão “option{}” adicione as linhas que irão fazer a comunicação ente o Keberos e o Bind:

options{
directory "/var/named";
tkey-gssapi-credential "DNS/dtux.org";
tkey-domain "DTUX.ORG";
}

Depois de configurado a sessão "options" incluiremos o arquivo "named.conf" do Samba4 no BIND, abaixo da sessão "options" adicione:

options{

   directory "/var/named";
   tkey-gssapi-credential "DNS/dtux.org";
   tkey-domain "DTUX.ORG";

}

include "/var/lib/samba/private/named.conf";

Nesse arquivo está a zona configurada pelo Samba4 quando foi utilizado o utilitário “provision”. Antes de testar o funcionamento do Bind, temos que setar as variáveis de localização do arquivo “dns.keytab”, que é onde estão as informações de DNS registradas pelo Samba4:

# KEYTAB_FILE=“/var/lib/samba/private/dns.keytab"
# export KRB5_KTNAME=“/var/lib/samba/private/dns.keytab"

Para não termos que ficar digitando essas linhas a todo o momento coloquemos elas no inicio do arquivo “/etc/rc.d/rc.bind”, responsável pela inicialização do daemon do named.

#killall -9 named
#named –u named
#ps ax |grep named
4450 ? Ssl 0:00 named -u named
4455 pts/3 R+ 0:00 grep named

Pronto seu Bind já estará rodando e trocando informações com o Samba4, vamos fazer um teste para verificar se seu funcionamento está ok, utilizaremos a ferramenta “nsloockup”:

Caso você queira configurar um DNS reverso para o IP de seu samba fica a seu critério. Também copiaremos o arquivo “krb5.conf” que está em “/var/lib/samba/private/“ para o diretório “/etc/”.

Por utilizar o Kerberos, é necessário que todas as máquinas envolvidas estejam com os mesmos horários (segundos) sincronizados. Para isso nada melhor do que setar o “Samba” para ser o nosso time server, adicione ao "/etc/samba/smb.conf" na sessão “[globlas] “time server = yes”, nos cliente é só setar “net time \\dtux.org /set /Yes”, que o horário ficará sincronizado o com o do servidor.

Acerte o sistema de arquivo para trabalhar com o “xattr” alterando o arquivo “/etc/fstab”.

/dev/sda1 ext3 defaults,user_xattr 0 1

Remonte o sistema para ativar as alterações.

# mount -o remount,rw /

Para testar, criemos alguns compartilhamentos. Para isso edite o arquivo “smb.conf” que está dentro do diretório “/etc/samba/”.

[profiles]
   comment = Profiles Remotos
   path = /home/profiles
   read only = no
   browseable = no

O compartilhamento “Profiles” indica a localização dos profiles dos usuários nesse caso se tratando de uma configuração para “Perfil Móvel(Roaming Profile)”

Agora testaremos alguns serviços e verificar se estão todos funcionais.

Iniciando do Samba

#samba -i -M single

Iniciando do Samba em modo debug

#samba -i -M single –d3

Iniciando do Bind

#/etc/rc.d/rc.bind start

Pronto com isso no servidor já está no ar com DNS funcionado, vamos a alguns testes:

Samba4

Autentique algum usuário do Samba4 com:

# smbclient //dtux.org/profiles -Uadministrator%anna

smb: \> dir
.                              D        0 Wed Sep 23 11:31:36 2009
  ..                             D        0 Tue Sep 22 17:26:38 2009
  Admin                          D        0 Tue Sep 22 15:28:02 2009
  alexandro                      D        0 Tue Sep 22 17:19:31 2009
  diego                          D        0 Mon Sep 21 16:42:47 2009
  nazir                          D        0 Wed Sep 23 11:31:36 2009
  danilo                         D        0 Tue Sep 22 12:04:42 2009
  gustavo                        D        0 Tue Sep 22 12:16:04 2009
  zeh                            D        0 Tue Sep 22 17:32:59 2009
  satarosa                       D        0 Tue Sep 22 17:26:38 2009
  anna                           D        0 Mon Sep 21 16:51:32 2009

Kerberos

Autentique algum usuário do Samba4 com e ofereça a senha quando pedido:

#kinit administrator@DTUX.ORG
Password for administrator@DTUX.ORG:
Verificando os tickets de conexão:

#klist

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: administrator@DTUX.ORG
Valid starting Expires Service principal
09/25/09 14:22:50 09/26/09 14:22:48 krbtgt/DTUX.ORG@DTUX.ORG

Verificando os tickets de conexão e os métodos de autenticação aplicados:

#klist -e

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: administrator@DTUX.ORG
Valid starting Expires Service principal
09/25/09 14:22:50 09/26/09 14:22:48 krbtgt/DTUX.ORG@DTUX.ORG
Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with HMAC/md5

Windows sendo Dominado pelo Samba4

Para colocar o Windows XP no domínio do samba, além da configuração de hora já foi falado, devemos configurar o ip da máquina onde está o samba4 no DNS do micro com Windows XP/2003/2008/7.

No Windows XP segue as seguintes configurações para se entrar em domínio, este procedimento serve para Windows XP/2000/2003/2008/7:

· Menu Iniciar -> Painel de Controle -> Sistema

· Guia “Nome do Computador”

· Alterar

· Marque o checkbox “Domínio”

· Coloque o seu domínio (DTUX.ORG) -> OK

· Caso ocorrer algum problema de apontamento de DN, pode-se editar o arquivo “C:\WINDOWS\system32\drivers\etc\hosts”, no arquivo “hosts” você coloca o IP do servidor samba e na frente o seu respectivo DNS name desta forma:

o 127.0.0.1 localhost

o 192.168.11.2 dtux.org dtux

Simple no primeiro logon logue como administrator, caso você queira fazer parte da administração do Samba4 através do “Windows Server 2003 Administration Tools Pack” antes de instalá-lo, instale o “Windows Server 2003 Suporte Tools”:

· http://www.microsoft.com/downloads/details.aspx?FamilyID=c16ae515-c8f4-47ef-a1e4-a8dcbacff8e3&displaylang=en

· http://download.microsoft.com/download/3/e/4/3e438f5e-24ef-4637-abd1-981341d349c7/WindowsServer2003-KB892777-SupportTools-x86-ENU.exe

Aproveitando vamos criar um “Perfil Remoto”, um problema encontrado com perfil remoto foi encontrado quando você cria um usuário pelo “Administrator Tolls” esse usuário não terá acesso ao Shell do Linux e com isso ele não irá conseguir ditar permissões de escrita e leitura. Portanto para criar usuário utilize o script da pasta: /usr/local/samba/share/samba/setup/.

· newuser

Antes de utilizá-lo você tem que adicionar o usuário no Linux usando o comando comum “useradd”.

Iremos simular o seguinte ambiente, criaremos um grupo e adicionaremos um usuário no Linux a colocaremos esse usuário no grupo criado entre no “Administrator Tools”, criaremos o grupo também e utilizaremos o script “newuser” para adicionar o usuário no samba4.

· Criando grupo:

#groupadd samba4

· Criando usuário no Linux:

#useradd teste –g samba4 -p senha –c “Teste Samba4 Users”

· Criando a pasta do profile do usuário, levando em consideração que “/home/profiles”, já foi feito acima:

#mkdir -p /home/profiles/teste

· Ditando permissões de acesso a pasta para este usuário recém criado:

#chown teste:samba4 /home/profiles/teste

Agora usaremos o script “newuser” para fazer a importação, um problema encontrado foram as bibliotecas python utilizadas por esse scripts elas estão localizadas em “/usr/local/samba/lib/python2.6/site-packages”, temos que copiar todo esses arquivos para a pasta real do python do sistema “/usr/lib/python2.6/site-packages/”:

#cd /usr/local/samba/lib/python2.6/site-packages
#cp –rp * /usr/lib/python2.6/site-packages/

Vamos fazer a copia do “newuser” para nosso diretório “/usr/sbin”:

#cp /usr/local/samba/share/samba/setup/newuser /usr/sbin

Tudo pronto para a execução do script:

#newuser teste senha –unixname=teste -k KERBEROS –workgroup=dtux.org

· –unixname: Usuário criado no Linux/Unix

· -k KERBEROS: Utiliza autenticação Kerberos

· –workgroup: Domínio Criado

Agora quando você autenticar no Windows com este usuário que ele já está sincronizado, quando você abrir o “Administrator Tools” pelo menu “Iniciar -> Executar”, digite “dsa.msc”.

Depois clique em seu domínio e vá em “Users” o usuário já irá aparecer na listagem, criaremos o grupo “samba4” pelo “Administrator Tools” e adicionaremos o usuário “teste” neste grupo, e configuraremos o seu profile remoto.

Criando o grupo: “Botão direito em Builtin ->Novo -> Group”, dê um nome uma descrição.

Agora na guia “Members” você define os usuários que farão parte deste grupo.

Os usuários que foi importamos já estão criados agora é só acertar alguns detalhes em “User logon name” que é o nome de logon é só colocar o nome do usuário e na frente o “@DOMINIO”, marque as opções “Use cannot chance password” se não quer que os usuários alterem a senha, e “Password never expires”, pra ela numca expirar.

Iremos agora á guia “Profile” e em “Profile Path” definiremos o caminho do diretório remoto onde serão armazenados os arquivos do usuário.

Em “Map Folder”, podemos colocar esse caminho do profile do usuário para ser montado em uma unidade de mapeamento de rede.

Podemos através do Windows os tickets do Kerberos através do “Windows Server 2003 Resource Kit Tools” (http://www.microsoft.com/downloads/details.aspx?familyid=9d467a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en). Utilizaremos Klist e o Kerbtray, que ficam localizadas em: “Iniciar -> Windows Resource Kit Tolls -> Command Shell”.

KLIST

A ferramenta klist é uma ferramenta de linha de comando que permite que você exiba o conteúdo dos cache de credenciais e pode ser usada em um cliente Windows para exibir ou destruir credenciais existentes de Kerberos.

A ferramenta klist exige um argumento. O argumento "tgt" mostra as credenciais no cache atual, e o argumento “tickets” mostram as credenciais em cache.

KerbTray

A ferramenta Kerberos Tray, KerbTray, (kerbtray.exe) é uma ferramenta gráfica da plataforma Windows que exibe informações de tickets Kerberos em um computador de plataforma Windows onde os tickets Kerberos foram armazenados no cache de credenciais. Os tickets Kerberos são adquiridos e armazenados nas credenciais de cache quando um usuário autenticar em um computador de plataforma Windows (cliente ou servidor) como um usuário de domínio. O KerbTray permite que você visualize e limpe o cache de ticket.

Quando executado, a ferramenta coloca um ícone na bandeja do sistema. Esse ícone exibe o status com base na presença ou ausência de credenciais válidas. Dados disponibilizados pela interface KerbTray incluem os selos de tempo nos tickets, os marcadores associados às credenciais e o(s) tipo(s) de criptografia dos tickets.

Administração do Samba4 via phpLDAPadmin

phpLDAPadmin é uma interface gráfica para gerenciar a base de dados LDAP. Para seu funcionamento será necessário ter instalação do Apache com suporte à PHP versão 5 ou 4 se preferir. O seu site oficial é (http://phpldapadmin.sourceforge.net).

#wget –C http://ufpr.dl.sourceforge.net/sourceforge/phpldapadmin/phpldapadmin-1.1.0.7.tar.gz  # tar -zvzf phpldapadmin-1.1.0.7.tar.gz # mv phpldapadmin-1.1.0.7 phpldapadmin

Copiaremos a pasta “phpldapadmin” na pasta do apache

# mv phpldapadmin /srv/www/htdocs

Acesse a pasta onde estão as configurações de seu samba, lá você irá encontrar um arquivo de configuração devidamente configurado para se conectar ao samba4, copie para a pasta de configuração do “phpLDAPadmin”.

# cd /var/lib/samba/private # cp phpldapadmin-config.php /srv/www/htdocs/ldap/config/config.php

Seu apache deve estar devidamente configurado com suporte a PHP. Caso você esteje utilizando o Slackware Linux, apenas descomente a linha “Include /etc/httpd/mod_php.conf” de seu “httpd.conf” em “/etc/httpd” e reinicie o apache:

# apachectl restart

Abra seu navegador no seguinte endereço:

http://localhost/phpldapadmin/index.php

Irá abrir a pagina lhe pedindo usuário e senha, você pode conectar usando o usuário “Anônimo” ou como “Administrator”. Para se conectar como “Administrator” você deve indicar o caminho completo da localização do usuário, neste caso ele se encontra em “CN=Users,DC=dtux,DC=org”, para o usuário “Administrator” ficará assim:

 CN=Administrator,CN=Users,DC=dtux,DC=org

Você pode se conectar com qualquer usuário desde que indique o seu caminho completo, assim como o “Administrator”

Arquivos de configuração, lembrando que esse foram usados na minha estrutura, lembre-se cada caso é um caso:

Unknown smb.conf - Arquivo de configuração do samba
Unknown named.conf - Arquivo principal do bind
Unknown dtux.org.zone - Zona principal criada pelo samba e adaptada
Unknown 11.168.192.in-addr.arpa - Zona Reversa baseada na Zona Principal
Unknown krb5.conf - Arquivo de configuração do Keberos criado pelo samba
Unknown adminSamba4.sh - Script criado por mim, para ajuda na tarefa de criar usuários no linux e im porta-los para Active Directory do Samba4, simple que pode evoluir, sujestões são aceitas.

Fontes de Apoio:
http://wiki.samba.org/index.php/Samba4/HOWTO
http://www.vivaolinux.com.br/artigo/Samba-4-como-controlador-de-dominio-com-Active-Directory-da-MShttp://www.nisled.org/?p=68

Tags: profile, SAMBA4

BIND9 , SAMBA4
Comments(3)

Servidor DNS (BIND9) – Integração Perfeita com o GOsa

clodonil August 9th, 2009

1. Introdução

O servidor DNS é utilizado para resolver nomes de computadores, ou seja, toda vez que chega uma requisição com um nome (ex: www.nisled.org), ele o transforma em um endereço IP. O servidor DNS é a base da Internet. Para uma compreensão mais ampla, imagine a Internet sem o servidor DNS: tudo funcionaria sem problemas; no entanto, imagine que, ao invés de acessar os sites pelos nomes (www.uol.com.br, www.estadao.com.br, www.nisled.org, etc.), você teria que decorar o endereço IP dos servidores para poder acessá-los!

Se decorar número de telefone já é difícil, imagine decorar IPs.

Normalmente, o DNS mantém suas informações numa lista gravada num arquivo de texto simples. No entanto, ao estudar a sua estrutura, descobrimos que ele trabalha em forma de árvore. Portanto, é possível diminuir as despesas gerais de administração (gerenciamento dos domínios) guardando os dados do DNS em forma de árvore; a estrutura geral do OpenLDAP já contribui para isso.

Outro fator que contribui para o uso do OpenLDAP é o fato dos servidores DNS necessitarem de uma replicação de dados para o DNS secundário. Como esse serviço já vem implementado no OpenLDAP, torna-se muito mais fácil a sua implementação. Os requisitos de segurança para a replicação são satisfeitos pelo OpenLDAP, o que nem sempre acontece com os servidores DNS.

Vamos começar esse artigo, descrevendo como criar a estrutura do DNS dentro do LDAP com ajuda do GOsa. Neste artigo vamos utilizar como exemplo o domínio "curso.ldap" e o ip do servidor 192.168.0.1.

2. GOsa

O ambiente GOsa é uma poderosa ferramenta de gerenciamento de recursos de rede no LDAP, e como não poderia ser diferente, ele tem suporte para gerenciar as entradas para o servidor BIND.

Para começar a criar as entredas para o BIND, entre no ambiente GOsa e logo em seguida click no ícone "Systems" como mostra a figura 1.

Figura 1 – Ambiente central do GOsa

Ao entrar no "Systems" será mostrada todos os componentes cadastrados, caso existão. Na parte superior da tela temos as lista de sistemas que podem ser cadastrados. Escolha criar um novo servidor como mostra a figura 2.

Figura 2 – Lista de Sistemas

Ao entrar na tela para criar um novo servidor, automaticamente abrirá a aba "Generic". Nela devem ser preenchidos os campos "Server name" ,endereço de IP e MAC. Esses dados não são utilizados pelo DNS, apenas para cadastrar o servidor. A figura 3 mostra o cadastro desta tela.

Figura 3 – Cadastro do servidor

Após o cadastro dos dados na primeira aba, click na aba "DNS" para criar uma nova zona de DNS. Para isso click no botão "Add", como mostra a figura 4.

Figura 4 – Criação de uma zona de DNS

Para adicionar uma nova zona, preencha os dados de acordo com o domínio desejado. O campo "zone name" define o domínio que será criado. Também defina o endereço da rede e a mascara. Os campo da área "SOA record" definem o cabeçalho do servidor dns, por isso preencha os campos "Primary dns Server for this zone" com o nome do servidor dns, como mostra a figura 5. Lembre-se de cadastrar essa servidor no registro de nome e também resolver esse nome no arquivo /etc/hosts do servidor dns. Também preencha os campos de email. Na área "MxRecords" registre os servidores de email deste domínio, lembre-se que o nome do servidor neste caso deve terminar com ponto (mail.curso.ldap.). Para editar os computadores deste domínio é necessário primeiramente salvar a zone para o botão "Zone records" habilitar.

Figura 5 – Criação da zona

Após salvar o registro da zona, aba novamente que o botão "Edit" estará habilitado e com ele podemos cadastrar os computadores do domínio, como mostra a figura 6.

Figura 6 – Criação das maquinas domínio

3. BIND9

Com a criação do domínio no GOsa, vamos passar para a instalação do servidor dns. Será utilizado o pacote pré-compilado para o servidor Ubuntu.

# apt-get install bind9

O próximo passo é a configuração da zona no bind9. Para isso altere o arquivo /etc/bind/named.conf acrescentando as seguintes linhas.

zone "curso.ldap" {
type master;
file "/etc/bind/db.curso.ldap";
};

zone "0.168.192.in-addr.arpa" {
type master;
file "/etc/bind/rev.curso.ldap";
};

O próximo passo é criar os arquivos db.curso.ldap e o arquivo rev.curso.ldap. Esses arquivos são criados através de um script que exporta as informações do LDAP (GOsa).

4. ldap2zone

Utilizaremos o script ldap2zone para exportar os registros da base LDAP. Esse script foi escrito com a linguagem de C, portanto é preciso compilá-lo. Para realizar essa tarefa entre no diretório /usr/local/src, e faça download do script.

# cd /usr/local/src
# wget www.venaas.no/dns/ldap2zone/ldap2zone.c

Antes de começar a compilar os fontes do script, instale os pré-requisitos que são as bibliotecas do LDAP e os compiladores.

# apt-get install libc6-dev gcc libldap2-dev

A compilação do script de exportação é bem simples. Segue o passo para a compilação.

# gcc -o ldap2zone -lldap -llber ldap2zone.c

Após a compilação mova o arquivo binário compilado para o diretório /usr/local/bin.

# mv ldap2zone /usr/local/bin

Agora com o script compilado, vamos realizar alguns testes para verificar se exportação está sendo realizada.

Primeiro vamos exportar o db.

# ldap2zone curso.ldap. ldap://192.168.0.10 604800
$TTL 604800
@ IN SOA ns1.curso.ldap. clodonil.nisled.org. (
   2009080904 ; Serialnumber
   3600 ; Refresh
   1800 ; Retry
   720000 ; Expire
   6400 ) ; Minimum TTL

   NS ns1.curso.ldap.
   MX 0 mail.curso.ldap.
   MX 1 server.curso.ldap.
www 7440 A 192.168.0.1
mail 7440 A 192.168.0.1
server 7440 A 192.168.0.1
ns1 7440 A 192.168.0.1

Como pode ver a exportação foi feita corretamente, também vamos testar a exportação do reverso.

# ldap2zone 0.168.192.in-addr.arpa ldap://192.168.0.10 604800
$TTL 604800
@ IN SOA ns1.curso.ldap. clodonil.nisled.org. (
   2009080904 ; Serialnumber
   3600 ; Refresh
   1800 ; Retry
   720000 ; Expire
   6400 ) ; Minimum TTL
   NS ns1.curso.ldap.
   MX 0 mail.curso.ldap.
   MX 1 server.curso.ldap.
1 7440 PTR www.curso.ldap.
   7440 PTR mail.curso.ldap.
   7440 PTR server.curso.ldap.
   7440 PTR ns1.curso.ldap.

Para tornar a tarefa de exportação mais automatizada, vamos criar um script para exportar as entradas do LDAP e criar os respectivos arquivos. Segue o script.

#!/bin/bash

ldap2zone 0.168.192.in-addr.arpa ldap://192.168.0.10 604800 > /etc/bind/rev.curso.ldap
ldap2zone curso.ldap. ldap://192.168.0.10 604800 > /etc/bind/db.curso.ldap

Para não precisar ficar executando o script toda vez que fizer uma alteração pelo GOsa, vamos colocar o script no crontab e pedir para executar em 5 em 5 minutos.

*/5 * * * * /usr/local/bin/dns.sh

5. Teste

Para realizar os testes que precisamos, vamos primeiramente reiniciar o servidor DNS.

# /etc/init.d/bind9 restart

O próximo passo é alterar o arquivo /etc/resolv.conf, e "apontar" para o servidor DNS que acabamos de configurar.

nameserver 192.168.0.1

Em seguida utilize o comando ping para verificar se o servidor tá "resolvendo" o nome pesquisa.

# ping www.curso.ldap
PING www.curso.ldap (192.168.0.1) 56(84) bytes of data.
64 bytes from nucleo.local (192.168.0.1): icmp_seq=1 ttl=64 time=0.037 ms
64 bytes from nucleo.local (192.168.0.1): icmp_seq=2 ttl=64 time=0.054 ms
64 bytes from nucleo.local (192.168.0.1): icmp_seq=3 ttl=64 time=0.056 ms

Conforme o resultado apresentado pelo comando ping, o servidor DNS tá funcionando corretamente.

6. Troubleshooting

Verifique se os arquivos db e rev estão sendo gerados pelos scripts;
Verifique os logs do bind9 (tail –f /var/log/daemon)
No GOsa verifique se colocou ponto (.) no final dos nomes definidos como servidor de e-mail.

Tags: BIND9, GOsa, OpenLDAP

BIND9 , GOsa , OpenLDAP
Comments(0)

Servidor DNS (BIND9) com OpenLDAP

clodonil June 26th, 2009

By:Diego Pereira Grassato

Muitas vezes, é desejável para armazenar informações de DNS em um banco de dados, e não em zonas em arquivos texto ASCII plano. Armazenar estes arquivos em uma zona de dados pode reduzir muito overhead desde associar informações, tais como contato de faturamento, gerenciamento de contas, backup simplificado, etc., podem ser armazenadas e processadas no interior do mesmo banco de dados. Além disso, devido à natureza do DNS(concepção), a informação deve ser armazenada redundantemente em dois ou mais hosts. O clássico de dados através da replicação zona transferência não é confiável, inseguro e muitas vezes difíceis de administrar.

Para ultrapassar este problema alguns projetos de DNS para armazenar informações em bancos de dados relacionais foram desenvolvidos. Como dito acima o DNS gravas sua informações em uma lista em arquivo de texto, no entanto se estudarmos sua estrutura veremos que ele trabalhar em forma de árvore, porque se trata de um sistema de diretório, igual ao LDAP. LDAP permite certa flexibilidade na sua base de dados usando esquema, assim como de uma organização cresce e muda constantemente; o banco de dados utilizado para armazenar informações tem que reflitam a organização.

1. BIND (Named)

BIND (Berkeley Internet Name Domain ou, como chamado previamente, Berkeley Internet Name Daemon) é o servidor para o protocolo DNS mais utilizado na Internet, especialmente em sistemas do tipo Unix, onde ele pode ser considerado um padrão de fato. Foi criado por quatro estudantes de graduação, membros de um grupo de pesquisas em ciência da computação da Universidade de Berkeley, e foi distribuído pela primeira vez com o sistema operacional BSD. O programador Paul Vixie, enquanto trabalhava para a empresa DEC, foi o primeiro mantenedor do BIND. Atualmente o BIND é suportado e mantido pelo Internet Systems Consortium. Seu site oficial é:
https://www.isc.org/software/bind.

O BIND é uma implementação do protocolo DNS e inclui os seguintes serviços:

Um servidor de domínios (named)
As bibliotecas para conversão de nomes de domínio em endereços de IP.
Outras ferramentas para verificar o funcionamento do servidor DNS e suas respectivas Zonas configuradas.
Para a versão 9, o BIND foi praticamente reescrito. Ele passou a suportar, dentre outras funcionalidades, a extensão DNSSEC e os protocolos TSIG e IPv6

1.1 Compilando BIND

Primeiro precisamos baixar e extrair a fonte do BIND-SDB-LDAP. Podemos realizar esta tarefa, que vai para o diretório BIND: Segue os links:

http://bind9-ldap.bayour.com/bind-sdb-ldap-1.1.0.tar.gz

Para maiores Informações de versões recentes do software:

http://www.venaas.no/ldap/bind-sdb/

BIND SDB LDAP é uma modificação do "Simplified Database" API que fornece uma interface LDAP para bind9 utilizando o "sdb". Com esta API, pode armazenar zonas do BIND no LDAP em vez de arquivos. Note que quando utiliza sdb, as zonas não são colocadas em cachê na memória, BIND irá efetivamente realizar uma pesquisa de dados sempre que recebe uma consulta.

Uma vez baixado, extraia-o para o diretório de sua escolha, executando o seguinte comando:

root@host#tar -xzf bind-sdb-ldap-1.1.0.tar.gz

Isto irá criar um bind-sdb-ldap-1.0 diretórios com a fonte no mesmo. Agora vamos ao BIND, faça o download da fonte em:

http://www.bind9.net/download

ou link direto:

ftp://ftp.isc.org/isc/bind9/9.6.1rc1/bind-9.6.1rc1.tar.gz

Procure baixa sempre a versão mais recente.

Copie a ldapdb.c bin/named e ldapdb.h para bin/named /include na árvore fonte.

root@host#cp ldapdb.c ../bind-9.6.1rc1/bin/named/
root@host#cp ldapdb.h ../bind-9.6.1rc1/bin/named/include
root@host#cd /root/bind-9.6.1rc1

Após os arquivos de origem tenham sido copiados para o diretório do bind9, então precisamos fazer algumas modificações no fonte do bind9 para que seja compilado com a nova API.

Altere os diretórios para /root/bind-9.6.1rc1/bin/named/Makefile.in e editar o arquivo e faça as seguintes modificações quando você vê estas linhas:

DBDRIVER_OBJS = ldapdb.@O@
DBDRIVER_SRCS = ldapdb.c
DBDRIVER_INCLUDES = -I/usr/local/include
DBDRIVER_LIBS = -L/usr/local/lib -lldap -llber -lresolv

Em seguida, será necessário modificar o arquivo para /root/bind-9.6.1rc1/bin/named/main.c no mesmo diretório do Makefile.in e procure a seguinte linha:

/* #include "xxdb.h" */
Temos que mudar-lo para utilizar a fonte LDAPDB arquivo:
#include <ldapdb.h>
No mesmo arquivo, procure a inicialização linha:
/* xxdb_init(); */
Temos que adicionar uma linha abaixo dessa para usar o LDAPDB inicialização função:
ldapdb_ini();
E finalmente, precisamos encontrar a limpeza rotineira linha:

/* xxdb_clear(); */
Temos que adicionar uma linha abaixo dessa LDAPDB limpeza para utilizar a função:
ldapdb_clear();

Assim que esse arquivo for salvo, deveremos ser capazes de retornar diretória base do bind9 para compilarmos com suporte a nova API.

root@host#cd /root/bind-9.6.1rc1

Utilizaremos estes parâmetros de compilação:

root@host :~/bind-9.6.1rc1#SLKCFLAGS="-O2 -march=i486 -mtune=i686" \
CFLAGS="$SLKCFLAGS" ./configure –prefix=/usr –libdir=/usr/lib${LIBDIRSUFFIX}\
–sysconfdir=/etc –localstatedir=/var \
–with-libtool –mandir=/usr/man –enable-shared \
–disable-static –enable-threads –with-openssl=/usr

root@host:~/bind-9.6.1rc1# make
root@host :~/bind-9.6.1rc1# make install

2. Configurações OpenLdap

Com o servidor OpenLDAP devidamente instalado adicionaremos uma nova schema, faça o download altere seu nome:

root@host:~# http://www.venaas.no/ldap/bind-sdb/dnszone-schema.txt
root@host:~# mv dnszone-schema.txt dnszone-schema

Copie o schema para o diretório de schemas do OpenLDAP:

root@host:~# cp dnszone.schema /etc/openldap/schema

Vamos configura o arquivo slapd.conf que fica no diretório /etc/openldap:

root@host:~#vi /etc/openldap slapd.conf

Você irá adicionar este novo schema logo abaixo deste:

Ficando assim:

No final do arquivo nos índices adicionará index zoneName,relativeDomainName eq,sub, ficará assim:

index cn eq
index sn eq
index objectClass eq
index uid eq
index gidNumber eq
index uidNumber eq
index zoneName,relativeDomainName eq,sub

Uma vez que o esquema tenha sido incluído, é preciso reiniciar OpenLDAP para que o processo slapd:

root@host# /etc/rc.d/rc.openldap restart

Pronto nosso servidor OpenLDAP já está em funcionamento, vamos agora adicionar as entrada para configuração de nosso servidor. A maioria dos administradores já utiliza algum tipo de ferramenta de administração do LDAP para executar operações, como adicionar e remover as informações do banco de dados. Para este exemplo, nós iremos fornecer o que é comumente conhecido como um arquivo LDIF para usar como orientação para a inclusão de registros no banco de dados. Primeiro vamos olhar para uma norma zona normal configurada no /etc/named.conf arquivo pode ser semelhante a este:

Domínio dtux.no-ip.org no Named:

dtux.no-ip.org.zone

$ORIGIN dtux.no-ip.org.
$TTL 86400
@ IN SOA ns1.dtux.no-ip.org. root.dtux.no-ip.org. (
   2009061500 ; serial
   28800 ; refresh (8 hours)
   14400 ; retry (4 hours)
   259200 ; expire (5 weeks 6 days 16 hours)
   86400 ; minimum (1 day)
)

   A 192.168.5.10
   NS dtux.no-ip.org.
   NS ns.dtux.no-ip.org.
   NS ns2.dtux.no-ip.org.
   MX 5 dtux.no-ip.org.
mx1 IN CNAME mail.dtux.no-ip.org.
dtux IN A 192.168.5.10
ftp IN A 192.168.5.10
www IN A 192.168.5.10
ldap IN A 192.168.5.10
ns IN A 192.168.5.10
ns2 IN A 192.168.5.3
cliente IN A 192.168.5.3
mail IN A 192.168.5.3
client IN A 192.168.5.1

Zona Reversa:

5.168.192.in-addr.arpa

$ORIGIN 5.168.192.in-addr.arpa.
$TTL 78000
@ IN SOA dtux.no-ip.org. diego@dtux.no-ip.org(
   2009061500 ; versão
   10800 ;refresh (3 horas)
   3600 ;retry (1 hora)
   432006 ;expire (5 dias)
   86400 ;TTL (1 dia)
);

@ IN NS dtux.no-ip.org.
IN NS ns2.dtux.no-ip.org.
3 IN PTR 192-168-5-3.dtux.no-ip.org.
10 IN PTR 192-168-5-10.dtux.no-ip.org.

No LDIF do domínio dtux.no-ip.org do OpenLDAP ficará assim:

dn: dc=BIND,dc=dtux,dc=no-ip,dc=org
objectClass: top
objectClass: dcObject
objectClass: organization
dc: BIND
o: DTuX BIND

dn: ou=teste,dc=BIND,dc=dtux,dc=no-ip,dc=org
objectClass: top
objectClass: organizationalUnit
objectClass: dcObject
dc: BIND
ou: teste

dn: zoneName=dtux.no-ip.org,ou=teste,dc=BIND,dc=dtux,dc=no-ip,dc=org
objectClass: top
objectClass: dNSZone
relativeDomainName: dtux.no-ip.org
zoneName: dtux.no-ip.org

dn: relativeDomainName=@,zoneName=dtux.no-ip.org,ou=teste,dc=BIND,dc=dtux,dc=no-ip,dc=org
objectClass: top
objectClass: dNSZone
relativeDomainName: @
zoneName: dtux.no-ip.org
dNSTTL: 86400
dNSClass: IN
sOARecord: ns1.dtux.no-ip.org. root.dtux.no-ip.org. 2009061500 28800 14400 2 59200 86400
aRecord: 192.168.5.10
nSRecord: dtux.no-ip.org.
nSRecord: ns.dtux.no-ip.org.
nSRecord: ns2.dtux.no-ip.org.
mXRecord: 5 dtux.no-ip.org.

dn: relativeDomainName=client,zoneName=dtux.no-ip.org,ou=teste,dc=BIND,dc=dtux,dc=no-ip,dc=org
objectClass: top
objectClass: dNSZone
relativeDomainName: client
zoneName: dtux.no-ip.org
dNSTTL: 86400
dNSClass: IN
aRecord: 192.168.5.1

dn: relativeDomainName=cliente,zoneName=dtux.no-ip.org,ou=teste,dc=BIND,dc=dtux,dc=no-ip,dc=org
objectClass: top
objectClass: dNSZone
relativeDomainName: cliente
zoneName: dtux.no-ip.org
dNSTTL: 86400
dNSClass: IN
aRecord: 192.168.5.3

dn: relativeDomainName=dtux,zoneName=dtux.no-ip.org,ou=teste,dc=BIND,dc=dtux ,dc=no-ip,dc=org
objectClass: top
objectClass: dNSZone
relativeDomainName: dtux
zoneName: dtux.no-ip.org
dNSTTL: 86400
dNSClass: IN
aRecord: 192.168.5.10

dn: relativeDomainName=ftp,zoneName=dtux.no-ip.org,ou=teste,dc=BIND,dc=dtux,dc=no-ip,dc=org
objectClass: top
objectClass: dNSZone
relativeDomainName: ftp
zoneName: dtux.no-ip.org
dNSTTL: 86400
dNSClass: IN
aRecord: 192.168.5.10

dtux.no-ip.org.ldif

dn: relativeDomainName=ldap,zoneName=dtux.no-ip.org,ou=teste,dc=BIND,dc=dtux,dc=no-ip,dc=org
objectClass: top
objectClass: dNSZone
relativeDomainName: ldap
zoneName: dtux.no-ip.org
dNSTTL: 86400
dNSClass: IN
aRecord: 192.168.5.10

dn: relativeDomainName=mail,zoneName=dtux.no-ip.org,ou=teste,dc=BIND,dc=dtux,dc=no-ip,dc=org
objectClass: top
objectClass: dNSZone
relativeDomainName: mail
zoneName: dtux.no-ip.org
dNSTTL: 86400
dNSClass: IN
aRecord: 192.168.5.3

dn: relativeDomainName=mx1,zoneName=dtux.no-ip.org,ou=teste,dc=BIND,dc=dtux,dc=no-ip,dc=org
objectClass: top
objectClass: dNSZone
relativeDomainName: mx1
zoneName: dtux.no-ip.org
dNSTTL: 86400
dNSClass: IN
cNAMERecord: mail.dtux.no-ip.org.

dn: relativeDomainName=ns,zoneName=dtux.no-ip.org,ou=teste,dc=BIND,dc=dtux,dc=no-ip,dc=org
objectClass: top
objectClass: dNSZone
relativeDomainName: ns
zoneName: dtux.no-ip.org
dNSTTL: 86400
dNSClass: IN
aRecord: 192.168.5.10

dn: relativeDomainName=ns2,zoneName=dtux.no-ip.org,ou=teste,dc=BIND,dc=dtux,dc=no-ip,dc=org
objectClass: top
objectClass: dNSZone
relativeDomainName: ns2
zoneName: dtux.no-ip.org
dNSTTL: 86400
dNSClass: IN
aRecord: 192.168.5.3

dn: relativeDomainName=www,zoneName=dtux.no-ip.org,ou=teste,dc=BIND,dc=dtux,dc=no-ip,dc=org
objectClass: top
objectClass: dNSZone
relativeDomainName: www
zoneName: dtux.no-ip.org
dNSTTL: 86400
dNSClass: IN
aRecord: 192.168.5.10
Agora zona reversa:

5.168.192.in-addr.ldif

dn: zoneName=5.168.192.in-addr.arpa,ou=teste,dc=BIND,dc=dtux,dc=no-ip,dc=org
objectClass: top
objectClass: dNSZone
relativeDomainName: 5.168.192.in-addr.arpa
zoneName: 5.168.192.in-addr.arpa

dn: relativeDomainName=10,zoneName=5.168.192.in-addr.arpa,ou=teste,dc=BIND,dc=dtux,dc=no-ip,dc=org
objectClass: top
objectClass: dNSZone
relativeDomainName: 10
zoneName: 5.168.192.in-addr.arpa
dNSTTL: 78000
dNSClass: IN
pTRRecord: 192-168-5-10.dtux.no-ip.org.

dn: relativeDomainName=3,zoneName=5.168.192.in-addr.arpa,ou=teste,dc=BIND,dc=dtux,dc=no-ip,dc=org
objectClass: top
objectClass: dNSZone
relativeDomainName: 3
zoneName: 5.168.192.in-addr.arpa
dNSTTL: 78000
dNSClass: IN
pTRRecord: 192-168-5-3.dtux.no-ip.org.

dn: relativeDomainName=@,zoneName=5.168.192.in-addr.arpa,ou=teste,dc=BIND,dc=dtux,dc=no-ip,dc=org
objectClass: top
objectClass: dNSZone
relativeDomainName: @
zoneName: 5.168.192.in-addr.arpa
dNSTTL: 78000
dNSClass: IN
nSRecord: dtux.no-ip.org.
nSRecord: ns2.dtux.no-ip.org.
sOARecord: dtux.no-ip.org. diego@dtux.no-ip.org 2009061500 10800 3600 432006 86400

Adicionaremos agora os LDIFs no servidor usando os seguintes comandos:

root@host#ldapadd -x -D cn=root,dc=dtux,dc=no-ip,dc=org -W -f dtux.no-ip.org.ldif
root@host# ldapadd -x -D cn=root,dc=dtux,dc=no-ip,dc=org -W -f 5.168.192.in-addr.ldif

3. Configurando o Named(Bind)

O named.conf é onde é armazenado as configurações em texto plano onde é indicado a localização das zonas no sistema. A configuração usual é parecida como está:

#Zona dtux.no-ip.org
zone "dtux.no-ip.org." IN {
type master;
file /var/named dtux.no-ip.org.zone";
notify yes;
};

#Reverso da Zona
zone "11.168.192.in-addr.arpa" IN {
type master;
file "/var/named/11.168.192.in-addr.arpa";
notify yes;
};

Agora ao invés de guarda as zonas em arquivos irão substituí-las com a opção do banco de dados LDAP, que irá fazer uma chamada utilizando a ldapclient com nova biblioteca:

#Zona dtux.no-ip.org
zone "dtux.no-ip.org" IN {
type master;
database "ldap ldap://192.168.5.10/ou=teste,dc=BIND,dc=dtux,dc=no-ip,dc=org 10800";
notify yes;
};

#Reverso da Zona
zone "5.168.192.in-addr.arpa" IN {
type master;
database "ldap ldap://192.168.5.10/ou=teste,dc=BIND,dc=dtux,dc=no-ip,dc=org 10800";
notify yes;
};

Ao fazer pesquisas BIND irá fazer uma sub-árvore abaixo da pesquisa base no URL. O número 10800 é o TTL, que será utilizado para todas as entradas que não têm o atributo dNSTTL definido no esquema. A partir daqui, devemos iniciar bind9 e testar a nossa configuração, simplesmente realizando uma pesquisa sobre o servidor de DNS:

root@host#named -u root

Verificando os log de mensagens.

root@host#tail -f /var/log/messages

Jun 23 11:35:53 CLIENTE named[9485]: starting BIND 9.6.1rc1
Jun 23 11:35:53 CLIENTE named[9485]: built with ‘–prefix=/usr’ ‘–libdir=/usr/lib’ ‘–sysconfdir=/etc’ ‘–localstatedir=/var’ ‘–with-libtool’ ‘–mandir=/usr/man’ ‘–enable-shared’ ‘–disable-static’ ‘–enable-threads’ ‘–with-openssl=/usr’ ‘CFLAGS=-O2 -march=i486 -mtune=i686′
Jun 23 11:35:53 CLIENTE named[9485]: adjusted limit on open files from 1024 to 1048576
Jun 23 11:35:53 CLIENTE named[9485]: found 1 CPU, using 1 worker thread
Jun 23 11:35:53 CLIENTE named[9485]: using up to 4096 sockets
Jun 23 11:35:54 CLIENTE named[9485]: loading configuration from ‘/etc/named.conf’
Jun 23 11:35:54 CLIENTE named[9485]: using default UDP/IPv4 port range: [1024, 65535]
Jun 23 11:35:54 CLIENTE named[9485]: using default UDP/IPv6 port range: [1024, 65535]
Jun 23 11:35:54 CLIENTE named[9485]: listening on IPv6 interfaces, port 53
Jun 23 11:35:54 CLIENTE named[9485]: listening on IPv4 interface lo, 127.0.0.1#53
Jun 23 11:35:54 CLIENTE named[9485]: listening on IPv4 interface eth0, 192.168.5.3#53
Jun 23 11:35:54 CLIENTE named[9485]: command channel listening on 127.0.0.1#953

Testando o nosso servidor:

root@host# nslookup dtux.no-ip.org
Server: ns.dtux.no-ip.org
Address: 192.168.5.3
Name: dtux.no-ip.org
Address: 192.168.5.3

Os nomes estão funcionando adequadamente ao buscar suas informações de que a zona de dados LDAP.

Segue um exemplo de named.conf completo:

#Aqui você deve informar o endereço da sua rede ou o ip das máquinas que podem utilizar este DNS

acl minha-rede {
127.0.0.1;
192.168.5.0/24;);

options {
directory "/var/named";
dump-file "/var/log/named/named_dump.db";
statistics-file "/var/log/named/named.stats";
memstatistics-file "/var/log/named/named.memstats";

minimal-responses yes;
empty-zones-enable no;
transfer-format many-answers;
forward only;

forwarders { 192.168.5.3; 192.168.5.10; };
allow-transfer { 192.168.5.10; 192.168.5.3; 201.91.215.134;};

## Aqui você pode colocar algum DNS para realizar um forwarders caso na
##queria utilizar deixe estas linhas comentadas

version "[secured]";
listen-on-v6 { any; };
querylog yes;};
# Configuração de Log

logging {
channel custom {
severity info;
file "/var/log/named/named.log "; # Onde armazenar as mensagens
print-time yes; # Imprimir informações temporais
print-severity yes;
print-category yes; # Mostrar a categoria da mensagem
};

category config {custom;};
category notify {custom;};
category dnssec {custom;};
category general {custom;};
category security {custom;};
category xfer-in {custom;};
category xfer-out {custom;};
category lame-servers {custom;};

};

# Na seção controls encontram-se os parâmetros para comunicação entre rndc e named

controls { inet 127.0.0.1 port 953
allow { 127.0.0.1; }
keys { rndc; };
};

# A chave especificada para comunicação com o rndc, igual a contida em rndc.conf

key rndc {
algorithm hmac-md5;
secret "RgKH/lcrH7AKfyQV9QM7cQ==";
};

zone "." IN {
type hint;
file "caching-example/root.hints";
};

zone "localhost" IN {
    type master;
    file "caching-example/localhost.zone";
    allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
    type master;
    file "caching-example/named.local";
    allow-update { none; };
};

zone "dtux.no-ip.org" IN {
    type master;
    database "ldap ldap://192.168.5.10/ou=teste,dc=BIND,dc=dtux,dc=no-ip,dc=org 10800";
    notify yes;
};

zone "5.168.192.in-addr.arpa" IN {
    type master;
    database "ldap ldap://192.168.5.10/ou=teste,dc=BIND,dc=dtux,dc=no-ip,dc=org 10800";
    notify yes;
};

Segue um exemplo de rndc.conf completo:

# Use a chave rndc quando comunicar com o servidor "localhost"
server localhost { key rndc;
};

# Aqui estão os detalhes sobre a chave rndc
key rndc {
algorithm hmac-md5;
secret "RgKH/lcrH7AKfyQV9QM7cQ==";
};

# Estas são as opções padrões

options {
default-server localhost;
default-key "key";
default-port 953;
};

Segue um exemplo de slapd.conf completo:

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/dnszone.schema
include /etc/openldap/schema/dhcp.schema
include /etc/openldap/schema/ppolicy.schema
include /etc/openldap/schema/samba.schema

allow bind_v2 bind_anon_dn

pidfile /var/run/slapd.pid
argsfile /var/run/slapd.args

sizelimit unlimited

idletimeout 30

password-hash {SSHA}
password-crypt-salt-format "$1$.8s"

access to attrs=userPassword
    by self write
    by anonymous auth
    by dn="cn=root,dc=dtux,dc=no-ip,dc=org" write
    by * none

access to *
by * read

database     bdb
suffix         "dc=dtux,dc=no-ip,dc=org"
rootdn         "cn=root,dc=dtux,dc=no-ip,dc=org"
rootpw dhcpserver
directory /var/openldap-data

# Indices
index cn eq
index sn eq
index objectClass eq
index gid eq
index gidNumber eq
index uidNumber eq
index memberUid eq
index loginShell eq
index zoneName eq
index relativeDomainName eq
index dhcpHWAddress eq
index dhcpClassData eq
index dhcpPrimaryDN eq
index dhcpSecondaryDN eq

mode 0600
cachesize 2000

Tags: BIND9, DNS, OpenLDAP

BIND9 , OpenLDAP
Comments(0)

OpenLDAP – Uma abordagem integrada

Clodonil Trigo, professor do UNASP-SP e coordenador do grupo de pesquisa em Software Livre.

Archive for the 'BIND9' Category

Instalação e Configuração do Samba4

Servidor DNS (BIND9) – Integração Perfeita com o GOsa

Servidor DNS (BIND9) com OpenLDAP

Archives

Categories

Tags